I’ve already evaluated what i would really need to protect my comms from 3rd parties; but i still miss the stream alike controllers on both ends to maintain the channels between the devices.

remote writing (arduino – arduino)

With the local self writing capability ready for use, i started adding some sequence based retrasmission capable stuff (i wasnt sure where i will end up with it eventually)…

After creating the prototype for a single one directional channel I was surprised that the encryption part will just fit into the playfield by adding it behind the seq handler later on.

Because the communication may became out of sync from time to time…i was planning to add something to counteract it…but while i developed the two endpoints I was forced to add it to the channel buildup phase…i’ve reserved seq#0 to be the iv sync phase…and it looked like it solves the problem (for now at least ;)

When a single page read was acceptable; i’ve prefixed all of my debug prints with a hashmark, and added a made-up protocol…R8192 means read from 8192…simple enough ;)

remote writing (desktop – arduino – arduino)

Creating the os level multiplexer / stk500 emulator was trickier than I expected…dealing with async io-s, and the stk500 emulator; while my program sometimes failed to pick-up the serial link was quite complicated ;(

But I just couldn’t slow down to fix the serial issues ;) after a few hours avrdude was happy with the provided pty interface and went thru reading the remote chip - the result was not entirely perfect; sometimes one of the serial links picks up garbage(or gets something which is out-of-place - i’m not sure)…bottom line is that it reads entire pages of junk sometime ;)

I suspect that my stk emulator is faulty…or maybe it is too slow to respond, and avrdude tries to resync..

Turned out to be neither…the emulator was not patient enough to wait for the next command ;)

Adding the page write had its issues…but nothing significant…

At the end avrdude was happy to use the virtual terminal to upload a blink program thru this whole stack of crappy software to a remote arduino.

kirk@antaeus:~/ws/arduino$ avrdude  -c arduino -p atmega328p -P serialotad/_ota1 -b 57600 -U flash:w:./dev/blink/Release/blink.hex:i
ioctl("TIOCMGET"): Invalid argument
ioctl("TIOCMGET"): Invalid argument

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./dev/blink/Release/blink.hex"
avrdude: writing flash (1066 bytes):

Writing | ################################################## | 100% 1.69s

avrdude: 1066 bytes of flash written
avrdude: verifying flash memory against ./dev/blink/Release/blink.hex:
avrdude: load data flash data from input file ./dev/blink/Release/blink.hex:
avrdude: input file ./dev/blink/Release/blink.hex contains 1066 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.84s

avrdude: verifying ...
avrdude: 1066 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)
ioctl("TIOCMGET"): Invalid argument

avrdude done.  Thank you.

Because i haven’t added the invocation of xchg to the firmware gateway program…it just loaded it into the new firmware area…I plan to add a check inside the gateway program itself; and issue xchg silently - when avrdude disconnects.

All these components i’ve created for the ota thing so far are pretty low quality…they may need restarts; the loader sometimes just hangs…and of course the code is a mess…i will need to clean up this later.