<story><title>Moving to a RTOS on the RP2040</title><url>https://blog.brixit.nl/moving-to-a-rtos-on-the-rp2040/</url></story><parent_chain></parent_chain><comment><author>DannyBee</author><text>This author seems like they are expecting an RTOS to be the same as Arduino environment, or at least, susceptible to just hacking around and hoping it works.  Most are not.&lt;p&gt;Given a lot of Arduino these days have mbed or freertos under the covers, with some way to expose it, that may have been a better route for the author&amp;#x27;s style.&lt;p&gt;Zephyr is easy to use (Clion also has good support for it), but like, you can&amp;#x27;t just choose not to install the toolchain and expect it to all work.&lt;p&gt;It also definitely supports the Pi Pico - i&amp;#x27;ve used it on it before, no issues.&lt;p&gt;A simpler rundown of these RTOSen would be:&lt;p&gt;1. FreeRTOS - supported by roughly everything, but drivers and such are mostly per-SOC&amp;#x2F;device, which is a pain in the ass.  The APIs are not very user friendly, but you get used to it.&lt;p&gt;To give a sense of level - if you wanted to use bluetooth with FreeRTOS, you get to find your own stack.&lt;p&gt;2. Zephyr - supports real hardware abstractions and supports most SOC. You may have to do a little board work.&lt;p&gt;If you wanted to use bluetooth with Zephyr, it has a bluetooth stack you can use, you may have to add a little support for your HCI.&lt;p&gt;3. NuttX - not great support, but very cool if you can get it working - not really highly supported by industry yet.&lt;p&gt;I never got far enough into NuttX to try bluetooth in NuttX.&lt;p&gt;There is also mbed, but we&amp;#x27;ll skip it.&lt;p&gt;In practice, people in the RTOS world will usually go with what the SOC vendor supports.  So if you are using Nordic stuff, you are probably on Zephyr.  If you are using NXP stuff, probably FreeRTOS, etc.&lt;p&gt;That is how they get good support.</text></comment>
<story><title>Moving to a RTOS on the RP2040</title><url>https://blog.brixit.nl/moving-to-a-rtos-on-the-rp2040/</url></story><parent_chain></parent_chain><comment><author>bborud</author><text>Having toolchains installed system-wide in the traditional UNIX way is painful, and dare I say it, not the smartest of approaches.  If it works for you: great, but if you work on a project with multiple developers, sometimes working on multiple projects that have different targets, you will spend a lot of time trying to figure out build and configuration problems.&lt;p&gt;It also doesn&amp;#x27;t help that people keep using Python for tooling.  Why would you want to insist on using a language that brings its own versioning problems and which will behave differently on each developer&amp;#x27;s computer?  I&amp;#x27;ve done embedded development for about a decade now (both as a hobby and professionally) and it is puzzling that people think it is okay to spend a week trying to make everyone&amp;#x27;s setup do the same thing on a project and then not see how this is a problem.&lt;p&gt;It &lt;i&gt;is&lt;/i&gt; a problem. It &lt;i&gt;is&lt;/i&gt; annoying. It &lt;i&gt;does&lt;/i&gt; waste time. It &lt;i&gt;is&lt;/i&gt; unnecessary.&lt;p&gt;Tools should be statically linked binaries. I don&amp;#x27;t care what language people use to write tools, be it Rust, Go, C, C++.  I just wish people would stop prioritizing ad-hoc development and start to make robust tools that can be trusted to work the same way regardless of what&amp;#x27;s installed on your computer. Python doesn&amp;#x27;t do that. And it doesn&amp;#x27;t help that people get angry and defensive instead of taking this a bit more seriously.&lt;p&gt;That being said, things like PlatformIO are a step in the right direction. I know it is a Python project (and occasionally that turns out to be a problem, but less often that for other tools), but they have the right idea: toolchains have to be managed, SDKs have to be managed, libraries have to be managed, project configuration has to be simple, builds have to be reproducible and they have to be reproducible anywhere and anytime.&lt;p&gt;I wish more of the embedded industry would realize that it would be better to have some common efforts to structure things and not always invent their own stuff. I know a lot of people who work for some of the major MCU manufacturers and I am always disheartened when I talk to them because they tend to be very near-sighted: they are mostly busy trying to solve their own immediate problems and tend to not have a great deal of focus on developers&amp;#x27; needs.</text></comment>