41–46 of 46 posts
As 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?
Of 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…
A similar approach, but rooted in the idea of synchronous languages like Esterel or Blech: https://github.com/frameworklabs/proto_activities
Seriously though, neat library! It took me a moment to realize that everything with a pa_ prefix is a macro, for the dumb reason of being used to only see those in ALL_CAPS. Not saying you can't use lower-case macros but I think a short sentence mentioning it before the demo code, and with a "see the protothread under the hood page[1] for an explanation of how it generally works" would help a lot with demystifying the code for people unfamiliar with the concepts involved.
Cooperative multithreading via setjmp and longjmp has been around in C since the 80s at least. I’m not sure this is so much hacking as an accepted technique from the old-old days which has somewhat fallen out of favour, especially as C is falling a little outside of the mainstream these days. Perhaps it’s almost becoming lost knowledge :)
This isn't using setjmp/longjmp It's using Simon Tatham's method based on Duff's device ( https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html )
https://jsbenchit.org/?src=1b165435c816c6d298e6b800b4742568
https://jsbenchit.org/?src=dedb07499cfa289b94d686bde05901df
Context: JS has an iteration protocol[0] that lets you create your own custom objects to be used with syntactic sugar for iteration. The sensible expectation is that the built-in syntax for generating such functions would produce the fastest code. It clearly doesn't.
Having said that I do not recommend manually writing code this way because if this is something that you need to worry about while writing JavaScript, it's a sign that you're using the wrong tool for the job anyway.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Cooperative multithreading via setjmp and longjmp has been around in C since the 80s at least. I’m not sure this is so much hacking as an accepted technique from the old-old days which has somewhat fallen out of favour, especially as C is falling a little outside of the mainstream these days. Perhaps it’s almost becoming lost knowledge :)
This isn't using setjmp/longjmp It's using Simon Tatham's method based on Duff's device ( https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html )
Also, by the time you're passing a coroutine context around anyway, you could refactor (say) the decompressor around a decompression context and the code would stay nice...
It's definitely interesting though, and it's been a few years since I read that coroutines page.