[ryukoposting]

You can certainly do that, sure, but any Cortex-M MCU can do that, and plenty of others have hardware AES acceleration that would make the process much less asinine.

Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.

[TickleSteve]

520K RAM is huge for most typical embedded apps. Most micros are typically around the 48K->128K SRAM.

[ryukoposting]

Define "typical."

To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading.

If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340.

So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.

[dmitrygr]

> Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.

what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded?

[ryukoposting]

I'm smoking multiprotocol wireless systems for industrial, medical, and military applications. To my recollection, the very smallest of those was around 280K in .text, and 180K in .data. Others have been 2-3x larger in both areas.

I would sure hope a decstation3100 emulator is small. After all, it's worthless unless you actually run something within the emulator, and that will inevitably be much larger than the emulator itself. I wouldn't know, though. Believe it or not, nobody pays me to emulate computers from 1978.

[vardump]

There are plenty of embedded applications that require megabytes or even gigabytes.

For example medical imaging.

As well as plenty that require 16 bytes of RAM and a few hundred bytes of program memory. And everything in between.

[my123]

If it's in the gigabyte range it's just not an MCU by any stretch. And if it has a proper (LP)DDR controller it's not one either really

[vardump]

Yes and no. Plenty of such applications that use a µC + an FPGA. FPGA interfaces with some DDR memory and CMOS/CCD/whatever.

Up to you what you call it.

[misiek08]

So you make hardware costing dozens of thousands of dollars and brag about memory on 5$ chip? That explains a lot why so many medical and industrial (I haven’t touch military hardware) are so badly designed, with some sad proprietary protocols and dead few months after warranty passes. Today I’ve learned!

[vardump]

As if that depends on the engineers!

When you make 1M thingies, $5 savings each means $5M CEO comp.