for exti, I dug through the codes and found this:
https://github.com/stm32duino/Arduino_C ... terrupts.h
https://github.com/stm32duino/Arduino_C ... rrupts.cpp
so I'd guess the codes may be like
Code: Select all
callback_function_t callback() {
//my ISR code here
}
void setup() {
attachInterrupt(PAxx, callback, RISING);
}
and as usual, keep the codes in your callback lean as is possible those gets in the way of interrupt handing throughput.
stm32 f4, g4 and h5 has that 'ART accelerator' on chip cache, so maybe it'd make a difference after all.
the theory goes that if your codes (maybe say ISR as well) is in the cache, ART accelerator can make that going from like 4-8 wait states to *zero* wait states, so if the bus is 250 Mhz, then 500 nsecs seemed 'extremely easy'
if this is feasible, it opens the door to a lot of things, e.g. it becomes possible to do usb full speed 12 Mhz in *software*, doing NRZI, bit stuffing, CRC, PID, clock recovery, full blown usb protocol handling everything in *software* - use case usb protocol sniffer.
this feat is deemed 'impossible' on simple mcus, traditionally deemed a USB "serial interface engine"
https://www.usb.org/sites/default/files/siewp.pdf
if one can do this whole thing in codes, it changes the game
there is 'another way', is to use Timer and DMA to read the ports, that can go quite fast into the Mhz ranges, but that this is not ISR, it is just reading data from ports verbatim.
