Will there ever be a supported FreeRTOS for the Raspberry Pi 3/4 ?
I would never say never, but we have a lot on our roadmap at the moment so this is not something we will do in the near term. There are other people running FreeRTOS on the Pi though. It would be very interesting to add a Pi project to the FreeRTOS Labs section, to make it available to others, and to tinker with it, but stopping a little short of it being an âofficialâ port in the main download.
I would have thought that the RPi would on top your list for FreeRTOS. I will not import some vague FreeRTOS - one has enough with the programing aspect so one needs a very stable OS.
Oh wellâŚIâll have to keep looking
As a long time FreeRTOS User, let me say I agree with Richard Barry. The RPi maybe a great little platform for what it does, but it loses a LOT of its luster if you dedicate it to a FreeRTOS app.
Some big issues are that it isnât designed to connect a standard âdebuggerâ to it to debug an embedded program from a remote terminal, but instead is based on the typical techniques of debugging with the debugger running on the machine itself, which pretty much assumes you are running Linux, and if you are running Linux on the machine, you arenât running under FreeRTOS.
Compared to a computer, it is small and cheap, but compare it to real embedded processor board it is big, expensive and power hungry. It might be a reasonable choice if you need the large memory resources of the Pi, but then you often want some of the other things that Linux will give you too.
1 Like
First Paragraph: Since there is no official port to the Raspberry Pi how can you claim that?
Second Paragraph: How do other boards debug then?
Third paragraph: The RPi is neither big nor expensive but yes, the RPi 4 is a bit power hungry but that is no problem for me at all.
OK so if freertos is not interested there is nothing anyone can do.
I didnât say I was not interested, but that it is not near the top of our priority list considering the mass of other things we want to get done that better address our core market. It is resource that is limited, not willingâŚand as far as what can be done I did suggest we could perhaps make a Pi port a Labs project.
I should have also asked what your particular use case was - it would be interesting to know because our roadmap has always been driven by our users and is effectively how our roadmap gets prioritised.
Another edit after posting. You may also be interested in some of the other work we are doing currently, namely refactoring some newer IoT related libraries to make them applicable to wider use cases, including use on Linux and bare metal. For example, this MQTT library, which is not fully documented yet, has a network interface specification that is implemented to use FreeRTOS+TCP in the example here https://www.freertos.org/mqtt_lts/index.html but we also have a network interface that uses POSIX/Linux sockets API with OpenSSL. That would run on the Pi.
Second question first: Most microprocessor development boards either have a standard connector on them to attach a debugger pod on them that connects to another computer to let it load programs and debug the program running on the system, or they include such a debugger pod on the board, and have a USB connecton to allow the remote computer to do the debugging. The RPi, because it was designed to be running a full OS on it, doesnât provide such a connector.
First Question, the lack of such a connector makes converting a RPi to run a standalone program very difficult.
Lastly, compared to some embedded systems designed for the purpose, the RPi is big, many embedded boards can be 1/4 the size and price of the RPi (or less). The RPi is a power hog, it needs Watts of power. You can build a small power supply to power a small processor off a single battery for a long time, but donât try that with a RPi. Yes, those processors have no where near the processing power of the RPi, but you often donât need that power.
FreeRTOS fits ideally to power programs on such processor/boards, and that is where I believe they consider their primary focus.
For support, the RPi is just an Arm processor, so I suspect that there is already a port that handles most of the details. It might need a driver for the interrupt controller and timer. Some bigger issues though is that the RPi has a multi-core processor. FreeRTOS at its heart only supports a single core per version of FreeRTOS loaded (AMP). There are some third party provided multi-core ports of varying quality, but SMP multi-processor systems have very different issues to solve than single core systems.
In one sense, running FreeRTOS on the RPi hardware would be like going out and buying a fancy racing car, and then using it to only drive around the city. You have hardware capable of doing a lot more than you are using it, and missing a few feature that would be useful for that environment.
Oh well, then Iâll forget freeRTOS. Bit of a pity that since the RPi is in a lot of teaching environments
as so pupils and students could learn how a RTOS system works - and compare it so Unix applications.
Please give an example of such boards that can run freeRTOS, I need the power of a RPI, one can of course use a RPi 3 which uses a lot less power.
Well, if you NEED the power of a RPi, than you probably have needs above what FreeRTOS is designed for. As I said, multiple cores are one big issue for FreeRTOS, as it is fundamentally based on a single core design, which means it can ignore a lot of the problems that come up with multiple cores. It also means you likely want Process Isolation, where you have multiple processes in your system and one process is very limited in what it can do to another. FreeRTOS does not support that.
As to examples of boards that can run FreeRTOS (maybe better to say work well with it, since as I mentioned, I suspect that you CAN run FreeRTOS on the RPi, it may just need a bit of peripheral porting work, and that FreeRTOS will run on just a single core) would be things like the Arduino modules, or the development kits from most microprocessors of this class of single core processors.
You could try something like a Xilinx Zynq. That is a dual core Cortex-A9, has some very low cost development boards, and the Xilinx tools will create FreeRTOS projects for you.
You mentioned in your post from nearly two years ago (FreeRtos porting to Raspberry Pi 3) that you were wanting this for ânewlingsâ to learn RTOS. And that Raspberry Pis are common in teaching environments. Trying to teach RTOS, and specifically FreeRTOS, for the reasons that @richard-damon so detailedly mentioned would be far more difficult on a Raspberry Pi. There would be many more minutiae details for newcomers to have to know.
What Iâve more commonly seen in higher education institutions around the world are students using lower powered hardware (e.g. from Microchip, ST Microelectronics, Espressif, and others) in their embedded development courses. These dev kits can be had by students be found for $2-10 from various retailers.
Lastly, youâre bringing the need for processing performance. We have some pretty powerful boards like the Xilinx option that @rtel mentioned. However, most new students will never need that level performance. Even the ESP8266 at 40MHz is underutilized in many cases until they need the memory for IoT and/or machine learning applications.
1 Like
@Bonzadog In my opinion FreeRTOS is not particularly suited to the bigger processors such as the Cortex-A series. Mainly on the grounds that the MMU is not supported. It is much better suited to the likes of the Cortex-M and Cortex-R (with or without an MPU).
The Pi really is not a good learning device for FreeRTOS. It is far to complex. Its great for Linux which provides all the drivers you need. Personally I think a Cortex-M4 is probably the perfect learning processor for embedded systems (I am a big fan of the STM32 range of processors).
Well in the deeply embedded world it is a very big processor. I would call a Cortex-M0 small and a M7 big. Much beyond the Cortex-M7 then I think you are in the fully featured OS domain such as Linux.
From what I can see from the semiconductor manufacturers I think the future will be multicore processors running Linux on an application processor cluster (Cortex-A7, A9, A53 etc) and an RTOS running on a Cortex-M. In this scenario the hard real time and safety critical code can run under the RTOS and the other stuff such as network, UI etc can run under linux. Itâs all about partitioning.
A possible use case is for commercial products that require compliance to IEC62304 for safety. Iâm aware of a medical product using the PI4 for the GUI since it supports 2 screens (local and large LCD display) using GTK+, but it uses another processor with an RTOS for the real time safety-related processing. There was concern about identifying and mitigating the risks in the large Linux code base with the many processes that are typically running in Linux. As safety concerns and national regulations proliferate for many commercial products, this market could become significant (if it is not already large). I expect that documenting IEC62304 compliance for FreeRTOS would be easier than doing so for Linux.
There supposedly is a port of it. I git cloned the master branch and got it to build with just the cross compile tools in the ubuntu distribution. It includes a demo program for LEDs. I thought that the demo programs were ready to build, but this lacks a Makefile for it and also for those files in the driver directory. Then I found out that there was a fork which fixed some of the previous problems. github com Forty-Tw0 RaspberryPi-FreeRTOS But after reading some ports it seems to beta if not alpha and tcp/ip seems to be broken.
I had wanted to try this freertos on the raspberry pi because I have a A/D hat for the raspberry pi and none of the APIs seem to be able to capture data without being interrupted or giving false data. So I tried to use a real-time kernel on that someone had patched and it did not work either. Supposedly you could run a process on one of the CPUs and not be interrupted. It didnât work. I had one channel which had a fixed voltage on it. Every so often it read a zero for that. Maybe I have a hardware problem, but it hasnât been used very much.