Hacker News Reader

Comment by jimmyswimmy | Hacker News Reader

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

View on HN

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

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

That's very much dependent on volume. $0.50 @ 1M units = $500,000k.

You'll always see the crunch at high volume it's just small to medium volume where your options open up. Back when I was in the smartphone business we'd easily see 10M+ volume on a single device and the associated BoM was tuned to a tenth of a penny.

Even at quantities of 1M, you barely would get ARM processors for $0.50 each, let alone entire BOM cost of a device.

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

Read what you quoted, let alone what I said fully, and you’ll understand how your comment is of questionable value. I clearly stated the entire BOM cost (which includes all other chips needed to make the device function), so your point is moot at best.

> Debugging hardware code written in Erlang sounds... challenging.

Depending on which part of the hardware code you need to debug, Erlang could make it easier; once you get the erlang shell running, you have hot code loading, some pretty extensive debug hooks, and nice bitmatching syntax. If the hardware code you need to debug is in the chain of getting to an erlang shell (getting the system running to the point where you can have a serial terminal and boot an OS), I don't think Erlang makes much of a difference -- projects big enough to run Nerves are likely going to run a full OS kernel, and Nerves is using a Linux kernel, once you can boot a Linux kernel, you've probably done a lot of the hard work.

Straight Erlang is not hard to debug. Functional language, little shared state, and much behavior in apps (for the Erlang geeks: pun intended) is based on message passing between processes, which is very well defined. That said, it gets much more complicated if you are using ETS or Mnesia (which builds on ETS), because now you have shared state, and that state has a rich API with lots of things that could be happening.

ETS interactions can be modeled as sending calls to a database server (but faster), you can use the debugging hooks to list all the calls to ets too.

My recommendation is to not do database reads and writes willy nilly all over the place, but to actually send sensible messages to a real server process, that does the interfacing with the database. Sometimes, it's useful to cheat and read ets directly, but it's really nice for writes to go through a server process, because the server process's mailbox provides an ordering for your writes, and you get to skip all the complexity of overlapping writes. In an mnesia system, that means writes should go to only one of the peers. (If you can divy up the writes to different servers based on the keys or something, then you can also divy up the servers onto different nodes).

All that said, distributed systems give rise to emergent behavior, but that's true if you program them in erlang, c, or assembly; it's just a little easier to get to crazy big systems in erlang. :)

Agreed, on all points, and that's basically what I do usually. I typically have a gen_server with a behavior defined data access and update message API, then that gen_server is the only process that can access a Mnesia table. I've seen a lot of code that doesn't do that though, and you still need to debug the gen_server if something goes wrong. If you use the gen_server approach though it is much easier to debug.

> when I think of embedded code I don't think of 12 MB.

That's one thing for creating a one off or prototype, but when a company creates millions of devices, the BoM becomes more expensive than developing a C version of the code to run in <1MB flash.

These days embedded is anything from multi-core systems with gigabytes OF RAM to tiny SoCs with barely a core and a few kilobytes of RAM

Reply on news.ycombinator.com