CH32V003 does not exit while loop?

[brucehoult]

You can't use a lock in an ISR so you need to ensure that your platform supports lock free atomics for the types you need.

ISRs are inherently locked against code running on the same CPU core. The problem there is that the lock might be already held by some normal application code, and then you've painted yourself into a corner.

If you think you need a lock in an ISR then that's a sign you're doing too much work in the ISR. You need to stash your data somewhere private and signal some non-ISR code to handle it and then return from the interrupt pronto -- that might be unblocking a thread, or it might be a global variable the main program polls.

[ejeffrey]

If you think you need a lock in an ISR then that's a sign you're doing too much work in the ISR.

My point was just that if you use C11 atomics in an ISR to communicate back to the main code you could end up with something that actually locks a mutex which will 99% of the time work but then deadlock of the ISR fires while the lock is held.

The object size where this happens on any given platform is likely to be the same threshold where volatile variables stop being effectively atomic, so it's really pick your poison: deadlock or tearing.  But it's part of why you can't just go blindly replace volatile variables with atomics.

[mikeselectricstuff]

Volatile requirements around peripheral interaction, and interrupt handlers  are always new traps for new embedded programmers.

A reason that new embedded programmers may be unaware of the volatile keyword is that although it applies to most peripheral registers, they will usually never see it used, as it's buried, often multiple files deep, in the manufacturers' supplied header files.

[SiliconWizard]

Volatile requirements around peripheral interaction, and interrupt handlers  are always new traps for new embedded programmers.

A reason that new embedded programmers may be unaware of the volatile keyword is that although it applies to most peripheral registers, they will usually never see it used, as it's buried, often multiple files deep, in the manufacturers' supplied header files.

And the root reason, as I have often said, is that C is not taught/not learned properly anywhere, in a majority of cases. That's a major issue.

[glenenglish]

and "not being taught C properly" is an excellent point.
I imagine many do C++ in school then try to write embedded C... without the low level knowledge.

I always feel my first 10 years in microcontroller/microprocessor programming being in 100% assembler with Rodney Zaks' book in hand, prepared me better than  say, learning c++ writing programs on a PC then making C work on a embedded platform, and then learning assembler when they get short of cycles or need to write vector intrinsics.

[SiliconWizard]

Yeah, from my experience, looks like most embedded C developers out there had learn some at uni, but really just the basics and not "learned" it as a programming language, as it should be. Then they just discover things as they go, in the professional world. Some will learn along the way, many will just apply some "recipes" and go on like this for years.

One key reason is that C looks so simple that everyone assumes it's like the BASIC of current programming languages and doesn't need any real learning.

Even if I don't buy it for a number of reasons that don't belong in this thread, I think that's one thing for which much more complex languages like Rust do better, regardless of their own technical merits: they just are too complex to be used without learning them. So, you're forced to learn, and that's a good thing.

Languages that seem simple enough almost not to need learning are, in the end, a plague. The idea looks all nice - like, make programming more accessible to everyone - but the reality is harsh. They just promote bad habits, quick recipes and cargo cult programming. Just my opinion.

[westfw]

when you have a complex expression accessing a volatile variable, the number of load/store will explode.

Doesn't have to be "complex."  Check out this (very old: v0012) implementation of the Timer0 ISR for Arduino:

Code: [Select]

volatile unsigned long timer0_clock_cycles = 0;
volatile unsigned long timer0_millis = 0;

SIGNAL(SIG_OVERFLOW0)
{
    // timer 0 prescale factor is 64 and the timer overflows at 256
    timer0_clock_cycles += 64UL * 256UL;
    while (timer0_clock_cycles > clockCyclesPerMicrosecond() * 1000UL) {
        timer0_clock_cycles -= clockCyclesPerMicrosecond() * 1000UL;
        timer0_millis++;
    }
}How many loads  of timer0_clock_cycles does that do?  (Each one being 4 slow, long instructions, on an AVR!)