3 ms·

Unbelievable proof of concept. It is just genius that this guy made this. But what do you think that we can get out of this? Are there any practical reasons to

by pant 12y ago

Unbelievable proof of concept. It is just genius that this guy made this. But what do you think that we can get out of this? Are there any practical reasons to run Linux on Micro-controller?

cnvogel 12y ago
> But what do you think that we can get out of this? One can learn that sometimes it's worthwhile, or even the prudent thing to do, to emulate the hardware instead of porting code. Emulating a 32bit CPU on a 8bit µC is certainly a little over the edge, but it's not unheard of to emulate a legacy/antique CPU on a newer one to make use of proven code. See for example the ancient HP48 calculators, where the obsolete original device (HP48) is emulated on the contemporary ARM CPU (HP50) to be able to reuse the proven old codebase. Or you might invent your own bytecode that isn't as intricate as implementing a full ARM computer, but maybe give you amenities like high precision math, or better sting handling, or portability between different microcontrollers (if you are a company supporting several generations of platforms)... > Are there any practical reasons to run Linux on Micro-controller? If you don't restrict yourself to 8-bit microcontrollers, you can run Linux on MMU-less Cortex-M3/M4: You loose all the convenience of memory-protection (apps can crash each other by writing in foreign memory space), have severe restrictions in your API (no mmap, restrictions on fork(), memory fragmentation issues, ...), but you gain a very powerful networking stack, filesystems, a LOAD of existing device drivers, ... that you would otherwise have to rewrite for yourself.
- nly 12y ago
  > it's not unheard of to emulate a legacy/antique CPU on a newer one to make use of proven code. It's probably less to do with using proven code and more to do with maintaining perfect bug-for-bug compatibility. You can't even reimplement the bugs you haven't discovered yet. Also, writing an interpreter for most microcode is fairly methodical. Depending on what level of detail you need to emulate (clock timings, interrupts etc) it could be quicker and simpler than digging up an old fossil of a developer who knows enough about the original software to port it for you.

by pant 12y ago

Unbelievable proof of concept. It is just genius that this guy made this. But what do you think that we can get out of this? Are there any practical reasons to run Linux on Micro-controller?

cnvogel 12y ago

> But what do you think that we can get out of this? One can learn that sometimes it's worthwhile, or even the prudent thing to do, to emulate the hardware instead of porting code. Emulating a 32bit CPU on a 8bit µC is certainly a little over the edge, but it's not unheard of to emulate a legacy/antique CPU on a newer one to make use of proven code. See for example the ancient HP48 calculators, where the obsolete original device (HP48) is emulated on the contemporary ARM CPU (HP50) to be able to reuse the proven old codebase. Or you might invent your own bytecode that isn't as intricate as implementing a full ARM computer, but maybe give you amenities like high precision math, or better sting handling, or portability between different microcontrollers (if you are a company supporting several generations of platforms)... > Are there any practical reasons to run Linux on Micro-controller? If you don't restrict yourself to 8-bit microcontrollers, you can run Linux on MMU-less Cortex-M3/M4: You loose all the convenience of memory-protection (apps can crash each other by writing in foreign memory space), have severe restrictions in your API (no mmap, restrictions on fork(), memory fragmentation issues, ...), but you gain a very powerful networking stack, filesystems, a LOAD of existing device drivers, ... that you would otherwise have to rewrite for yourself.

nly 12y ago
> it's not unheard of to emulate a legacy/antique CPU on a newer one to make use of proven code. It's probably less to do with using proven code and more to do with maintaining perfect bug-for-bug compatibility. You can't even reimplement the bugs you haven't discovered yet. Also, writing an interpreter for most microcode is fairly methodical. Depending on what level of detail you need to emulate (clock timings, interrupts etc) it could be quicker and simpler than digging up an old fossil of a developer who knows enough about the original software to port it for you.