Nerves – Elixir Platform for IoT
nerves-project.org
nerves-project.org
You can find the source on GitLab [2] with the interesting part being in the lib folder. The game folder there contains the game part, while web contains the score UI. It's somewhat messy as I was learning both Nerves and LiveView and just trying out different things.
The hardware is still in prototype stage and the LED lights aren't even inside the buttons. I have to say, for me the implementation of the game logic in Elixir was much easier than planning and soldering the electronics! [3]
[0] https://www.youtube.com/watch?v=C8gbcYwmpvU
[1] https://github.com/phoenixframework/phoenix_live_view
[2] https://gitlab.com/Nicd/ex_speed_game/
[3] https://drive.google.com/file/d/1zc_HlcMH3QfayqxRqWYN9M-duCN...
FYI, [3] doesn't work (access denied)
Many IoT devices run on very limited hardware mostly without an MMU, usually shared with the Radio like the Nordic NRF52 or Semtech's Lora modules. Often times with serious size, power, and cost constraints. This often rules out higher level languages like Erlang, Go, etc. These are great languages for different use cases, but really not well suited to any low level hardware. The runtime language has huge impact on cost and battery performance. More memory == more $$, more CPU cycles == more power.
As a hobbyist tool, this is great and nothing wrong with it. But in the traditional IoT sense, we are usually talking large volumes of cheap devices running on batteries.
> Not to mention, having to rely on Raspberry Pi of any kind for commercial use is tough in large quantities
Maybe you weren't talking to the right people? I've shipped two products using raspberry pi and getting them in quantity was never a problem for me. we could easily get them in quantities of 500-1000 at a time for the RPI0W models and the RPI3B+ models.
> True, but also consider you still need to add a radio and then run it all on batteries
I don't think Nerves is a great fit for battery power, but RPI0W comes with a BLE and WiFi radio built in. It's also easy to add LORA or other sub ghz radios.
RPI0W is now double the price at $10. You still need to add power (lipo and/or charger), enclosure.
With Raspberry Pi stuff 1.) There is nearly 0 (max I have seen is $2 off) price break at volume. 2.) You have essentially one vendor (that uses distributors) 3.) When a new version launches, the older version inventory gets very constrained. 4.) You can't customize the PCB 5.) You can't get any support from Broadcom
I mean a lot IoT problems/solutions seems all about tiny things running on coin-cell batteries for years.
I guess the point is that there is a huge difference between hobbyist and commercial viability. It is a significant gap in terms of engineering effort and target BOM costs between the two. Have seen countless products fail because people with no commercial hardware experience tried to launch a product with hobbyist tools and components.
But, again, as a hobbyist it is fine. If you are considering commercializing your hobby project one day, then I would think about it differently. At least consider Rockchip. You can get a Raspi clone for less money and can work with them to customize if needed. If it runs on batteries in a small form factor, would reconsider using linux.
[^1] https://smartlogic.io/podcast/elixir-wizards/s4e13a-dojo/
- Learn about comms protocols, IP, CoAP, MQTT, UDP, etc, etc
- Learn about driving hardware.
- Learn about bare-metal programming.
- Learn Cortex-M
- Stay away from raspberry pi and arduinos in order to get properly marketable skills (real devices tend to use Cortex-M).
- Stay away from anything with Python or JS on a micro... again... market realities.
As of recently, I had to work on Microsoft Azur IOT. Their "embedded" library doesn't even load into memory if you are not plugging in an external ram on the most beefy MCU on the market. It takes 1mb+ to do a very, very basic HTTP+TLS+JSON parsing. And even this way, it often triggers watchdog on moderately long transfers.
-----
On a sidenote, had a conversation one time with an ex-webdev in the setting of developing for MCUs:
— "How did you get it to 1MB?"
— "I shortened the strings, and removed the dead code!"
— "No, I mean, how did you manage to get it past that 1MB?"
-----
It's quite hard finding experienced non-webdevs in general these days, but among those, the number of people who can do C for embedded (and under embedded I mean bare metal, not Linux on SBC) is so low that we can say that real embedded devs have pretty much went extinct.
I have seen some technology that is amazing though, for example DDS, Zenoh, OPC UA.
I for once look at the side of, reliability and quality of the signals. Most IOT frameworks don't care about when or how the data arrives. What about QoS ?? What about Jitter of the signal?
If people use Managed languages in IOT, for example the hobby stuff like micropython on microcontrollers. It's fun for hobby. But nothing else. Waisting alot of resources etc.
A good IOT frameworks consists out of a Tweakable QoS for the data from hard-realtime with (TSN time sensitive networking) up to soft to no-realtime data. Network will balance things out regarding the QoS.
What if i need an IOT platform/framework and need hard-realtime data between a sensor somewhere and a robot with a control loop?
Reliability, scalability , adjustable QoS of signals, and also low on resources that can run on Microcontrollers with TCP stack that enables TSN.(Therefore an RTOS is best solution, but rather no RTOS if possible) (And two NIC's to make reliable hardware, when you have hardware failure)
For one project I've spent considerable time trying to get the Azure IoT SDK going on a low-cost Wifi chipset, only to find out that it ended up not working after all the platform glue was in place because of inexplicable decisions from both the host APIs (no source code access, of course) and the Azure SDK, making most of the built-in functionality (eg https/MQTT/encryption) useless for Azure, resulting in not only code bloat, but also running out of heap memory with fantastic silent crashes.
After spending weeks on trying to fit everything into ROM in the first place. The end-result was ditching the SDK and re-implenting most of MQTT and websockets before the project was ultimately canned for other reasons.
A pi zero w, otoh, costs about $20 (with a reasonable SD card) vs $5 for something like the ESP32, and makes life easier with unlimited storage and open source platform code, but it is impossible to mass-produce anything for under about $120 retail cost due to the high price of the rpi alone, which is a real bummer in a competitive IoT market.
I was proper bare metal at one point (even wrote my own crappy rtos at one point) but couldn't resist the better pay and better treatment that you get up the stack.
Or we may be the last two left standing... we have the market to ourselves, time to pump up the rates! ;o)
Embedded / firmware takes a lot more tedious work, often requiring more people and time and that's just for a single purpose device. Whereas a few Web developers can create a web service that runs an entire profitable company with tens of thousands or millions of users. Of course that's the generalization but I'd guess it's a 1:10 or at least a 1:5 ratio on the income/profit vs development time/effort required between web dev and embedded.
I strongly believe that projects like Nerves can help lower that ratio and make a lot of IoT type projects follow economics more similar to web development. Sure a RPi costs $35 per unit, but lets say you're making a veterinary monitoring system which costs $100k for the software it fits into the budget much easier if a couple of devs can implement it in weeks versus the months and/or large teams it used to take. There's a lot to be said for the long-tail of economics in areas where leveraging more productive tooling can increase productivity and profitability.
Unfortunately that only generally applies to roughly pre-canned hardware and commodity sensors, etc. You won't get that effect when building say a new Camera Sensor CCD chip.
> As of recently, I had to work on Microsoft Azure IOT: Their "embedded" library doesn't even load into memory if you are not plugging in an external ram on the most beefy MCU on the market.
AWS Greengrass has the same issue, it only runs on Raspberry Pi's and up, which is like using a semi-truck as your daily driver in a city where a good bicycle is all you need. At worst we need things to load into 0.5MB with room to spare for our own code too. At best we'd like things that could load into 32KiB with room left over for our own code too.
32KiB lets me get temperature/humidity monitoring over WiFi working at <$2 per sensor+wifi+mcu. So if you need 200 sensors to monitor a space, that's just $400 for bare minimum parts, not including enclosure or power supply.
0.5MB raises that price to $5/unit, but mcu's that can handle this can also generally handle generating/using enterprise-grade wifi certificates, which might be nice.
Using AWS Greengrass / Azure IOT means I need to use a raspberry pi, so $38 or so per unit. Now instead of $400 you're looking at $7,500 for baremetal parts. Put another way that would raise a hypothetical consumer-oriented device's MSRP by $100 vs whatever it would be if it could use the lightweight $1 mcu.
Overview of AWS IoT offerings and what they can run on: https://blog.ippon.tech/exploring-iot-infrastructure-support...
I don't care that it's not the most efficient framework or not suited for industrial stuff, it does drive my creativity and brings me joy.
Would recommend.
I've seen a wide range of devices being marketed as embedded, from the truly low-power microcontrollers using one lithium battery's worth of energy over its lifetime up to a PC with a fast x64 processor in a signage system.
But anything where you might want a non-trivial web UI? Something closer to a smart weather station with streaming data? This would be great.
Also... Rust based NIF's (bits of code in other languages that can be wrapped as modules in elixir) are insanely cool!
This is somewhat old now, but the PRU code which i find to be the most important part is still good.
Nerves I still love you!
Nerves is also the first Pi software that worked the very first time I plugged in the flashed memory card, which was a really good start.
I'm currently adding Nerves/Pi to a small home autonomous robot and it's been very easy for a guy who definitely isn't a hardware expert. I'm looking for other fun ideas, if anyone has a good idea. I live in an apartment, so indoors ideas only for now.
To clarify I'm doing hobby projects, not industrial applications, but I do expect industrial-level reliability from my home automation.
Nerves is good for hobbyists that want a better workflow and more serious and reliable setup. But it focuses on solving for production devices of you compare it to Raspbian.
I'm still waiting for a nerves compatible PID control module!
> until you realize it's basically all just ported C code that you're trusting to not crash the whole erlang VM.
We rely on very little C code at runtime. The networking libraries have a tiny bit of C glue code to talk to Linux, but other than that we use mostly Elixir. I've been shipping Nerves in production for 4+ years now and "trusting C code not to crash" has never been a problem for me or anyone else I know using Nerves in production.
> It's effectively one huge NIF.
We actually don't have any NIFs in the core of Nerves. You would have to bring them in yourself, which I expect would be caught in the dependency screening process of your project. Any time we need C to access something in Linux, we usually reach for Ports since they can be properly supervised.
> I'm still waiting for a nerves compatible PID control module!
there is at least one PID library in Elixir that I know several people have used, and at least one company uses in production.
I wish you had done a bit more research before writing this message, but I hope I've addressed any concerns for future viewers.
Thank you for educating me and informing me that I was wrong ;). We need more people like you who know how to tell others they're wrong while doing so in a cordial and friendly matter.
cheers!
Is it really only a way do package the Elixir app with a Linux distro and a template config that includes a couple of hex dependencies?
With Nerves I could just write code and run `mix firmware && ./upload.sh` (the upload script was generated by Nerves).