Hi,
Bernhard Kraft wrote:
Hi Alex,
On 2015-05-19 14:20, Alex Beregszaszi wrote:
So I sat down and wrote an Arduino implementation of that specification
just to see what the performance would be. You can find it at:
https://github.com/axic/dtiic
I already took a look at the robot-electronics.co.uk link yesterday. I
wasn't very fond of the serial protocol. It seems they implemented
some kind of timeout which determines the start and end of a message.
Quote:
http://www.robot-electronics.co.uk/htm/usb_iss_i2c_tech.htm
"A gap will result in the USB-ISS re-starting its internal command
synchronization loop and ignoring the message."
Hence my implementation uses <ESC> as ERROR character. Whenever one of
the devices PC/Arduino looses sync or notices another problem it sends
an <ESC> on to the serial line (0x1B). The <ESC> character is even
valid through data transfers. This requires a literal <ESC> character
to get escaped somehow. For this reason I introduced a quoting
character (indeed it is an escape character - maybe I should use
another character than <ESC> for signaling an error). The quoting
character (currently '\') can quote itself and the <ESC> character.
Every other combination of '\' and another character is invalid and
causes the other end to send <ESC>
(error).
Common way for escaping is to choose the least frequent character as an
escape character and if it needs to be represented as a vanilla value,
use double escaping for that. E.g. in your example <ESC> is escaping and
<ESC><ESC> represents data.
I think to create a nice and useful sketch the communication would
have to get a layer for supporting different client side (Arduino)
features (I2C, SPI, GPIO).
I know you don't like the USB-ISS (and I am not 100% happy with it
either), but that does support I2C, SPI, GPIO and UART.
Best,
Alex
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
