Today with Nathan we spent a lot of time rethinking the work distribution between the synchronizer and the led band controller. I won’t go into details because Nathan already explained it in his last post, but basically the synchronizer will have more work than expected because it will have to generate all the signals needed by the led band controller to output the right bit at the right time. Indeed since every led band has the same display pattern (the leds are all multiplexed the same way on the PCBs), the calculations can be made only once for each led band.
On my side, I drew some timing diagrams that represent the main tasks that the synchronizer will have to perform.
I haven’t represented the FPGA clock because every signal actually uses SCLK, which will be synchronized with the FPGA clock.
GCLK is not represented either, it is the clock that will only be used for PWM, is does not interfere with the other signals.
On reset the synchronizer will have to tell the led band controller to write in the Function Control register of the driver (the register used to configure the led driver, see Romain’s post for more details). There are three main steps:
- sending the FCWRTEN command to enable writing in the FC register
- writing the 48 bits in the common register
- sending the FCWRT command to write in the FC register the content of the common register
Actually, the FCWRTEN command can be sent at the same time as writing the 48 bits, but in our case it is easier to send it before so that it can serve as a signal for the led band controller to start sending the data for the FC register.
The various signals (LEDS, BIT, MULT) will be pretty simple to output since they follow a repetitive pattern: LEDS is a list of 16 indices that represent which leds on the PCB have to be displayed, MULT will successively represents which line is being displayed, it is no longer needed by the led band controller because of LEDS, but it is still needed by the transistor drivers, and BIT is here to inform the led band controller of which bit of the color it has to send.
The pattern of LAT commands pretty much follows what the driver wants in input, again see Romain’s post for more details.
I haven’t done the situation of a reset while functionning, but it basically is the same as the initialization, and every data written in the driver’s register will be forced off with a LINERESET command followed by a TMGRST command.
I now have a pretty good image of what the synchronization module should do, so I can start coding, even if there will probably be some more changes.