How much RAM and FLASH memory is available for sketches on Maple Rev 3

LeafLabs Garden » Support » Maple Hardware Support

How much RAM and FLASH memory is available for sketches on Maple Rev 3

(5 posts) (5 voices)

Started 5 years ago by StephenFromNYC
Latest reply from poslathian

StephenFromNYC
Moderator

August 25, 2010

Hello,

I am using a Maple Rev 3 board with IDE 0.0.6 on a Pentium III Thinkpad (512 meg RAM) with USB 1.1 running Windows XP Professional SP3.

I am wondering if my unpredictable experience with uploading sketches (yes, I was using the problematic SerialUSB.print() function) is related to the amount of memory reported to be available after I compile a sketch. My problem is described here:

http://forums.leaflabs.com/topic.php?id=128

The STM32F103RB chip used on the Maple R3 board should have 20KB RAM and 128KB FLASH memory.

How much of the 20KB RAM and the 128KB FLASH memory is available for sketches?

I am asking because when I compile the Blink example I am surprised by the amount of "available" memory.

Here is my data:

1) Maple R3 set to upload to "LeafLabs R3 Maple RAM"

Compile reports:

Total 12296
Binary sketch size is reported above. Check it against a 17000 byte maximum.

Question: Where are the missing "3KB"?

2) Maple R3 set to upload to "LeafLabs Maple R3 FLASH"

Compile reports:

Total 12296
Binary sketch size is reported above. Check it against a 61000 byte maximum.

Question: Where is the missing "67KB"?

I am not surprised that the full 20KB and 128KB bytes are not available, but I am surprised that so much is not available (especially when the sketch is compiled to upload to the FLASH memory).

Thanks!

Stephen from NYC

Posted 5 years ago #
bnewbold
Ex-Leaflabs

The "61000 byte maximum" issue was a mistake and was fixed in this commit (to be included in v0.0.7):
http://github.com/leaflabs/maple-ide/commit/119edd46a245ff544698c2b0166a0361c494ff28

20k and 128k are the full hardware memory sizes. During early development of the maple bootloader we decided to be very conservative and reserve 3k of RAM and 28k of FLASH exclusively for the bootloaded. The bootloader doesn't actually use nearly that much space, but we wanted to make sure that special or customized versions of the bootloader would be compatible with the IDE. 100kb of FLASH also seemed unimaginably huge and plenty for any use. At this point libmaple has become somewhat bloated and even simple blinky programs barely fit in the RAM section, and audio effects lookup tables could make use of some of the 28k of reserved FLASH. For context, bootloaders for other chips are very frequently under a thousand bytes, and our USB code should not add more than a couple KB beyond that.

Looking forwards it would be nice to "reclaim" this reserved space, but as this will require modifications to the IDE, libmaple, and the bootloader, as well as careful testing to ensure compatibility with older bootloaders, it is not at the top of our development queue. We would probably rewrite the bootloader first to see how small we can make it.

We are thinking of ways to reduce the base sketch sizes, especially now that almost all functionality has been added and the API is stabilizing.

Posted 5 years ago #
leaflabsandy
Member

http://forums.leaflabs.com/topic.php?id=107

Posted 5 years ago #
CarlO
Member

Is there any reason that the sketch can't use all 20K of Ram when using the "FLASH" profile? It seems like the bootloader and the sketch won't need the ram for stack and heap space at the same time if the code is all stored in flash. After reset, the bootloader will build it's stack in ram. Once the bootloader does the jump to the sketch code, the sketch will build it's stack in ram.

I have been doing some testing on this and so far have not had any problems. Anyone see any hidden issues with this approach?

CarlO

Posted 5 years ago #
poslathian
LeafLabs

I think you may be right. It used to be that the bootloader stayed running in the backround all the time, and provided the interface for the USB handler via callbacks from user code. This is now longer the case, so we can probably return the RAM used by the bootloader back to the user code. Thanks for pointing this out!

Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.