Hacking Coroutines into C
wiomoc.de
Hacking Coroutines into C
1–10 of 46 posts
Re: Hacking Coroutines into C
#2FreeRTOS can also be used with a cooperative scheduler: https://www.freertos.org/Why-FreeRTOS/Features-and-demos/RAM...
That said, if I was stuck rolling this myself, I think I’d prefer to try to do it with “real” codegen than macros. If nothing else it would give the ability to do things like blocks and correctness checks, and you’d get much more readable resulting source when it came to stepping through it with a debugger.
Re: Hacking Coroutines into C
#3The intent here is nice. I historically hate state machines for sequential executioners. To me they make sense in FPGA/ASIC/circuits. In software, they just get so complicated. I've even seen state managers managing an abstracted state machine implementing a custom device to do what's ultimately very sequential work.
It's my same argument that there should be no maximum number of lines to a function. Sometimes, you just need to do a lot of work. I comment the code blocks, maybe with steps/parts, but there's no point in making a function that's only called in one place.
But anything is better than one person I met who somehow was programming without knowing how to define their own functions. Gross
Re: Hacking Coroutines into C
#4As the article acknowledges at the end, this is sort of like protothreads which has been around for ages. The article's CSS was so awful that I didn't read anything except the last paragraph, which seemed to tell me what I wanted to know.
Re: Hacking Coroutines into C
#5As the article acknowledges at the end, this is sort of like protothreads which has been around for ages. The article's CSS was so awful that I didn't read anything except the last paragraph, which seemed to tell me what I wanted to know.
Right, this is more or less this blog author’s riff on (PuTTY author) Simon Tatham’s old page on coroutines using switch[1], which itself indicates that Tom Duff thought of this (which makes sense, it’s only a half-step away from Duff’s device) and described it as “revolting”. So in this sense the idea predates the standardization of C.
[1] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Re: Hacking Coroutines into C
#6The intent here is nice. I historically hate state machines for sequential executioners. To me they make sense in FPGA/ASIC/circuits. In software, they just get so complicated. I've even seen state managers managing an abstracted state machine implementing a custom device to do what's ultimately very sequential work. It's my same argument that there should be no maximum number of lines to a function. Sometimes, you j…
I actually write a lot of Go in state machine like patterns. My state types files would make you think im schizophrenic. I just finished up a project this week that was 10k lines of comments in 18k loc. Noone else has to read it tho, they actually probably appreciate it if they did.
Re: Hacking Coroutines into C
#7As the article acknowledges at the end, this is sort of like protothreads which has been around for ages. The article's CSS was so awful that I didn't read anything except the last paragraph, which seemed to tell me what I wanted to know.
> The article's CSS was so awful
Small text sizes? What is the problem for you?
Re: Hacking Coroutines into C
#8As the article acknowledges at the end, this is sort of like protothreads which has been around for ages. The article's CSS was so awful that I didn't read anything except the last paragraph, which seemed to tell me what I wanted to know.
> The article's CSS was so awful Small text sizes? What is the problem for you?
Whilst I wouldn't call it "awful", the spacing between the lines isn't helping any.
Re: Hacking Coroutines into C
#9The intent here is nice. I historically hate state machines for sequential executioners. To me they make sense in FPGA/ASIC/circuits. In software, they just get so complicated. I've even seen state managers managing an abstracted state machine implementing a custom device to do what's ultimately very sequential work. It's my same argument that there should be no maximum number of lines to a function. Sometimes, you j…
> 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.
Re: Hacking Coroutines into C
#10Of 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 here.