I've recently read a bunch of articles explaining these weird macro soup setups for emulating coroutines in C. This one is probably the most advanced writeup in implementing fibers/coroutines I came across. The focus is on a multithreaded context, which seems to complicate things a lot. Honestly I feel like you need language level support for them in that case, they seem more trouble than they're worth otherwise, at least in plain C.
Hacking Coroutines into C
31–40 of 46 posts
Re: Hacking Coroutines into C
#32Rust can be used in an embedded environment and also offers asynchronous execution built into the language
Re: Hacking Coroutines into C
#33[dead]
Re: Hacking Coroutines into C
#34Looks overly complicated to me.
This is an alternative I wrote for my C book:
Re: Hacking Coroutines into C
#35Earlier quoted context omitted.
> there's no point in making a function that's only called in one place. There's nothing wrong with doing that if it helps make your code clearer. The compiler's optimizer will inline it when appropriate so there's no runtime overhead either.
Not only that, the compiler's optimizer might actually do a better job if you split up a big function. Because the smaller functions have less register pressure.
I'm not sure I agree and I think you should try some stuff out on godbolt first. The compiler can see where variables are no longer in use, whereas unless you turn on link time optimization (which is known for being messy so nobody seems to), you'll likely get a lot of unnecessary push/pop between the function calls.
Re: Hacking Coroutines into C
#36Of course, the project didn’t allow us to use an RTOS. That tends to just make the project eventually implement an approximation of one... as what appears to have happened here. How I'd solve the given problem is by using the PWM peripheral (or timer interrupts if no PWM peripheral exists) and pin change interrupts, with the CPU halted nearly 100% of the time. I suspect that approach is even simpler than what's shown…
You should not use interrupts for button inputs. You will just end up hammering the processor with useless interrupts when the switch bounces. Human interfaces can be polled and still maintain responsiveness. If polling isn't fast enough for machine actuated IO or you need to stay in a low power state then interrupts could be considered but you really need a non-naive solution that disables the interrupt from within the handler for a specified timeout duration.
Re: Hacking Coroutines into C
#37I would have used CPC or adapted qemu's coroutines. Coroutines in C are a very well explored field with several mature solutions.
Re: Hacking Coroutines into C
#38I’ve used libaco for coroutones in C and liked it. In my case I used it to deal with the differences betwen between eventing in libevent/libuv and feeding zlib for streaming decompression. It allowed the zlib loop to continue to look like a standard zlib loop.
Re: Hacking Coroutines into C
#39Of course, the project didn’t allow us to use an RTOS. That tends to just make the project eventually implement an approximation of one... as what appears to have happened here. How I'd solve the given problem is by using the PWM peripheral (or timer interrupts if no PWM peripheral exists) and pin change interrupts, with the CPU halted nearly 100% of the time. I suspect that approach is even simpler than what's shown…
You should not use interrupts for button inputs. You will just end up hammering the processor with useless interrupts when the switch bounces. Human interfaces can be polled and still maintain responsiveness. If polling isn't fast enough for machine actuated IO or you need to stay in a low power state then interrupts could be considered but you really need a non-naive solution that disables the interrupt from within…
I've worked on several low power projects, while yes we needed an interrupt to wake the processor, they all still used polling for all the actual button handling. At worst the interrupt just set a flag. It's actually kind of amazing how polling turns the main loop into a denounce filter, entirely for free.
Re: Hacking Coroutines into C
#40Earlier quoted context omitted.
Not only that, the compiler's optimizer might actually do a better job if you split up a big function. Because the smaller functions have less register pressure.
I'm not sure I agree and I think you should try some stuff out on godbolt first. The compiler can see where variables are no longer in use, whereas unless you turn on link time optimization (which is known for being messy so nobody seems to), you'll likely get a lot of unnecessary push/pop between the function calls.
Declare the functions static and the compiler won't export the symbols and it can do more inlining.