5 ms·

I realize linux might be too heavy for many applications, but for any powered device, let's please make linux the default.

zwieback 12y ago
Generally, that's the way it's going but there are still many situations where a lightweight real-time kernel like uC/OS or ThreadX, etc. is preferable.
pinkyand 12y ago
Linux also means higher hardware costs and bigger size and worse peripheral selection. Those are critical parameters in this market.
- fragmede 12y ago
  > higher hardware costs Yes. > bigger size If you're comparing something like a bare ATTiny to a Raspberry Pi, sure, but the size difference between a standard Arduino and the Pi isn't great. > worse peripheral selection Um, compared to what? mbed, a new operating system, will have to have drivers written for everything it supports - which is likely much shorter list than for Linux.
WallWextra 12y ago
I'd really rather not have my toaster running, e.g., bash, since a toaster will never get firmware upgrades.
- mindslight 12y ago
  Rather than encouraging proprietary blobs that will have their own bugs and never get updated (if they're even publicly disclosed), we're better off solving the firmware update problem (eg GPL3).
  - georgemcbay 12y ago
    This only solves the problem in theory, not in practice. The vast majority of users aren't going to bitbake their own toaster firmware to fix bugs (nor will they even suspect the latest Linux bug might impact their toaster).
    - mindslight 12y ago
      So then you build auto-updating frameworks on top. If you don't start off with the option to DIY, you cannot possibly end up with a functioning market for repair service. It certainly beats the current standard of manufacturers dropping firmware support after 5 short years, and older devices being left completely high and dry for the sheer majority of people that don't update appliances based on fashion.
  - pinkyand 12y ago
    The GPLv3 model, i.e the need to release all your source, isn't compatible with the mindset of embedded product manufacturers, which are highly afraid of copying. Until you solve this mindset problem(god knows how), GPLv3 isn't a workable solution.
    - mindslight 12y ago
      Oh I'm well aware. Version control with something other than zip files isn't compatible with the mindset of embedded developers :P Right now I've got a dishwasher that pukes on every second cycle. I know it's a software problem, yet their solution is to replace the whole controller board, taking months to diagnose and order a new one. Luckily I don't own it, so I'm only paying for this circus with my time. The quip about GPL3 was meant as one possible example, although it does line up incentives pretty well. Users should be wary of devices that have worked quite well with mechanical timers/thermostats/etc being replaced with an essentially infinitely complex microcontroller, and the solution for taming that complexity to be the manufacturer retaining indefinite control.
      - pinkyand 12y ago
deleted 12y ago
[deleted]
swah 12y ago
I agree this has to be considered. I see this pattern some times: wow, this small device is really fun to work. Now I want to hook a camera (usb) and process the data (opencv) to do something. And I realize I should've been using arm + linux.
tmuir 12y ago
Maybe some people like reinventing the wheel with every piece of code they write Or, they like having a pool of only a couple hundred people that can help with problems, instead of a couple hundred thousand. Or they don't like the freedom to program in fifty different languages. Or they don't like a thoroughly tested, mature, code base. Perhaps they don't like when their code runs on multiple different processor architectures. Maybe they hate the abundance of freely available communication protocols, file systems, and graphical frontends. Maybe they're overwhelmed by the ease of searching for solutions to common problems because of linux's ubiquity. I don't get it.
monocasa 12y ago
Linux won't run on most Cortex-Ms that this is for. These devices have 192KB of RAM on the high end and no MMU.
Sanddancer 12y ago
Linux as the default for the sort of devices mbed is focusing on is, plain and simple, not feasible by any shape of the imagination. The first constraint is memory; the microcontroller world is full of very powerful chips that can only address a few kilobytes of memory. Using a chip capable of running any sort of Linux kernel means limiting yourself to chips that cost at least 5-10 times more than other chips, plus the added cost of RAM, plus the design costs associated with the extra chips and discrete components, etc. Second, you are limiting what you can do with the chip; Linux, for example, has no support for being an SPI slave device, so if that's part of your design requirements, you now have to start writing your own kernel drivers for something that's almost always built into other OSes/frameworks for microcontrollers. Finally, for many tasks, your code will end up being more complicated. Because power consumption tends to be crucial in a lot of designs, you want to spend as much time as possible sleeping, waking up only to handle whatever event you received. As such, most microcontroller frameworks have excellent support for event/interrupt-centric programming, where a device will only wake up long enough to handle the input at hand before going back to sleep. Linux just doesn't have the apis needed to support this sort of behavior well, which means you either need a proper real-time microkernel under Linux to handle your i/o, or you're going to be stuck putting all of your operations in kernel space, negating the point of Linux. In short, stating Linux should be the default is short-sighted and neglects a lot of what is going on in the systems that mbed is focusing on. Trying to wedge it in, or even think of wedging it in, is going to make your device more expensive, and less useful, than using the right tool for the job from the get-go. All the world does not need to be Linux.
justincormack 12y ago
Linux is just too big. And we need variety to explore new ideas.
fra 12y ago
Linux doesn't run without an MMU (cortex M only has an MPU). Furthermore, I don't think one size fits all. Putting a server OS on an embedded system is nuts and will hurt you across the board (power consumption, performance, ... etc.).
- unmole 12y ago
  Clearly you've not heard of uCLinux.

zwieback 12y ago

Generally, that's the way it's going but there are still many situations where a lightweight real-time kernel like uC/OS or ThreadX, etc. is preferable.

pinkyand 12y ago

Linux also means higher hardware costs and bigger size and worse peripheral selection. Those are critical parameters in this market.

fragmede 12y ago
> higher hardware costs Yes. > bigger size If you're comparing something like a bare ATTiny to a Raspberry Pi, sure, but the size difference between a standard Arduino and the Pi isn't great. > worse peripheral selection Um, compared to what? mbed, a new operating system, will have to have drivers written for everything it supports - which is likely much shorter list than for Linux.

WallWextra 12y ago

I'd really rather not have my toaster running, e.g., bash, since a toaster will never get firmware upgrades.

mindslight 12y ago
Rather than encouraging proprietary blobs that will have their own bugs and never get updated (if they're even publicly disclosed), we're better off solving the firmware update problem (eg GPL3).
- georgemcbay 12y ago
  This only solves the problem in theory, not in practice. The vast majority of users aren't going to bitbake their own toaster firmware to fix bugs (nor will they even suspect the latest Linux bug might impact their toaster).
  - mindslight 12y ago
    So then you build auto-updating frameworks on top. If you don't start off with the option to DIY, you cannot possibly end up with a functioning market for repair service. It certainly beats the current standard of manufacturers dropping firmware support after 5 short years, and older devices being left completely high and dry for the sheer majority of people that don't update appliances based on fashion.
- pinkyand 12y ago
  The GPLv3 model, i.e the need to release all your source, isn't compatible with the mindset of embedded product manufacturers, which are highly afraid of copying. Until you solve this mindset problem(god knows how), GPLv3 isn't a workable solution.
  - mindslight 12y ago
    Oh I'm well aware. Version control with something other than zip files isn't compatible with the mindset of embedded developers :P Right now I've got a dishwasher that pukes on every second cycle. I know it's a software problem, yet their solution is to replace the whole controller board, taking months to diagnose and order a new one. Luckily I don't own it, so I'm only paying for this circus with my time. The quip about GPL3 was meant as one possible example, although it does line up incentives pretty well. Users should be wary of devices that have worked quite well with mechanical timers/thermostats/etc being replaced with an essentially infinitely complex microcontroller, and the solution for taming that complexity to be the manufacturer retaining indefinite control.
    - pinkyand 12y ago

deleted 12y ago

[deleted]

swah 12y ago

I agree this has to be considered. I see this pattern some times: wow, this small device is really fun to work. Now I want to hook a camera (usb) and process the data (opencv) to do something. And I realize I should've been using arm + linux.

tmuir 12y ago

Maybe some people like reinventing the wheel with every piece of code they write Or, they like having a pool of only a couple hundred people that can help with problems, instead of a couple hundred thousand. Or they don't like the freedom to program in fifty different languages. Or they don't like a thoroughly tested, mature, code base. Perhaps they don't like when their code runs on multiple different processor architectures. Maybe they hate the abundance of freely available communication protocols, file systems, and graphical frontends. Maybe they're overwhelmed by the ease of searching for solutions to common problems because of linux's ubiquity. I don't get it.

monocasa 12y ago

Linux won't run on most Cortex-Ms that this is for. These devices have 192KB of RAM on the high end and no MMU.

Sanddancer 12y ago

Linux as the default for the sort of devices mbed is focusing on is, plain and simple, not feasible by any shape of the imagination. The first constraint is memory; the microcontroller world is full of very powerful chips that can only address a few kilobytes of memory. Using a chip capable of running any sort of Linux kernel means limiting yourself to chips that cost at least 5-10 times more than other chips, plus the added cost of RAM, plus the design costs associated with the extra chips and discrete components, etc. Second, you are limiting what you can do with the chip; Linux, for example, has no support for being an SPI slave device, so if that's part of your design requirements, you now have to start writing your own kernel drivers for something that's almost always built into other OSes/frameworks for microcontrollers. Finally, for many tasks, your code will end up being more complicated. Because power consumption tends to be crucial in a lot of designs, you want to spend as much time as possible sleeping, waking up only to handle whatever event you received. As such, most microcontroller frameworks have excellent support for event/interrupt-centric programming, where a device will only wake up long enough to handle the input at hand before going back to sleep. Linux just doesn't have the apis needed to support this sort of behavior well, which means you either need a proper real-time microkernel under Linux to handle your i/o, or you're going to be stuck putting all of your operations in kernel space, negating the point of Linux. In short, stating Linux should be the default is short-sighted and neglects a lot of what is going on in the systems that mbed is focusing on. Trying to wedge it in, or even think of wedging it in, is going to make your device more expensive, and less useful, than using the right tool for the job from the get-go. All the world does not need to be Linux.

justincormack 12y ago

Linux is just too big. And we need variety to explore new ideas.

fra 12y ago

Linux doesn't run without an MMU (cortex M only has an MPU). Furthermore, I don't think one size fits all. Putting a server OS on an embedded system is nuts and will hurt you across the board (power consumption, performance, ... etc.).

unmole 12y ago
Clearly you've not heard of uCLinux.