Yesterday, Xavier and I went through the STM32F207 documentation to finish preparing the code for the LED-driving processors. As we explained on Thursday, we would like to go bare-metal on this one.

Reminder of the SPI protocol

As Vlaya already explained, the LED configurations are 16-bits frames (8 address bits and 8 data bits)  send by the main board on a SPI bus. By looking at the firsts bits of the frame, the processor determines whether the following 8 bits configuration concerns it (configuration for one of its LEDs or “TOP” to turn on the LEDs) or not. 

  • If so, it retrieves the following 8 bits on the SPI bus and uses it to configure one of its LEDs or start the flash. 
  • If not, in our current configuration, it does not need to do anything.

Some of you have raised doubts about the reliability of the communication between a master and several slaves on the same SPI bus. This is why this last part will possibly be modified: as explained in this article the electrical assembly on the PCB leaves us the possibility of regenerating the SPI signal to transmit it to the following processors. As we are going to use the 3 planned SPI buses and not put all the processors on the same one, we hope not to have too many problems.

However, unlike what we originally plan and what Vlaya explained in her article, we will use a “TOP” command containing also the number of repetition needed in order to configure the repetition counter of one of the timers. In that way, we would be able to turn off the output without destroying our configurations and at the end of a PWM cycle.

The DMA idea

Our first idea was to use a DMA to store into memory all the frames which passed by the SPI bus. The CPU had to look first at the last frame copied by the DMA (so it doesn’t waste time to turn on the LEDs in case it is a top) and, for each frame copied by the DMA, analyze it to find out it is concerned if necessary, use it to configure one of its LEDs.  But the synchronization which had to be done between the DMA and the CPU so that the CPU does not analyze frames when they had not yet been updated by the DMA was a bit heavy.

Return of the IRQ

Finally, we realized we didn’t need to use a DMA and could instead send an interrupt to the processor with each new frame arrival on the SPI bus. Thus, only the useful frames are stored and each frame is naturally examined as soon as it arrives. This method is simpler and turns out to be feasible because the frequency on the SPI bus doesn’t need to be high. We have a maximum of 5 processors per SPI bus, with 8 RGB LEDs per processor. So every 1/30th of a second, each processor must receive at worst 8 * 3 * 5 + 1 (for the “TOP”) frames, therefore 1936 bits. So the frequency of the SPI bus can be as low as 60 kHz. 

On the other hand, the STM32F207 can have a core frequency as high as 168 MHz. For the moment we are tabling on having the SPI bus at 1 MHz, which would still leave at least 16 x 168 = 2688 system clock cycles for the interrupt routine to do its job before the next frame arrives. We still need to make sure the memory accesses can be fast enough. The interrupt routine as we envision it now only needs to read the SPI RX buffer data, access an array value once, and write the configuration in the timer register. We’ll try to get some hard numbers on memory latency, but hopefully, we won’t have any trouble. If you have some better ideas, don’t hesitate to let us know 🙂

We’ve ordered this development board which features an STM32F207. We should receive it sometime next week and start writing code and doing tests.

Stay tuned !

Leave a Reply

Your email address will not be published. Required fields are marked *