The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It's an ESP32. The chip itself can operate up to 240Mhz but its external SPI buses (of which it has 2) are limited to clock multipliers of 40MhZ, up to I think 80Mhz at 2x clock multiplier, but don't quote me. I'm pretty sure 80Mhz is the max under normal circumstances, but I've heard scuttlebutt on some forums about hacking it to go faster.
Also, the ESP32 has some dedicated MMC and "High Speed" SD reader dedicated hardware so i think if you use the right reader modules (the kind with 4 data pins) you can get higher than 80Mhz effective transfer rates.
This is all pieced together from memory and what I've picked up here and there online so again, don't quote me.
It's not very fast though. With my non-fancy SD reader I was only getting like 75kBps throughput.
I know it can go a lot faster than that though. MB/s with the right setup and doing raw sector writes to the SD instead of using a filesystem, but I've never done it.
4MB of flash + 4MB of RAM, what can anyone even do with that?
8051 was a quite nice embedded CPU.
When I started working on the 8051, the first application I programmed (in c - we never used c++) - for running a number of tests on the radio peripheral - filled 1103 bytes. I had been given a budget of 1200 bytes: If I exceeded that, the the system would have to be shipped without the radio test software, which would be very unfortunate. (We are talking about Bluetooth LE, Direct Test Mode - DTM.)
Sure: This is 11 years ago. Yet we are talking about a factor of almost 4000. Then I find the question "what can anyone even do with that?" sort of ... let me call it "out of place".
Now, although DTM was run as a standalone application, it was activated through special input hardware input signals. The rest of the 16 bit address space was occupied by the "normal" IoT application (even thought the IoT term wasn't invented then). This 8051 actually had a huge address space: The upper 16 Ki could be bank switched among 4 banks, so the total code space was 48 + 4*16 Ki byte, 112 Kibyte total. So you might say that calling it a factor of 36 in available code space would be more correct, even though the DTM application filled less than a percent of the available space.
I'm sorry I wasn't more clear. It isn't the total space that's irksome to me but rather the ratio of RAM to non-volatile storage. I run out of flash to store my program code in practice. I don't run out of RAM. And I'm far from the only one. One of the most frequent complaints around on the forums is not having enough flash to store code that uses all of the features of the ESP32 chip. IOW, the software stack necessary to support the entire hardware stack will not fit on the flash.
Hence my issue. Why did they add 4MB of RAM when people really need another 4MB of flash instead!
Couldn't you simply pretend that half of the RAM isn't there?
Right now, my desktop PC uses less than 3 GiByte out of 16 GiB RAM - more than 80% is unused. Half of my disk space is currently unused. Except in a few extreme cases, over any one-hour interval, my Internet connection is used less than one percent. It doesn't bother me.
If your real problem is lack of flash space, then forget everything about RAM and focus on the flash. Either, switch to a larger device, or revise your system architecture.
In another post, you tell that you do data logging to flash - so you are not running out of code space, but of data space. To answer your headline question: 'They' were thinking that flash is for code, RAM is for data. Actually, that is a quite common approach! For persistent storage, one commonly uses external devices, not CPU internal code space. Maybe you should consider thinking the same way.
The space I'm using in flash for data in this case is trivial. About 90 bytes a second over a minute or two.
As far as external drives, you're thinking PCs and such. The external bus on a device like this just isn't up to that. You're looking at topping out at 1MB/s and that's hacking the elephant out of the thing, and doing raw sector writes to SD. The flash by comparison is much, much faster
If I get you right: You run out of 4 MiByte flash code space, less about 90 bytes a second over a minute or two (that is in the order of 10 KiByte, which is small change). So your code size is very close to 4 MiByte in size. I would take a look into that! 4 MiByte of code in an IoT device sounds like quite a lot.
Doesn't that development kit of yours provide any sort of flash card interface, or a USB memory stick interface?
If speed is a problem: Using a tiny little corner of the RAM (that you seem to detest so much) as a buffer - I can't believe that the RAM isn't fast enough for you! - and flushing it from RAM to SD or USB stick or whatever, at whatever pace is available: Maybe that would be a nice use for that otherwise useless RAM!
RAM is fast enough for me. Maybe I wasn't clear before or something. I was pretty exhausted when I started this thread.
My code is indeed close to 4MB in size, and most of that is beyond my control. For example, probably the lion's share of my available space is taken up by the ESP-IDF's bluetooth stack (they don't let you just include BLE even though that's all i use) and then the silly Adafruit graphics library, which is just garbage and includes all kinds of code for different display adapters i'll never use, but is the only game in town for doing rich, relatively well tested graphics on the arduino framework against an RA8875 controller.
In fact, were it not for all the dependencies my code wouldn't be that big.
I could use extra flash theoretically but i can't put code on it. the ESP32 just doesn't let you extend its flash size as seamlessly as you can its RAM. The extra flash would register as external, not integrated..
( too much ignorance - partly re. your power supply / power cycles ) can't you view the PSRAM as flash? Considering that it's slow, as disk space?
Then you load to that over?? and run. As long as you can maintain sufficient power to keep it live.
How good is your power supply, how bad is dead ( boot - reload ) time?
( I've one tool that wants 5 minutes start up, unless it's been off a while, then it gets fussy for a half hour. - One that want's a day under vacuum and purge. Remote program load wouldn't count. )
B) even if it wasn't, the program code is too big to fit on flash, meaning literally even if i could just store the code in PSRAM it would have to be downloaded to the device every time you turned it on.
C) even if it weren't for B there's no way to set the external RAM as executable AFAIK. It's not addressable as program code space.
More confused, 320K working ram ( running program, scratch ( or are you running from flash and ram just as scratch? )) 4M flash, 4M PSRAM.
My picture was; on power-up load PSRAM, then swap from PSRAM into RAM ( or flash ) the parts you need as you go.
Either as small programs or overlays ( a hell I've never been involved in. )
So, yes, load the PSRAM on every boot, which may take too long, may not be feasible with the connections you have.
So 1. I wasn't thinking ( as I should ) running from flash,
2. wasn't clear that I meant swapping. AND having to re-load every boot.
Of course, that grief is likely not worth it. Unless you only needed the WIFI rarely and could swap that in / out as needed. And wouldn't get bricked when the swap failed.
Yeah, overlays aren't really practical. I think i can keep this within 4MB of total storage. I'm using some of the flash to store session data, but I could use the 4MB of PSRAM for that instead and that would give me a little more space for program code. I think i can fit it when i do that.
The reason i'm not doing that currently is I'm using a WROOM not a WROVER for the current device. A WROOM does not have the 4MB of PSRAM, it only has the 320kb of ram (which includes the program's variables and such but not the program code itself which i think runs straight off of the flash)
Oh and to be clear,
WROVER: 4MB of non-volatile flash. 4MB of volatile PSRAM (accessible as RAM), 320kB of core RAM available
WROOM: 4MB of non-volatile flash.. 320kB of core RAM
I'm playing with toys from the same family. You can get the ESP32-DEVKIT-VIE[^] with 8MB flash.
OTA upgrade is a PITA. If at all possible, try to explain to your client all the security issues he can have and steer him away from it. The way it is currently implemented is brain-dead: for the smallest change you need to have twice the amount of flash.
If there are more of us playing with these toys maybe CP can open a discussion forum where we would not annoy everyone else with technical details. Just a thought.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Last Visit: 31-Dec-99 18:00 Last Update: 5-May-21 22:03