Hacker News new | past | comments | ask | show | jobs | submit login
Amazon FreeRTOS – IoT operating system for microcontrollers (amazon.com)
193 points by tdrnd on Nov 29, 2017 | hide | past | web | favorite | 102 comments

The most useful aspect of this, from my perspective: they've finally abolished the non-FOSS license of the old FreeRTOS, and released it under an actually Open Source license, namely MIT. That's one less headache to deal with.

It's a nice present from Amazon. They should keep doing this, I'd like a MIT licensed QNX next please. God knows they have the money.

GPL would be fine too; I'd just like something that actually qualifies as FOSS, rather than something proprietary.

Baseline FreeRTOS was "GPL" but it had a silly clause prohibiting you from publishing benchmarks.

GPL is also a non-FOSS license. It says it is, but its not.

Can't wait until the GPL is a rarely used license.

It meets the Free Software definition, the OSD, and the DFSG. And even anti-copyleft zealots rarely descend as far as to attempt to claim (falsely) that it isn't a FOSS license, rather than simply complaining that they find it distasteful.

We will be back to the world of public domain and freeware.

Everything will have a light version open source, with the actual goodies only available in the commercial version.

Until then we have the actual goodies only available in the cloud. ;)

Would you care to elaborate on what you believe makes the GPL a non-FOSS license?

It definitely limits the freedom of both the author and user, by restricting the means in which the software may be distributed and the limiting author's right to add additional restrictions (the "all distributions must adhere to these restrictions but can't add more" clause which makes it incompatible with the Apple App Store, for example). It's "Free" in the Free Software Foundation sense but not really in the way some people think of "freedom."

It limits the freedom of the author yes. It severely expands the freedom of the user. That is the whole point of the license, any user has the code available to modify, inspect, or audit himself. I don't see how you think that it limits the freedom of the user too.

I think you don't know what GPL is intended for. It's to give the USER the four basic freedoms, not the dev, not the author, the user.

I tried to research your statement and landed here[0].

I'm somewhat shocked at how many different competing active RTOS's there actually are. There amount of reinventing the wheel must be huge. I mean I know the wikipedia page on Operating Systems lists a lot more.. but the majority of them are long dead.


To be fair, a loop spinning and some malloc / free functions in a library are enough to call something a RTOS.

Yeah but the important question is what about the future investment into these projects? Is there any, or is it just a throwaway thing that Amazon does?

For those looking for context around this acqui-hire/stewardship, here's our take from late 2016 when Silicon Labs acquired FreeRTOS competitor Micrium:

Going forward, we expect to see non-traditional IoT software and infrastructure platform vendors looking closely at the embedded OS space. A compelling OS offering could drive millions of device signups for IoT services platforms, such as AWS IoT, Microsoft Azure, and GE Predix, which derive recurring revenue from services rendered to an installed base of devices. Onboarding an OS offering (or complementing Windows 10 IoT Core with an MCU-focused OS in Microsoft’s case) would allow these players to potentially hook analytics and connectivity services into a portion of the billions of MCUs that are shipped yearly, bumping up services revenue substantially.

We see this acquisition as a substantial, missed opportunity for leading MCU vendors, such as Renesas, Microchip/Atmel, and Qualcomm/NXP/Freescale, who we had shortlisted as likely acquirers. Micrium competitors Express Logic and WITTENSTEIN would be rational targets for the next round of RTOS acquisitions.

We had expected Microsoft to refocus its attention on the MCU space (perhaps with a derivative of WinCE) but they have been more focused on providing runtimes for maker boards and playing catch up with AWS, than building out the bottom end of their OS portfolio. Ditto Google with Android Things.

Think this is a great move on Amazon's part providing, but not forcing, an easy on-ramp to AWS for the billions of MCU-powered devices that ship every year.

How do ppl like freertos vs zephyr vs nuttx?

Have any real comparisons been done? Both on flexibility (platform support and code portability... I know... Nuttx, POSIX) and performance (interrupts, context switching, etc)

I've been looking at zephyr which seems all around better, albeit a bit less mature. I have no hard data though... Hence this question.

>Amazon FreeRTOS ... and extends it with software libraries that make it easy to securely connect your small, low-power devices to AWS cloud services

why do IoT devices have to connect to the cloud? Is there any legitimate use case other than reporting data gathered on the customer? Why do have all these gadgets have to snoop on us?

why do IoT devices have to connect to the cloud?

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.

If you're going to sell a consumer an internet connected device, they're probably going to assume that it'll work on its own and they can review and adjust things on a website (that isn't a 192.0.0.*)

Sadly, thats the IoT world I want to live in. All the devices communicate only through the internal network. This increases security a ton by default.

If you want to use it outside your network, then you do it the old fashioned way, by setting up a vpn to your router.

I've shipped a few products that work like this, but the support burden is incredible. Practically no users are capable of configuring IP addresses or forwarding ports on their router.

Config-by-phone or config-by-cloud is definitely the way to go for consumer gear -- see Roku or Chromecast for great examples.

Hm, I wonder if it is just the IP address people don't like to use? Like if it used Bonjour/Avahi and you could (after a bit of initial config) connect to your internet connected lightbulb via http://kitchen-lightbulb.local would that be better?

There are some other good reasons mentioned here, but this is the one that makes me glad they are: firmware updates.

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.

Why do internet of things devices have to connect to the internet? Because that's the whole definition of them. Without an internet connection, it's just a thing.

devices could be connected on a home network, without calling home.

they could, but again: then they aren't an internet-of-things device. They could do cool things, but without an internet connection it's not IoT. And the internet connection is the selling feature for most IoT devices.

I can turn my dumb non-internet connected thermostat up if i'm at home, the interesting thing about a Nest is that i can turn up the thermostat before i leave work and the house will be warm when i get home. The internet connection is the value-add. If you don't like internet connected devices that's cool, but IoT devices can't have the same feature set if you remove the internet connection. the call-home is not useless. If you want to argue that certain devices don't need an internet connection, that's fine. and in many cases i'd agree. but arguing that the whole class of devices that is defined by being connected to the internet doesn't need an internet connection is pretty silly.

If you want to turn on the thermostat from work then it does not need to connect to the cloud, also it would be safer not to expose the thermostat directly to the net - have a more secured control server on your local home network and have that one call the thermostat.

When I think of IoT I think of devices gathering data, and the data has to go somewhere to be useful. What's the alternative to putting it in the cloud, self-hosting the storage? That's what I would do, but I think it is a pretty niche market who wants to deal with the storage, backing it up, etc.

IMHO the apps should be storage agnostic, with setup including choosing storage (possibly including paid plans).

Meditating that through a standardised storage connector would mean the IoT apps have very little to do.

That could be something like SFTP, but there are some interesting things like https://remotestorage.io/ that allow you to write your own storage provider so decentralised apps can choose their own data store/change storage later without changing the app.

> why do IoT devices have to connect to the cloud?

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.)

Lets Encrypt is adding wildcard support in 2018


i don't see how that helps. what wildcard pattern are you thinking will be useful, and issuable?

Not a wildcard solution (or a particularly legit one or one a serious vendor is going to take up, but could work for DIY):

DNS poison within LAN (or proper internal DNS, or even HOSTS if DIY) for .product.tld Product initiates letsEncrypt for: uid.product.tld And posts some form of identity proof to vendor, setting up a link to carry out letsEncrypt challenges.

Verification negotiated between letsEncrypt and the vendor via public resolution of uid.product.tld

Device completes cert process with letsEncrypt and installs cert to the device.

LAN now has TLS to uid.device.tld internally (via DNS spoof/poinon) and vendor hasn't seen the cert. (but, if not DIY, the vendor is distributing a DNS poisoner in their product)

() Caveat: I've still not set up letsEncrypt in the wild, so don't know it's limitations, but from the doc's the above looks doable.

The lack of ability to have a browser TLS to *.local without an internal CA or non-public root and the endpoint management to goes with either is a pain.

"NASA Jet Propulsion Laboratory robots need to work in harsh environments, often on the edge of the known Universe."


It's edge devices man!

Dude, you think this Amazon Cloud Service will still be active when the messages are received?

More important, will the device battery still be charged when it gets a response back?

Often - as in traveling back and forth to the frontier.

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.

Is this like the sample projects Microsoft makes available for interfacing a variety of development boards to their IoT hub [0] (a few of which use FreeRTOS), or is there something more to it? As usual the AWS docs are rich in inspiring buzz-words and very poor in explaining what the thing actually does. Not that Azure is better in that regard...

[0] https://catalog.azureiotsuite.com/

In this case it seems Amazon outright acquired whoever was maintaining FreeRTOS and has made it available under an MIT license:


So presumably they have bigger plans beyond examples.

Richard Barry, founder of FreeRTOS, has joined AWS as a principal engineer, and will continue to support Amazon FreeRTOS. WITTENSTEIN high integrity systems (WHIS) will continue to support and develop OPENRTOS and SAFERTOS, commercial implementations of FreeRTOS for projects that require certification or support.

Richard released FreeRTOS in 2003, and had been working on FreeRTOS in partnership with WHIS since 2006, when they started to provide commercial support for it.

I do hope they'll keep maintaining it - I've been working with an ESP32 lately and the stuff Espressif has been able to build using FreeRTOS as a base is nothing short of incredible. $7 for wifi and bluetooth on a development board.

Agreed, the esp32 has blown me away with what it can do for a few dollars. I have a custom board with the esp-wroom-32 and the temperature sensor I'm using is more expensive than the esp32 module!

The ESP32 is just like a tiny Amstrad PCW 1512, with dual core and extra network support.

Which for anyone that used a PCW, means it can do a lot.

Additionally they are adding in things like native drivers for WiFi, BLE, and signed updates. AWS Version will be v5.0.

I'm a bit confused. I guessed he was selling it with Wittenstein given (a) they have commercial licenses for the same source and (b) one of their docs said he helped set up the High Integrity Division of Wittenstein. That link makes me wonder what impact they had at all on FreeRTOS.


Note that I don't follow FreeRTOS's closely. I just discovered it searching for RTOS's with Wittenstein looking at who was doing safety-certified RTOS's. At least back then, it was neat to think someone's RTOS project was getting adoption in the commercial sector with some money going back to them. Now I wonder...

This certainly seems to make OPENRTOS^R redundant

    The additional value offered by OPENRTOS is as a ‘commercial and legal wrapper’ for FreeRTOS users.

The commercial variant still offers indemnification, warranty, and support; all of these are at the least mandated by many large organizations' acquisition policies.

Ok, now I get it. The core of the announcement is that they're doing with FreeRTOS what Apple did with CUPS, basically (plus the MIT relicensing). On the one hand, it feels like a power grab; on the other hand, one can only hope that it might bring some sorely needed standards of decency in the IoT world...

I hope so too. At least FreeRTOS has tons of track time on it (I've been using it for years). Whence Google Brillo (or whatever it's called this year?)

The "Get Started For Free" button on the front page has an ominous ring to it. I wonder (hope!) that the free version available from FreeRTOS.org remains available w/out an AWS account.

Amazon has ownership of FreeRTOS.org now, but the good news is that they are licensing it under the MIT license. Even if they hide the official download link behind an AWS login, there will be plenty of public mirrors.

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.

What's the advantage of a RTOS?

"RTOS" is the term used to describe the core component of most embedded systems. Technically it should mean a scheduler that provides 'bounded latency' in scheduling operations. That means that if a certain (internal or external) event happens, the code to run it should happen with no more than a certain delay.

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.

Been awhile since I dealt with microcontrollers, but my recollection is that some non-trivial amount of things have to be done by a RTOS.

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).

Two models are common in embedded systems: "main loop" or RTOS. In the main loop model, once initialization is complete, the program loops indefinitely, servicing various functions. Since the developer is responsible for a larger portion of the code, it is easier to meet timing deadlines.

An RTOS provides a convenience to allow various threads to block and thus simplify programming. I would choose an RTOS where there are a greater number of independent tasks which need to be performed.

Both are alternatives to a conventional OS which makes hitting deadlines difficult or impossible.

An additional advantage of some kind of RTOS, or at least using interrupts: infinite looping uses more power than sleeping and waiting for interrupts.

It's worth noting that very few devices using an RTOS actually have real-time constraints. In practice, "RTOS" just means "operating system for an embedded device".

Does an RTOS have a built-in theorem prover to accomplish that?

The usual reason for using an RTOS on small embedded controllers is that a full OS is way too big to fit on such small CPUs (eg. 64K of RAM and 256K of FLASH is common). FreeRTOS is tiny - it only uses a few KB of FLASH. Non real time OSes also don't provide the timing guarantees that are often required in those kinds of applications.

Valid point, but I’d have to disagree with you here. My experience as to why RTOS are chosen for small embedded micros is either a) some hard real time requirement is a must, eg motor control. You’re right that a non real time OS won’t provide that, but a blocking super loop baremetal application with round-robin task queueing may not either, depending on what’s in the queue b) the source of baremetal super-loop applications gets too jumbled as requirements grow and/or they require some multi-tasking mechanism for performance reasons. RTOS provide a multi-tasking mechanism.

People have listed other benefits such as timing guarantees, lack of general OS overhead, etc.

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.

Not having to worry about a more complex OS burping, leaking, or otherwise failing on you. As one poster on the Arduino forums explained it to me once, "you never know when Linux is going to nip off for a cup of tea and interrupt your program with some system overhead tasks." You are going to get your n cycles per second, every second.

This is a common misconception about RTOSes, or at least needs to be further qualified with soft real time vs hard real time OSes. RTOSes provide schedulers and multitasking mechanisms for context switching between tasks. Tasks can be assigned priorities. A higher priority task can pre-empt a lower priority task (depending on the RTOS’ scheduler implementation). In that case, you may never get your cycles, or at least not deterministically. tl;dr, depends on the scheduler implementation.

The advantage is that you can make claims about the maximum time it take to process something. Contrast that to Windows, macos, or Ubuntu that generally are zippy on new hardware, but sometimes the circle spins or the hourglass shows up and makes you wait, possibly for an outsized period of time for what is being processed.

To make any worthwhile claims you need the worst case execution time of your code. Even in the absence of multi-threading, technologies like caches or out-of-order execution can make this quite painful.

The common solution seems to be: Don't care for some missed values (e.g. non-safety critical systems) or over provisioning (absence of budget pressure).

-> A RTOS alone doesn't give you any reliable claims (but does make a lot of embedded stuff much easier).

What I assume IncRnd is referring to is the deterministic behavior of an RTOS. Here is a good white paper from National Instruments:


Thank you. That is a good explanation and is indeed what I meant.

It might have been nice of them to change the name slightly to avoid confusion with the originating FreeRTOS. https://www.freertos.org/

At the top of the page you linked to, I see this message:

> 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.

Good catch I didn't see that announcement there. That does change things

It seems it is exactly freeRTOS, but with some additional drivers and libs so not changing the name seems to be a good decision I think. I am wondering however if by using this os, the dev is obliged to use aws services. Isn't this more of a limitation than a benefit?

According to [1] "FreeRTOS remains open source, with no commitments. [...] FreeRTOS users are not required to be AWS customers in any way."

Most likely Amazon's motivation is that they can make sure FreeRTOS makes using Amazon's services very easy; there are some IoT offerings that can't connect to Amazon's services, (or at least can't connect easily) [2]

By making sure FreeRTOS can easily pull in the right libraries, they can make it easier for people to connect devices to AWS without compromising on secure encryption.

[1] https://aws.amazon.com/blogs/opensource/announcing-freertos-... [2] Last time I checked, Amazons MQTT service required TLS1.2 and an esp8266 only supported TLS1.1

The latest axtls port for esp8266 supports TLS 1.2.

That's a fair question. There definitely are people not wanting the additional stuff from Amazon.

For example, probably most people using FreeRTOS thus far were using it for ordinary MCU stuff like listening for button presses and blinking LEDs without even involving a wifi transceiver at any point.

i would assume it’s like amazon linux; rhel with extras to make amazonization easy... but freertos rather than rhel

>Amazon FreeRTOS is based on the FreeRTOS kernel, a popular open source operating system for microcontrollers, and extends it with software libraries that make it easy to securely connect your small, low-power devices to AWS cloud services like AWS IoT Core or to more powerful edge devices running AWS Greengrass.

What devices (not chip) on the market that they support? I can't seem to find it anywhere.

They list 4 dev boards on their website, from Microchip, NXP, STM and TI. With the exception of the PIC from microchip it looks like they are all ARM based. Will be exciting to see if the ESP 32 becomes supported, since it already supports regular FreeRTOS

And they already habe AWS IoT support in their SDK.

I'm curious if there are commercial deployments on these types of IoT platforms? Last time I looked, it all seemed like devkits and examples and such. One project I was following - mbed from ARM - it is quite unclear if it ever made it beyond hobbyist/prototyping usage.

Agreed, a market survey of some sort would be helpful.

In the FAQ they mention that >64kB RAM is required. That doesn't answer your question, but it helps narrow down the answer. It runs over MQTT.

Really nice move, hopefully FreeRTOS becomes _the_ OS for those IoT MCUs similar what Linux does to higher end CPUs. It's always amazing to see many great OSS projects are primarily done by an individual while becoming extremely useful for so many.

Side note: I see that some of the graphic assets on the a:freeRTOS site have "Amazon_Treadstone_..." in the names. I imagine "Treadstone" was the internal project name for this initiative? Nice shout out to the Bourne series...

Amazon^WAmazing how four of the top page articles are about new Amazon products today.

I guess an old IRC joke is lost on this audience?

How does it compare to mbed-os?

I would say mbed is more like library ecosystem for ARM devices than OS. FreeRTOS is just a tiny microkernel that you can easily adapt it to any device.

Mbed OS supports a much wider range of boards and controllers: https://os.mbed.com/platforms/

mbed is only for ARM based systems (license limitation, not technology related), and in the embedded world there's much more than ARM.

FreeRTOS is easy to use on any and all CPU architectures, and is much more common. Actually, FreeRTOS is the most popular RTOS in the embedded world with Linux, and uptrending (see https://m.eet.com/media/1246048/2017-embedded-market-study.p... slides 62/63). This is a survey of professional embedded developers, not newcomers. Notice than mbed doesn't even show up. My feel is that mbed can be attractive to newcomers in embedded (easiness), but has not (yet?) much traction with people already doing embedded dev.

Good point: Mbed OS is only for ARM-based processors. The main difference lies in the vast number of drivers it offers, which is the reason why you already have 100+ supported boards today. In comparison, FreeRTOS would run on any MPU but without drivers you won't go far.

My money is on Linux based RTOS platforms. It's a bit of a surprise that Amazon has backed a non-Linux horse in this race.

Linux is totally unsuitable for the vast majority of microcontroller tasks. It has way too much overhead, requires a 32-bit CPU with MMU (or a very slow emulator like Dmitry Grinberg made[1], but that takes 6 hours to boot.) Microcontrollers that FreeRTOS is used on are very often 8-bit or 16-bit jobs, and even the 32-bit ones often lack an MMU. Linux on a micro is like trying to go to the corner store to get beer in a C5 galaxy transport aircraft.

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

Since linux also fundamentally has non-deterministic timing, which makes it incapable of doing what people want microcontrollers to do, you can replace C5 galaxy transport aircraft with a Nimitz-class aircraft carrier. It can't even get to your corner store without converting the street into a canal.

As a former embedded SW engineer, I'm willing to put money against it (for 99% of the use cases for micro controllers by volume), most of the ones I worked with were 8 or 16 bit, had at most 1 MB of volatile storage, and you were lucky if you had 1 MB of RAM to work with.

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.

No existing Linux-based RTOS that I know of will run on a microcontroller. Not enough Flash for program memory or RAM for volatile storage. Can any useful Linux-based RTOS kernel fit into 1MB of non-volatile storage and use less than ~512KB RAM; would love to know of one if it exists!

Replied as a sibling, and it certainly doesn't qualify as useful, but Dmitry Grinberg wrote an ARM emulator for AVR, soldered a SIMM to a board with an ATMEGA1284P and an SD card on an SPI bus connection, and got Linux to boot. The 24MHz clock rate is effectively reduced to about 6.5kHz, but it might be possible to find a use for such a device.

Interesting, thanks for sharing!

This is a common sentiment and I have a lot to say on the topic, so I'll try to keep it brief:

- 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.

Don’t forget power consumption - this is also a huge factor in the down-selection process for computing hardware. This is in addition to the others you mentioned, sometimes referred to as SWaP-C (Size, weight, power and cost).

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact