If you're interested in seeing a (toy) example project in Nerves, I implemented my own version of an old Finnish reaction speed game [0]. It runs on an RPi0W that I had lying around and has a live score display over WiFi (using Phoenix LiveView [1]). I've still yet to implement a memory game mode, currently it only has the classic speed game (and pro version where you start at score 100, with the corresponding speed).
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]
Although pretty nice if you have a Linux host, I would say this isn't well suited to typical embedded IoT devices that would be used in large scale deployments. It would be cost prohibitive to blanket a city with temperature sensors if they all needed to use a $35 raspberry pi.
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.
To be fair, Pi Zero's are $5, which will happily run nerves. Outfitting with relevant hardware for the task at hand will of course increase the price (as would any hardware product), but the "$35 pi" is a little misleading. You are right that it will require larger hardware constraints, but there is a lot of nuance to the price discussion. Operationally, nerves grants you the ability to provision fleets and deploy updates in the field, rollback bad firmware pushes, etc. Value wise, this kind of feature set out of the box should factor in to life-time device cost considerations. I'm not aware of an equivalent offering on other platforms, but I'm admittedly just a spectator in this space.
True, but also consider you still need to add a radio and then run it all on batteries. There are much better solutions that still cost less. Not to mention, having to rely on Raspberry Pi of any kind for commercial use is tough in large quantities (speaking from direct experience).
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.
While i agree that products shouldn't ship on raspberry pi, it's not as nonviable as you might think.
> 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.
Didn't say Raspberry products aren't viable. I have shipped over 50k units with Raspberry Pi across three products. But the margins are terrible and many times a loss when you factor in user acquisition costs.
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.
A recent episode of the Smartlogic podcast[^1] interviewed the Nerves team and discussed this a bit. Their example was something like: you wouldn't build a smart lightbulb with nerves, but you might build the smart bulb hub with it. I think that makes a lot of sense and still fits a very good use case: something low power, but internet connected and possibly serving a UI over a browser or an API to a mobile app. There are a great number of IOT or IOT-adjacent projects that are a good fit for something like this, even if it isn't necessarily appropriate for everything.
Yep, 10 out of 10 of those "IoT frameworks" unequivocally qualify as epic fails.
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 agree with you totally, these IOT frameworks mostly have clients that do not really work properly on the "edge". Als IOT frameworks based on "runtimes" always have way too much overhead that does not scale.
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.
At least in Sydney, I found that bare-metal jobs typically paid far less and required far more experience. Some of the best engineers I know are being paid peanuts but are just happy to be quietly amazing in their corner.
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.
oi, I'm not extinct, it's just many embedded programmers, especially bare metal programmers, tend to hang out in very different places, if they hang out anywhere on the net at all.
I work with a few! So may have to get our pod registered as endangered species, I could monetize it by selling sightseeing tours for web and backend devs to see what real engineers look like.
Generally wages there correlate to the amount of productivity of the field.
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.
I used Nerves for a hobby project. A "smart" recycling bin which uses a camera to recognise recycling labels and open the lid of the appropriate bin. It was so much fun building it! Hooking a phoenix + LiveView backend was painless and straightforward.
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.
I hooked up a Raspberry Pi to some dev boards from Analog Devices to make a test rig with some analog and digital outputs and high precision ADCs. It was a lovely experience. Supervised Elixir genservers are a wonderful abstraction to wrap around hardware devices. Also, binary pattern-matching was a _dreamy_ way to work with registers over SPI. A Phoenix LiveView user interface on top was performant and convenient.
It took me a while to find that this targets linux boards (Raspberry Pi, Beaglebones), not the smaller embedded platforms that are often used in IoT. It may be more suited for industrial projects rather than consumer ones. Interesting nonetheless.
The original meaning of embedded has pretty much lost its meaning outside electronics engineering. I remember being taught that an embedded system has a microprocessor inside while it might not be readily apparent to the end user. It can be argued that nowadays many if not most electronic devices contain one and the user may assume so by default.
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.
There have been a few projects that use the PRUs with Nerves. It's pretty trivial to get setup. We've been trying to come up with a way to package an Elixir project to get started.
Please link me to some example code or articles! So excited to hear this is a thing, my absolute dream is to implement a PID control loop for a PRU in nerves.
I've tried to build several Pi projects over the years, and I'll happily plug Nerves as probably the easiest way to develop software that runs on the Pi, especially for the reliability. Genservers supervising sensor inputs and managing motor outputs is really simple to reason about. The easy learning curve is nice given how robust Nerves is under the hood. I've worked harder for less reliability.
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.
I've been looking at it many times, but I don't want to add myself work. Say I want to use RF24 (nrf24l01), if I just use raspbian I know it's an environment it's been tested on heavily, that all sensors libraries should just work because everybody is using the same hardware and software (in case of raspberry pi) and if it doesn't, I'm doing something wrong. But with heavily modified environment I don't want to spend 2 days debugging why i2c sometimes doesn't work or something like that. Am I understanding it wrong? Does anybody has some experiences to share?
To clarify I'm doing hobby projects, not industrial applications, but I do expect industrial-level reliability from my home automation.
If you want the reliability you open yourself to the eventuality that you might have to put in some of the work to achieve it. Things like SPI, I2C and GPIO can be expected to work with Nerves + Elixir Circuits. But some hobby hardware is definitely not straight forward since they tend to have libraries only in Python. I've ported one such myself (Inky eInk display) and many others have contributed similarly.
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.
Nerves looks very similar to Balena [1] which is definitely worth checking out if you want to manage a fleet of micoro-computers. Balena also uses light-weight docker containers which simplifies things nicely for developers who are more comfortable working higher up the stack.
Nerves is cool, until you realize it's basically all just ported C code that you're trusting to not crash the whole erlang VM. I say this as someone who does erlang professionally. It's effectively one huge NIF.
I'm still waiting for a nerves compatible PID control module!
Hello, Nerves Core Team member here. Unfortunately, most of this just isn't true and i'd like to address some of your concerns to prevent incorrect information from being spread.
> 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.
Hi, I apologize for the rather inflammatory nature of my post. I actually built a brewing controller back in the day with Nerves and it's still kicking today! At that point I was much more of an elixir noob and was referring back to my knowledge of nerves at the time.
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.
When I visit a site such as this (with 'fade up and in all of the content' animations), the first thing I do - is quickly scroll to the bottom. Then I scroll back to the top, so I can read it.
Your homemade solution to do hot code reload have nothing to do with Nerves though, it's just plain Erling/Elixir.
So again, what do I gain from using Nerves?
That's the beauty of Nerves in my opinion. We aren't trying to be a web framework. If that's what you want, bring it yourself.
Nerves is here as a tooling for deploying your application to hardware platforms. It takes care of all the stuff that most people don't want to deal with. This means that aside from learning some basic mix tasks (`mix firmware` to assemble your firmware and `mix burn` to write it to an SD Card), you don't need to "learn Nerves" only "learn Elixir".
As a casual user of Nerves, it's the easiest way of getting Elixir code running on a clean RPi system. I don't want to install a stripped down Linux myself, then install Erlang and Elixir, then transfer the built code every time and restart the board, or write scripts to do that. That would be a waste of my time when I just want to develop my app.
With Nerves I could just write code and run `mix firmware && ./upload.sh` (the upload script was generated by Nerves).
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...