By: Alfman
In reply to <a href="https://www.osnews.com/story/140153/moving-to-an-rtos-on-the-rp2040/#comment-10441437">gdjacobs</a>.
gdjacobs,
<blockquote>What’s typically written for smaller CPUs like the 8 bit AVR family, 8 bit PIC, etc. is what’s known in the trade as a single process executive. It’s a wonderful solution when the compute logic is uncomplicated. The introduction of non trivial amounts of concurrency and complicated I/O rapidly begins to test the limits of that model.</blockquote>
People often assuming you <i>need</i> an RTOS for realtime tasks, but there are tricks you can use to achieve good timing characteristics without a RTOS OS.
<blockquote>Austere embedded RTOS’ like FreeRTOS, ThreadX, and RTEMS are the next logical step in complexity. All of them implement multi-threaded single process execution architectures. They’re sometimes described as a threading library as much as an operating system.</blockquote>
Sure you can go full RTOS and I'm not putting those down, but most devs are not very familiar with those and it turns out that sometimes you can use a regular OS and dedicate some of the cores to a real time task without causing the OS or real time process to flinch. My orange PI had 6 cores and I was able to get real time IO under the non-RTOS linux kernel by dedicating some cores to my userspace IO handler. You might emulate a full 8 bit microcontroller in real time if you really wanted to.
I've found that building state machines to handle real time IO works well and it scales up too. I like using this approach for concurrent PID controllers that don't step on each other.
<blockquote>This is very conducive to concurrency and deterministic timing in a highly resource constrained environment, although developing in this model can be a little unusual for those coming from big, traditional OSes.</blockquote>
Of course the microcontrollers one might use are extremely resource constrained. But there are a ton of DIY hackers today who are skipping those entirely and just using resource plentiful ARM SBCs instead. That's the context that I was talking about.
By: gdjacobs
In reply to <a href="https://www.osnews.com/story/140153/moving-to-an-rtos-on-the-rp2040/#comment-10441356">Alfman</a>.
What's typically written for smaller CPUs like the 8 bit AVR family, 8 bit PIC, etc. is what's known in the trade as a single process executive. It's a wonderful solution when the compute logic is uncomplicated. The introduction of non trivial amounts of concurrency and complicated I/O rapidly begins to test the limits of that model.
Austere embedded RTOS' like FreeRTOS, ThreadX, and RTEMS are the next logical step in complexity. All of them implement multi-threaded single process execution architectures. They're sometimes described as a threading library as much as an operating system. This is very conducive to concurrency and deterministic timing in a highly resource constrained environment, although developing in this model can be a little unusual for those coming from big, traditional OSes.
By: Alfman
cpcf,
<blockquote>you have a heart of gold</blockquote>
Completely O/T, but reminded me of this clip for some reason:..
"Andy Richter Zings Chelsea Handler"
https://www.youtube.com/watch?v=VN3zrFBXynw
By: cpcf
Thom, thank-you for re-implementing the Edit button, you have a heart of gold, normality restored.
By: cpcf
In reply to <a href="https://www.osnews.com/story/140153/moving-to-an-rtos-on-the-rp2040/#comment-10441363">Alfman</a>.
Yes, the modern processors promote poor coding practises, (not an accusation), it's just that the power makes up for a lot of high level clutter. The devil is in the detail.
Actually Rpi 2040 is a great example of this, semi-technical types often think the Pico or Pico W are close to the bare chip and therefore performant. They ask me or some of my associates why they can get simple subroutines to run with a significant duty cycle. Then I point out to them they are reading the Pico datasheet which is typically under 100 pages. The 2040 datasheet, just the chip, is nearly 700 pages, that's the one they need to read and understand, not the datasheet for the demo board.
Personally, I think for makers who are coming from an experienced/strong coding base, they are much better off starting with a platform like STM32. ESP32 or ESP8266. They get an Eclipse or VS Code Dev environment that is much more aligned to what they are accustomed to, and can even go the PlatformIO route in VS Code. Both those IDE choices expose the intricate detail of the chipset, where the Arduino IDE is typically driven by the demo board libraries.
By: Alfman
In reply to <a href="https://www.osnews.com/story/140153/moving-to-an-rtos-on-the-rp2040/#comment-10441362">cpcf</a>.
cpcf,
<blockquote>It’s tough, ideally makers want to collaborate but they must do so with trust which is often not a maker trait.</blockquote>
Yeah, sometimes there's a strong desire to do it oneself to learn. But at the same time having a mentor could save time / effort / failure. Sometimes I wish I had someone to help me with hardware projects. To be honest I'm quite jealous of those who have access to a good workshop too. I have to lug tools out in the back yard if I want to work on something. I started working on an autonomous lawn mower and as ill equipped as I am I manged to build a working drive mechanism by mounting motors with bicycle sprockets and castor wheels! I temporarily hooked up a remote control and it still makes me laugh! It depresses that I had to throw it away because the landowner didn't appreciate my using their space for my projects. God I wish houses weren't so expensive.
<blockquote>It takes a bit to use interrupts and hardware registers and the like effectively, but doing so will release the full potential of the devices, people wanting high performance should probably know it, people wanting real time performance just can’t avoid it.</blockquote>
A lot of libraries available out of the box are inappropriate for real time use cases. But if you're willing to write your own IO code (which isn't particularly hard even though it puts people out of their comfort zones) you can often get your desired "real time" results with nothing more than a tight loop around the necessary IO patterns.
I do prefer micro-controllers because they are more efficient and you have low level control but from a pure workability standpoint ARM processors with full operating systems are simply so fast that they can often emulate the hardware features of much slower microcontroller with just a tight loop. I typically use a variation on Bresenham's line drawing algorithm ( https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm ) to synchronize loop time with wall clock time. This coding pattern is so versatile and I've found so many applications for it over the years! I've successfully programmed an organgePI and RPI to drive PWM servos and speed controllers from userspace without any special drivers or even interrupts just by using a high priority thread. Today's multi gigahertz SBCs are total overkill but regardless of that bit banging is both simple and effective. Of course if your hardware has PWM/SPI/UART/etc features those are naturally going to be more efficient.
By: cpcf
In reply to <a href="https://www.osnews.com/story/140153/moving-to-an-rtos-on-the-rp2040/#comment-10441356">Alfman</a>.
It's tough, ideally makers want to collaborate but they must do so with trust which is often not a maker trait.
But in a project like the one the article describes there is nothing in it for a commercial entity, it's just more of a pre-existing technology even if it is cheaper.
It takes a bit to use interrupts and hardware registers and the like effectively, but doing so will release the full potential of the devices, people wanting high performance should probably know it, people wanting real time performance just can't avoid it.
By: Alfman
In reply to <a href="https://www.osnews.com/story/140153/moving-to-an-rtos-on-the-rp2040/#comment-10441355">cpcf</a>.
cpcf,
<blockquote>Great article that shows the current state of the IoT maker universe.
A lot of makers just blend basic knowledge from several areas including coding, electronics and design, but never quite get to a slick product. Just further proof to me that no matter how powerful the hardware becomes you often won’t get the result you think without learning the fundamentals.</blockquote>
You're right, it sounds like the author would benefit from some help on the software aspects. I have the opposite problem in my DIY projects, I'm good at the software but generally can use more help on the hardware side of things - making PCBs and whatnot.
I haven't tried it personally but his description of Zephyr makes it seem very bloated. My personal taste is to keep things extremely simple. Simple toolchains, simple dependencies, minimal bloat, etc. It's one of the things I love about developing for arduino - trivial low level control and full understanding over all aspects of the code if you seek it. Ironically I find that controlling IO is easier and more straitforward to do directly on some of these microcontrollers than the "friendly" high level abstractions designed for them. And very often the low level code is significantly more performant too. However the con is that inexperienced users just don't know how to do low level IO without a lot of hand holding - it takes time to learn and if they aren't interested in learning they can get frustrated.
<blockquote>Of course the RP2040 is probably overkill, you could do this with a suitably chosen MCU or PIC if you held the electronics skills to design and build the supporting hardware.</blockquote>
The main area where I find arduinos are consistently poor is for anything needing a networking stack. I've come to appreciate RPIs in this regard, but RPIs can be a bit more annoying to do IO with. Still, any of these platforms should be able to do what the author wants with or without a RTOS.
By: cpcf
Great article that shows the current state of the IoT maker universe.
A lot of makers just blend basic knowledge from several areas including coding, electronics and design, but never quite get to a slick product. Just further proof to me that no matter how powerful the hardware becomes you often won't get the result you think without learning the fundamentals. I feel the author would get the result needed with any of the available operating systems if they just spent time learning more about the hardware, registers and interrupts and how to use them in his chosen platform. I don't see the issues as a limitation of the Arduino IDE, PlatformIO or anything at a similar level, the problem is some missing basic knowledge, not sure they even need a RTOS of the required task. Of course the RP2040 is probably overkill, you could do this with a suitably chosen MCU or PIC if you held the electronics skills to design and build the supporting hardware.