Price and memory size aren't the only considerations. This might have low power consumption.
These are seem to be mostly evaluation boards to check the chip against your requirements. After that, it might be just a few dollars to add the SoC, some DRAM and the passives on your product board.
It does seem like it at a first glance - these are Cortex-M microcontrollers which are really not suitable for running a full-fledged OS. They don't even have an MMU, and they usually only have ~10-100KB of RAM on the chip. Plus, only some packages with >144 pins are able to memory-map external RAM chips like these evaluation boards do.
It's a very cool and impressive project, but I wouldn't use it to write an application. Besides cost, the biggest reasons to use these instead of Cortex-A chips are power efficiency and simplicity, and implementing things like process isolation in software seems like throwing all that out the window.
But on the other hand, if your device will be plugged in and power consumption isn't a huge concern, I could definitely see the appeal to having things like a Ruby interpreter or an X server running on your MCU. You could compile and deploy existing code, ideally. But I bet it would take more time to get all of that working well than it would to just write your application with an SDK and an RTOS.
The MPU does look more capable than I'd originally thought, but it still seems very restrictive for general-purpose computing. 8-16 slots and difficult data boundary/width conditions:
Like I said, this is a very impressive project and I admire the people who were able to make it happen, but in the context of writing an application it sort of seems like a solution looking for a problem.
It reminds me of running Linux on the Nintendo DS. You can, and it's a fascinating toy, but the games are written bare-metal for a reason.
If the Linux kernel on STM32 has something important to offer for the application, like quicker time to market, while meeting the requirements and hitting price targets, why not?
But yeah, if I needed to run Linux, I'd quickly pick something like Cortex A53, Cortex R52... etc. But hey, there might be a niche for Linux running on STM32.
The Cortex-M controllers just don't seem too competitive for networked applications or anything requiring complex code/IO.
The cost for a full fledged ARM board is quite close to a STM32 with some addons, making me think one would be better off with something like an OrangePi Zero: https://www.aliexpress.com/item/32760774493.html
I've shipped a product with a Cortex-M3 running ucLinux.
Designs considerations included cost, of course. A comparable A series part would usually be double the price.
RAM is also built into the part or attached via a low speed or parallel interface. Once you get into higher speed A parts, you'll need DDR and all the multi-layer PCB design work that goes with it. More cost.
There was also development speed. I could use drivers and filesystems from the Linux tree without much extra work. I also recommend the EmCraft ports, they do great work.
No, that isn't Linux on a HDD microtroller. It's bare metal on an HDD MCU sort of fooling the Linux box that is accessing it. True that you can run uCLinux on some MCU devices, but this thread isn't necessarily showing the best one for that. Dancing bears are amusing, but not common or recommended.
I'm a much bigger fan of either bare metal or an RTOS for embedded systems; it's amazing how people will shoehorn Linux into places it doesn't belong, because Linux.
If you want to collect a few sensor readings and don't want to learn an entire new stack...just use Arduino. Yes it's "learning a new stack" but honestly I bet it's easier than getting Linux to run on something it shouldn't be running on.
That's not a law of nature though. Linus Torvalds hasn't decreed "thou shall not run this on an MCU". If it runs on an MCU that's fine. Theres a rich history of using computers for things they weren't designed for.
Id agree though, Arduino is in general the way to go, but STM32 is cheaper than Arduino and it depends what you're wanting to do.
Some STM32 chips can go below $0.50 (?). Not chips like in the article, though. Quick Digikey search came up with $0.83 for STM32L011F4U6TR (32 MHz Cortex M0+, 16 kB program memory, 2 kB data RAM, 512 bytes EEPROM).
Atmels ("Arduinos") were a bit cheaper in general, but then again it's hard to compare MCUs without application requirements in mind. Like if I needed 32 MHz Cortex M0+ class performance, comparable Atmels would be more expensive (I think).
The conclusion is, either one can be cheaper. Depends on the requirements.
> If you're going with an MCU that's uses Linux because you don't want to learn another platform you aren't the demographic to be buying bare chips.
Say, you have an existing prototype running on Linux and production ready (or nearly) hardware. Porting it to another platform might delay the launch and make you go out of business.
The other choice is SOC setups that are already proven with uCLinux, like the various chips used in home routers. Also minus MMU, etc, but with dev boards that already have reasonable amounts of RAM and proven field success.
That's why I'm confused with this project. FriendlyARM, for example, already has cheap uCLinux proven boards with a bundled display, which seems to be what this is trying to be.
I'm assuming this project was just a personal "itch to scratch", which is cool, but doesn't make it generally useful.
Yes, there are "better" choices, but perhaps not within product budget. Or perhaps missing some I/O feature, like high frequency ADC channels. Or any other parameter you need to optimize for. When you're making 100 000 gadgets, you really have to think about BoM.
> ... uCLinux proven boards with a bundled display, which seems to be what this is trying to be.
I don't see any reason to think that's what this projects tries to be? Just because some dev board happened to have a display?
> I'm assuming this project was just a personal "itch to scratch", which is cool, but doesn't make it generally useful.
Now, I don't see a need to personally use this project in production. But I don't either think it's outlandish if someone else does. In the end, nothing is generally useful in the embedded space, it's all just smaller and smaller niches.
Linux doesn't run on Arduino, except that guy who wrote an arm emulator, but I'll let you watch the video of it booting before you decide whether that's a valid exception.
Then you might as well just be using the STM drivers directly, and ignore the OS entirely. It would be a few trivial function calls into the C code for the sensors in question.
31 comments
[ 3.4 ms ] story [ 87.7 ms ] threadJust seems like taking a good product and trying to use it in an odd/unintended way.
These are seem to be mostly evaluation boards to check the chip against your requirements. After that, it might be just a few dollars to add the SoC, some DRAM and the passives on your product board.
And who cares about whether these are intended to run Linux or anything else. If it fits the requirements, just use it.
It's a very cool and impressive project, but I wouldn't use it to write an application. Besides cost, the biggest reasons to use these instead of Cortex-A chips are power efficiency and simplicity, and implementing things like process isolation in software seems like throwing all that out the window.
But on the other hand, if your device will be plugged in and power consumption isn't a huge concern, I could definitely see the appeal to having things like a Ruby interpreter or an X server running on your MCU. You could compile and deploy existing code, ideally. But I bet it would take more time to get all of that working well than it would to just write your application with an SDK and an RTOS.
Also, I'm guessing this project predates the STM32MP1: https://www.st.com/en/microcontrollers-microprocessors/stm32...
But they might have an MPU.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
http://embedded-computing.com/articles/security-and-the-cort...
Like I said, this is a very impressive project and I admire the people who were able to make it happen, but in the context of writing an application it sort of seems like a solution looking for a problem.
It reminds me of running Linux on the Nintendo DS. You can, and it's a fascinating toy, but the games are written bare-metal for a reason.
But yeah, if I needed to run Linux, I'd quickly pick something like Cortex A53, Cortex R52... etc. But hey, there might be a niche for Linux running on STM32.
Doing embedded (and drivers) at dayjob.
The cost for a full fledged ARM board is quite close to a STM32 with some addons, making me think one would be better off with something like an OrangePi Zero: https://www.aliexpress.com/item/32760774493.html
Designs considerations included cost, of course. A comparable A series part would usually be double the price.
RAM is also built into the part or attached via a low speed or parallel interface. Once you get into higher speed A parts, you'll need DDR and all the multi-layer PCB design work that goes with it. More cost.
There was also development speed. I could use drivers and filesystems from the Linux tree without much extra work. I also recommend the EmCraft ports, they do great work.
For example here is how to get Ubuntu linux to boot on an 8-bit AVR ATmega1284p, by emulating ARMv5: http://dmitry.gr/index.php?proj=07.+Linux+on+8bit&r=05.Proje....
Here is linux on a hard drive microcontroller http://spritesmods.com/?art=hddhack&page=1
There is even a port of linux, uClinux, that doesn't require an mmu. http://www.uclinux.org/ports/
No, that isn't Linux on a HDD microtroller. It's bare metal on an HDD MCU sort of fooling the Linux box that is accessing it. True that you can run uCLinux on some MCU devices, but this thread isn't necessarily showing the best one for that. Dancing bears are amusing, but not common or recommended.
That's not a law of nature though. Linus Torvalds hasn't decreed "thou shall not run this on an MCU". If it runs on an MCU that's fine. Theres a rich history of using computers for things they weren't designed for.
Id agree though, Arduino is in general the way to go, but STM32 is cheaper than Arduino and it depends what you're wanting to do.
Wait, what? Did you mean the opposite?
Atmels ("Arduinos") were a bit cheaper in general, but then again it's hard to compare MCUs without application requirements in mind. Like if I needed 32 MHz Cortex M0+ class performance, comparable Atmels would be more expensive (I think).
The conclusion is, either one can be cheaper. Depends on the requirements.
A low end STM32 with KB of ram isn't going to boot Linux.
The cost comparison of "STM32 that can reasonably run Linux" vs "Atmel that can reasonably run Arduino" is a chasm.
If you're going with an MCU that's uses Linux because you don't want to learn another platform you aren't the demographic to be buying bare chips.
Can you even get bare stm32s in hand solderable form factors???
Say, you have an existing prototype running on Linux and production ready (or nearly) hardware. Porting it to another platform might delay the launch and make you go out of business.
Just playing devil's advocate.
That's why I'm confused with this project. FriendlyARM, for example, already has cheap uCLinux proven boards with a bundled display, which seems to be what this is trying to be.
I'm assuming this project was just a personal "itch to scratch", which is cool, but doesn't make it generally useful.
> ... uCLinux proven boards with a bundled display, which seems to be what this is trying to be.
I don't see any reason to think that's what this projects tries to be? Just because some dev board happened to have a display?
> I'm assuming this project was just a personal "itch to scratch", which is cool, but doesn't make it generally useful.
Now, I don't see a need to personally use this project in production. But I don't either think it's outlandish if someone else does. In the end, nothing is generally useful in the embedded space, it's all just smaller and smaller niches.
Linux doesn't run on Arduino, except that guy who wrote an arm emulator, but I'll let you watch the video of it booting before you decide whether that's a valid exception.
Yeah, TQFP is fine to hand solder. We're starting to use as we move on from AVRs. But no, definitely not running Linux.