10 ms·
Nerves – Craft and deploy bulletproof embedded software in Elixir
- cztomsik 9y agoWhat makes elixir/erlang good fit for rpi? When compared to let's say rust or lua. Serious question, no offense.
- sunkencity 9y agoerlangs bit matching syntax, case statements for structs... incredibly elegant. I don't know about Rust or Lua, maybe they have this too.
- steveklabnik 9y agoRust doesn’t have the bit matching syntax, but we do have match generally.
- anuragsoni 9y agoIt'd be interesting to explore something similar to the bitstring[1] library for Ocaml. Where should one start if exploring syntax extensions for Rust. I haven't looked into rust in a while now so i'm not sure how far one can get with macros these days. [1] https://github.com/xguerin/bitstring https://github.com/xguerin/bitstring
- steveklabnik 9y ago“Macros 1.2” is what you want to look up; it’s in FCP right now!
- timgilbert 9y agoIn particular, the elixir_ale library is a very pleasant interface to various bits of hardware you might want to interact with at the GPIO/i2c/etc level. https://github.com/fhunleth/elixir_ale https://github.com/fhunleth/elixir_ale
- zeckalpha 9y agoMetaLua does!
- brightball 9y agoIMO the BEAM run time is ideal for it. If I were writing code to drop onto a small device, I’d want the capability to efficiently have a lot of things run at the same time with a small processor, to know that a single heavy unit of work wouldn’t negatively affect the responsiveness of everything else and to know that all of those tiny pieces were built to basically never go down. Personally speaking, it would be difficult to imagine using anything else for that type of work.
- elcritch 9y agoThe ability to utilize the BEAM's fully pre-emptive processes makes it great for programming hardware tasks and higher level tasks in the same environment. Compared to other languages like Lua, Node, Python, or even Go which all use various forms of cooperative multi-tasking or async-io. In these systems you have to be careful not to block other critical tasks. That's a pain but not the end of the world. However, for me the best feature is that I can remotely log into a running BEAM VM and interactively explore the live system [1]. Since Erlang has been used in "embedded" type systems for a long time there are a lot of useful libraries. For example a tiny bit of wrapper code let me setup a secure remote Elixir REPL using standard SSH keys for our embedded devices [2]. You can also run entire "applications" much as you would a system service, but which you can communicate with natively in Elixir/Erlang. Also the support for running sub-processes as ports is really nice. In general it's really more like a live operating system which you can program and investigate. The primary thing lacking is a capabilities system to allow running non-privileged code in a sand-boxed manner. 1: https://tkowal.wordpress.com/2016/04/23/observer-in-erlangelixir-release/ https://tkowal.wordpress.com/2016/04/23/observer-in-erlangel... 2: https://github.com/elcritch/iex_ssh_shell https://github.com/elcritch/iex_ssh_shell
- sevensor 9y agoNot an Erlang user, but I'm tickled by the idea of having a reliable cluster made out of unreliable little computers. Erlang has a great reputation for process supervision.
- elcritch 9y agoIt would be fun to build a redundant hardware control system which used three cheap SBC’s to do a form of Triple modular redundancy [1]. It’d be straightforward to prototype with Nerves/Elixir! 1: https://en.m.wikipedia.org/wiki/Triple_modular_redundancy https://en.m.wikipedia.org/wiki/Triple_modular_redundancy
- jbhatab 9y agoThere's a few reasons to use nerves, 1. It has a good system to hot load the code onto the pi and immediately start running your new code making deploys more efficient than other compiled languages. 2. Erlang uses processes which are very resilient and a good fit for projects that require constant streams of data & lots of connections which can be relevant in IOT. Basically the jobs restart themselves in a robust fashion. 3. Erlang runs on beam which is a well established VM that has years of development behind it making it a robust core for your project compared to some other operating systems that you may load onto your RPI. I don't think this is the biggest reason, but it is one. The hot reloading & concurrency model are my favorites & elixir is just fun to build in as well. I'm already using it for web so to bring it into IOT makes it natural for a web/IOT mixed project.
- dividuum 9y agoSince parent ask for a comparison with Lua and the Pi: I'm running a digital signage service (https://info-beamer.com/hosted https://info-beamer.com/hosted) that uses a custom minimal Linux (~35MB) on the Pi and a program written in C that is scriptable in Lua. One of the key features is hot reloading of code (and visual assets). Thanks to the flexibility and robustness of Lua that works incredibly well: You can even push new code to the central website using git, it instantly deploys it to connected devices and they reload their code. If done correctly you can update the content and logic your displays without any interruption. The C code is pretty robust for a few years now and never crashes or leaks memory.
- necrodome 9y agoThis is great. How is the business side of it?
- dividuum 9y agoLooking good. Once customers realize that our platform is far more powerful that just throwing a browser at everything, they get really excited. You can fully automate everything with the API, build perfectly smooth 60fps content and even play synchronized content across any number of screens. And a lot more. Coupled with the low cost and the reliability of the Pi, it really looks great. Still, getting the word out is difficult as the Pi is still considered a toy by many.
- equalunique 9y agoThe BEAM VM's preemptive multitasking may be a more efficient use of rpi's limited CPU in comparison to the cooperative multitasking of say NodeJS for example.
- jerf 9y agoBroadly speaking, Node is faster than BEAM: https://benchmarksgame-team.pages.debian.net/benchmarksgame/compare/hipe-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... Unless you're going pretty crazy with concurrency, BEAM isn't going to catch up to Node. BEAM is a beast when it's in its own runtime managing concurrency, but the bytecode interpreted language it implements is very "meh" when it comes to performance. (Since people seem to take these sorts of assessments personally, full disclosure and cards on the table: I massively prefer the BEAM world to the Node world. Nevertheless, the facts are what they are. The interpreter for BEAM is just not where you go for performance.)
- querulous 9y agosure, but you might not care so much for throughput in a situation where latency is critical
- dnautics 9y agoThese are mostly computational tasks... Why would you use BEAM for these?
- singingboyo 9y agoSeriously. Elixir/Erlang are VERY clear about the VM (BEAM) not being particularly good at intensive computation. Use a port (or NIF if you really need to).
- dnautics 9y agodon't do intensive computation in a NIF! You'll screw up the scheduler. Use a port.
- jerf 9y ago"What makes elixir/erlang good fit for rpi?" Honestly, I'd say it isn't a good fit for any particular reason. jbhatab isn't wrong, but there's other environments that will have other advantages over Elixir/Erlang/BEAM, depending on what you want to do. What is the case here is that the Raspberry Pi is basically a little computer and can run pretty much anything, Erlang included. Erlang was built in a world where a Raspberry Pi's specs would have been mindblowing, so it works just fine, just like anything else first built in the 1990s.
- hbcondo714 9y agoHere's an example posted on here yesterday fixing a Barcode Scanner using Elixir and Nerves: https://news.ycombinator.com/item?id=16902628 https://news.ycombinator.com/item?id=16902628
- punnerud 9y agoIt inspired me to do this post. Something that useful could not be hidden in the “dark”.
- desireco42 9y agoI only can say that I enjoy Elixir a lot and wish I had a project in mind where I can use Nerves. I am sure it will come.
- mmartinson 9y agoI think Nerves is cool because it really lowers the conceptual overhead for the cohort of web developers using Elixir to hack on hardware projects. There was a whole track on Nerves at ElixirConf in Bellevue last year, and I saw a ton of people who'd never done anything with hardware get really excited about it. The keynote by the Nerves creator Justin Schneck was particularly good. https://www.youtube.com/watch?v=bd_EIWU9GzQ https://www.youtube.com/watch?v=bd_EIWU9GzQ
- MisterTea 9y agoI've been following some of the interesting Erlang stuff for distributed embedded systems. A similar project which caught my eye is GRiSP https://www.grisp.org/ https://www.grisp.org/ Basically the BEAM VM ported to run directly on bare metal using the RTEMS RTOS (Think of it as a library that allows you to run a unix process on bare metal).
- e_proxus 9y agoI'm one of the developers on the GRiSP project. Our main difference is as you say, that we combine Erlang with RTEMS to make the Erlang VM essentially be the kernel (no Linux running underneath). This let's us use Erlang's inherent soft real-time properties more reliably and allow us to do more hard real-time things. Our low-level drivers for accessing hardware are written in C, and high level drivers are written in Erlang (for development speed, readability, testability, line count etc.) but can of course be written in C if you need the performance. I'd be happy to take questions about the project.
- X4lldux 9y agoProject looks very interesting! What hardware is supported? I've seen you product your own prototype board, but what about some off the shelf opensource openhardware solutions like BeagleBone Black or NextThing's CHIP?
- e_proxus 9y agoThanks! Right now only the GRiSP board is officially supported, although the project is made in such a way that new platforms should be easy to add. We're deliberately focusing on smaller platforms than the ones you mentioned. If a small Linux kernel can fit together with Erlang, you don't really need the RTEMS combo as much. That being said, we're happy to receive any contributions for other platforms, even larger ones!
- peerst 9y agoRTEMS supports all 32bit hardware architectures. We also run it on a PowerPC controler for a customer project, but it also runs on Sparc, Mips all Arm and many other architectures. We don’t use the MMU so we don’t need it, some embedded chips have even small MMUs that allows it running Linux size OS but since they have very small translation lookaside buffers it needs to traverse the in RAM page table very often and performance is quite poor then
- jimmyswimmy 9y agoHeh, when I think of embedded code I don't think of 12 MB. That's not to say this isn't useful. I usually try to size the hardware to the task. Sometimes the task calls for a little 8-bit micro, sometimes analog-only. When the job calls for a heavy linux-running processor, this seems like it could be interesting, as long as I can dig out all the details of what it's actually doing. The chips I use usually have an errata document 20+ pages long, and we usually find some new bugs to add to it during development. It's hard to code around hardware bugs period, and that's in a language hardware guys know, like C or assembly. Debugging hardware code written in Erlang sounds... challenging.
- jsjohnst 9y ago> Heh, when I think of embedded code I don't think of 12 MB. ARM processors are so cheap these days that I think your idea of “embedded” is a bit stagnant or too focused in one field. I’ve built and shipped a product where it had an ARM processor and ample flash (among a bunch of other components) packaged the size of a key fob and the BOM cost is way less than I used to pay for Arduino or other micro controllers.
- keithnz 9y agoIt's not that cheap, having recently gone through the process of looking at a hardware refresh of one our devices, anything that runs Linux ended up too expensive as it really needs something with a MMU and more RAM. Not to mention boot times are an issue. Real Time is trickier, also if low power is a issue, then it's really a bad idea. Rust is kind of interesting in this space, but a little bleeding edge, will likely look at adopting it later. Ended up picking an Cortex-M3 and using FreeRTOS. With a C / Lua mix. Not because I particularly prefer them, but it requires the least compromises. Also writing robust embedded C code is pretty well understood with many common patterns. Still, it requires being more diligent and disciplined than many other languages.
- spotman 9y ago> and the BOM cost is way less than I used to pay for Arduino one would hope so, arduino is a retail packing of other chips into a kit.
- Communitivity 9y agoI think I met the guy behind Nerves a while ago when he presented at an Erlang/Elixir meetup in DC, and had a good conversation. Smart guy, and the project was impressive. Also, as other commenters have pointed out, embedded doesn't mean what it used to. Embedded now can range from a custom real time operating system written in embedded C with memory allocations from a static pool to Java running on an Arm processor.
- atonse 9y agoAre you part of the DC Elixir community? I am too. Haven't had too many meetups recently. I too met the Nerves dude, very nice and approachable. I was proud to have such a project come out of my area.
- shock 9y agoThis looks very interesting but I haven't found any mention of GSM connectivity. Is there any?