I want to improve the modular architecture, both at the arduino end and at the python end.
In order to add different modules at the python end for things like Analog, PWM, SPI and I2C (especially to mimic other third party libraries like rpi-smbus to enable a range of existing python libraries to be used out of the box), there needs to be a way to multiplex a single link to the arduino board for multiple purposes.
The arduino firmware already has a 'character prefix' command style that can be multiplexed to different driver modules at the arduino end, so that should probably cope ok. However, at the Python end, the GPIOClient owns the serial port and won't really share it amongst different usages. This will get especially hard if different code is running indifferent threads (e.g. pwm in one thread and analog in a second), as there is a single shared link to the arduino board, and this does not share very well at the moment.
I'm going to suggest some architectural changes at the Python end that should be mostly compatible with existing code, but probably introduce a better request multiplexer with thread-safe support, and a message router for incoming rx messages (so that responses can correctly be routed to the thread/task/code that expects that response).
The ultimate aim is to allow any number of I/O capable libraries to be sat on top of this and work together. The test case is to be able to use RPi.smbus and RPi.GPIO like abstractions simultaneously underneath existing code that uses those two existing abstractions (clearly performance might tail off a bit, but it should at least logically work).
I want to improve the modular architecture, both at the arduino end and at the python end.
In order to add different modules at the python end for things like Analog, PWM, SPI and I2C (especially to mimic other third party libraries like rpi-smbus to enable a range of existing python libraries to be used out of the box), there needs to be a way to multiplex a single link to the arduino board for multiple purposes.
The arduino firmware already has a 'character prefix' command style that can be multiplexed to different driver modules at the arduino end, so that should probably cope ok. However, at the Python end, the GPIOClient owns the serial port and won't really share it amongst different usages. This will get especially hard if different code is running indifferent threads (e.g. pwm in one thread and analog in a second), as there is a single shared link to the arduino board, and this does not share very well at the moment.
I'm going to suggest some architectural changes at the Python end that should be mostly compatible with existing code, but probably introduce a better request multiplexer with thread-safe support, and a message router for incoming rx messages (so that responses can correctly be routed to the thread/task/code that expects that response).
The ultimate aim is to allow any number of I/O capable libraries to be sat on top of this and work together. The test case is to be able to use RPi.smbus and RPi.GPIO like abstractions simultaneously underneath existing code that uses those two existing abstractions (clearly performance might tail off a bit, but it should at least logically work).