Closed daveythacher closed 1 year ago
Decided against the effort on this.
There are many different external notions which could be included. The RPI could be used via Ethernet, SMP may be possible however the performance of this may be problematic.
I would only support the multicore. One core for the OS and IPC, one for the pin-pulser, one for the background thread and one for managing the cache for the background thread. This means the OS only gets to be scheduled on core 0. I would disable the GPU and this should prevent significant memory bus usage.
If you wanted to use SMP as IPC instead of Ethernet this should work. However the drawing performance could be low. Note the pin-pulser would need to use PWM hardware only. It cannot use GPIO as only the background thread can use GPIO. If you do this the bandwidth and access issues could disappear completely.
Note I may also consider doing SIMD like processing also. 18 way operations. This would change the concept of processing significantly and the memory performance of this is not known.
As neat as this is moving back to closed. Note we could also support BeagleBone Black, STM32MP1, Zynq, Series 7, Max 10, MachXO 2, STM32H7, iMX, etc.
I would prefer to avoid transmission lines and cross talk issues if possible. (There are others.)
Originally I planned to build my own panel with the control logic built into the board. I think this is likely a decent approach or a board connected directly to the back of the panels.
For custom application only. This would provide low cost alternative. Currently this is experimental. Only supports PoE display using 16x96 RGB with MBI5124 panels.