Interesting about the ESP32-P4. I’m not sure what you mean about embedded Linux needing more memory in 2025 than in 2011 (when I wrote the program that I mentioned). As far as I know, zillions of wifi routers right now run Linux with 8MB of ram. We used Angstrom Linux iirc, and I think the current equivalent would be Yocto. 64MB was really plenty for our Python app and a few add-on modules. We weren’t running a web browser or anything ridiculous like that on it. I haven’t followed that area though.
I’d want to run Linux rather than an RTOS since that’s what I’m used to for programming. It was nice that we could ssh into the box to move files around, among other thing. It had cron jobs to upload its logs to a remote server nightly. Plus the Python app was multi-threaded and used a bunch of Python libraries that were probably Linux dependent. And, we could do a lot of dev and testing on desktop machines which was easier than having to constantly test on the target box.
It felt about like an older and slow-ish Linux box rather than something terribly constrained. I could run Emacs and GCC on it in addition to Python.
Zero 2W is 15 USD here, though that doesn’t include sales tax (like VAT) of about 9%.
I guess that is a reasonable point about longer term support for those CM’s though that seems like a tragedy of the ARM ecosystem in general. The 2011-era x86 laptop I’m using right now runs current Debian just fine.
It seems to me that most people use cooling fans on the Pi 5. I wonder if the 500/500+ need that.
I remember thinking the Pocket Beagle was nicer than the Pi Zero but it cost considerably more. I guess the gap is now a bit narrower.
If I were to do something with these bigger embedded boards again I’d be interested in running Erlang on it. That’s easy with Linux but I have no idea if Erlang runs under FreeRTOS. It doesn’t look that way, by quick web search.
Is the ESP32-P4 SPI memory painfully slow compared to the on-chip memory? Is there CPython for it? Having 32MB makes those MCU’s interesting for some things that would have been beyond their capabilities otherwise.
Unrelated, for something else I’m semi-involved with: do you know what is around these days in small cheap MCU’s comparable to midrange AtMega? Let’s say 16K of program flash and 2K of ram. Right now we use AtMega but those are fairly expensive. The application is a flashlight controller (toykeeper.net/anduril) so the hardware is cost sensitive. I’ve been wanting to look into porting to the WCH CH32V003. There is also a new much more powerful CH570 that lacks ADC’s. I’m wondering what else is out there. I write embedded software sometimes, but I’m not a hardware guy.
My experience with embedded Linux was mainly working on some Linux-based SDN switches between 2014 and 2020. The jump from Linux kernel 2.6 to 3.x increased the memory consumption quite a lot. I honestly don’t know if that improved since, but for desktop Linux the kernel got bigger, not smaller, in the meantime.
We really struggled fitting a small Web.py webserver and a process that communicates with the SDN system into the 128MB RAM. Especially using Python 3.x instead of 2.7 (had to switch due to EOL) bumped up the memory requirements.
I guess that is a reasonable point about longer term support for those CM’s though that seems like a tragedy of the ARM ecosystem in general. The 2011-era x86 laptop I’m using right now runs current Debian just fine.
Yeah, I don’t know what’s up there. Intel isn’t supporting my ancient 2010 netbook either and yet Antix works just fine on it. But apparently, for ARM someone needs to manually provide drivers for every device individually or something.
Maybe it’s a device tree vs UEFI thing? Or maybe nobody working on the Linux kernel can be bothered supporting ARM natively? It’s certainly weird.
It seems to me that most people use cooling fans on the Pi 5. I wonder if the 500/500+ need that.
I don’t have a 500, but according to this, you need to populate an unpopulated M2 slot and some power management components.
Is the ESP32-P4 SPI memory painfully slow compared to the on-chip memory? Is there CPython for it? Having 32MB makes those MCU’s interesting for some things that would have been beyond their capabilities otherwise.
Not painfully slow. With stock settings they have a 80mhz 16bit parallel connection. The internal RAM has 200mhz, can’t find how many bit parallel though. At least on the S3 the PSRAM can be clocked to 120mhz, I think it’s the same on the P4, but I don’t know.
The two-layer cache probably also helps in that regard.
Unrelated, for something else I’m semi-involved with: do you know what is around these days in small cheap MCU’s comparable to midrange AtMega? Let’s say 16K of program flash and 2K of ram. Right now we use AtMega but those are fairly expensive. The application is a flashlight controller (toykeeper.net/anduril) so the hardware is cost sensitive. I’ve been wanting to look into porting to the WCH CH32V003. There is also a new much more powerful CH570 that lacks ADC’s. I’m wondering what else is out there. I write embedded software sometimes, but I’m not a hardware guy.
I do have some experience with the ESP32-C3. It’s much more powerful than your requirements while being much cheaper than the Atmega168p.
But I’m sure there’s even cheaper stuff.
I have only Atmega/Attiny and ESP32 experience, can’t really say much about other platforms. I’m sure there are some cheap STM32 around.
Hmm, yeah, depending on what httpd you were running, there might have been an issue, but you could possibly decrease the memory footprint with some configuration choices. It looks to me like python 3.9 uses about 4MB more memory than 2.7.whatever.
Re ARM vs x86, I would say that PC’s in general have consistent hardware interfaces evolving gradually since the original 8088 PC’s of the 1970s. Every ARM system on the other hand has its own incompatible hardware world. A lot of it is totally undocumented too, so it’s not so easy to repurpose old mobile phones the way you can old PC’s.
That’s interesting about the 16 bit SPI memory. I thought that SPI was usually a 1-bit interface though SDIO is, I believe, 4 bits wide. 16 bits at 80mhz is fast enough for 2nd level memory. Maybe they can start putting MMU’s into those processors.
Yeah the ESP32-C3 is an amazing value but way overkill for a flashlight, in terms of package size and power consumption in addition to cost. I wonder whether the BLE can communicate with a phone held near the flashlight though, if the flashlight is a metal tube that would block most of the RF. There might be a non-metallic path out the front, through the PCB, leds, and optics.
Interesting about the ESP32-P4. I’m not sure what you mean about embedded Linux needing more memory in 2025 than in 2011 (when I wrote the program that I mentioned). As far as I know, zillions of wifi routers right now run Linux with 8MB of ram. We used Angstrom Linux iirc, and I think the current equivalent would be Yocto. 64MB was really plenty for our Python app and a few add-on modules. We weren’t running a web browser or anything ridiculous like that on it. I haven’t followed that area though.
I’d want to run Linux rather than an RTOS since that’s what I’m used to for programming. It was nice that we could ssh into the box to move files around, among other thing. It had cron jobs to upload its logs to a remote server nightly. Plus the Python app was multi-threaded and used a bunch of Python libraries that were probably Linux dependent. And, we could do a lot of dev and testing on desktop machines which was easier than having to constantly test on the target box.
It felt about like an older and slow-ish Linux box rather than something terribly constrained. I could run Emacs and GCC on it in addition to Python.
Zero 2W is 15 USD here, though that doesn’t include sales tax (like VAT) of about 9%.
I guess that is a reasonable point about longer term support for those CM’s though that seems like a tragedy of the ARM ecosystem in general. The 2011-era x86 laptop I’m using right now runs current Debian just fine.
It seems to me that most people use cooling fans on the Pi 5. I wonder if the 500/500+ need that.
Do you know if I can use the M2 hat on a regular 500? I mean this: https://www.adafruit.com/product/6427
I remember thinking the Pocket Beagle was nicer than the Pi Zero but it cost considerably more. I guess the gap is now a bit narrower.
If I were to do something with these bigger embedded boards again I’d be interested in running Erlang on it. That’s easy with Linux but I have no idea if Erlang runs under FreeRTOS. It doesn’t look that way, by quick web search.
Is the ESP32-P4 SPI memory painfully slow compared to the on-chip memory? Is there CPython for it? Having 32MB makes those MCU’s interesting for some things that would have been beyond their capabilities otherwise.
Unrelated, for something else I’m semi-involved with: do you know what is around these days in small cheap MCU’s comparable to midrange AtMega? Let’s say 16K of program flash and 2K of ram. Right now we use AtMega but those are fairly expensive. The application is a flashlight controller (toykeeper.net/anduril) so the hardware is cost sensitive. I’ve been wanting to look into porting to the WCH CH32V003. There is also a new much more powerful CH570 that lacks ADC’s. I’m wondering what else is out there. I write embedded software sometimes, but I’m not a hardware guy.
My experience with embedded Linux was mainly working on some Linux-based SDN switches between 2014 and 2020. The jump from Linux kernel 2.6 to 3.x increased the memory consumption quite a lot. I honestly don’t know if that improved since, but for desktop Linux the kernel got bigger, not smaller, in the meantime.
We really struggled fitting a small Web.py webserver and a process that communicates with the SDN system into the 128MB RAM. Especially using Python 3.x instead of 2.7 (had to switch due to EOL) bumped up the memory requirements.
Yeah, I don’t know what’s up there. Intel isn’t supporting my ancient 2010 netbook either and yet Antix works just fine on it. But apparently, for ARM someone needs to manually provide drivers for every device individually or something.
Maybe it’s a device tree vs UEFI thing? Or maybe nobody working on the Linux kernel can be bothered supporting ARM natively? It’s certainly weird.
I don’t have a 500, but according to this, you need to populate an unpopulated M2 slot and some power management components.
Not painfully slow. With stock settings they have a 80mhz 16bit parallel connection. The internal RAM has 200mhz, can’t find how many bit parallel though. At least on the S3 the PSRAM can be clocked to 120mhz, I think it’s the same on the P4, but I don’t know.
On my handheld physio game console, it’s fast enough to keep the framebuffer there.
The two-layer cache probably also helps in that regard.
I do have some experience with the ESP32-C3. It’s much more powerful than your requirements while being much cheaper than the Atmega168p.
But I’m sure there’s even cheaper stuff.
I have only Atmega/Attiny and ESP32 experience, can’t really say much about other platforms. I’m sure there are some cheap STM32 around.
Hmm, yeah, depending on what httpd you were running, there might have been an issue, but you could possibly decrease the memory footprint with some configuration choices. It looks to me like python 3.9 uses about 4MB more memory than 2.7.whatever.
Re ARM vs x86, I would say that PC’s in general have consistent hardware interfaces evolving gradually since the original 8088 PC’s of the 1970s. Every ARM system on the other hand has its own incompatible hardware world. A lot of it is totally undocumented too, so it’s not so easy to repurpose old mobile phones the way you can old PC’s.
That’s interesting about the 16 bit SPI memory. I thought that SPI was usually a 1-bit interface though SDIO is, I believe, 4 bits wide. 16 bits at 80mhz is fast enough for 2nd level memory. Maybe they can start putting MMU’s into those processors.
Yeah the ESP32-C3 is an amazing value but way overkill for a flashlight, in terms of package size and power consumption in addition to cost. I wonder whether the BLE can communicate with a phone held near the flashlight though, if the flashlight is a metal tube that would block most of the RF. There might be a non-metallic path out the front, through the PCB, leds, and optics.