Bizarre problem on CH32V003 with SysTick ISR corrupting UART TX data

[brucehoult]

Ah, interesting. Even a favourable case is still slightly slower. But this is chasing nanoseconds now, haha.

If you want to chase another few ns...

Compile your main program code (and any library code it calls) with "-ffixed-a4 -ffixed-a5" and then don't bother saving registers in your interrupt routine at all.

[Siwastaja]

Also often the need for low latency if to do some tiny simple operation, like write one GPIO pin, then continue doing something else which is not that latency critical anymore. You can split stacking in two parts (maybe with the first part with zero registers stacked, or just one). I don't know if you can control C compiler to do this for you, so may need to use assembly for the whole ISR.

[SiliconWizard]

Also often the need for low latency if to do some tiny simple operation, like write one GPIO pin, then continue doing something else which is not that latency critical anymore. You can split stacking in two parts (maybe with the first part with zero registers stacked, or just one). I don't know if you can control C compiler to do this for you, so may need to use assembly for the whole ISR.

As we often discuss, use appropriate hardware peripherals as much as possible if you need to trigger some hardware action like a GPIO toggle with minimal latency from a condition that is supported by said hardware. Not always possible in all cases of course, but that should be the #1 approach before resorting to fiddling with interrupt latency. IMO.

May sound obvious but I still see a lot of this stuff done in ISRs when the hardware would have allowed much more efficient handling without resorting to interrupts and software handling.

[brucehoult]

I can't stop liking the ARM's idea that stacking, interrupt entry and exit are completely handled in hardware, and interrupt handlers can be any usual C functions, even if it increases latency to very small/simple interrupt handlers.

It certainly has its attractions for inexperienced programmers using unmodified toolchains.

WCH *almost* achieved that. They just forgot one thing. All would be wonderful if they had added:

• copy SP to new hidden register/CSR MISP after stacking saved registers (if not using a shadow register set) and before calling the interrupt handler.
• when RET instruction is executed then IF in_fast_interrupt and SP = MISP THEN execute MRET instead of RET

Then you could use absolutely standard C functions as interrupt handlers, just like on Cortex-M.

Ha!  I wrote a tweet to WCH suggesting this. They just PHONED me and I had a conversation with their CTO and a couple of engineers. They like the idea and will look into it to see if they can include it in future revisions of their cores. They like the idea of making things simpler for people coming from Cortex-M, and also not needing a custom toolchain. They said if I want any chips or boards just write and they'll send some for free.

[HwAoRrDk]

Compile your main program code (and any library code it calls) with "-ffixed-a4 -ffixed-a5" and then don't bother saving registers in your interrupt routine at all.

After looking at the docs for that and related options, a thought experiment: could one compile an ISR with several -fcall-used-reg options specifying that the set of 10 registers that HPE saves/restores are not to be saved/restored in code? Then you could in theory have HPE enabled and use the regular __attribute__((interrupt)) together.

[brucehoult]

Compile your main program code (and any library code it calls) with "-ffixed-a4 -ffixed-a5" and then don't bother saving registers in your interrupt routine at all.

After looking at the docs for that and related options, a thought experiment: could one compile an ISR with several -fcall-used-reg options specifying that the set of 10 registers that HPE saves/restores are not to be saved/restored in code? Then you could in theory have HPE enabled and use the regular __attribute__((interrupt)) together.

Nice idea, but sadly it doesn't seem to do anything with an __attribute__((interrupt)) function.

https://godbolt.org/z/Mrfq8GqY3

[HwAoRrDk]

Nice idea, but sadly it doesn't seem to do anything with an __attribute__((interrupt)) function.

https://godbolt.org/z/Mrfq8GqY3

Hmm, that's weird; playing with different compiler versions, it works in GCC 8.x, but not in later versions. I wonder why that is?

GCC 8.2.0:

Code: [Select]

handler:
        li      a4,1048576
        lw      a5,0(a4)
        addi    a5,a5,1
        sw      a5,0(a4)
        ret

GCC 12.2.0:

Code: [Select]

handler:
        addi    sp,sp,-16
        sw      a4,12(sp)
        sw      a5,8(sp)
        li      a4,1048576
        lw      a5,0(a4)
        addi    a5,a5,1
        sw      a5,0(a4)
        lw      a4,12(sp)
        lw      a5,8(sp)
        addi    sp,sp,16
        mret

Edit: Oh, I just noticed the 8.2 version has "ret" instead of "mret" - seems to be just ignoring the interrupt attribute completely.

[brucehoult]

8.2 is from July 2018 which would have been marginal whether __attribute__((interrupt)) got in upstream:

https://patchwork.ozlabs.org/project/gcc/patch/20180525223027.1792-1-jimw@sifive.com/