I've looked through most of the FreeRTOS documentation, and it is pretty light. Most of the remaining features of FreeRTOS that pyRTOS either can already be achieved easily using Python built-ins or cannot be achieved at all in CircuitPython, due to lack of support for interrupts and parallelism. Python is an incredibly powerful language, that quite frankly already covers much of the peripheral functionality found in FreeRTOS. In fact, some pyRTOS functionality might be redundant, and should perhaps be removed in the next major version.
There are a few places where there is potential for improvement. These are task blocking conditions, documentation, sample code, and synchronization/mutual exclusion.
Task blocking for I2C and SPI isn't going work. Adafruit's libraries don't seem to provide any way to check if an I2C or SPI
command has been fully sent. Further, most I2C and SPI communication is abstracted at least one additional level, with device driver libraries that also provide no way to tell if a command has finished sending. This is probably not terribly important though, because I2C and SPI are pretty fast, and if you are using Python, you probably don't care about performance at this resolution. There are other places where task blocking is valuable. Many are device or application dependent and thus should be implemented by the user, but if there are general cases with broad application, I would be happy to add them. To be clear, I don't have any right now, so this won't be going on the roadmap. Please open an issue if you have a general blocking condition that you feel should be part of the OS, but note that anything highly dependent on device or application will not be considered.
There is significant potential for improvement in the documentation. Some places could benefit from suggested use cases for elements, and there is a ton of room for example code. Also, it would probably also be good to add a section explaining how to use Python built-ins to achieve functionality normally provided by the RTOS, especially if existing functionality is going to be removed in favor of using built-ins.
We need more sample code. The one piece of official sample code is little more than a start. It has no practical value. The one upside it has is that it runs in Python 3 on normal personal computers, which makes it good for testing during development. We need a bit more generic Python 3 sample code, for more comprehensive testing. We also need a selection of sample code designed for Adafruit devices using CircuitPython. Currently, all we have is a sample program for the Rotary Trinkey, which merely changes LED colors, based on two touch inputs (one of which is a through hole pad for a rotary encoder). We can do better. I've got NeoKey Trinkeys and Neo Trinkeys, as well as a Trinkey QT2040. These are all valid targets for pyRTOS, so maybe a selection of a few programs for each would provide a solid suite of sample programs.
Lastly, I haven't completed implementing all of the mutual exclusion devices found in FreeRTOS. Specifically, I have no implemented Counting Semaphores or Recursive Mutexes. I am not sure Recursive Mutexes are sufficiently valuable to be worth adding, but I'll look into applications for them and add them if I feel they are worth the cost in space and memory. It might also be worth adding Reader/Writer locks. I've implemented them before using Python's built in semaphores, and if they are sufficiently cheap, it might be worth adding them.
Also, Python has built-in mutual exclusion devices. I'm not sure if CircuitPython includes these, however if it does, it might be a good idea to replace the current pyRTOS mechanics with Python's built-in mechanics, wrapped to provide blocking conditions.
So here is the current roadmap:
[ ] Add Counting Sempahores and maybe Recursive Mutexes*
[ ] Look into adding Reader/Writer Locks*
[ ] Improve documentation with example use cases, example code, and a section on Python built-ins
[ ] Write more sample programs (which can also be used for testing)
[ ] Look for elements of pyRTOS that are redundant due to Python built-in elements, and remove them (pyRTOS 2.0)
(* Possibly using Python built-in mutual exclusion devices and changing existing pyRTOS mutual exclusion to use Python built-ins.)
I don't have any sort of time schedule for this. pyRTOS 1.0 is already pretty solid. Hopefully I can get all of this done in around a month, but I make no promises. If you would like to accelerate this process, consider donating, DONATIONS.md.
I've looked through most of the FreeRTOS documentation, and it is pretty light. Most of the remaining features of FreeRTOS that pyRTOS either can already be achieved easily using Python built-ins or cannot be achieved at all in CircuitPython, due to lack of support for interrupts and parallelism. Python is an incredibly powerful language, that quite frankly already covers much of the peripheral functionality found in FreeRTOS. In fact, some pyRTOS functionality might be redundant, and should perhaps be removed in the next major version.
There are a few places where there is potential for improvement. These are task blocking conditions, documentation, sample code, and synchronization/mutual exclusion.
Task blocking for I2C and SPI isn't going work. Adafruit's libraries don't seem to provide any way to check if an I2C or SPI command has been fully sent. Further, most I2C and SPI communication is abstracted at least one additional level, with device driver libraries that also provide no way to tell if a command has finished sending. This is probably not terribly important though, because I2C and SPI are pretty fast, and if you are using Python, you probably don't care about performance at this resolution. There are other places where task blocking is valuable. Many are device or application dependent and thus should be implemented by the user, but if there are general cases with broad application, I would be happy to add them. To be clear, I don't have any right now, so this won't be going on the roadmap. Please open an issue if you have a general blocking condition that you feel should be part of the OS, but note that anything highly dependent on device or application will not be considered.
There is significant potential for improvement in the documentation. Some places could benefit from suggested use cases for elements, and there is a ton of room for example code. Also, it would probably also be good to add a section explaining how to use Python built-ins to achieve functionality normally provided by the RTOS, especially if existing functionality is going to be removed in favor of using built-ins.
We need more sample code. The one piece of official sample code is little more than a start. It has no practical value. The one upside it has is that it runs in Python 3 on normal personal computers, which makes it good for testing during development. We need a bit more generic Python 3 sample code, for more comprehensive testing. We also need a selection of sample code designed for Adafruit devices using CircuitPython. Currently, all we have is a sample program for the Rotary Trinkey, which merely changes LED colors, based on two touch inputs (one of which is a through hole pad for a rotary encoder). We can do better. I've got NeoKey Trinkeys and Neo Trinkeys, as well as a Trinkey QT2040. These are all valid targets for pyRTOS, so maybe a selection of a few programs for each would provide a solid suite of sample programs.
Lastly, I haven't completed implementing all of the mutual exclusion devices found in FreeRTOS. Specifically, I have no implemented Counting Semaphores or Recursive Mutexes. I am not sure Recursive Mutexes are sufficiently valuable to be worth adding, but I'll look into applications for them and add them if I feel they are worth the cost in space and memory. It might also be worth adding Reader/Writer locks. I've implemented them before using Python's built in semaphores, and if they are sufficiently cheap, it might be worth adding them.
Also, Python has built-in mutual exclusion devices. I'm not sure if CircuitPython includes these, however if it does, it might be a good idea to replace the current pyRTOS mechanics with Python's built-in mechanics, wrapped to provide blocking conditions.
So here is the current roadmap:
(* Possibly using Python built-in mutual exclusion devices and changing existing pyRTOS mutual exclusion to use Python built-ins.)
I don't have any sort of time schedule for this. pyRTOS 1.0 is already pretty solid. Hopefully I can get all of this done in around a month, but I make no promises. If you would like to accelerate this process, consider donating, DONATIONS.md.