Arduino for STM32

Hi all,

I'm new to the STM32, I'm more of an 8-bit AVR guy and now I've grown up and want to play with the big boys.

My project requires a lot of I/O, so I landed on the STM32H523VE. I'm developing in the Arduino IDE, and I think I've managed to get the IDE set up, more or less. I'm not using any pre-made boards. For now, I'm talking directly to the MCU.

I need some help getting a better understanding of how to deal with certain I/O requirements, because the AVRs that I'm used to don't have support for those on the MCU, instead I'm used to having external ICs manage those, connected via SPI, I2C or parallel.

Here's what I need to talk to:

- SD-Card
- USB Keyboard (so STM32 acts as USB Host)

and my questions are:

- For SD, should I just use SPI or should I use the built-into-the-MCU SD-card support ?
- For the built-in USB, how would I go about it (library-wise and code-wise) ?

Also, unrelated to I/O: When running at full speed (250 MHz), is the interrupt overhead for a GPIO-initiated interrupt known? By that, I mean: How much time passes between the time that there's a signal transition on the pin until my interrupt-attached code starts executing? And when my interrupt-attached code finishes, how much time-overhead is there on the tail end?

Thanks !

JE

memotronics wrote: Wed Jul 02, 2025 4:28 pm ...

Also, unrelated to I/O: When running at full speed (250 MHz), is the interrupt overhead for a GPIO-initiated interrupt known? By that, I mean: How much time passes between the time that there's a signal transition on the pin until my interrupt-attached code starts executing? And when my interrupt-attached code finishes, how much time-overhead is there on the tail end?

Thanks !

JE

There is probably a fair bit of overhead in the Stm32duino and HAL code.

If you have a DSO you could toggle a spare GPIO in the interrupt routine. I have also done what I call the "out to lunch test", where I also get the mainline code to spin doing nothing other than flip another GPIO. EG as at viewtopic.php?p=2562&sid=c6ea9100e61396 ... e11a#p2562 .

I don't have a H523 to try that on though. I do have a couple of H503 boards but have not done something like that on one of those.

stm32h5 series is fairly new
the STM 'official' core (implementation) is one that supports them
https://github.com/stm32duino/Arduino_C ... 2h5-boards
https://github.com/stm32duino/Arduino_Core_STM32/wiki
https://github.com/stm32duino/Arduino_C ... ng-Started

you may need to add a variant for your board
https://github.com/stm32duino/Arduino_C ... 28board%29

there is a SD library here, but that I've not used it
https://github.com/stm32duino/STM32SD
alternatives are like SdFat, it uses SPI
https://github.com/greiman/SdFat
for now SPI is 'slow' due to DMA not being used
there are some untested SPI DMA codes here, I've not tested them and I'm not sure if it'd work.
viewtopic.php?p=15283#p15283

currently, USB is supported out of the core in *device* mode. USB host is not.
there are various usb classes supported, usb (CDC) serial (virtual comm port) is one of them.
if you need usb (CDC) serial (virtual comm port) to your serial monitor (terminal), simply select that as Serial from the (Arduino IDE) menu when you build your sketch. I think there is also hid (keyboard) device.

if you need USB host, you may need to review and use the original usb libraries from STM for Cube IDE, Cube MX , HAL etc
https://wiki.st.com/stm32mcu/wiki/Intro ... with_STM32
https://wiki.st.com/stm32mcu/wiki/Intro ... y_overview

that library is apparently bundled in the core
https://github.com/stm32duino/Arduino_C ... lewares/ST
but that you would need to figure out how to use it.

playing with SD and USB especially host is somewhat "jumping into the deep end" if you are a beginner.

if what is needed is a keyboard, there are some alternatives e.g. ps/2 keyboard
https://en.wikipedia.org/wiki/PS/2_port
https://www.aliexpress.com/w/wholesale- ... board.html
https://www.burtonsys.com/ps2_chapweske.htm
https://oe7twj.at/images/6/6a/PS2_Keyboard.pdf
https://github.com/PaulStoffregen/PS2Keyboard

it'd seem like stm32's u(s)art can handle it, but that I'm not sure and you may need to find or make a driver to handle the key scancodes
https://github.com/gandro/stm32-ps2
https://github.com/RobertoBenjami/stm32_ps2
these seemed to emulate the keyboard itself rather than the host

attaching a keyboard to stm32 playing the host is an interesting idea

but that for usb host, that needs to be implemented manually (linking the usb host library)
https://wiki.st.com/stm32mcu/wiki/Intro ... y_overview
and that the board needs to supply usb power and implement usb OTG
https://en.wikipedia.org/wiki/USB_On-The-Go

this should be a feasible option as well, just that I've not done it (yet)

I think stm32 h5xx in some sense can practically run as a full host (instead of device), e.g. as like a PC with an OS
e.g. stm32h562 can have like 640 k (sram), that is the 'grand old' number for old IBM PC XT/ATs running msdos !
and this is *much* faster
https://www.st.com/en/microcontrollers- ... eries.html

what is more interesting, is the support for Octo-SPI interface
https://www.st.com/resource/en/datashee ... h562rg.pdf
in which you can practically add SPI PS RAM possibly extending that to megabytes to even gigabytes
https://www.st.com/en/partner-products- ... psram.html
https://www.avalanche-technology.com/do ... am-memory/

for a buy-off-the shelf stm32h562 board, WeAct has one
https://github.com/WeActStudio/WeActStu ... _CoreBoard
https://www.aliexpress.com/item/1005007502799023.html
and is directly supported in the core
https://github.com/stm32duino/Arduino_C ... 2h5-boards

oh about those interrupts and hardware etc stuff
note that STM32 has verbose very detailed well written reference manuals
https://www.st.com/resource/en/referenc ... ronics.pdf
as well as review the specs documents
https://www.st.com/resource/en/datashee ... h523ce.pdf
^ there is figure 1 block diagram which is quite informative
what is quite interesting is that STM32 H5 APB (peripheral buses ) is capable of running at 250 Mhz
I'm not too sure if the GPIO itself can be clocked that fast, but I'd think that would be covered in the ref manual or spec sheets

EXTI (external interrupts) ISR normally can't run too fast, usually has some limits say like (well) below 1 mhz. code latencies etc.

one thing to learn and understand stm32 is to review the "reset and clock control" chapter 11
https://www.st.com/resource/en/referenc ... ronics.pdf
and the various chapters e.g. GPIO, EXTI etc as relevant

ag123 wrote: Thu Jul 03, 2025 7:34 am
EXTI (external interrupts) ISR normally can't run too fast, usually has some limits say like (well) below 1 mhz. code latencies etc.

I didn't see anything in the documentation that led me to believe that an ISR from an external interrupt would be much slower than a peripheral interrupt, can you explain?

I saw another thread here where someone was trying to use registers to attach to a GPIO interrupt

viewtopic.php?t=1923

He was running into some issues during compilation. Would that approach give me the fastest response between the pin-change and the entry into my ISR ?

memotronics wrote: Fri Jul 04, 2025 6:24 pm

ag123 wrote: Thu Jul 03, 2025 7:34 am
EXTI (external interrupts) ISR normally can't run too fast, usually has some limits say like (well) below 1 mhz. code latencies etc.

I didn't see anything in the documentation that led me to believe that an ISR from an external interrupt would be much slower than a peripheral interrupt, can you explain?

I saw another thread here where someone was trying to use registers to attach to a GPIO interrupt

viewtopic.php?t=1923

He was running into some issues during compilation. Would that approach give me the fastest response between the pin-change and the entry into my ISR ?

stm32 h5 are new mcus and among the features very high speed APB buses, so your mileage may vary.
if you look at a "plain old" stm32f103c8, popularly used in "blue pill" (term is actually 'invented here', well, but that's a detour')
that bus has a max of 72 mhz and 36 mhz (partly that is the cpu speed)
https://www.st.com/resource/en/datashee ... f103c8.pdf

how did I discover the speed limits of IRQ?
I've this little app
https://github.com/ag88/GirinoSTM32F103duino
(that makes the blue pill a liittle 'usb oscilloscope', well a better term is a DAQ data aquisition device)
for a 'gui' you can try this
https://github.com/Chatanga/Girinoscope

among which I made some improvements in the data aquisition by using a hardware Timer IRQ to trigger ADC sampling
https://github.com/ag88/GirinoSTM32F103duino
there are 2 ADCs in stm32f103 each of them can go to a max of 1 Msps (1 Mhz) sample rates
this is in 'continuous' mode.
However, as memory is limited (20 k sram) , using a timer to drive sampling allows for fiexible time base / sampling speeds.
i.e. you can vary the sampling speeds by varing the driving hardware timer frequency.

it turns out the timer triggered ADC sampling (the sampling is triggered in the IRQ itself) max out at 500 khz (500 k samples per sec)!
only sampling is triggered by timer using the IRQ, data transfer is DMA with the ADC
and just as above and in the specs the ADC is capable of 1 Msps in continuous mode.
https://github.com/ag88/GirinoSTM32F103 ... _adc.c#L35

the limits are likely due to a combination of various factors, e.g. the hardware limits on how fast the IRQ (with its codes) can run.
and it is worse if there are a lot of codes in the IRQ callback routine itself.
in addition, that there are many other periodic interrupts that can fire e.g. systick (1 ms), usb (every 1 ms as well) and during the ISR run, its code may disable other interrupts.

but that is stm32f103, for stm32 h5 I've not tested the same, hence yoiur mileage may vary. But that I've tested similar with stm32f401 and the result with interrupts triggered ADC sampling is similar , it is faster than stm32f103 but has limits

for a different (non IRQ) test on stm32f401 is this "sump compatible logic analyzer"
viewtopic.php?t=116
it samples raw gpio pins, the sample speeds is timer triggered/driven
accordingly it max out at 5 Msps reading gpio ports and accordingly, it is DMA driven as well, i.e. the timer triggers DMA by hardware to fetch next sample reading gpio ports
the configuration is hardware i.e. no ISR is used
ISR is used in a different way, for DMA to callback and signal that buffer is full when done.

For the interrupt, I'm planning on giving them the highest priority, to preempt other interrupts from messing me up. I only have about 500ns in my handler to read some GPIO, do some "math" and then write some GPIO, so I'd like to write that code in assembler:

void irq_handler() {
asm volatile (
"...\n"
"...\n"
"...\n"
);
}

So now the question is: How do I get the chosen interrupt vector to point directly to my irq_handler, bypassing anything HAL / arduino.

I can't even find anything that tells me if the vector table is in flash vs. ram and I couldn't find the source-code in stm32duino that shows how interrupt-attaching (the arduino-way or the HAL-way) works, any pointers would be appreciated (no pun intended).

The vector comes from an assembly .s module, which of course ends up in flash with your code and everything else. For your processor, it looks like it would be startup_stm32h523xx.s, which on my system is in . ..STMicroelectronics\hardware\stm32\2.10.1\system\Drivers\CMSIS\Device\ST\STM32H5xx\Source\Templates\gcc .

The default/dummy routines in there are defined as weak, so you can provide your own, but stm32duino may already be doing that itself, so you might have to get it to not do that using a #define. I have not done that for EXTI... interrupts, so I can't can't tell you any more than that.

500ns could be a challenge regardless.

ozcar wrote: Mon Jul 07, 2025 10:08 pm The vector comes from an assembly .s module, which of course ends up in flash with your code and everything else. For your processor, it looks like it would be startup_stm32h523xx.s, which on my system is in . ..STMicroelectronics\hardware\stm32\2.10.1\system\Drivers\CMSIS\Device\ST\STM32H5xx\Source\Templates\gcc .

The default/dummy routines in there are defined as weak, so you can provide your own, but stm32duino may already be doing that itself, so you might have to get it to not do that using a #define. I have not done that for EXTI... interrupts, so I can't can't tell you any more than that.

500ns could be a challenge regardless.

I'll give that a try. My IDE is all set up (me thinks), just waiting for the LQFP-100 test-socket.

From looking at the code in the module, I saw what you mean with the weak function. That makes me think that, at interrupt-time, my code should be called immediate (other than the STM's latency to save off registers, which I think is 12 clock cycles or roughly 50 ns at 250MHz)

That leaves me about 450ns to read a 16-bit address from port D (port D is hooked to the Z80's address bus), do some bounds checking, then (for a READ operation) fetch the data from SRAM based on that address, set the databus to output and write the fetched data to port E (which is hooked to the Z80's databus). For a write-operation, set port E to input, read the data and store it in SRAM based on the address.

Housekeeping can be left until after that work is done, because I know that there won't be another read for at least 1us. So, as far as the Z80 is concerned, my ISR could take as long as 1.5uS (but must handle the I/O stuff in the first 500ns).

That strikes me as very doable, but I guess the proof is in the pudding. Like I said, I'm a complete noob to the STM32. Don't ask me how I ended up with the H523. Maybe because it was free

I do feel the need to test this though. I was thinking of using my signal generator and feed a square wave into the IRQ pin, then have the ISR toggle an unused GPIO and put my oscilloscope on that. The frequencies should match, right? If I crank up the frequency on the square wave then I should find the "breaking point"?