Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency #964

Merged
merged 2 commits into from
Mar 1, 2023
Merged

[stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency #964

merged 2 commits into from
Mar 1, 2023

Conversation

strongly-typed
Copy link
Collaborator

@strongly-typed strongly-typed commented Feb 25, 2023 •
edited

As mentioned by @chris-durand in #963

Shaves off 80ns on (slightly overclocked) STM32F107 ...

@salkinium salkinium added this to the 2023q1 milestone Feb 25, 2023
@salkinium salkinium linked an issue Feb 25, 2023 that may be closed by this pull request
[stm32] Interrupt handler indirection causes unnecessary latency #963
Closed
@strongly-typed strongly-typed changed the title [stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency #963 [stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency Feb 25, 2023
@strongly-typed strongly-typed self-assigned this Feb 25, 2023
@salkinium
Copy link
Member

Shaves off 80ns on (slightly overclocked) STM32F107 ...

How much can you overclock it before it becomes unstable? Why not use something faster, like the F7/H7? Parts shortage?

@strongly-typed
Copy link
Collaborator Author

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 setTransferCompleteIrqHandler and saw some cycles wasted there. Timings are good (enough) with the [[gnu::always_inline]].

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.

@strongly-typed
[stm32] [dma] [irq] Always inline IRQ handler to reduce IRQ latency
756b0a5
@strongly-typed
[stm32] [dma] [irq] Check for pointer first for speed
d982a85 
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.
@salkinium salkinium merged commit d982a85 into modm-io:develop Mar 1, 2023
@strongly-typed strongly-typed deleted the feature/inline_irqhandler branch March 5, 2023 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@salkinium salkinium salkinium approved these changes

@rleh rleh rleh approved these changes

@chris-durand chris-durand chris-durand approved these changes

Assignees

@strongly-typed strongly-typed

Labels
enhancement 🌈
Milestone
2023q1
Development

Successfully merging this pull request may close these issues.

[stm32] Interrupt handler indirection causes unnecessary latency
4 participants
@strongly-typed @salkinium @rleh @chris-durand