Exode is a library for communication between Arduino microcontroller boards and a connected computer.
It's designed to be really simple to use, here an example :
from Exode import *
uno = Board('/dev/tty.usb-3')
led = Led(13)
led.blink(500)
Once your Arduino connected to your device (computer, Rasberry Pi, smartphone ..) using a serial IO (usb/bluetooth), you're now allowed to have remote interactions with your board. And then :
You're not constrain to compile your source after each modifications
You can let your computer process the most complex tasks
Interesting work, and thanks for sharing it with the world. It's nice to see it's documented, too!
I released a similar communication library (from C#) just today - ArduinoLibCSharp so it's quite interesting to see the differences in overall approach and design decisions.
Could you elaborate on the reason for "protothreading" the core? Is it just for scheduling purposes e.g. for PeriodicSwitch?
One possible improvement would be to allow the serial protocol to operate at a speed higher than 9600 bps (since e.g. it reduces the number of readings you can achieve per second in tight loops).
I found that in order to bump the speed, the serial protocol must really be designed with synchronization and error detection in mind (since loss does definitely occur at higher speeds).
I have looked your project on github and I really appreciate the possibility to upload the C# code directly on the board.
To answer your actual question about prothreading, yes is mainly for scheduling purposes. I use this to read my inputs periodically (event-driven programming). At the beginning of my project, the "arduinoListener" was very similar to yours, with a big switch case on the loop. Due to the scheduling on the board, I reduce the necessary to use the serial connection, too.
About the serial speed, today I don't really need a speed higher than 9600 bps, 9600bps it's a good compromise. It's also stable.
Also, at my beginning I was using an error detection, I removed it because USB provides error detection and retry natively.
sn33ks:
I have looked your project on github and I really appreciate the possibility to upload the C# code directly on the board.
That would be super awesome (upload C# code to be transformed and executed directly on the board) but that's not what the uploader in my project does. The uploader (which itself is pure C#) is able to upload a compiled hex file directly on the board (e.g. much like avrdude, but without simply wrapping avrdude - like many other uploaders do).
sn33ks:
About the serial speed, today I don't really need a speed higher than 9600 bps, 9600bps it's a good compromise. It's also stable. Also, at my beginning I was using an error detection, I removed it because USB provides error detection and retry natively.
USB provides error detection and retry natively but that's only for the connection between the USB chip and the PC. You can still have packet loss etc. on the connection to the Arduino (typically when operating at higher speeds) so some system of framing / synchronization and error detection is still required for higher baud rates (in my experience).
spcrngr:
USB provides error detection and retry natively but that's only for the connection between the USB chip and the PC. You can still have packet loss etc. on the connection to the Arduino (typically when operating at higher speeds) so some system of framing / synchronization and error detection is still required for higher baud rates (in my experience).
Ok ! thanks for it, I never met these problems because I always use a 9600bps baud rate I may well need to integrate error detection/ synchronization if i use a higher baud rate.
