Now we're going to dig into FreeRTOS a bit. As we discussed, you have lot of choices for operating systems and real time operating systems for your prototypes and for your eventual embedded devices. But in particular, FreeRTOS is well suited for prototyping and because of its life cycle. It's also well suited for creating devices that interface with Amazon Web Services. We want to talk about all that and just look a little bit about how FreeRTOS is structured, how you might consider using it. Why FreeRTOS? Again, we've talked a lot about different choices you could make. We've talked about the criteria you could use to select different operating systems. In most cases, you probably won't need the full support of a full-fledged Windows, Linux, Android-based system. You might need something for a device design that's more controllable for performance and for resource use. FreeRTOS is typical of those types of RTOS where they can be configured. They provide the functionality you need to run multiple tasks and to do things that are a little more complicated than you might do on a bare metal system. Again, FreeRTOS has some extra advantage now because it's part of Amazon. Amazon is responsible for some of the development of the system. It's still an open source. But we'll look at some of the Amazon Web Service elements of FreeRTOS as we get into those. FreeRTOS specifically, again, a portable open source, very small footprint operating system, commonly used for small embedded systems. It's been around for awhile. It was originally developed by Richard Barry back in 2003. Around 2017, the control of the FreeRTOS project passed to Amazon. While it's still open source, now there are extensions to FreeRTOS that are specific to AWS, and we'll talk about some of that later. FreeRTOS can be used with most open source compilers like GCC. It's also used with auto commercial compilers. FreeRTOS supports most popular microprocessor architectures. All the arm variants, PIC processors, x86, etc. FreeRTOS is a solid choice for you. It conforms to the majority of the MISRA coding standards. You can be sure about the quality of the tool itself. The footprint is dependent on the parts that you select, you can drive it down to a very small chunk of memory. But generally in a lot of cases, especially for prototyping, we might be bringing in some optional pieces to try and get some extended functionality. FreeRTOS, again, is a under MIT opensource license. It's easily found on the web for support, lots of books, lots of tutorials, lots of examples, really nice environment to work with from that aspect. There's two primary variants of FreeRTOS: OpenRTOS which is a commercial version, so you'll get warranty and dedicated support. Then there's SAFERTOS, which you would use perhaps for any of the system where you're absolutely concerned about reliability for medical, industrial, automotive type applications and certifications. Both of those variants are not open source however. The architecture of FreeRTOS is fairly simple. If you walk through this diagram, basically there's demonstrations, there's the source code that makes up the operating system. There's a kernel, and then there's a portable part that's really targeted towards whatever specific architecture that you're going to be working on, including the compiler, the microprocessor architecture, and any other elements. There's also a variety of dynamic memory implementations that come with FreeRTOS as well as the ability to do accustomed dynamic memory management scheme. If that's something you need to add generally in a layered application. Now we would have our applications running on top of the FreeRTOS kernel. Then we might use extensions FreeRTOS+ as well as drivers that we access through a hardware abstraction layer to get through to actually working with the microprocessor and peripherals and the target hardware. This is a fairly typical view of how it all comes together. It is a very flexible environment to be able to add elements into four different peripheral support. Very portable, it's really made up of three core files, tasks, queue and list.c. That's the minimum that you need to get the system up and running, as well as some include files. But what's interesting about the way that the system runs is the operating system is built as part of your application. When you get done with your code and you merge in into object modules from the FreeRTOS kernel, you end up with a single executable that includes all the FreeRTOS functionality in with your code. It's a little bit different in that aspect, that bundling together. You can certainly add additional files, which usually they are in most default applications, event groups, timers, coroutines, etc. These are all common things that are included in ports to different architectures. Again, there is also a configuration file where you can go in and tweak certain aspects of the OS. Because when you build a FreeRTOS based application, you end up with a single combined image, the structure of working with the operating system becomes fairly simple. Interprocess communication is pretty straightforward since all tasks are sharing memory. However, the downside of that is, the tasks aren't really well-protected from each other and it is possible to reach in the memory that you shouldn't if you're not careful. Some processors provide a memory protection unit to allow some limited protection between tasks. But that's not common across all architectures, certainly not amongst the lower-level microprocessors that are often used for devices. Because there's linkages between the RTOS and the application, the application is responsible for actually starting the RTOS task. One of the first things you'll see in your code is this function called for task starts scheduler, which fires up the scheduler and then at that point you'll be able to run tasks and have them intercommunicate, etc. Task scheduling is pretty straightforward. Really FreeRTOS is only supporting a single process. Multi-programming, multiple threads of execution, they're all sharing that same address space and so FreeRTOS has to handle how tasks are pre-emptied. What tasks get time slices of to run, and there's some custom configuration you can do there. In general, FreeRTOS doesn't restrict the number of tasks that you run. A task that's doing something in the system is either running, it's ready, it's blocked, or it's suspended. FreeRTOS does support a low power mode, of course when we're developing our devices and we're concerned about power issues, this can become something that we want to depend on. The FreeRTOS system has an idle task hook that allows entry into a low power state. Potentially, you could create your own functions for that optional hook where you could decide to try to do things in a specific way when you're in that idle state or you could drive the processor into selected power modes to try and maintain the level of power that you need for a specific application. FreeRTOS supports debugging. It has a mechanism for detecting stack overflows. Again, another hook function that you could call if you needed to when stack overflow occurs, you could do something specific to pull information, or figure out what's going on with this system. Generally speaking, the kernel provides trace macro also, that are empty by default, but you can go in and add to them to allow your application to deal with trying to debug specific issues in your code. Interprocess communication, and synchronization is provided for within this system. Everything within the system really is based on the message queue mechanisms that FreeRTOS uses. Things like semaphores, mutexes, et cetera, they're actually based on message queuing. For that reason, message queuing is one of the things that you can't take out of the FreeRTOS application. Very straightforward to work with and again, because all these things share this common bases in the queue library, it's pretty easy to get used to the functionality around those. FreeRTOS does support set of timer based functions, primarily it's determined by a system tick. Then you have the ability to delay a task, or stop a task, or start a task based on either a relative, or the absolute tick target. You could look for a specific time, or you could look for a certain amount of time that's passed, to control what you're doing with your tasks. This of course, gets to be important as we're doing multiple tasks, communicating with multiple peripherals. Again, the timer elements are a bit specific to the architecture, although the functionality that is provided is fairly common. Now, there are a lot of FreeRTOS editions available. Things like filesystems, networking stacks, command line interfaces, I/O frameworks, et cetera. All those things are available to you, and you can explore the FreeRTOS plus source directories for your platform. But what's more important for us is the fact that FreeRTOS supports more direct communication with Amazon Web Services. When we get to that part of the course, we're going to be talking quite a bit about Amazon Web Services IoT support for things which are definitions of devices within AWS. Device shadows, which lets us communicate with devices that may not be connected at that point. The device defender helps look at security issues. Greengrass is a local AWS support to let us do some things on the device that we might otherwise do in the Cloud, and the support for common connectivity protocols like MQTT and HTTP. HTTP has the secure version. All of those things are available as well as a FreeRTOS Windows-based device simulator. So you can imagine if you're working with AWS from a custom IoT device design, this is a pretty strong set of features to have at the RTOS level for your application to interact with, and take advantage of this conductivity. Again, we're going to spend quite a bit of time looking at the details of these AWS features in one of the classes for the course. In summary, if you're using a microprocessor-based system, and your team or you are comfortable in C-based embedded development, a FreeRTOS-based prototype might be a good alternative to something like writing Python on Linux-based pie. In addition to being able to create solid embedded multithreaded applications, you have all the extensions of the FreeRTOS+ libraries in the AWS extensions. This might be a good alternative platform for you, certainly one to understand well for most embedded device development environments. Eventually, you'll want to spend some time taking a look at how FreeRTOS compares with other RTOSs that might be more commonly used in your development space, and try to think about how you would use those for effective prototyping. Thanks so much.
