506: How Do I Fit a Whale Into an Apartment Building?
Transcript from 506: How Do I Fit a Whale Into an Apartment Building? with Dmitry Grinberg, Christopher White, and Elecia White.
EW (00:00:06):
Welcome to Embedded. I am Elecia White, alongside Christopher White. Our guest this week is Dmitry Grinberg. We are going to talk about Linux on microcontrollers, or whatever is smaller than microcontrollers, like itty bitty controllers.
CW (00:00:23):
Picocontrollers. Hi Dmitry. Welcome.
DG (00:00:27):
Hi. Nice to be here.
EW (00:00:29):
Dmitry, could you tell us about yourself, as if we, I do not know, met on an airplane?
DG (00:00:38):
Sure. I am a software engineer. I mostly like to write code for small systems. I occasionally have delusions of designing hardware. Sometimes it even works. I like to write up my projects, because I like to think that people sometimes will try to reproduce them and actually learn something from it. Sometimes people write to me, and tell me that is what happened. That is kind of cool.
EW (00:01:01):
You have some really interesting projects. But before we talk to you about those, we want to do lightning round, where we ask you short questions and we want short answers. And if we are behaving ourselves, we will not ask, "Well, what about the networking system?" or other longer questions. Are you ready?
DG (00:01:19):
Bring it.
CW (00:01:21):
Favorite processor?
DG (00:01:24):
Probably one of the Apple silicon processors. ARM64.
CW (00:01:28):
Favorite Linux distribution?
DG (00:01:30):
Debian, because it mostly just sticks to doing what it is supposed to be, and not showing off.
CW (00:01:35):
How many bits is enough bits?
DG (00:01:39):
It depends for what. I could do a lot with just one.
CW (00:01:42):
<laugh>
EW (00:01:45):
How many bits is too many bits?
DG (00:01:48):
I do not play too much with 64-bit and higher. It is just too big. Not much of a challenge.
CW (00:01:55):
KDE or Gnome?
DG (00:01:57):
Neither. I use Xfce.
CW (00:01:59):
Okay.
EW (00:01:59):
Complete one project, or start a dozen?
DG (00:02:05):
I do not allow myself to have more than two projects in flight, because if I did, I would never finish anything. I do not consider a project done, until it is finished and written up. I would like to start a dozen, but I do not let myself do that.
CW (00:02:19):
Favorite fictional robot?
DG (00:02:22):
Absolutely Marvin the Paranoid Android.
EW (00:02:25):
And, do you have a tip everyone should know?
DG (00:02:27):
Yes. If you do not know how to do something, find some corner of it that you kind of know how to do, and then do it. That will get you into the problem more, and both motivate you and help you figure out how to do some other adjacent parts of it. Eventually, before you know it, the whole problem will be done.
CW (00:02:42):
Okay, I got to go write that down. That is really, really good.
EW (00:02:45):
<laugh> It is a really good one.
CW (00:02:46):
It applies to lots of things besides technology. That is very good. I like that.
EW (00:02:53):
<music> Before we get back to today's discussion, I want to share a new resource for anyone curious about the rise of AI in engineering.
(00:03:00):
Mouser Electronics has a dedicated Empowering Innovation Together hub, that covers the latest breakthroughs in tech. Their new series explores how AI is reshaping engineering, from design automation to rapid prototyping and predictive maintenance. You will find insightful articles, podcasts, and videos that showcase real-world applications across industries.
(00:03:25):
If you are ready to see how AI is powering the next generation of engineering, head over to mouser.com/empowering-innovation. Now, let us get back to the show. <music>
(00:03:37):
We have been skirting around small processors, and we mentioned Linux. So, last spring you posted about an 8-pin Linux project. This was three chips, that each have eight pins. Could you tell us about it?
DG (00:04:02):
Yeah. The idea was that some time long ago in computing history, you could actually buy a kit computer, that was comparable to the sort of computer you could buy in a store. But you could assemble this at home, and have comparable computing power.
(00:04:15):
We are very long away from that now, but I thought it would be cool to try something similar. For some definitions of "modern computer," being able to run Linux and compile a C program can sort of qualify. So I tried to find the minimal set of parts I could use to produce such a computer, that one could still hand assemble at home, assuming no soldering skill. Which means you are only using very large chips, with very few pins.
(00:04:43):
I built on some previous code I had written to emulate MIPS, and boot Debian on it. Then I designed a small board, that is about an inch across, circular, with a USB connector on it, that actually does all this.
(00:04:55):
If you assemble this at home, it will over about a minute boot. You will be faced with a command line, with the real Linux on it, that you can then actually write some code and compile it and run it.
EW (00:05:07):
So the Linux has- You mentioned GCC compiler, and Make, and then an editor, vi, right?
DG (00:05:17):
Yep.
EW (00:05:19):
But there is no networking.
DG (00:05:22):
No. Networking was something I thought about, but there was not much I could do with just chips with eight pins. Which was of course an artificial limitation, but that is what made the project interesting.
(00:05:32):
So in order to interface to USB, the options are very few, in terms of things that have eight pins. It is either USB to serial chips, which is what I used. Or you can use something like a 8-bit AVR ATtiny to bit bang USB. That gives you a few more options, but networking is not happening anyways.
EW (00:05:52):
So this USB to serial chip was one of your three allowed chips?
DG (00:05:57):
Yes. It was a really cute chip I found from Prolific. I had never seen it before, but now I like it a lot. Basically you connect USB to one end of it, serial comes out the other. It does not need any external parts. It even will supply 3.3 volts for the rest of your project. It is actually pretty awesome.
CW (00:06:14):
Yeah. I have seen those on a previous project. Unfortunately, we did not get to use it. But I was pretty excited that it existed.
EW (00:06:21):
One of your other chips was RAM, right?
DG (00:06:24):
Yes. Linux needs megabytes of RAM. If you are going to stick with text mode Debian, you can fit into about eight megabytes. So I used an eight megabyte PSRAM chip. There is actually a bunch of them out now. They are pretty convenient for all sorts of projects. They are made by AP Memory in the US, and in China there is a company called "Vilsion" that also makes them.
EW (00:06:46):
And an SD card, which is not counting against your chip count.
DG (00:06:50):
Well, I do not think it is a chip. It does not have legs, and you are not soldering it. So I think that is a fair excuse.
CW (00:06:54):
<laugh>
EW (00:06:56):
I will accept that. Yes. Now the big question. You actually in your write-up did an analysis of half a dozen, almost a dozen, microcontrollers, with the pros and cons. I have to admit that I have a little bias concerning the PIC16. And so I loved your analysis. Why was that not suitable for this <laugh> particular project?
DG (00:07:28):
So, the annoying part about PIC16s is, it is not very performant at all. I actually started my microcontroller project programming long, long ago with PICs. I was a reasonably big fan of them at the time, because they could go relatively fast at the time. But now we have ARM microcontrollers that go much, much faster.
(00:07:49):
PIC16 will go at 32 MHz, which does not sound terrible, until you realize that it takes four cycles to do an instruction. So you are down to about eight million operations per second. But then it is also an accumulator based architecture. So even moving a value from one location to another is two instructions. God help you if you needed to actually do something with the value. So before you know it, you are going really, really slowly.
(00:08:14):
That, and even though there is a C compiler for these, it does not produce very good code. It cannot. This architecture was never designed for C. It was designed for being programmed in assembly. Which is fine. I have done plenty of assembly programming. But even assuming I wrote my MIP simulator in assembly, the other options were a lot more performant.
(00:08:35):
My goal was not only to have this thing be small, but also performant enough that I could claim it is interactive with some degree of being honest. I do not think that could be done on that PIC. But I did fairly evaluate every 8-pin microcontroller I could find.
EW (00:08:51):
Yeah. Including an AVR, which you have run Linux on before.
DG (00:08:55):
Yes.
EW (00:08:57):
But you did not think that would be interactive, because the boot time on that was a little long.
DG (00:09:04):
Yeah. First time I did this was six hours long, because I wrote it in C.
CW (00:09:08):
<laugh>
DG (00:09:08):
If I did it assembly now, I could probably get it down to two, but that is still a lot. I mainly chose the fastest thing that had enough useful pins. You would be surprised how many manufacturers make an eight pin part, and then do completely stupid stuff with actual pins.
(00:09:25):
Like, if you are making an eight pin part, there should be one supply pin and one ground pin. Why would you have two supply pins? Why would you waste an extra pin out of your array of just eight? I do not know. And yet that was really, really common.
EW (00:09:39):
Then you determined you needed one MIPS of CPU. How did you make that determination? Is it a Debian thing?
DG (00:09:49):
No. There are no official requirements. One of my other projects had booted Linux at 74 Hz. That was basically me trying to evaluate how fast it would need to boot, in order to boot within a few minutes, so a user does not get bored. And so that vi is interactive enough, that you are not annoyed using it.
(00:10:09):
I just evaluated it by trying. I literally made an emulator for MIPS a while ago for a different project. I was able to slow it down on purpose on my PC, and come up with that approximate number.
EW (00:10:21):
So this MIPS emulator. We are- Okay. Maybe take me through the boot process, from the reset vector. I am on an ARM processor, and I have hit the reset vector. Normally now I would be doing the C init, and then going to main.
DG (00:10:41):
Most of the same thing. There is C init, and you go to main. Main will then just load the first sector from the SD card into the external RAM. Then it will start a MIP simulator. The MIP simulator sees the external RAM as being its only RAM, and it jumps to the beginning of it.
(00:11:00):
The code there loads the partition table and looks at it, to look for a partition which is marked with a particular type. I think I use type 0xBB. It then sees which sectors it contains, and loads those sectors into RAM.
(00:11:17):
Then that is the next stage bootloader, which then looks at the partition table again; finds which partition is marked as active. Actually this one is much bigger, so it has a file system support. So it mounts it as FAT16. Finds a file on there called vmlinux; parses as an ELF file; loads it properly into RAM.
(00:11:38):
Then it looks for a file with "clock" in the name. That, it is used to figure out how fast the CPU should be running, since I am overclocking it, and I wanted to give people a chance to decide how fast.
(00:11:50):
After that, it just jumps into executing the MIPS code in Linux kernel, which will then come up. Eventually it will load partition number three, because that is what the command line says as the rootfs. And then you are just running MIPS Linux.
EW (00:12:09):
Okay, so this clock file. I want to separate between the MIPS simulator, and the...
CW (00:12:16):
The bare metal?
EW (00:12:16):
The bare metal. The C running bare metal.
DG (00:12:20):
Yeah.
EW (00:12:21):
Does the C running bare metal- It has access to the file system?
DG (00:12:30):
Yes.
EW (00:12:32):
It has something like TinyFS, or some other FAT file system?
(00:12:39):
Yeah. So a very long time ago for a different project, I wrote a very tiny implementation of FAT16, that only supports read-only, and needs about nine bytes of state. That is what I am using.
CW (00:12:50):
Wow! That is a cool idea. Read-only. It saves a lot of headache.
EW (00:12:55):
It really does.
DG (00:12:56):
Exactly. If you are clever, if you are using an SD card, because it is SPI and you can pause the clock anytime, you can get away without even having a 512 bytes sector buffer. This was used when I was writing a project to play audio from an SD card, on a microcontroller that only had 128 bytes of RAM.
(00:13:12):
The idea is you can start reading a sector, get to the byte offset you need, and read it. If the next offset you need is further, you just keep going. If not, you keep going and skip to the end, then start it again. It is slightly inefficient, but you can get away with only having nine bytes of state.
EW (00:13:28):
Sorry, my brain is whirling about that. So then you read this clock. You have to go to the bare metal for that, because that needs to access the chip registers for this particular microcontroller. Then after that, you are all in emulation.
DG (00:13:47):
There are a few steps here that I guess I sort of skipped over, because they are not relevant to the emulator. But there is also a bootloader on the MCU, in order to allow me to update it. Since there is no debug connection that is usable. Not enough pins.
(00:14:02):
So in order to allow people to update it, there is also a bootloader which also mounts the SD card, looks for an update file, and if it finds one, will apply. It then jumps to the application that we discussed.
(00:14:11):
It will work without the bootloader as well. It is not an integral part. It will just be very, very difficult to update, if you wanted to change the emulator and fix something.
EW (00:14:21):
You just need a JTAG- No, you would not just need a JTAG unit, because this processor does not have- How would you update it?
DG (00:14:29):
Well. There are only eight pins, which means there are not enough pins to do everything. So to allow me to debug it, I do have an SWD connector here. When the processor starts, it waits for about six seconds before doing anything, including reconfiguring those pins. So if you attach a debugger within the first six seconds, you can debug it.
(00:14:50):
But this board cannot boot with the debugger attached, because the debugger will mess with the other uses of those pins. So initially debugging I did over that. But now, basically you can only update it using the SD card.
(00:15:03):
You put a file called "update.bin" on the SD card, and a particular byte offset is a version number. It is compared to the current firmware's version number. If the one on the card is a higher one, it will be copied from card into flash, and then a reboot will happen. So you can update it that way. No debugging. Most you can do is output serial console, out through the serial port.
CW (00:15:25):
I want to take a little step back, because we talked about the emulator. History of Linux stuff. Like you said, Debian runs in text only with eight megabytes of RAM.
(00:15:34):
When I first started using Linux, it was a million years ago. On a 486 with I think four, eight megabytes of RAM, something like that. It was very small, but that was as big as Linux got back then, when it first came out. Okay. Long way around to my question. Using MIPS emulator, why is that architecture the right choice for something like this?
DG (00:16:01):
Well. Two parts to this question. One is why use an emulator at all, since Linux technically supports ARM.
CW (00:16:07):
Sure. Yeah. Good to answer that. Yeah.
DG (00:16:09):
The answer here is that my RAM is not real RAM. It is an SPI device. It is not actually in the address space of a microcontroller. I cannot just read and write to it. So things that Linux expects like, "Let us allocate an eight megabyte buffer. Or a two megabyte buffer," it is not going to happen.
(00:16:24):
Because of that, we cannot run Linux natively. We have to emulate, to basically make this fake RAM look like real RAM. Every time an emulated device tries to do a memory load or a store, I can actually issue an SPI transaction.
(00:16:36):
But why MIPS? I guess I should have made a table for that too. I did not. But basically, if you have to emulate, there are a few choices you can use for what is properly supported by Linux. You are looking at x86, ARM, MIPS and RISC-V nowadays. Almost everything else is more or less not properly supported, if you want a real kernel and a real file system.
(00:16:58):
X86 is a giant pain in the ass to emulate. Just decoding x86 instructions properly is enough to make a man go mad. Then there are all sorts of other arcane stuff you are going to have to support. So that goes out the window right away.
(00:17:12):
Next up is ARM. I have done ARM before. My first attempt running Linux on AVR was ARM. But emulating ARM is also slightly tedious, because all instructions can be conditional. What that forces you to do, is constantly be valuing that condition. That slows down your emulation, because before you get to the guts of emulating instruction, you are first forced to evaluate if it should execute or not. Great for actually writing code, annoying for emulation.
(00:17:41):
That leads us with MIPS and RISC-V. Those are quite similar in design. But RISC-V designers did one really annoying thing for emulation, is a lot of immediates. So the values in instructions, are not continuous in instruction. They are split over some bits here, some bits there. It makes it convenient for making a hardware implementation of RISC-V, but very annoying for emulation. Because now in order to assemble this immediate value, you have to AND with one constant, AND with another constant, SHIFT and ADD.
(00:18:12):
I just described six instructions that I am doing to get this immediate. Whereas in MIPS, it is always the bottom 16 bits, one single UXTH or SXTH instruction, and you have got your immediate. When you are trying to go fast, every cycle in the emulation counts.
(00:18:27):
So picking the architecture where I can get the value out, four cycles faster, matters. Which is how you end up with MIPS. Plus, it is still quite well supported by Linux kernel and by Debian user space, which is kind of cool.
EW (00:18:41):
But you do- Part of that emulation is some sort of hardware abstraction, where you mentioned the RAM needed to be- I am going to say, "Translated." Wrapped? And I assume the SD card interaction, and also the serial port?
DG (00:19:00):
So you emulate not just the processor. You emulate a machine. Linux does not support just processors. So the machine I am emulating here is a DECstation 2100. It is something DEC made a while ago, just because I happened to be familiar with that.
CW (00:19:14):
Yes. <laugh>
EW (00:19:14):
That is a long- That is a deep cut. Yes. Okay. <laugh>
DG (00:19:19):
That one did have a serial port card in it. It is a pretty simple one. It is based on DZ11, which was actually a serial port card back in PDP-11 days. DEC just grabbed it and reused it. So I am emulating a serial port card for real. Linux thinks it is talking to a real DZ11 card.
(00:19:36):
I am not emulating SCSI disk drive, because that is very tedious. So instead I am using the fact that Linux is open source to my advantage here. And I wrote my own disk driver, which I call "PVD," or partially virtualized disk.
(00:19:54):
The idea is that I am using a undefined MIPS instruction, to make a call from the emulated world into the emulator itself. And one of those calls I can make is, "Give me a sector," or, "Write a sector." You provide a physical address in your RAM, and a sector number. Then the actual emulator does the SD card access. So Linux just thinks it has a very weird disk device that is instantly fast.
EW (00:20:23):
I assume you were not using Debian 12, because that I think released later than your project notes.
DG (00:20:32):
Yes. Debian did finally drop MIPS I support. Let me see if I can find out when was the time they dropped it, because I researched all this when I was writing it, and I forgot the actual answer. It looks like- I think it was the last release, that they dropped MIPS I support. It lasted for a while, but now it is dead, which makes sense. MIPS I is long, long, long, long, long dead. So I think it might be the one before Bookworm, that the release I am using is.
CW (00:21:04):
Okay.
DG (00:21:05):
The thing is MIPS had a number of revisions. So it was MIPS I, then there was II, III. Then there was MIPS32, MIPS64. Then there was MIPS32e2, e3, e5, e6. I do not think I skipped any there. There was no four, at least not that I know of.
(00:21:18):
But anyways, MIPS I was supported for a very, very long time. So that made my life very easy. Just grab a rootfs, and it all works.
(00:21:25):
The other cool thing there, is that MIPS was the last architecture I could find supported by modern Linux, where having a floating point is optional. Floating point unit, that is. Which is really convenient for emulation, because emulating floating point units is a pain in the ass.
EW (00:21:41):
When I download a new Linux- Which I usually end up with Ubuntu, for all that says about me, I am sorry. It has a whole bunch of cruft that I do not want. And yet I have trouble getting rid of it, because I do not know how everything interacts. And because I just do not care.
(00:22:01):
How did you make a Debian distribution that was this small? What did you have to go through to get a clean distribution, that did not have all of the cruft?
DG (00:22:17):
There are kind of two parts to this question. So one is, Debian has a minimal rootfs, which has none of the graphical stuff. That makes it quite easier.
EW (00:22:26):
<sigh> Why do I not use Debian?
DG (00:22:27):
But the other part- You are in fact using it. Ubuntu is based on Debian.
EW (00:22:32):
Right.
DG (00:22:32):
But the other part is, all this stuff gets started by an init system. To make this project faster, I actually did not use the init system. So initially for testing, I booted directly into Bash. But that leaves you with too few things, to a point where console will not act correctly. Oh, and you will not have tmpfs, which will break some applications.
(00:22:55):
So I wrote my own little tiny init system here, which will mount tmpfs and procfs, and start a couple of services, and then dump you into Bash. However the emulator is complete. You can enable swap on SD card and run proper init, and it will bring up the entire thing, complete with send mail and everything else you might not want.
EW (00:23:17):
<laugh>
CW (00:23:17):
<laugh>
DG (00:23:17):
It takes a while though. So spawning a new process takes a really long time, just because we are still running only at one MIPS. You will be amazed how many processes get spawned by even Debian, which is pretty small. Starting. Some point in time, I counted a few hundred.
(00:23:37):
So basically if you actually want to exec init, which is the command you would use to go properly boot up the whole system, all the way up to the proper login prompt at all, it takes a little over an hour.
EW (00:23:48):
Oh! Oh, okay.
DG (00:23:50):
There is just no need to ever do that, because my init brings up all you need in order to integrate with a compiler, vi. You have a shell. Basically all the parts you would need, you have.
EW (00:24:03):
No, no. That totally makes sense. But I was having trouble with the idea. You were booting it all up in a few minutes. If you were booting it all up.
DG (00:24:16):
Kernel is up, you have a command line, /proc is mounted, /sys is mounted, /dev is mounted, your compiler works, vi works, Emacs works, and your command prompt works. What more could you need?
EW (00:24:28):
But you did not trim it. You did not try to get to-
DG (00:24:31):
No. Just started with Debian minimal.
EW (00:24:33):
Okay.
DG (00:24:34):
If you do not start- They are not hurting me by sitting on the SD card. If I was trying to use a smaller SD card just for some other reason, maybe yes. But one gigabyte SD cards nowadays are in fact becoming more expensive than larger ones. So at this point in time, the cheapest SD cards I buy on eBay is hundred packs of two gig SD cards for 40 cents each. So, trimming it down to less than two gigs made no sense.
EW (00:25:00):
<laugh> Part of my brain still has a hundred megabyte SD card, is probably the largest you are going to get. I know that that part of my brain lives in 2004, but-
DG (00:25:11):
I know how you feel.
EW (00:25:12):
It is just sometimes I forget, that what used to be rare now is common.
CW (00:25:17):
That is because we are venerable. That is the word.
EW (00:25:22):
"Venerable." That is the word. <laugh>
CW (00:25:24):
I know podcast listeners are probably tired of me saying things from the past. But I remember how much it cost to get a 15 MB hard drive computer. <laugh>
DG (00:25:37):
Yep, I am with you there. But nowadays, go on eBay, search for "2 GB SD card." There are people selling hundred packs. They will come to you in a ziplock baggie. Buy a couple of those, and you are set for projects for life. You never even reuse one. You just stick a card to a project and that is it.
CW (00:25:53):
That is a really great idea, actually. When I need SD cards, I usually go to some larger vendor and buy, "Oh, well. The smallest one I get is 32 gigs. Well, I need 500 megs for this project, but that is the smallest I can get. So I guess I will pay the five or ten bucks for that." But that is a much better idea, to just stock up with <laugh> the two gigs and forget about it.
DG (00:26:14):
Yeah. I just buy them in hundred packs.
EW (00:26:16):
Okay. This is back from 2004. The larger SD cards and their SPI interface did not used to work well. But it sounds like it is all fine now. That in the intervening 20 years they became okay. <laugh>
CW (00:26:32):
The larger two gigabyte SD cards?
EW (00:26:33):
Yes.
CW (00:26:33):
Uh-huh. Uh-huh.
DG (00:26:35):
No. So maybe what you are thinking of is when we switched from SD to SDHC. A lot of code that supported SD did not work. But yeah, because the protocol changed. I had some fun time with that back in PalmOS days. But yeah. Nowadays they are all HC cards, and it is all nice and easy.
(00:26:52):
SPI protocol is still mandated in the spec. So they all do support it. Though there are bugs. There are all sorts of exciting bugs, because there are corners of the spec that no one reads quite accurately.
EW (00:27:05):
Yeah. There always have been. It is just which ones they are right now. And which SD cards- Do you end up being reliant on one or three brands of SD cards? Or calling out some that do not work?
DG (00:27:23):
I just buy whichever ones are on eBay.
EW (00:27:25):
Okay.
DG (00:27:25):
Then if- I have an SD card driver, I have been slowly improving since about 2004. It is the one that I initially wrote for PalmOS. Over time I just improve it. So when I find a card that does something weird, I will add support for that weirdness. I actually have a stack of SD cards I test with, the more weird ones over the years. Make sure I did not break any of them, and that is it. So my driver over time slowly evolves to support all sorts of stuff.
(00:27:48):
My latest one was a fake SanDisk branded card, that claims to support CMD23. It is optional, you are not required to, but there is a way to query if the card supports it. It claims to support it, but if you send it, it rejects it as invalid. Why? I do not know. It is not a marketing thing. No one cares if you support that command. But claiming to support it and then rejecting it, is an interesting thing I have never seen before.
EW (00:28:15):
Yes. Okay. I know you did not want to talk about your day job, and I am not going to ask direct questions. But does this work at all reflect your day job? Does it contribute to your day job? Is this purely separate?
DG (00:28:34):
Well, I suppose this keeps me sharp, so I can do clever things in my day job occasionally. But no one is going to pay me to tinker with microcontrollers all day, I am afraid.
EW (00:28:44):
To be able to minimize Linux in this way, I think you would be surprised. Some of my clients have wanted it, and I am not the person for it.
DG (00:28:54):
Oftentimes, if someone asks you that question- I think this is called an "XY problem," is what the name for this is. When someone asks you a question, where an answer may exist, but really you got to wonder why they are asking the question. Because they are probably already headed the wrong way.
(00:29:08):
`
EW (00:29:52):
Yes. <laugh> Sorry, Dmitry. Please go on.
DG (00:29:54):
Oh no, I was going to say that usually when they ask you for that, what you would find is they are going to try to run a five line Python script they have lying around.
CW (00:30:00):
Yes. Yes.
EW (00:30:01):
Yes. Yes, indeed.
DG (00:30:03):
I have had some fun experience with that, because a really long time ago, I wrote the world's tiniest JVM that fit on microcontrollers. I have had people actually license it from me, for all sorts of very strange reasons.
EW (00:30:15):
This is the Java virtual machine.
DG (00:30:16):
Yeah.
EW (00:30:16):
Just before we go on. Okay. Go ahead.
DG (00:30:19):
Yeah. I wanted to see how Java works, so I figured the best way is to write a JVM. So I did. I wrote one that fits in microcontrollers, in like a few hundred bytes of RAM. I have had some companies license it from me.
(00:30:29):
Including one that makes agricultural products. Apparently, there are weather stations for farmers. They wanted a way for them to program arbitrarily complex alerts, to be alerted about. The way they decide to solve this was by letting them upload a compiled Java class file, to this weather station's microcontroller. They license my JVM from me to do that.
(00:30:50):
But you probably donated JVM to-
CW (00:30:54):
You helped them with the whale in that case. <laugh>
DG (00:30:54):
"The wind is greater than five miles an hour, and it is raining."
CW (00:30:54):
Yeah.
EW (00:31:00):
And yet, it was the way they wanted to do it.
DG (00:31:02):
Yeah.
EW (00:31:04):
Okay. So we mentioned- Did we mention 8-bit AVRs in Linux? We did, did we not?
CW (00:31:10):
Briefly.
DG (00:31:10):
Mm-hmm.
EW (00:31:12):
And the boot time there was six hours.
DG (00:31:15):
Well, that was not speed optimized actually, that emulator was actually written in C. So it could have been optimized quite a ways, in assembly.
EW (00:31:22):
Okay.
DG (00:31:24):
At the time, it was just a yes or no thing. Could I make it work or not? Once I made it work, I moved on with my life. This time I actually care about performance, so the emulator is written in assembly.
EW (00:31:33):
But that is not the smallest, or most venerable-
CW (00:31:40):
<laugh>
EW (00:31:41):
Processor you have put Linux on.
DG (00:31:45):
No. That would be the Intel 4004.
CW (00:31:46):
Okay <laugh>.
EW (00:31:49):
A 4-bit microprocessor from 1971.
DG (00:31:53):
Yep. That is the one.
CW (00:31:54):
Finally, something that predates me. <laugh>
EW (00:31:58):
And this does not have eight megabits of RAM, and one MIP CPU.
DG (00:32:03):
Well, it still uses the same RAM chip-
EW (00:32:05):
Okay.
DG (00:32:06):
The eight megabyte PSRAM. I am just talking to it over a bit-banged SPI, that I am bit banging out of 4004, at a great speed of seven kilohertz.
EW (00:32:15):
<laugh> Seven kilohertz. Kilohertz! Okay.
DG (00:32:19):
It is the best I could do. 4004 is not very fast. The fun part there is that the RAM chip- It is PSRAM, so it needs to self refresh internally. So they specify how long you are allowed to keep it selected over SPI, so you do not break refresh. And it said eight milliseconds. So I spent a lot of time optimizing my 4004 code, to fit into that eight millisecond boundary. After I got it working, I realized I misread the data sheet. It was actually eight microseconds.
CW (00:32:46):
Oh, no!
EW (00:32:48):
Oh! Oh. At that point you are-
DG (00:32:49):
But it turns out it still worked.
EW (00:32:51):
It still worked?
DG (00:32:53):
Yes. So the reason the limitation is there, is to give it enough time to refresh. Because it is designed that you select it, read or write, deselect it, select it again, et cetera. It is not designed to just sit there, deselected for a long time. So it expects to do its own internal refresh in small chunks.
(00:33:06):
But I select it so rarely, because I am running so slowly, that it has enough time in between these eight millisecond selections, to refresh itself plenty. So it turns out to work fine.
EW (00:33:18):
Ahh. So 120 hertz. Eight milliseconds? Did I do that right? Yeah. So what was running at 120 <laugh> hertz?
DG (00:33:26):
Well. I also did a MIPS emulator on the 4004, because once again, MIPS is the easiest thing to emulate. That emulated CPU runs at an effective speed of 74 hertz.
EW (00:33:37):
<laugh>
CW (00:33:39):
So it is still booting now?
DG (00:33:42):
No, it takes about five and a half days.
CW (00:33:44):
<laugh> I love it.
EW (00:33:48):
Where did you get in Intel 4004?
DG (00:33:53):
EBay. I had to beat out some collectors who buy them, just because it is the first microprocessor ever made. Most of them just put it on a table and never look at it again. But unfortunately there are a lot of them, so the prices tend to climb up. The plastic ones are 250 bucks. If you want one of the pretty ceramic ones, you will be paying thousands.
EW (00:34:12):
TubeTime. Eric. I think you are familiar with him?
DG (00:34:16):
Yep.
EW (00:34:17):
He has the 8008 board.
DG (00:34:24):
Yep.
EW (00:34:25):
Have you run Linux on his exploded-
CW (00:34:29):
It is a 6502.
EW (00:34:30):
Oh, is it?
CW (00:34:31):
Yeah.
DG (00:34:33):
He made a 6502 out of transistors. Yeah.
EW (00:34:35):
Right. Have you run Linux on his transistor board?
CW (00:34:40):
That is way too slow.
DG (00:34:41):
No, but-
CW (00:34:41):
<laugh>
EW (00:34:42):
Well, it was not when I thought it was an 80.
DG (00:34:44):
No. A similar thing is on my to-do list. So the reason I did the 4004 thing, is after I ran Linux on AVR in 2012, that was basically the record for lowest end machine to run Linux, for a very long time. Then in 2023, two people actually beat that record. One person used a smaller AVR, and another one did it on a Commodore 64. Which has basically a 6502 processor on it.
CW (00:35:09):
Yeah.
DG (00:35:10):
So I needed to regain my record. I needed something lower end than 6502. So I went with a 4004.
CW (00:35:17):
That kind of sets the floor.
DG (00:35:20):
Oh, no. It is not setting the floor. I already have plans for the next ones. My plan is to try to beat this record once every ten years, to give people a chance to beat me as well, since this time someone did. So my next few steps. Next one will be a 1-bit industrial controller Motorola did.
CW (00:35:38):
Oh. Okay.
DG (00:35:38):
It is an [MC14500B], I think. After that I will try to make a board with just transistors. And after that I am hoping I will have time to put together a board with only vacuum tubes.
CW (00:35:49):
<laugh> And run it on ENIAC.
DG (00:35:52):
I will have to put together my own CPU there, since there is not really a mass market vacuum tube based CPU I can go buy. But the idea is to keep moving this record for lowest end machine to run Linux, down further and further. Just for fun.
(00:36:05):
Obviously, we are well below the speed where it is practical. On 4004, you type "ls" and you come back 20 hours later to see the directory listing.
CW (00:36:14):
Seems like you should be collaborating with museums at some point.
DG (00:36:17):
Well, at some point in time it will become a museum.
CW (00:36:18):
Yeah.
EW (00:36:20):
I think about Eric's board, and how you can see it light up as it works.
CW (00:36:26):
That would make the five days worth watching.
EW (00:36:27):
Yeah, it would be really interesting.
DG (00:36:31):
Well, so once I get to a transistor based board, it will be something similar. But even now on my projects, I literally output the current instruction counter PC to LEDs. So you can literally see Linux boot.
CW (00:36:42):
Cool.
DG (00:36:42):
When it is going so slow, you can actually notice it. You can look at the patterns of lights and know which part of the kernel it is in. While watching it, I learned to recognize the common things like memory zeroing function. I know what that looks like in LEDs now.
EW (00:36:58):
Is that on the 8-pin Linux?
DG (00:37:02):
No. That is on the 4004 based one.
EW (00:37:04):
Okay.
DG (00:37:04):
The 8-pin one is too fast. The whole point was that one had to be interactive.
EW (00:37:07):
That makes sense. Yeah.
DG (00:37:08):
If you could see how fast the instruction counter is moving, it would not be interactive.
EW (00:37:11):
Have people come to you and asked you to build the 4004 one for them?
DG (00:37:17):
I have built two more. One for a friend, and one for a paying customer who wanted one. I tried to set it up as a kit that people could actually order. But the companies that make kits pushed back on it, with very legitimate concerns, that it would be very strange to sell half a kit. Because you could get the board and the modern components, but no one is going to buy you the original components. You have to go and scour eBay for those. And that would be a very strange kind of kit.
(00:37:48):
At the same time we could not really go and source them. A, because it is a huge capital expenditure, and it is hard to predict the sales. But also there is no guaranteed supply. Some days eBay has supplies of 4289 and some days it does not. So basically now it is just, "Here are the design files. Go buy the parts, and put it together." I know of at least a few people currently building one of these boards.
EW (00:38:11):
You mentioned earlier that you limit yourself to two projects, until they are written up. And offline, you mentioned that you did not really enjoy writing. Why do you bother? I am not discouraging you. You do a great job, and I am really glad you do it.
DG (00:38:28):
The number of people who have reached out to me over the years, and told me that reading about my projects encouraged them to get into embedded, or encouraged to get better, is worth the results of that.
(00:38:40):
There is a shortage of people doing low level software. You can get a whole CS degree nowadays, without ever touching assembly, or even C. Which is terrifying, because all these people who think the world runs on JavaScript, do not realize someone has to write their JavaScript VM.
(00:38:55):
Getting people into embedded is sort of one of my hobbies. This is how you do it. You do it by trying. It is like riding a bicycle. You can read all the books on riding bicycles you want. Until you get a bicycle and skin your knee a couple of times, you are not actually going to learn anything. It is the same here.
(00:39:15):
You learn by doing. You do not just wake up one day and know how to do this. Having a project you can follow can be helpful. There are people who started my projects and modified them. So my original, for example, Linux on AVR.
(00:39:28):
I know a guy who actually took that, attached a display and an I2C real-time clock to it, and made a nightstand clock for himself, that just happens to run emulated Linux. He wrote a Python app that runs on there, that updates the time on this display, which was really, really cool.
(00:39:45):
So I try to make sure that my write-ups are clear for people, and that they can be followed. That plays into part selection, because I hate when I read someone's project and says, "Oh, I use this part that my grandpa left me in his will." I am, "Okay, great. Where do I get one?"
EW (00:40:03):
<laugh>
CW (00:40:03):
Get a grandpa. <laugh>
DG (00:40:03):
So I try to make sure that my directions are reproducible, and the parts I use are something you could at least have a hope of sourcing. I limit myself to two projects, because I hate the writing part. It is not fun. Going there with soldering iron, is fun. Seeing things work for the first time, is fun. Writing is not.
(00:40:22):
But the way I force myself to do it, is I am allowing myself two projects in progress at a time. And a project is in progress, either until I have given up on it and destroyed it, to make sure that I cannot try to lie and say it is not in progress, but come back to it. Or until it has been completed, and an article about it has been published.
(00:40:42):
So that is basically how I forced myself to write. Because if I have two projects that need to be written up, I cannot start another one, until I have written one up.
CW (00:40:49):
Do you tend to write as you go? Or do you kind of do-
DG (00:40:52):
No.
CW (00:40:53):
Retrospective after you finish? Okay.
DG (00:40:55):
I take very messy notes as I go, so I can later figure out what I did and when. But like I say, I hate writing. I would not want to spoil the final project with it. Usually it will take me, depending on the project, a few months to go from start to finish. And then probably about a week or two of writing.
(00:41:12):
First, I will take my notes and try to make an outline. Then I will go and write very haphazard and typo-ridden article. Then I will go and spell check it a few times, and read through it a few times, and organize it. And then add a table of contents.
(00:41:25):
I really hate that part. I tend to do it in times when nothing else to do. Like if I am on a plane. Or if I just have a headache and I cannot think right.
EW (00:41:35):
You write complex and interesting technical articles, when you have a headache and cannot think right.
DG (00:41:41):
Because when I can think right, I would rather go and think about something challenging.
EW (00:41:47):
One thing- This was totally me, I think. I could not really find your code. I could not find you on GitHub or anything.
DG (00:41:59):
That is on purpose.
EW (00:42:00):
If I wanted to rebuild this, I saw the list of parts. But how do I get the rest of it?
DG (00:42:06):
Oh, every one of my articles has the code down there. So if you look for example, 8-pin Linux, there is a section that says, "Downloads and Use." There is a subsection called "The files," and it says, "The main download is here." There is a link there that has-
EW (00:42:17):
Yeah. It was a zip file.
DG (00:42:18):
All the design files, the source code, everything.
EW (00:42:19):
Oh. Okay.
DG (00:42:22):
Yes. I am purposefully not on GitHub. A lot of my code is uploaded by other people, but I am not on there on purpose. I do not really want to contribute to training some ML models with my work. If they want to train on it, they can at least go crawl my website.
EW (00:42:37):
And unzip the file.
CW (00:42:38):
That is right.
DG (00:42:38):
Yep.
EW (00:42:40):
If they cannot figure out how to unzip it, they are not a human.
CW (00:42:41):
It is not a- <laugh>
DG (00:42:43):
It is a poor human test. I have been working on implementing a better anti ML model thing for my website, but I have not finished it yet.
CW (00:42:50):
I wanted to ask- We talked a lot about this project. I am about to make a horrible pun, so warning upfront.
EW (00:42:58):
Preparation for pun.
CW (00:42:58):
What was the kernel of this idea? Did this just come to you? Like, "I want to attempt this"?Were you thinking about it tangentially for another reason? Or, was it suggested to you? Or?
DG (00:43:13):
Well. The 8-pin Linux one, the physical size small one, that one was mainly because I was explaining to a neighbor's kid, that back in the day you could just go and assemble a computer from a kit. I got this look back up to him, like I was telling him that we used to go strolling around the main street with martians.
CW (00:43:35):
<laugh>
DG (00:43:35):
So I decided to try to see if I could recapture some of that, in a way that could be appreciated today. Because if I give you a computer kit from the eighties, it does not run anything modern today. So it is not actually believably a computer anymore. Definition has shifted. So I wanted something that can be considered a computer today, for some definition of that.
(00:43:59):
For lower end things like the 4004, there, it is- I just thought it was cool to have this record.
CW (00:44:05):
This challenge. Yeah.
DG (00:44:06):
Now that someone actually took the time to beat it. I wanted to provide a return challenge, "Okay. Here. Here is the next thing to beat."
EW (00:44:15):
It is funny. I see where you came to it from that description. But I would have given them a Raspberry Pi, not a pico. But that is more of a computer than I had through college. <laugh>
DG (00:44:32):
Sure. Absolutely. But you are not going to assemble a Raspberry Pi.
EW (00:44:35):
No.
DG (00:44:36):
The whole point was, I was explaining that there used to be a time when a computer you would buy, and a kit you would buy to assemble, would produce approximately the same computing power, running the same exact software more or less.
(00:44:47):
So my goal was to run modern ish software, on something you could actually hand assemble. In theory with a reflow plate and all the right parts, you could maybe assemble a Raspberry Pi with some effort. But certainly not if it is your second time soldering.
EW (00:45:02):
Be more likely to do a BeagleBoard. But yeah. Yeah.
CW (00:45:06):
Yeah. But, the original Apples came in a kit version, I think. The Apple I-
DG (00:45:11):
Exactly. Yes.
CW (00:45:12):
And Heathkit had a ton of computers. A lot of Z80 based stuff.
EW (00:45:15):
Yeah? Yeah.
CW (00:45:15):
So. Yeah.
DG (00:45:17):
But the actual limitation of eight pins was my own, just to keep it fun for me. Because realistically, Allwinner makes a chip that has pins. So it is not BGA, it is not even QFP. They have a real QFN with actual solderable pins, V3s, I think, that will run proper real Linux.
(00:45:36):
It is an actual ARM core, a modern one, with built-in RAM in the chip. So you can literally plop this thing on a board, sprinkle maybe a dozen parts around it, and you will have real Linux running on that board. They are very cheap too.
(00:45:49):
So the limitation of eight pins was just my own. Because I decided to lower the requirement from hand solderable, to hand solderable as your first soldering project.
CW (00:46:00):
So when you embark on the transistor only one- Let us not talk about the vacuum tubes for a second.
EW (00:46:05):
<laugh>
CW (00:46:08):
Are you going to invent your own architecture? Or?
DG (00:46:12):
Yes. The idea is to minimize the number of transistors. So I have to create an architecture that is just designed to run this emulator. Luckily, it does make a lot of things simpler. There are some things you just do not need, if you are only going to run an emulator. Do not need memory protection, because you can emulate that anyways. And you do not need serial ports, because you can use SPI for everything, because life is much easier.
(00:46:36):
So yes, the idea then is to write my own architecture. Probably eight or 4-bit one at that point in time. Working with less than eight or four bits, would just be tedious. And more bits would require a lot more transistors. The idea here is I will be writing in assembly anyways, so the fact that it is a new architecture is in no way a difficulty.
EW (00:46:59):
If I was going to do this- You can tell me how wrong I am, because this is not the sort of thing I think about. But if I was going to do this, I would go to the "Nand to Tetris" book, from Shimon Schocken. And look at how he has done the transistors to his small assembly.
DG (00:47:22):
Yeah.
EW (00:47:22):
Because I do not know all of the different assemblies very well. I really only know ARM, and some TI.
DG (00:47:31):
That is the perfectly good approach.
EW (00:47:33):
Then I think because he actually builds this up the opposite direction you are going, that would be a good way to figure out the possibilities of it.
DG (00:47:45):
Yeah. That is a perfectly good approach. By the way, if you liked "Nand to Tetris," in case you have not seen it, there is a nandgame.com which is pretty cool. It is by a different person. But it is basically you start with putting together a NAND gate out of MOS[FETs], and then you build other components. This website will guide you through a set of projects-
EW (00:48:06):
Yeah!
DG (00:48:06):
All the way to a working maze solving robot. So if you have not seen it, really recommend it. I am not connected to it anyway, but I recommend it to everyone. It is really, really, really cool.
EW (00:48:16):
We have talked about some similar games, but that one is on the web. It is really fun. Especially for folks who are like, "Okay. But what is under the processor?"
(00:48:25):
It starts out with truth tables, which is kind of painful. But it builds up pretty quickly to, "Okay. This is how you actually put it all together." And then suddenly you have AND gates and OR gates, and then suddenly you are interpreting things to be much more complicated.
DG (00:48:42):
Suddenly you have a robot that solves a maze.
EW (00:48:45):
I will make sure that is in the show notes. Okay. We did not talk about processors. I mean, we talked about PIC16s and their C compiler. Their joy of a C compiler. Their anti joy of a C compiler, I mean.
DG (00:49:03):
It is not even theirs. It is a third party company.
EW (00:49:07):
You ended up looking at some Cortex-M0s and M0+s, which was what my brain went to when you first mentioned this.
(00:49:17):
Then I was a bit surprised about the 8-pin chips, because <laugh> I had kind of forgotten that anyone made 8-pin chips. I think I knew at one time, because I have had some really tiny projects. But they have gotten- I mean, now you can get 16 pins in a tiny, tiny package. But your goal to solder-
DG (00:49:41):
Let me blow your mind. There are actually 6-pin Cortex-M0s you can buy.
EW (00:49:45):
That is...
CW (00:49:47):
All right. So we got power and ground, and...
EW (00:49:51):
Serial.
CW (00:49:51):
Serial.
EW (00:49:53):
And SPI.
DG (00:49:54):
Well, four pins for whatever you want. Whether they be serial, or SPI, or whatever else.
EW (00:49:58):
Yeah. USART. But you do have two SPI things, so you do have to have a chip select.
DG (00:50:06):
I managed without it in this project.
EW (00:50:09):
Did you? How?
DG (00:50:12):
Well. So six pins, after you take away power and ground. Two for serial port, leaves you with four. For RAM, you need SPI. So master out, master in, clock and chip select. That is your four. Now you have no pins left for SD card.
EW (00:50:25):
Oh! But if you put an inverter in there, you are either selecting SPI or SD card.
DG (00:50:30):
That was one of the things I considered.
EW (00:50:32):
Okay.
DG (00:50:32):
The problem is I found some cards really did not like being selected for a very long time. But also, inverters would be an extra chip on the board. I considered it, but I found a solution without it.
EW (00:50:43):
Okay.
DG (00:50:44):
So SD cards, besides SPI, also support their native SD protocol. It is not as well documented in the open specs, but it is not hard to figure out.
EW (00:50:52):
It is not hard to figure out. I have tried to figure it out. But go ahead.
CW (00:50:55):
<laugh>
DG (00:50:56):
Well, you can go grab my code now.
EW (00:50:57):
Yeah.
DG (00:50:57):
But the idea is that protocol does not use a chip select. Uses three wires, but instead of SPI, having all uni-directional wires, this uses bi-directional wires. But with that protocol, you can combine it with SPI, on the same exact pins.
(00:51:13):
Basically, when you are accessing the memory, the SD card just sees a clock, and the command pin is in idle state, which is allowed by the spec. And when you are accessing the SD card, memory sees itself being selected and deselected repeatedly, with no command byte coming in, which is also allowed.
CW (00:51:32):
Ohh! Tricky.
DG (00:51:33):
So I run them on the same exact wires, at the same exact time.
CW (00:51:38):
Tricky, tricky, tricky. Okay.
EW (00:51:39):
Okay. This goes along with overclocking, in that it would make me uncomfortable to ship a product with this.
DG (00:51:45):
Sure.
CW (00:51:45):
Well, it is not a product.
EW (00:51:47):
No, no.
DG (00:51:48):
It is not a product. But also by default, it does not overclock very much. But I allow people to do it, because it is faster that way.
CW (00:51:55):
Yeah.
EW (00:51:56):
It does not overclock very much. The chip goes 64 MHz, and you have overclocked it to 150 MHz.
DG (00:52:03):
Well. By default, I think I run it 130. But yes. So mainly to make things go faster, when it comes to processors, it is a question of giving it a higher supply voltage, and making sure it does not melt itself.
(00:52:14):
So the core in this particular STM chip, runs at around one volt. There is a built-in regulator. In order to allow power savings, ST gives the regulator two settings.
(00:52:26):
In one, it supplies just under one volt, and the chip is allowed to run, I think up to 32 MHz. Let me go see if I can find it for you. Yes. Up to 16. And then they have a second setting, which supplies 1.2, where the chip can run up to the stock 64. And if you try, it will run at about 80 or so.
(00:52:47):
But some of the older chips with very similar power regulator registers, also had another setting, which supplied 1.35 volts. So I tried that setting on this chip, figuring ST was probably too lazy to design a whole new regulator. They probably plopped the same one in. And I was right.
(00:53:06):
So with that setting, the chip will run a lot faster. A few chips I have here, because obviously it is very individual, can get up to about 180. But every single one ran at 136, which is obviously quite a bit faster than 64.
(00:53:20):
So I allow people who put this project together to run as fast as they want, and see how fast they can get before it gets unstable. If you have an external supply of Vcore, you could go even higher. But obviously in this chip, not enough pins for that. But that is how people overclock RP2040s and such. Supply Vcore externally, you can go even faster.
CW (00:53:40):
Add some external cooling, and- Yeah.
EW (00:53:44):
Yeah. I am really uncomfortable with overclocking. I know you have done it with your computers, but-
CW (00:53:49):
Why? Intel will sell you a chip that is unlocked, specifically so you can overclock it.
EW (00:53:58):
I guess I am just so, "Engineering design spec. Must not, must not go over."
CW (00:54:03):
Well. Remember-
DG (00:54:04):
Well. Yes. I am certainly not claiming that this will run across the automotive temperature range, and will age properly across a decade. Those are just not design guidelines here. I certainly would not do this, if I was shipping a product that is going to run someone's airplane or something.
(00:54:18):
But this is a hobby project. So faster silicon aging, due to higher voltages, is not a problem. And performance in subarctic winter outside is also not a problem, because I suspect no one is going to try to use this outside in Alaska in February.
EW (00:54:35):
I do not know. Those Antarctica scientists do get really bored.
DG (00:54:40):
They can do it indoors.
EW (00:54:42):
Exactly. <laugh>
CW (00:54:42):
The chip manufacturers, they are trying to hit a spec where they want the chip to survive, even if you put it on a board and do not do any cooling or anything...
EW (00:54:53):
Yeah. No. I know. They have to over-engineer it, and then people who want to go outside that span can. I am just- It is not how my brain works.
DG (00:55:05):
It is not the way you would ship a product. But for a hobby project, where you only need to make two of these, and maybe a couple dozen people will follow in your footsteps, it is fine. Plus the performance benefits! Think about this! Going from 64 MHz to 160 is not something you would really want to leave on the table.
EW (00:55:23):
Not for this, no. Not when you are talking about a boot time. And you are right, it is a hobby project. It is for fun. Let us make it fun. And overclocking, I guess because it is a "Do not do," is kind of fun, just on principle.
CW (00:55:40):
Just so you know, your computer is overclocked.
EW (00:55:43):
<laugh> Things he does not tell me.
CW (00:55:45):
Because the BIOS has a thing where you just push a button, and it determines the appropriate clock setting.
EW (00:55:52):
I thought the BIOS was just so I could change its little LEDs.
CW (00:55:55):
Yeah. <laugh>
EW (00:55:57):
Sorry. That was not true. I am sorry.
CW (00:55:59):
I just wanted to make sure, that you knew you were lying to people, that you do not over overclock things. I have overclocked on your behalf.
EW (00:56:04):
Thank you.
CW (00:56:05):
<laugh>
EW (00:56:05):
You mentioned that you actually chose an ST part, STM32G031, which is the M0+. And you had looked at a TI part and a PSoC part as well. But this will work on almost any M0 at this point. There is not a lot of difference between them.
DG (00:56:35):
No. So because I am using basically no hardware peripherals at all, it will work on anything. I begrudgingly was forced to choose the TI part, just because of the speed.
EW (00:56:45):
The STM part? Or the TI part?
DG (00:56:47):
STM. Sorry, that is what I meant. Yes.
EW (00:56:47):
Yeah. Okay. Just because it had the highest clock speed?
DG (00:56:52):
Yes.
EW (00:56:54):
And you begrudgingly chose this, because you do not- Their errata is not as up to date as you would like.
DG (00:57:01):
I am a huge foe of ST Micro. I try to convince everybody who I know is using them, not to. I even offer my time for free, to companies who are considering switching away from ST Micro to anything else, to help them do so.
EW (00:57:16):
<laugh> Really?
CW (00:57:17):
We would like to thank our sponsor ST Micro- <laugh>
EW (00:57:20):
<laugh> No. Not our sponsor.
DG (00:57:23):
I have beef with them from a number of years ago on a project. They released a part, STM32H7, which was supposed to support external PSRAM, memory mapped and read-write mode.
CW (00:57:34):
Ohh. Right.
DG (00:57:34):
And the problem is, it was broken. If you enable caching, it would sometimes hang if you ran code from it. If you disable caching, some writes would sometimes get lost, or write neighboring bytes. I tried to show them, and even with a demo, they basically denied the issue was there.
(00:57:50):
Then I found a workaround for the issue, and I was able to complete my project. Then a few months later they came back and said, "Hey. We have a customer who is experiencing similar issues. Can you tell us the workaround?"
EW (00:58:02):
<laugh>
CW (00:58:02):
You got to be kidding me.
DG (00:58:04):
"As soon as you guys admit that the chip is broken." And that is basically as far as that went. So the chip remains broken. I still have not told them what the workaround is.
(00:58:13):
But basically if people are out there knowing that their chips are broken and not documenting it, I am not okay with that. So I have made it my personal mission, to try to make sure as few people as possible use ST Micro parts.
(00:58:28):
So being forced to use it was not my personal favorite, but it was the best part in this particular case. And because I am using no IP on there at all, except the actual core, there was very little chance of hitting an errata. Because they do not design the ARM core, ARM does.
EW (00:58:45):
I am trying to think which processors I have used, that were fresh, that did not have some errata that they then denied, and later came back for.
DG (00:58:55):
I recommend RP2350 to anybody doing anything nowadays, that needs an ARM core, or even a RISC-V core. I am a huge fan. The documentation is great. The support forum has actual people from Raspberry Pi answering questions. And these things are really, really fast.
EW (00:59:13):
And the hardware abstraction layer is beautiful!
DG (00:59:17):
That I would not know, I am afraid.
CW (00:59:19):
My favorite thing is when the chip vendor says, "Oh! Wow! You found a new problem. Thank you for telling us," when they have already admitted it to somebody else, separately.
EW (00:59:27):
Yeah. It is like we do not talk to each other.
CW (00:59:29):
Yeah.
EW (00:59:29):
Yeah. That was what I was thinking of. Okay.
(00:59:34):
Well, I think we are about out of time. But I wanted to know if you wanted to say anything about DEF CON.
DG (00:59:42):
Nah, I think that is already played out.
EW (00:59:45):
Okay.
DG (00:59:46):
They have said everything they want to say. I have said everything I want to say. Everyone has already made up their mind. I think that is over.
EW (00:59:53):
Do you think you will be attending in the future?
DG (00:59:57):
I never attended DEF CON before this event. I am not usually big on conferences. I went just to make my appearance. I do not think I have any reason to do that again.
EW (01:00:09):
<laugh> Okay! Dmitry, do you have any thoughts you would like to leave us with?
DG (01:00:13):
More people should get into embedded. It is fun. I think that it is going to be a very good career going forward. Everyone who is worried about LLMs taking over their jobs, should go ahead and try to get one of these coding LLMs to spit out some useful embedded C code for you. It is like having a very enthusiastic three-year-old help you in your wood shop. You are mostly just very, very scared of the results.
(01:00:39):
I do not think that is going to change. So it is fun, and it will be a good job. So anybody who wants to get into embedded, please do. Please encourage everyone else you know, as well. We need more people who understand how things actually work.
CW (01:00:53):
Fully endorse.
EW (01:00:56):
Our guest has been Dmitry Grinberg, hardware hacker. You can find his website at https://dmitry.gr and I will have links in the show notes.
CW (01:01:11):
Thanks, Dmitry. That was great.
DG (01:01:12):
Thank you.
EW (01:01:15):
Thank you to Christopher for producing and co-hosting. Thank you to Dennis Jackson for the introduction. Thank you to Mouser for sponsoring the show. And thank you to our Patreon listener Slack group, for their continuing encouragement of our book discussion. Finally, thank you for listening.
(01:01:34):
You can always contact us at show@embedded.fm or hit the contact link on embedded.fm, where the show notes also live. As well as the transcripts.
(01:01:43):
And now a quote to leave you with, from Cory Doctorow, "It is the stupid questions that have some of the most surprising and interesting answers. Most people never think to ask the stupid questions."