Dinghy index concept papers
PIC32 Platform
.
Abstract
This paper is part of a larger project to create a new computing platform
that feels nible and light. This concept is called Dinghy. Dinghy is a
reaction to the heavy platforms that currently define desktop computing.
See songseed.org/dinghy for more.
This paper considers whether the PIC32 architecture would be a strong
foundation for Dinghy. It concludes that it would not.
Through this project, I reached a better understanding of the evolution of
Unix.
Intro
MIPS is a CPU architecture that has been around for decades. In the late
80s and early 90s it was a leading processor family in workstations.
MIPS is an elegant instruction set, and well-regarded. My generation were
taught 32-bit MIPS instruction set programming at university.
PIC32 is a SoC architecture produced by Microchip, built around a 32bit
MIPS core. Separate to the MIPS core, a PIC32 SoC contains controllers for
CAN bus, analogue comparators, UARTS, DMA, SPI, and much more. It also
contains 128k of system RAM.
The PIC32 family is oriented towards embedded work. But, it is a flexible
platform and has been adapted to other purposes.
Platform resources
The tooling situation for PIC32 is unpolished. Microchip make a large,
highly-integrated IDE. Some may love it. I live in the command line, and
it is not for me.
It is possible to get gcc running for this platform MIPS32. See
https://github.com/RetroBSD/retrobsd/issues/78
Serge Vakulenko has produced several console-based development tools for
this platform, including a tool to install binaries on the target platform
(as an alternative to the Microchip IDE) and a port of QEMU that emulates
PIC32 systems.
There is a strong book resource for the PIC32 platform, _Programming
32-bit Microcontrollers in C_ by Di Jasio. I have not worked through it
methodically and am a novice in the embedded space. My impression is that
this is an excellent one-stop-shop guide to fundamental concepts and
developing on embedded platforms, with a specific focus on the PIC32. This
book keeps close to an ancient, buggy and obsolete version of the
Microchip IDE. Still, it is a good resource.
Notable PIC32 projects
Maximite on PIC32MX
This is a hardware+software platform that originated via an article in
an Australian electronics magazine. It offers a BASIC repl and feels a
lot like an early-80s home computer.
The PIC32MX chip used in the Maximite is roughly equivalent in power
to a high-end 386DX. Hence, the Maximite is far more powerful than any
systems from the era that it imitates. PIC32MX was released in 2007
and has no built in support for memory protection.
The hardware does offer sound and graphics, and this can be accessed
from the BASIC console. The BASIC dialect is impressive, as is the
story of the Maximite designer building it from scratch on his kitchen
table. It is called MMBASIC.
Alas, MMBASIC goes out of its way to prevent users from interacting
with machine code. It does offer PEEK or POKE, but no command to jump
to specific memory addresses. [1]
There will probably be a way to leverage the lack of memory protection
in order to find a way past this. Loosely: you would find a way to
populate MIPS machine code into some memory, and then peek code over
the top of part of the basic interpreter in order to escape it. I
doubt it is particularly difficult, but have not done it so far.
There are also licensing issues with MMBASIC. I found the author's
ideas about copyright to be confusing. It seems likely that the source
will never be released under a free software license.
You can pick up Maximite clones from a number of sources online. It is
best to find one in your region.
I have bought several from Olimex and had no issues with these. If you
decide to get into it yourself, note that you will need an unusual
type of USB cable for powering the Maximite. I think it is called
CABLE-USB-A-MINI-1.8M on the Olimex website.
You can connect it to a VGA monitor and PS2 mouse. The PIC32MX does
not have native support for VGA. Rather, the Maximite creator created
a clever hack by repurposing the outputs of the on-chip interfaces.
Alternatively, you can connect to it using a serial interface over
USB. From linux, I find this works well,
sudo picocom -b 9600 /dev/ttyACM0 --omap delbs,crlf
The platform has some graphics features that are only visible from
VGA.
MMBASIC offers a text editor. It works, but is flawed. The editing
context has a fixed resolution, even when you connect over serial. The
screen-update code is primitive and lethargic. And it has almost no
features beyond arrow keys, typing text.
Similarly, MMBASIC offers a minimal shell for moving files between the
SD card and memory, and for launching things.
The Maximite does not support networking. There is an Olimex variant
of the Maximite that comes with an ethernet port, but there is no
integration to it in MMBASIC.
RetroBSD on PIC32MX
Serge Vakulenko has ported 2.11BSD to the PIC32MX chip. This system
can be installed onto Maximite hardware. This is fiddly, but there are
decent instructions on the RetroBSD website. Extra parts are needed.
For example, a PIC32 programmer. I got all the parts I needed from
Olimex.
RetroBSD is sensitive about SD card performance. I had to try several
cards before I found one that worked. If you are trying it and get
weirdness, this is something you should look at. The card that worked
for me was a SanDisk Ultra 16G.
Once RetroBSD is up, it is a riot. Wondering around it feels a bit
like being inside someone's monograph. There are editors and an
assembler and a tight C compiler, and three dialects of Forth, and
Scheme and console games. Several of these things are Serge's own
work, from a long career.
When you compile things, it doesn't produce an ELF file. Hell no. It
just dumps raw MIPS machine code to a file and marks it executable.
You can open a MIPS architecture book, and read the machine code
directly. Or, open the file in a hex editor and flip bytes around to
change the logic. It is glorious, and feels accessible in a way that
x86 *nix systems never have to me.
When RetroBSD came out, people in the forums were blown away that it
had been done at all. Unix, converted to an embedded platform. It is a
magnificent hack, and I feel my life has been a bit richer from having
experienced it. I have bought several duinomite/retrobsd kits to give
to friends.
RetroBSD has no TCP/IP. (I think TCP/IP only came to BSD in 4.2.)
From memory, the Maximite VGA and keyboard interfaces do not work
either. It is serial only.
I attempted to integrate a Gameduino, via the Arduino shield on
socket. My aim was to get it to present vga and sound, via the
Gameduino. But, in my ignorange, I think I have fried my Gameduino.
Fortunately, this did not damage the Maximite.
RetroBSD seems to be an unusual port of 2BSD in the way it does not
need any kind of MMU. Discussed at hacker news,
https://news.ycombinator.com/item?id=29352463 (The top comment at that
link is wrong about "did not use a MMU", a bad inference from me. Read
on for comments by people who have worked with the codebase.)
LiteBSD on PIC32MZ
In 2013, Microchip released a faster, more powerful version of its
PIC32 the PIC32MZ. This is probably roughly equivalent in power to a
Pentium (P5), although not for FPU purposes, and it has far less
avaialble RAM than a standard Penium system would have.
The PIC32MZ has support for protected memory.
Serge responded by porting 4.4BSD to this. Amazing. This is LiteBSD.
It is run as a separate project from RetroBSD.
Olimex released some boards that will run LiteBSD. I tested the EMZ64.
Not all of the EMZ64 hardware is supported by LiteBSD. For example,
the small display does not work. Also, there is no VGA. Only serial.
LiteBSD on EMZ64 does support TCP/IP networking.
Separately, you can run LiteBSD under Serge's qemu port. I found it
fiddly to get going.
Serge and his team had all kinds of problems getting development tools
working for it. There is no hosted assembler or C compiler.
Potentially you could get a Forth repl going for it, but this would
give you less power than in RetroBSD, due to the presence of memory
protection in LiteBSD.
The LiteBSD/RetroBSD slowed after 2015. The forums have been closed.
There are still github pages. Serge is consistently responsive, and
will investigate bugs and integrate fixes. Other than that, there is
no evidence of active work on this project.
I was surprised at the contrasat between RetroBSD and LiteBSD. They are both
unix adaptations, and both target similar hardware. But they have an entirely
different character.
RetroBSD feels like a cheeky challenge-response interaction. You type
something in at the console, it reacts to you. And, it feels light to
interact with.
LiteBSD feels heavier to interact with. You have a sense that it is doing
more. But, its potential is unrealised due to the tooling problems. The
difficulties the team had porting tools to the platform relate to BSD4.4
being a much more complex foundation, and LiteBSD being forced to
implement protected memory in order to support shared object libraries.
Interacting with RetroBSD feels like a sailing a dinghy or driving a track
car. Interacting with LiteBSD does not.
Design Pressure
1) Networking. I guess that the design pressure of networking raised the
complexity bar on BSD unix over a short space of time. The gap is about
four years: 2BSD was released in mid 1979, 4.2bsd was released in mid
1983.
2) ELF. ELF emerged to allow support for shared-object libraries. In
RetroBSD, you can put raw MIPS instructions in a file, chmod it, and then
run the result. You can't do this in LiteBSD.
Of these, networking will be a challenge for Dinghy. Shared Object libraries
are probably unnecessary.
Evaluate the reviewed system against the Dinghy concept
Maximite
Maximite is really two things. A solid hardware platform, and a
troubled software layer that sits on top of it.
:: hardware
The hardware is pretty good. It is partly the result of a clever hack
(the VGA implementation), it gives expansion options. The concerns
with it are storage and networking.
Storage. It uses sdcard only. There is nothing resembling a hard
disk option.
Networking. It doesn't have any. There is an Olimex variant which
does, but I don't know if support has ever been built for it.
Some of the issues above could be overcome by adding devices on the
arduino shield interface on the board. I don't know how fast or slow
that interface is, and whether that would impede such attempts.
:: software
MMBASIC consciously denies denying machine code interaction. This
could be overcome: you could use memory tricks to hack a new kernel
into place at each boot and thereby reach the the Bedrock and
Mechanical Sympathy design goals. (Or, there is an old fork of MMBASIC
in the Olimex code repositories, left over from a time when the code
was open. You could start with that.)
:: stepping back
Conclusion: It would be modest work to get a forth going, significant
work to get an event-loop+ethernet-drivers+tcp-stack going. And, at
the end of that, it is still only a single PIC32MX processor.
RetroBSD
There is basically no support for its VGA or audio at the moment.
Several people in the forums report on having had this working, but I
could not find source.
Hypothetically you could add support for these things, but I found
RetroBSD to be pushing close to the PIC32MX RAM limits. I expect you
would not have enough RAM left to do worthwhile applications.
Also, I think it already swaps to the SD card at times.
With arduino-shield extensions, someone who was sufficiently
determined would be able to make something work. But, you would be
building substantial parts of a clean computer on those Arduino
shields, and I expect you would hit unacceptable IO bottlenecks.
Conclusion: stacks of work, inadequate outcome.
LiteBSD
Like RetroBSD, it does not currently support VGA or audio. All
interaction is through serial. It has more RAM, and you should be able
to add support for those things.
The existing hardware has fewer connectivity options.
Bad tooling story.
Conclusion: stacks of work, inadequate outcome.
There would be value to creating a small kernel for the high-end Olimex
hardware, hosting a forth or scheme repl. That system would not be Dinghy, and
it would not be able to network. But it would be cool.
If you were building a new system, you could seek to incorporate
several pic32 chips in the specification, and get extra power via
parallelism.
Method,
Build a new kernel for the existing maximite, as described
above.
Create a new single-board computer consisting of a pic32 running
the kernel and handling video and keyboard IO. This is the core of
the new system.
Create a bus from the fastest/most-flexible of the built-in buses
(can, i2s, etc), in order to support the addition of daughter
cards.
Build a static-ram daughter card. This will evolve into swap.
Build a disk-io daughter card.
Build a network daughter card.
--
[1] 20200527. There is a new platform release coming, the Maximite 2. This
will be based on a faster ARM processor. Geoff's decision to bedrock to
mmbasic will allow this to be a seamless transition for any existing maximite
code.