4 ms·

There is a battle between the old school people who want to do everything with microcontrollers and who measure RAM in Kilobytes, and the new generation who wan

There is a battle between the old school people who want to do everything with microcontrollers and who measure RAM in Kilobytes, and the new generation who want to embed a full microprocessor + OS in everything. 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. 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). The microcontroller people are right in one way though. Their products are simpler. Battery life will be better (it is easier to control power usage when you start with nothing and build up, then trying to minimize an entire OS down) and the code will be purpose built with less complexity to it. The ESP8266, ESP32, and Arduino are one view of things, Raspberry Pi and "Things with Android Running On Them" are another. Of course against all of this, the analog EEs laugh at us and continue to make things that just /work/.

DougWebb 9y ago
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.
- jimmywanger 9y ago
  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.
- dreamcompiler 9y ago
  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 https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO [1] https://en.m.wikipedia.org/wiki/RTLinux https://en.m.wikipedia.org/wiki/RTLinux
anyfoo 9y ago
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.)
- monocasa 9y ago
  We're at the point where a microcontroller is simpler to manufacture and cheaper than a bunch of popcorn logic.
  - dreamcompiler 9y ago
    And in many cases, dramatically less reliable. If you care about such things.
komali2 9y ago
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.
philipkglass 9y ago
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.
wott 9y ago
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.
- joshvm 9y ago
  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.
- joe_the_user 9y ago
  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...
blackflame7000 9y ago
The downside of a full blown OS is a lifetime of security updates and maintenance.
- VLM 9y ago
  ... or not. The "or not" is the real downside, and its what you're gonna get (see smart TVs, etc)
  - blackflame7000 9y ago
    Ignoring the fact doesn't change it.
    - benchaney 9y ago
      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.
      - blackflame7000 9y ago
        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.
bsder 9y ago
> 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 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.
- jpindar 9y ago
  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.
- makomk 9y ago
  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.
- MarkMMullin 9y ago
  I was once told a long time ago that analog is proof that god hates us :-)
bsder 9y ago
> 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).
adrianratnapala 9y ago
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.

DougWebb 9y ago

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.

jimmywanger 9y ago
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.
dreamcompiler 9y ago
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 https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO [1] https://en.m.wikipedia.org/wiki/RTLinux https://en.m.wikipedia.org/wiki/RTLinux

anyfoo 9y ago

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

monocasa 9y ago
We're at the point where a microcontroller is simpler to manufacture and cheaper than a bunch of popcorn logic.
- dreamcompiler 9y ago
  And in many cases, dramatically less reliable. If you care about such things.

komali2 9y ago

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.

philipkglass 9y ago

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.

wott 9y ago

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.

joshvm 9y ago
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.
joe_the_user 9y ago
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...

blackflame7000 9y ago

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

VLM 9y ago
... or not. The "or not" is the real downside, and its what you're gonna get (see smart TVs, etc)
- blackflame7000 9y ago
  Ignoring the fact doesn't change it.
  - benchaney 9y ago
    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.
    - blackflame7000 9y ago
      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.

bsder 9y ago

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

jpindar 9y ago
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.
makomk 9y ago
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.
MarkMMullin 9y ago
I was once told a long time ago that analog is proof that god hates us :-)

bsder 9y ago

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

adrianratnapala 9y ago

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.