You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, only DMX output is implemented. However, DMX input is highly desirable (so we can build an active DMX splitter, or receive DMX data from a console on an input port and forward that data to a PC or via wireless) and is also a requirement for RDM.
DMX input on the rp2040 has been implemented at https://github.com/jostlowe/Pico-DMX and I've verified it working (after some changes that have been merged in the meantime).
However, with the current "big locks" (which disable all interrupts as well) in the code, incoming DMX frames could be lost (if the end of an incoming DMX frame happens while the CPU is busy generating data for the next frames to be sent).
So besides changing the patching infrastructure and properly assigning the PIOs, SMs and GPIOs properly, the locking and interrupt disabling code needs to be re-worked.
Proposal: Split up the current "big lock"/spinlock to several smaller ones and think hard, when to disable interrupts and when not. Caution: Deadlocks can appear when code owning a mutex is interrupted by a service handler that also wants the same mutex that is locked by the interrupted code.
Also, the incoming data should NOT be immediately processed in the ISR. It should be appended to some kind of queue and be handled in the main loop.
Currently, only DMX output is implemented. However, DMX input is highly desirable (so we can build an active DMX splitter, or receive DMX data from a console on an input port and forward that data to a PC or via wireless) and is also a requirement for RDM.
DMX input on the rp2040 has been implemented at https://github.com/jostlowe/Pico-DMX and I've verified it working (after some changes that have been merged in the meantime).
However, with the current "big locks" (which disable all interrupts as well) in the code, incoming DMX frames could be lost (if the end of an incoming DMX frame happens while the CPU is busy generating data for the next frames to be sent).
So besides changing the patching infrastructure and properly assigning the PIOs, SMs and GPIOs properly, the locking and interrupt disabling code needs to be re-worked.
Proposal: Split up the current "big lock"/spinlock to several smaller ones and think hard, when to disable interrupts and when not. Caution: Deadlocks can appear when code owning a mutex is interrupted by a service handler that also wants the same mutex that is locked by the interrupted code.
Also, the incoming data should NOT be immediately processed in the ISR. It should be appended to some kind of queue and be handled in the main loop.
Work in progress is here: main...kripton:dmxIn
The text was updated successfully, but these errors were encountered: