Also Fuzix, which can run a Unix-like on a variety of tiny, ancient processors like the Z80 and 6809; I've ported it to the MSP430, a modern micontroller, and I also have a half-finished port to the Raspberry Pi that I must get round to fixing one day (hilariously, the Pi has more RAM than Fuzix can handle)...
Considering that the first Unix was on a PDP-7 with roughly the same computing power, and many embedded systems are of similar capacity yet also run Unix-likes, it's not all that surprising. (Depending on what you call "Unix-like" --- I'd say any OS with a unified hierarchical filesystem and devices-as-files to varying extents qualify.)
Personally I like the idea behind RetroBSD [1] - port of 2.11BSD Unix intended for microcontrollers.
I was thinking if a system like this powered by solar panel would be a good idea for poor countries. The idea is to have computing of the past in sustainable form available for poor. The main problem is probably to have a cheap and low energy display. Maybe epaper made in bulk would be enough? But probably such a computer can only be cheap if made in bulk. Maybe it could be cheaper than RaspberryPi? The question that remains is what about networking? Maybe they could function in similar fashion to BBS, but using shortwave radio?
It sounds like you're about to re-invent the failures of "One Laptop Per Child".
The one thing people in poor countries do not want is special weird incompatible systems designed for the poor. They want a solution which is adequately close to the western ones, just cheaper. Look at cellphones: http://qz.com/451844/africas-smartphone-market-is-on-the-ris...
I also think that smartphone will get there faster. Maybe Chromebooks if Google will play it nice, because of Android apps support and normal keyboard.
However I think OLPC is different from what I have in mind. OLPC targeted children with OS designed for children. I am thinking about something more like RaspberryPi with integrated power and display systems, but with external keyboard. Also I think about it to be extremely cheap. $100 laptop is already done by Chromebooks, but it is not cheap enough. It would have to be around $25 or less. It should expose GPIOs like RaspberryPi so it could be used in more settings. It would be black and white and mostly text only. Basically my pipe dream. Maybe I would just like to go back in time sometimes and I am just projecting?
It is just a loose idea, but outside of people's preferences economics of scale are certainly supporting smartphones.
Sure, that's what you'd want; is it what the target market wants? Would people be happy limited to B&W text?
For something like what you've described, the cost is driven by casework, screens, touchscreen components and batteries. Not the processing electronics. It sounds like something halfway between a Kindle with a keyboard and one of the cheap Windows tablets, now below $100. (http://www.dx.com/p/onda-8-v820w-quad-core-dual-os-tablet-pc...)
Perhaps a cheap phone combined with a cheap, keyboard accessory and bundled software would be better? Definitely include Wikipedia app on homescreen and Python w/ learning guide somewhere on there.
"It is common to see newbies asking in microcontroller forums if they can run Linux on their puny little 8-bit micro. The results are usually laughter..."
The reason why...
"uARM is certainly no speed demon. It takes about 2 hours to boot to bash prompt ("init=/bin/bash" kernel command line). Then 4 more hours to boot up the entire Ubuntu ("exec init" and then login)."
It is so slow. Btw if you ever ask about system compiles of Elm on RaspberryPi which requires Haskell, you'll get similar responses.
One is better using a programming language with a rich runtime when targeting such processors, but newbies aren't going to search for programming languages with bare metal toolchains.
Chrome gives some ssl-shaming for this site that I haven't seen before. An angry red warning and text that says "This site uses a weak security configuration (SHA-1 signatures), so your connection may not be private."
> That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.
was reading about instruction sets a couple of hours ago, the performance bottleneck is often the memory pipeline not so much the size of the instructions
More like Linux on 32-bit ARM, but running in an emulator on an 8-bit processor. I don't think this qualifies as “Running” Linux on an 8-bit processor.
I voiced the same complaint when somebody claimed to “run” Windows 3 on an Apple watch (IIRC), which also was achieved by running a standard PC-hardware emulator, and running Windows 3 on that.
These are somewhat interesting accomplishments, but the click-bait factor is high.
So Linux isn't 'running' on your x86_64 cpu because cpu is microcoded... or transmeta? Or... Linux is written in C.. so it's not running on your computer because it doesn't execute C directly?
Come on. There is a 8-bit microcontroller running a linux system, the rest is implementation details and semantics.
I think the argument is that one would expect "Linux running on architecture Foo" to imply support in Linux for Foo, rather than support in Foo for Linux that allows Linux to run unmodified. I certainly expected, when I clicked, to read about someone's effort to rewrite a minimal subset of the Linux kernel to use exclusively 8-bit registers and no MMU.
Linux can already run on MMU-less systems (CONFIG_NOMMU). GCC already supports AVRs, though you may have to tweak the backend a bit so ints are 32-bit wide etc.
These are not the big issues in porting the Linux kernel to an AVR. The major problem is that AVR is Harvard architecture and there's probably tons of assumptions in the kernel that code and data resides in the same memory space.
- also ATmega1284P and ATmega644A mentioned in the article doesn't support external code memory nor changing the code memory after boot. However they do support a boot loader that can load code initially. So you would have to implement some sort of paging by resetting the cpu to give control to the bootloader to load the new code. Sound like fun. Also the kernel itself is far too large to fit in code memory, so it would constantly have to page parts in and out through this mechanism.
Rhetorical question: If writing the emulator was the “crux”, then why doesn’t the headline mention it? Why isn’t the whole article about it? I would certainly have upvoted and whole-heartedly lauded a story entitled “An 32-bit ARM emulator for an 8-bit CPU”.
Instead, they used the headline and article content to heavily imply to actually have ported Linux to an 8-bit processor. It’s not until into about half the article that they reveal the emulation bit. Therefore, click bait, pure and simple.
There is some wonderousness that they completed the emulation enough to run something complicated like linux.
Its very easy to use something limited, say a HP48 in RPN mode and some arrays as "memory" and variables as registers to implement a couple opcodes of say a 68hc11. I did that around '93 or so when the 'hc11 was contemporary (its ancient history now, but it was kind of a 6809-like microcontroller with pretty good specs for the era)
On the other hand its hard to get a complete emulator working of everything, or at least close enough to everything to boot a major software project on top of it.
Sort of like implement a system/360 emulator that only does opcode ADD, well, ok cool, but when you can boot MVS/360 thats a whole nother level of wow.
Sure it’s a cool emulator. Which is why they should have led with that. But they implied they did something else and waited until half the article to even mention the emulator.
I'm with you on the title and such. I thought it was a port of Linux to 8-bit with something like uCLinux. Then I saw it was a project emulating a 32-bit CPU to spend 4 hours booting Ubuntu. A cool accomplishment but not what title made me think.
Indeed! It is also a nice real-world analogy to the idea of a Turing machine. As long as the machine can advance and rewind the tape, and read and write to the tape, it can accomplish any computational task...
I find tl;dr to be extremely useful to find out if the article is worth reading or not.
There is no joy in being fooled by a clickbaity title. Also, HN is not a novel book, therefore I do not feel spoiled. I always silently thank people that write tl;dr. They try to save my time.
I somewhat agree; TL;DR can seem dismissive and certainly discards most of the value of the actual article.
In this case I did it because the title made me wonder if this was the article I read years ago about implementing an ARM emulator for AVR to boot linux. I clicked through, confirmed it was, and that it was a 2012 article. I figured I'd leave the TL;DR as a shortcut for others to confirm they've already read it, not as a replacement of the article for those that haven't.
I'm not baiting down-votes. Far from it. Just voicing that TL;DR is annoying. There's a reason you can't have both text AND a url in a HN submission - it's to encourage people to actually visit the link.
Next, we'll have people just copy-pasting the entire article body as a comment ... :(
> it's to encourage people to actually visit the link.
You read the links? I'm just here for the commenting. If the comments imply the article is good enough I'll read it.
(This effect used to be very strong on the Guardian's commentisfree site, where the top comments often contained valuable correction/context to the tritness of the article)
> Next, we'll have people just copy-pasting the entire article body as a comment
I've seen that done a few times; it's useful if it's paywalled/adwalled/unusuable-crashy-javascript-walled.
http://elks.sourceforge.net/
Also Fuzix, which can run a Unix-like on a variety of tiny, ancient processors like the Z80 and 6809; I've ported it to the MSP430, a modern micontroller, and I also have a half-finished port to the Raspberry Pi that I must get round to fixing one day (hilariously, the Pi has more RAM than Fuzix can handle)...
https://github.com/EtchedPixels/FUZIX
Both of those run natively, of course.