-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency #964
[stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency #964
Conversation
How much can you overclock it before it becomes unstable? Why not use something faster, like the F7/H7? Parts shortage? |
I have a (Japanese) encoder that needs a 18-bit serial protocol with 2.5 Msps over half-duplex RS485. Frames with 18 bits (1 start bit, 16 data bits, 1 stop bit, 1 to 4 frames) do not fit into U(SART), SPI, et cetera. That is why I use GPIO DMA triggered by a timer. I run a blue pill at 80 MHz to achieve 2.5 Msps (80/2.5 = 32). I already have multiple STM32G474 on my desk and will do some custom hardware asap, but I wanted to test software and constraints before building the board. I need to quickly change from TX to RX. I use the GPIO toggle works quite fine. I successfully read the encoder and can fully interpret the data. Data is protected by a CRC8 and everything works on the STM32F103 (clone?) so far. |
110010d
to
fb2867d
Compare
In case of IRQ for transferComplete is used and halfTransferComplete is not used: HT_Flag is always/mostly set when TC_Flag is set. So checking the flag first is wasting time. In case that TC_Flag is set and halfTransferComplete is used, IRQ latency stays the same with this change.
fb2867d
to
d982a85
Compare
As mentioned by @chris-durand in #963
Shaves off 80ns on (slightly overclocked) STM32F107 ...