Amazon FreeRTOS – IoT operating system for microcontrollers

Because otherwise you're in the business of explaining to non-technical users how to open up ports in their NAT firewalls and do other fun things required to make the device Just Work(tm) from any Internet connection.

It's important IMO for device vendors to offer as many options as possible in that regard. Ideally it should be possible to use a given device with a paid service sponsored by the manufacturer, a free service run by anyone else, a private server running on the customer's own LAN, or with no external servers at all.

Insecurely designed, networked embedded devices are a serious issue. Look at the botnet based on CCTV cameras for an example. A company that doesn't care about security is still going to produce crap devices and isn't going to update, but for a company that cares about security, ability to patch devices in the field is an absolute necessity to stay on top of vulnerabilities.

The ability to add features and keep your device 'fresh' is a nice bonus.

to allow a "secure" connection (plus all the snooping and reporting).

as near as i can tell, there's no way to concoct a device to run on a home network which an average consumer's browser will be happy talking SSL to.

(if anyone knows a way i'd love to hear it.)

Wow, not only reached the edge of the obervable universe, but easily outpacing expansion and communicating back to a cloud service.

FTL travel confirmed. FTL info confirmed.

https://aws.amazon.com/blogs/opensource/announcing-freertos-...

So presumably they have bigger plans beyond examples.

This is actually an improvement over the old "FreeRTOS open source license", which was basically the GPL plus:

> FreeRTOS may not be used for any competitive or comparative purpose, including the publication of any form of run time or compile time metric, without the express permission of Real Time Engineers Ltd.

A strange exception, which ostensibly prevented you from running benchmarks? But the GPL prohibits the addition of such clauses?

But now it's just plain MIT. Super easy.

Embedded systems tend to be doing things that look more like real-time control applications. Let's say the processor is running a radio. It is important that certain requests form the radio hardware are processed quickly enough otherwise the data isn't ready to transmit in the time slot that it is meant to be in, and you don't meet the standard for that protocol.

In practice though, what people are actually wanting is an abstraction around the concepts of scheduling, and facilities like multi-tasking (with pre-emption), and facilities to communicate between tasks in a thread safe way. Mostly they don't need the 'hard' RTOS aspects (and so this is often referred to as 'soft RTOS').

To explain this a little - your traditional simplistic embedded app while look like 'while(1) {}' at the bottom of main. It will sit in a loop servicing the things that need to be serviced - pulling characters off a UART, waggling the line for the LED to make it flash on the right interval etc.. This is fine for a small app on an 8 bit processor but as embedded applications grow, you have a lot of functionality that is all tied up with each other. What an embedded scheduler does is put the main loop at the bottom of the dependency tree rather than the top - modules of code can be separated out and request themselves to be scheduled when necessary allowing for much cleaner separation, and more robust code.

For example if your thing is attached to a sensor that spits out 47 bytes of sensor data every N clock cycles, and has a buffer that is 94 bytes, then you damn well better be reading that thing every N*2 clock cycles with a hard guarantee that your routine is finished copying all 94 bytes of data by the time it finishes (including time for interrupts).

This gets complicated when you have specific requirements about when data is available or other things too (e.g. if reading data requires pulling pin X low, waiting at least Y clock cycles, and then reading all data in no more than Z clock cycles before returning pin X back to high, then good luck doing that in a normal OS where you have no hard time guarantees).

One of the things I like about an RTOS is the organization it gives to your code. It gives you primitives like tasks, queues, and semaphores and allows you to easily organize and synchronize independently running tasks. On something like Arduino where you just have a setup() and a loop() function, it can become a mess if you're trying to do many different things with different timing requirements.

> The FreeRTOS kernel is now an AWS open source project, and these pages are being updated accordingly.

Given that, the distinction probably isn't super important.

[1] http://dmitry.gr/index.php?r=05.Projects&proj=07.+Linux+on+8...

For my area at least, we're talking about the microcontrollers for your car's key fob, your car's instrument cluster, etc. Every electronic component in your car has an embedded microcontroller connected to the CAN bus. And cost is a big issue.

High end electronic might contain more powerful micro controllers, but I doubt that by volume it makes a significant percentage of the microcontrollers in circulation.

- You want to keep manufacturing costs low so you can make more money.

- Running Linux requires a relatively large CPU with an MMU and a lot of RAM and Flash. This adds significant cost -- $5-$20 per unit.

- Some devices do enough local processing that they have this hardware anyway (routers, streaming TV widgets, smartphones). In this case, you might as well just run Linux and take advantage of the big software ecosystem.

- Most devices do not require such big hardware. This is where you want something like FreeRTOS (or smaller!) so you can ship smaller, cheaper hardware.