Will my H743 chip handle 2 x 24 MHz, driven by 2 x SDI?

[MEwen.1]

I have a Nucleo H743ZI2. 

I have been reading "Mastering STM32" by Carmine Noviello, and on page 188 (last paragraph) he says that the maximum IO toggle rate is 10 MHz on the STM32F446. He gives oscilloscope traces, but I can't see the frequency, because there is only a single pulse shown. I need 24 MHz on each of two serial channels, each driven from an SPI to illuminate an LED strip. Will I be able to get 24 MHx on my H743? If not, could I drive four LED strips at half the speed (12 MHz) each, using four SPIs? I also need an SPI for an SD card.

[TDK]

The SPI on the STM32H743 can support up to 150MHz speed. Should have no problem using 2 at 24MHz each.

The max SPI on the STM32F446 is up to 45 MHz.

The datasheets have the best info on the max peripheral speeds for each particular chip.

[Tesla DeLorean]

The F4 can toggle GPIO faster than 10 MHz, and the pin drivers should be able to clock at 90 MHz

Driven via TIM should be able to hit that.

One can also drive across all/any 16 GPIO pin​ via TIM/DMA, should be at least 45 MHz

The SPI/SAI​

[MEwen.1]

Thanks very much for those answers. I was wondering if I should give up the attempt to develop my project, but you have renewed my faith in the chip.

I'm not presenting this as an argument (I accept what you say), but for reference, he says this ...

---Begin----------

What about the effective switching frequency? ST claims in its datasheets that the fastest toggle speed of an output pin is every two clock cycles. The AHB1 bus, where the GPIO peripheral is connected, runs at 42MHz for an STM32F446 MCU. So a pin should toggle in about 20MHz. However, we have to add an additional overhead related to the memory transfer between the GPIO->ODR register and the value we are going to store inside it (0x110), which costs another CPU cycle. So the expected GPIO maximum switching speed is ∼14MHz. The oscilloscope confirms this, as shown in Figure 9

 [Sorry - the image doesn't paste in]

figure 9

---End------------

[berendi]

STM32F446 is capable of 180 MHz core and AHB clocks. Where does this 42 MHz come from?

Under very limited and idealized conditions, the CPU could perhaps write alternating values every other cycle to the GPIO register, thus achieving 90 MBits/pin for short bursts.

AFAIK, using DMA (running on AHB clock as well) to transfer a sequence of halfwords to GPIO requires 4 cycles to transfer a value, resulting in 45 M samples/sec. Using DMA at that speed would block pretty much everything else on the system.

SPI1 runs on the 90 MHz APB2 bus, it is capable of 45 MBits/s, sustained with the help of DMA transmitting 16 bits at once to the DMA data register.

SPI2 and SPI3 of the STM32F446 are on the slower 45 MHz APB1 bus, so they are capable of 22.5 MBits.

The STM32H743 is much faster and more flexible than that.

SPI peripherals can be clocked by separate PLL outputs, capable of sustaining 150 MBits/s data rate. All 6 of them.

[MEwen.1]

@berendi​ 

Ah! I must explain that on the ARM learning path, I'm not even in the foothills yet - more like still in the camp at the bottom of the mountain.

Maybe I should tell you something about what I'm trying to do, and you'll have a better idea what advice to offer. It's all valuable!

I came from AVR Assembler, so I have some notions of uC operations, but this is my first ARM project - something to get started with - and I'm not finding it easy so far. I find that learning is greatly assisted by having a project in mind, and mine is to make a POV (Persistence of Vision) Earth globe. It spins a semicircle of LEDs to produce what appears to be a solid globe (examples on YouTube). There is a strip of 106 RGB LEDs for the Northern hemisphere, and 105 for the Southern, so two strips. They are fed by SPI, and for the number of LEDs and the speed of spinning (15 RPS = 900 RPM), and the fact that each LED takes 32 bits, my calculated data rate is 24 MHz for each strip. I had envisaged using DMA, but I had thought 32-bit DMA would be preferable, as the LEDs take 32 bits (8:Red, 8:Green, 8:Blue, 8:intensity). 16-bit DMA is also doable, of course, but I thought the lower DMA rate on a wider word would be better for the chip. DMA bursts will not be short - they will be continuous. The image size is 92840 pixels, each requiring 32 bits, which gives 371360 bytes - which is why I chose a chip with a large memory.

It's OK if there's not much power left over after the DMA, because most of the time, that's all it will be doing, though it will also need a bit of headroom to monitor the rotation rate (one pulse per rotation) and set the motor speed (3-phase BLDC motor). I may drive the phases, or I may opt to use a commercially produced ESC (Electronic Speed Control) which only needs a 50Hz PWM signal. Would you expect the chip to get hot?

The globe image will show the earth. I mentioned using a separate SDI for an SD card, but that is only to refresh the globe image to show slow-moving stuff like continental drift, so update of the image can take several seconds - though I would like my continental drift to be a little faster than reality! The globe will show a day side and a night side, and the night side will have only city lights and a lot of black - but it still needs 32 bits/pixel (mostly zeroes). It will have a time-of-day clock to set the day/night line, which will also move.

Thanks for your advice, and for your time.

[berendi]

OK, the bottom line is that SPI+DMA can handle that without effort as long as there are enough SPI ports capable of 24 MBit/s, on any STM32 MCU that has enough memory to hold the whole picture.

(The STM32H7 could do it bit-banging on two full GPIO ports i.e. 32 pins in parallel, maybe more, but let's not get distracted by that.)

> I'm not even in the foothills yet 

It's a dome-shaped mountain. Get prepared for a vertical climb at the beginning, it will become easier later.

> this is my first ARM project - something to get started with - and I'm not finding it easy so far

The examples provided by ST don't make it easy for beginners. They are rather circling around the foothills, hiding important details instead of showing them. Starting with a badly designed interface, it goes to worse when you look at the implementation.

Getting the basics sorted out, replacing their bad excuse for drivers with your code for basic stuff is the vertical part. Get a basic blinky going, then replace every function call with register accesses. Repeat the exercise with a PWM signal. IMO the best way to learn how to do stuff on STM32 is to follow the step-by-step pseudocode instructions in the functional description chapters of the reference manual.

> lower DMA rate on a wider word would be better for the chip

The SPI controllers on the STM32H7 can take 32 bits at once, so the DMA has more than one μs to transfer each word. The SPI regulates the data flow, i.e. it requests the next burst if the FIFO level falls below a programmable threshold. The impact on system performance would be barely noticeable even at that speed.

> I may drive the phases, or I may opt to use a commercially produced ESC (Electronic Speed Control) which only needs a 50Hz PWM signal.

The various timers should be able to generate all control signals with little software intervention.

> Would you expect the chip to get hot?

It might get somewhat warm at full speed, but shouldn't need any extra cooling. You can clock it down to 1/10 of its rated speed for reduced consumption if heat would become a concern, it will still be able to do all the stuff just fine. The STM32H743 is like a sledgehammer to crack this nut with.

> I mentioned using a separate SDI for an SD card

There is a dedicated 4-wire SD/MMC interface, but of course you can use SPI if you already have some experience with that.

You can also read data from a flash drive through the onboard port and a smartphone adapter cable.

[MEwen.1]

Thanks again, Berendi. That really gives me encouragement. I'm not working with anybody - I'm learning on my own, so it's comforting to know that other people have found it a steep hill to climb. I especially liked what you said about "replacing every function call with register accesses. Repeat the exercise with a PWM signal [... using] the reference manual". I've written many thousands of C lines, but for a reason I can't really explain, I wanted to do my AVR projects in Assembler - and that was hard-won knowledge too - but I liked it, and will probably make more sense of using registers on the ARM, and getting close to the hardware.

I don't want to build the "globe" hardware yet, so I'm writing a spin emulator on an ATTiny85 - to give a pulse every 66667 uS, to emulate 900 RPM.

About the sledge hammer approach, that was my early impression too, but I initially chose an STM32H750 because it has enough memory to hold my image, and more than enough program memory for my little application. Then I moved my ambitions to the H743 because there was a Nucleo card available for it. I only came here to ask about it because a book called "Mastering STM32" said that the toggle rate on a pin wouldn't exceed 10 MHz.

So - I'll go off and do what you suggested. If I don't ask another question within six months, call Mountain Rescue!

[MEwen.1]

Berendi, there's one other query I have. I'm nowhere near working on the code to do it yet, but as the data I read off the SD card will have been written to it with a Windows PC, it will have a file system. Will I need to use the RTOS? I presume so, but I'd appreciate your say-so.

[berendi]

The limits in that book reflect the limits of the author's knowledge :)