Hacker News Reader

Comment by qalmakka | Hacker News Reader

Why didn't they pack more ram on this? 400K is a bit tight, we often hit the ceiling with the ESP32's 512K of internal RAM. Does anyone know if they support SPI-connected external RAM on this? It has been a lifesaver on the ESP32, especially since WROVER-E fixed most of the long standing bugs that were plaguing the earlier revisions. It is slow as hell, but having 4MB (+4MB high memory) of connected RAM on a microcontroller has been a real game changer.

View on HN

Thanks for mentioning the possibility to extend RAM on an ESP32.

Found the official documention about it:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...

> ESP32 has the ability to also use up to 4 MB of external SPI RAM memory.

> The external memory is incorporated in the memory map and, with certain restrictions, is usable in the same way as internal data RAM.

> While ESP32 is capable of supporting several types of RAM chips, ESP-IDF currently only supports Espressif branded PSRAM chips (ESP-PSRAM32, ESP-PSRAM64, etc).

There are esp32 available with 8MB psram

Have you seen the die images of the ESP32? Basically the entire die area is SRAM. SRAM eats a ton of space, and with a bigger die area you have a much higher likelihood per part that you will have a defect and have to scrap the entire chip.

More SRAM will increase the price both in terms of die area and in terms of defects.

Isn't memory the easiest part to remap to use build in redundancies during the factory testing of the chip?

Sure, if you add extra remapping hardware, nonvolatile storage, and eat the performance penalties. Makes sense for massive quantities of crappy cheap flash, not so much for this.

> Sure, if you add extra remapping hardware, nonvolatile storage, and eat the performance penalties.

Nothing a few fuses can't solve.

> Makes sense for massive quantities of crappy cheap flash, not so much for this.

Coming from the x86 world, they use plenty of fuses for everything. I can't imagine a reason why they would not absorb production variation with this for esp32 dies.

Especially since the multi-thread OS means wasting space for multiple stacks. 400k is a lot for an MCU, but for the ESP32 its really not that much. A 1MB Sram version would be great, with two cores.

Why use the OS then? Just do bare metal runtime like we used to do on MS-DOS days.

What about botnet operators? This would give them a hard time if they have to hack each device specifically instead of recycling old linux vulnerabilities wholesale. The whole IoT industry is strongly committed to make devices available to botnet operators, indeed this looks like the main function, the function on the packaging usually works poorly and is likely just there to convince punters to install the botnet relays and pay for the hardware and power.

:-)

The ESP-IDF environment is based off of FreeRTOS, not Linux. It's essentially a threading library, not so much an OS.

Well the ESP-IDF is freeRTOS based, so: threads. But have fun re-inventing the SDK I guess?

Exactly, FreeRTOS makes it trivial to spin up 20 threads... who was doing that with MS-DOS?

You wouldn't, because the whole point of bare metal is to ignore the OS and use directly the BIOS and hardware.

And regarding threads, we would use cooperative concurrency, and also take ownership of the timer interrupt.

Anything is easy when there is an abstraction implemented as library.

Games and demoscene tricks.

I don't understand why they used a wasteful threaded model instead of an event reactor. It makes no sense to me on a constrained embedded platform. The right way to do it is Japaric's "Real-Time Interrupt-driven Concurrency". Only works for ARM cores though...

> Why didn't they pack more ram on this? 400K is a bit tight, we often hit the ceiling with the ESP32's 512K of internal RAM.

512k is already monstrously high for a microcontroller.

From my MS-DOS/Speccy programming days 400KB is a lot, no need to make use of the OS, if one can avoid it.

lol. yes. i was going to recommend writing a 6502 or Z80 emulator and then write the application in Tiny Basic or FORTH.

If you happy to answer - what are you doing with them?

Well unlike the Atmel chips, it is -- like it's predecessor the ESP8266 -- a totally internet focused MCU. So with TLS and HTTP requests, and receiving streams and WebSockets and whatever else, it's not hard to imagine what to do with it. More is better. For example I have one ESP32 setup with 8 megs of PSRAM that does a full scan of a currency exchange every 15 seconds. Loads all the data into RAM, which I can subsequently process. Run LED displays on after, trigger other events etc. It's pretty cool!

It's certainly alot more direct to implement than booting up Armbian on a PI, and then starting Node, and then....

>For example I have one ESP32 setup with 8 megs of PSRAM that does a full scan of a currency exchange every 15 seconds.

May I ask why you're doing that on a ESP? Very cool...just surprised at the choice.

Well I wanted to have the exchange info on my watch, which is the simplest answer. :P

https://www.banggood.com/LILYGO-TTGO-T-Watch-2020-ESP32-Main...

(I get no money if you click that btw -- it's just for reference)

The watch has some "trading features" even. If I see an interesting trade I can let it take the trade and finish it to "take profit", while I go and do something else. It has a touch UI and a 240x240 16bit colour screen -- so lots of possibilities there.

You should checkout Nerves sometime. Flashing an rpi0 and booting directly into a programmable environment is great.

Most of my ESP32s are driving stepper controller boards for custom microscopes, telescopes, or my CNC. It's nice because the ESP32 has a wifi connection so I can just connect directly to it to control it via g-code.

Reply on news.ycombinator.com