Hacker News Reader

I was hired to design embedded electronics in my last job. Came a project. I would have designed it with one microcontroller in the 50-120 MHz range, or two of those to make it easy to deal with all interfaces, and called it a day (on the electronic side) because almost nothing more was needed. It was basically just a glorified RS485 extender + Web -> RS485 interface. But our boss decided of the design: mandatory Linux and Python scripting, so we ended up with a Big Mama Ubuntu on a 1 GHz dual core processor with 512 MB DDR2 RAM... Because yeah, on the software side, you 'just' have to throw ready-made drivers and link pieces of ready-made software developed for the desktop. Supposedly...

The board ended up with 1500 components, it took 1 extra year to get just half of the features kinda working, the rest of the features was discarded. And the power budget was blown, which probably led to interesting negotiations with other involved bodies, but I had already quit at that time.

Obviously, 'embedded' meant very different things for me and for him.

It's fun being on the other end of the scale - the last major commercial project I did used an Atmel Atmega1284. Most other systems in this space go down the route of FGPA which is hell to support. I was actually amazed we got away with an 8-bit micro, but it was a great example of pushing the chip to its limits and comfortably achieving the goal of the project.

So, good case study

At the end of the day, it has nothing to do with what's good design or with which generation's philosophy we're going on. It has a bit to do with bragging rights but also any company selling a trivial doo-dad has a lot to gain in the vague importance scale by including including a whole OS with their doo-dad. They don't quite know what, they may not quite be thinking "now at least we're as important as a Russian mafioso running a giant botnet" but inherently the management has some kind of dream that's more likely to be satisfied by a million Ubuntu instances than a million light bulbs.

Just for example, they haven't got the gall or tech to put push ads from your light bulbs YET but I'd guess that's one of the things floating around some board tables somewhere ("but how to offer value with hmm..").

Those urges won't go away. They care more about themselves than the public or their customers? Who'd have thunk.

Welcome to the "everything's adversarial" era...

Let me guess, every missed milestone, was traded with the customer against additional features (for free of course?).

Some CEOs just try to postpone the day of deafeat to infinity by allowing customers to glue stuff to the device. Its like the captain of a sinking ship deciding to freeze all the water in it - making it float by the virtue of beeing a iceberg with scrap on the side.

It ponzi-scheme kinda works for a hellish year, and then it usually implodes under the weight of a crust of hacks.

> When it comes to capabilities, the people arguing for entire OSs generally win. Go with Linux, get an HTTPS stack, get XML parsing, get JSON parsing, don't worry so much about RAM.

Not where I come from. I have to fight to get 32-bit microcontrollers accepted. And there is zero reason to use 32-bit controllers over 8-bit controllers on new projects nowadays. Zero. None.

> And heck, the price different between a microprocessor and a microcontroller is minimal now days, a couple bucks in large quantity (especially if you have to outfit the microcontroller with more chips to add functionality).

Not even close. An ARM Cortex M0 is 70 cents. The cheapest ARM Cortex A7 is $10.

And the point of the microcontroller is that functionality is part of the part and doesn't require external chips (or at least a very minimal number).

> Of course against all of this, the analog EEs laugh at us and continue to make things that just /work/.

Uh, yeah, no. LOL. We just had an entire article dedicated to the weird and wacky ways that things can fail in the analog world (corrosion, light, standing waves, etc.). https://news.ycombinator.com/item?id=14765868

There is a reason everybody moves as much of analog and RF circuitry into digital as they can as soon as they can.

Analog and RF are notoriously unreliable and disgustingly difficult to debug. Once things hit digital land, they become repeatable and debuggable.

Hunting down a stack smasher is nothing compared to hunting down some screwball oscillation in an amplifier.

Besides, the individual rf components like synthesizers, attenuators, switches etc. that make up a system are all digitally controlled. You don't need much of a microcontroller to control them - I generally just use a PIC - but you need something.

And once you have a product with a serial or USB interface, some manager is sure to ask if you can add a LAN connection.

Yeah, and - to extend the smoke detector discussion - most modern smoke detectors are photoelectric and seem to have a somewhat involved state machine that periodically checks that the sensor is still working, calibrates for ambient light and component ageing, reduces false triggering, etc.

I was once told a long time ago that analog is proof that god hates us :-)

More capable devices are a liability if you don't really need them. If your product can work with a low end 8 bit microcontroller instead of a full Linux stack on a SoC, that also minimizes attack surface and rewards for attackers. It won't have enough resources to mine cryptocoins or run the Mirai botnet code even if it could be subverted.

Microcontroller? Often what you need is digital logic circuits, not even a microcontroller. (Of course, in your last sentence, you illustrate that even that may be too much.)

We're at the point where a microcontroller is simpler to manufacture and cheaper than a bunch of popcorn logic.

And in many cases, dramatically less reliable. If you care about such things.

Not every IoT company is fighting to get a full blown OS on everything. (speaking as a non-rep, please don't tell my boss I'm posting this :D) Here, I've noticed the hardware engineers regularly lambasting companies that "are just going to use linux," or think that the raspberry pi prototype they got running full blown linux means the solution at scale should be the same, when a simple microcontroller with maybe a hundred kilobytes max of RAM would do.

I generally fall into the microcontroller-fogey side of these debates. But the other side has an advantage in that "just use linux" is an easy, dumb choice that brings you into contact with the whole unix ecosystem.

There's always a certain cheezyness to your tools when doing what I think of as real embedded work. Probably the only nice part of it is the basic GNU compiler toolchain (if present). The rest -- including any high level development tools -- are either closed source, vendor specific stuff of varying quality or low quality half dead open-source projects.

Is there software that you can run on a Pi that emulates a microcontroller that uses the Pi's I/O pins? That might be an easier to use way to prototype, with the ability to restart the microcontroller while the host is still functioning. It could also be a nice way to emulate additional IoT devices in a neat little package, which might help simulations and debugging.

I think the problem is the realtime.

You can certainly write software that emulates a microcontroller on the Pi, but the problem is that it can't guarantee timing, since it's running on Linux fundamentally, and other processes can pre-empt it.

For certain things it doesn't matter as much, such as for a door lock or something like that. Then you gotta worry about power consumption, since running cables to your lock is problematic, and it has to run on batteries for months at a time.

That's a reason why realtime controllers can't run on Linux - if you were controlling an industrial robot that controls welding temperatures and times, even like 300 ms off can drastically affect the finished product with fit and finish and metal heat treating.

"This whole batch of parts worth hundreds of thousands of dollars went bad!"

"Well, the network is down, and the robot controller was busy trying to reconnect to the network, so that's why the welds were formed over 300 ms more than they should have been."

That can't cut it in industrial applications.

I think you're asking about writing "direct to the metal" software on the Pi, which I hope someone will address here. To answer your question indirectly, there are ways to bend Linux to do realtime like rt-preempt [0] but it doesn't go as far as RTLinux [1], which virtualizes the entire OS to run under a hypervisor that is essentially just a service routine for a hardware nonmaskable interrupt. Linux isn't even aware it's being preempted in this model. It's a beautiful approach, but RTLinux was proprietary and hard to write code for (because, interrupt handler), so it never achieved much traction.

[0] https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO

[1] https://en.m.wikipedia.org/wiki/RTLinux

The downside of a full blown OS is a lifetime of security updates and maintenance.

... or not. The "or not" is the real downside, and its what you're gonna get (see smart TVs, etc)

Ignoring the fact doesn't change it.

GP meant that companies aren't going to supply updates and maintenance, and that users would suffer for it. He wasn't ignoring any facts.

If users are being quantifiably harmed by lax IoT security then there will inevitably be lawsuits which will adversely affect the company that chose to pretend that Updates aren't necessary for a device with a full blown OS.

It might be hard to prove that someone has hacked your smart tv and is causing you monetary damages but all it takes is for one smart toaster to burn down a house to set a precedent for liability.

The question the manufacture needs to determine is the risk / reward value for their device and what could happen if it's hacked.