jonnew
commented
8 years ago In general, this looks quite promising. I'm greatly looking forward to a proof of concept on your fork. Don't worry about perfection. It will be much easier to talk about this once you have some proof of concept written.
If we switch to the 32 bit MCU, we will have a lot more processing power and therefore, the optimization will become less critical.
That said: its always good to think small IMO so I really like the approach you present. The RPC portion of the code should be primarily used to modify start/stop state of a waveform generation loop, as you suggest. Perhaps we should also have some atomic flag set by the waveform generation loop that indicates whether or not the MCU is in critical section of code. For instance, timing of pulses should take precedence over RPC input unless that input is specifically meant to interrupt the waveform generator.
A remote procedure call interface for the Cyclops Led driver for integration into the open-ephys software suite .
Prelim Report :: Broadly settled on as to how to implement it and ways to further improve it.
Approach :: • Given the use of the attached microcontroller primarily serving purpouses for Signal generation / feedback, any operation [ISR/LWP] that ran concurrently with the main thread / procedure must be extremely small.
//-Possible approach 1 • queue RPC`s on the client side and later transmit to the server when the server sends a "Free"/"Ready" State Signal. Doing this improves the precision of the output signal. • In the case of a procedure having an infinite time of execution - bringing up the need for a terminate signal, a "Override"/ "accept next procedure “signal can be sent. since the serial TX is at the end of the procedure the precision of the signal is maintained. • In order to implement the same, I could either modify the Serial ISR (finite/infinite time procedure) or check the number of waiting bytes in the serial buffer after each finite loop in an infinite time procedure. • Could additionally take an execution time parameter and appropriately setup a timer interrupt / check, that returns to the parent. • all procedures can be interleaved with breakpoints where (either the termination condition / ISR Terminate flag, is checked)
Issues/ Drawbacks:: • Sending the RPC after a "Free" signal increases latency. and a very small delay in the execution of the next RPC. • Modifying the serial ISR May limit our maximum baud rate. (latency) • Maintaining the queue on the client side is a small overhead. • no way to soft reset the Arduino Micro controller in order to return to main.
ToDo:: • add parameters to the procedure call input, • modify the ISR and setup flags, • work out a neat system to introduce break points. • Write queue software for the client side
WIP code for the ^^ will be updated to https://github.com/command-paul/cyclops shortly.