Re: Trying to use timers to avoid a blocking loop
Posted: Wed Aug 13, 2014 3:57 pm
I suspect you have substantially more experience in this field than me. But it strikes me that some of your comments are more relevant to preemptive multitasking than my strictly cooperative model. With no underlying OS I'm not sure that the concept of a blocked thread is relevant. If presented with a piece of hardware which takes time to respond the options I envisage are either to write a thread which polls the device (and yields in each iteration) or to use an interrupt with a simple handler and wait on its execution. In each case other threads get a look-in. As far as I can see we're talking of embedded systems where, if you need a device driver, you write it - as with my LCD and switch classes.
I take your point regarding priority. At the moment the scheduler is designed on the KISS principle with its main loop consisting of 19 lines of code but I'll seriously consider implementing a better priority mechanism along the lines you suggested.
As for more advanced concepts like semaphores, mutexes and suchlike I have no plans to implement these as I feel they go beyond the kind of simple applications I envisage. Many of the nastier aspects of realtime programming are reduced in a cooperative enviroment. That said, Micropython's support for interrupt handlers does imply true concurrency and hence offer justification for such objects. I think, however, it might be prudent for me to leave those aspects to others with more experience.
To put the discussion into context, I'm a programmer and hardware developer who retired a decade ago and am now purely a hobbyist. But many of my projects have used simple cooperative "concurrency" to sensibly manage user I/O and hardware interfaces. My aim is to provide a small, simple solution for the micropython board. If I tried to be more ambitious here I'd probably end up with egg on my face
Regards, Pete
I take your point regarding priority. At the moment the scheduler is designed on the KISS principle with its main loop consisting of 19 lines of code but I'll seriously consider implementing a better priority mechanism along the lines you suggested.
As for more advanced concepts like semaphores, mutexes and suchlike I have no plans to implement these as I feel they go beyond the kind of simple applications I envisage. Many of the nastier aspects of realtime programming are reduced in a cooperative enviroment. That said, Micropython's support for interrupt handlers does imply true concurrency and hence offer justification for such objects. I think, however, it might be prudent for me to leave those aspects to others with more experience.
To put the discussion into context, I'm a programmer and hardware developer who retired a decade ago and am now purely a hobbyist. But many of my projects have used simple cooperative "concurrency" to sensibly manage user I/O and hardware interfaces. My aim is to provide a small, simple solution for the micropython board. If I tried to be more ambitious here I'd probably end up with egg on my face
Regards, Pete