Older readers and those with an interest in retrocomputing may remember the days when a computer might well have booted into a BASIC interpreter. It was simultaneously a general purpose device that could run any software it would load, and also a development environment. Not something that can be said for today’s development boards which typically require a host computer on which to write code. Have we lost something along the way? Perhaps an answer to that question can be found in [lurk101]’s self-hosted development environment for the Raspberry Pi Pico.
It presents itself as a shell, with a flash file system, a port of the vi editor, and a C compiler. We might think of vi as being more at home on a UNIX-derived system, but in this case it’s a port of the vi included in BusyBox. Meanwhile the compiler comes from amacc project.
Of course, this still requires a terminal of some type which in practice will mean a host computer. But the feat is nevertheless an interesting one, and we can see that it might not be impossible given the Pico’s surprising versatility to being some of the terminal features onto the chip itself.
It’s worth noting that this isn’t the first attempt we’ve seen to put a command line interface on a development board.
Hmm, if I understand this correctly, it doesn’t actually compile C to ARM machine code, but to some interpreted bytecode?
Interesting exercise, but micropython might be more effective in practice.
No, it compiles to ARM. But it does so in two steps, first to another representation, and that representation is then transformed to ARM instructions. LLVM does the same thing.
Hmm, ok, interesting.
I only found this which looks like bytecode interpreter: https://github.com/lurk101/pshell/blob/master/src/cc.c#L4169
Mmm.. odd, I checked amacc, so made the assumption from there that it would compile. Guess you are right. I stand corrected.
Ah, the actual news is the on-board C-compiler :-)
In those days the “computer at hand” was complete, It had everything it required “on-board”, a keyboard and a screen (mostly – a TV was enough, if not KIM-1, partly, the IBM 5150 had at least a text card and a monitor to work; TRS 100/NEC PC8201/Olivetti M10/Epson HX-20 “some” LCD). So, despite “booting into BASIC” (an interpreter, see also the BASIC-stamp) you anyway needed a terminal, didn’t you? And then the path to a host computer is short (Ok, Exabytes of Eclipse IDE you may not need anyway ;-)). And there were the OpenWRTs with LUA and a vim on-board that this may be nearer to. Would this have been worth a notice? VT-100 anybody?
being -> bring?
I swear, I did not search on google for it. But I am sure the first thing ever ported to the RP2040 was a forth enviroment. :-D
Olaf
I thought the same thing at first pass: “huh, sounds like forth with more work”. But, looking at what they’ve done, it’s REALLY cool to think that it can run on the Pico itself. Different types of cool. Both very cool.
Who needs a host computer when you can use a terminal? :)
https://hackaday.io/project/13273-diy-vt100-a-miniature-hardware-terminal
A terminal, yes. But in your case the BBB is a powerful host computer :-o
Sounds similar to the Lua based NodeMCU, other than of course, that was entirely interpreted.
Still, had a console you could do your programming of the ESP8266 on, and changes were live in the running Lua state.
This is entertaining as a “ship in a bottle” exercise. However I realized long ago that for embedded work, striving to be self hosted is just a bad idea. If you actually want to get things done a good cross compile hosted on a full blown linux system is overwhelmingly the best way to go.
I agree in today’s environment. Still a neat exercise. In perspective though, the PICO is much more powerful, than my first desktop back in the 80s, the DEC Rainbow. I ‘only’ had two floppies of storage and I maxed memory with 256K (base was 64K) and 4Mhz or so processors (Z80 and 8088)…. Much later when I got a ‘100Mhz’ 486 DX computer, I made the comment that I probably wouldn’t need anything else for a loooong time as it was soooo fast…. Of course that was a false prediction! Anyway, PICO is really capable of ‘more’ than just an embedded device in that sense. We just ‘feel’ it is limited when today you have Gigahertz processors, Gigabytes of memory, and Terabytes of drive space….
Ah yes, the DEC rainbow. I used to have several of those that I bought for a song at a surplus sale. I never did much with them. That was the era when it was unclear whether CP/M on the Z80 or DOS on the 8088 was going to rule the earth.
Yes indeed, todays $3 microcontrollers run circles around those old machines. How far we have come! How spoiled we are. I developed my thoughts about self hosted embedded systems in the m68k arena with a collection of systems like PDOS and VersaDOS that all supplied you with a crappy editor and a buggy compiler. It was much better to use a sun workstation with vi and a gcc based cross compiler and I never looked back.
Yep. The Rainbow got me through College. A good Word Processor ran on it which was a super over trying to type documents on a manual typewriter…. Also the ‘new’ Turbo Pascal ran on it which was great as I could do my projects at home, rather than ‘fight’ for a terminal at school. Pascal was ‘the’ language that we used on the VAX in CS department. Went on to use Borland Turbo Pascal, C++, and Prolog over the following years on PCs. Finally Borland Delphi (that was really awesome at the time for RAD GUI programming) at home and work. It was a fantastic time to be a programmer. We have Lazarus today which works ok too — just not quite the same though.
I worked at a place back in the early 1980s who had quite a few DEC rainbow PCs. My recollection was that it was a dual boot, or perhaps you could consider it triple boot, option: ROM based VT-100, CP/M or MS-DOS 2.11. The Rainbow was ahead of its time with tool-less maintenance where most parts snapped or latched together, only needing a Dime to help loosen the thumb screws on the main logic board. There was an option for a hi-res color graphics board with a NEC 7220 controller, though software support for it was pretty much zero, and an option for a 5 megabyte Seagate ST-506/412 HDU supported on MS-DOS 2.11.
The dual spindle belt-drive floppy drive was a bit strange, made by DEC itself in Maynard. The same belt drove both spindles, so the spindle on the bottom rotated the opposite direction from the top spindle. It would have been better to use a pair of direct drive Shugart floppies for improved reliability.
There was also apparently Pascal P-system available where the Rainbow booted directly into the p-code interpreter and ran applications. We had a department running a Pascal application which had been built by a contractor, and I don’t know how the application was built, cross compiled or developed on a Rainbow.
The Rainbow was a pretty good idea for its time, but didn’t take off as strongly as it may have for the following reasons: not ISA bus, not CGA graphics compatible (even if Rainbow had better graphics), not the best floppy drives, and rather expensive hardware. For PDP-11 minicomputer users exchanging data, I don’t believe DEC itself made 8 inch floppy drives for the Rainbow, though Emulex or another 3rd party may have had them.
It is quite a thing that a 2022 $5 Pi Pico has a more processor performance, RAM and storage than a 1984 $4,000 (before adjusting for inflation) table-top PC system. But then, there is almost 40 years in between.
“There was also apparently Pascal P-system” …. There was. But then Turbo Pascal came out. No more P-Code. And you are right the Rainbow was expensive. Parents helped me buy one for school as they were offered for half price to students. That was still like $1500 in 80s money for a student. Note Tuition was $700 a semester (two semesters) to put in perspective…. Plus a good 300 baud Hayes modem added on. Don’t recall if I ever got to experience 9600 baud before graduating… I remember one of my first fun projects for the Rainbow was generating the Mandelbrot set ‘slowly’ overnight on the green screen. Was ‘cool’ at the time.
Having a PC to crossbuild stuff faster than on the Pico is nice, but doing the same on a system of 1 or more Picos (maybe even one as terminal) would be much nicer.
It needs the SDK to build an firmware that cannot rebuild itself on the Pico?
Do I understand this right?
If so: How far is it from being able to rebuild itself on itself?
CP/M can do that on an 8-bitter with 64k RAM or even a bit less. Why aren’t we there yet with today’s micro-controllers that are by dimensions more powerful than my systems in the early 80s?
Fallback question:
Are there already other OSes (Forth?) that can rebuilt themselves on the Pico without needing a PC plus SDK?
This article start with “old reader” probably someone is interested in this:
https://github.com/dwelch67/raspberrypi-pico#readme
That is an eviroment (not from me!) that allow tp program the RP2040 with makefile and without the sick enviroment from the RP2040 people, just good old C, only you, emacs, make and the world is good!
Olaf
Yes!! That is the way to do real work. Thanks for the link. (I will swap vi for emacs, but all the rest is EXACTLY what I want). Thanks again. And if I forget to mention it. Thanks.
Ha!! Yes, hot tip indeed. I know Dwelch and we see eye to eye, and have on other projects as well. Very cool.
I which there was a precompiled binary…
Nice! this helps shorten the compile, upload, run, debug loop present on the pico. Especially since you need to unplug, or use a reset button mod in order to reflash the firmware.
I’ve been using a port of MMBASIC [ MIcroMIte] called PIcoMite. It has a built-in BASIC interpreter that is about the era of QuickBASIC 4.5 [ think subs, functions, etc ] . It has support for SPI, I2C, and even the PIO assembler.
It also had a build in editor. Programs and statements could run standalone, or in “immediate” mode, so you could instantly see what something did.
No compile, run, upload loop.
Good to have this in C finally.
PicoMite Gives Your Pico A Deluxe BASIC
https://hackaday.com/2021/11/24/picomite-gives-your-pico-a-basic-with-all-the-features/
It is possible to flash/debug the RP2040 with a Segger J-Link. And it is relative easy to glue a connector to the pico board. But before that check out the Segger homepage if your hardware is new enought, because older hardware can not connect the new ARM-debug port.
Olaf
Good idea, but this is still a remote compile, upload, run , debug loop. Having something execute like BASIC, on the immediate window speeds this up a bit, especially if debugging something like PIO program call.
So thinking further, is there a possibility of a word processor / spreadsheet program for the Pico, or any of the other low cost micros (like ESP32 or something)?
Today’s micros are always compared to and said to be more powerful than yesteryear’s computers, e.g. Commodore64, but those platforms were useful for everyday computing. Is it that those sort of applications CAN’T work, or is it just that there is no market for it or no impetus for anyone to develop such a thing.
I ask this from an inexperienced/naive point of view, just interested!
I think you have to write the programs yourself, companies will not do it. I see the RPi 400 as a goid example of a useful machine, a pair or RPis Pixo could also provide a useful environment with keyboard an all
Intel MCS BASIC-52 embedded controller software technology interactive development
environment on distributed hardware system superior to the batch c/c++ mainframe software technology is some cases?