search

katbinaris / NanoD_RatchetH1

FW for Ratchet / NanoD++
6 stars 4 forks source link

Finalize data structures and define their access rules #3

Open runger1101001 opened 9 months ago

runger1101001 commented 9 months ago

Define the different parts of the firmware state, and who owns them:

Perhaps I would keep things simple by defining the access rule that only the owning thread may write to the data structures it owns.

I'm of course most especially interested in the parts that are involved in the serial communication...

katbinaris commented 9 months ago

SimpleFOC, Motor Settings, Active Haptic program - owned by for_thread LED (FastLED), Keys (AceButton), Sound (I2S library) - owned by hmi_thread MIDI and Communication - com_thread. Display Driver - lcd_thread

Alternatively I was considering have separate LED task as a lot of led related feedback bases on delay, unless non-interrupting timer can be used for this? Happy to articulate and hear you out.

For AceButton also there is need to run loop for checking button press state (eg. key up, key down, pressed, clicked, long press etc.)

Sound, LCD and LED need read only, they don't send any feedback.

FOC thread receives config and send current position integer. Keys receive mapping from config and send press state Midi receive mapping and send message but only over hardware Out (UART)

runger1101001 commented 9 months ago

MIDI and Communication - com_thread.

My comments on this: why not make MIDI its own thread?

The comms could certainly go in its own thread. But your haptic loop as it is in the code is spending 1500us (!) just waiting. That's plenty of time to do the comms during that wait. The big advantage of handling the comms in the haptic/motor thread is that it can directly set all the values without having to pass them via queues/use semaphores or other synchronisation constructs.

Sound, LCD and LED need read only, they don't send any feedback.

From my point of view that is "write only" but I get you.

katbinaris commented 9 months ago

With 1500us waiting are you referring to the delayMicroseconds(1500); in the haptic_loop() correct? If that gap can be utilised to perform communication, that's great. Ultimately this value could be tuned between 750-1500us but best response is between 1000-1500.

katbinaris commented 5 months ago

I think this issue is no longer present can this be closed?