Hi,
Programming the maple mini with the GCC-chain is still a pleasure and my FM synth is almost finished :-)
I imagine i'm not far from the 20kb limit.
I wondered if there is a way to know how much free RAM i still have ?
What happens when the maple is out of RAM ?
Thanks,
Cheers,
Xavier
mbolivar
LeafLabs
I'm no good with ld-script, so these are only guesses, but:
It looks like the end of statically-allocated RAM is defined by the linker script as _end (in common_ram.inc or common_rom.inc, depending on a Flash or RAM build). At least, that's what syscalls.c says:
https://github.com/leaflabs/libmaple/blob/0.0.11/libmaple/syscalls.c#L28
That's supported by these lines:
https://github.com/leaflabs/libmaple/blob/0.0.11/support/ld/common_ram.inc#L175
https://github.com/leaflabs/libmaple/blob/0.0.11/support/ld/common_rom.inc#L177
Those lines seem to be assigning _end to the address immediately following the .data and .bss sections.
Given that, and the definition of _sbrk in syscalls.c, it seems to me that you can use STACK_TOP - sbrk(0) to get the number of free bytes. (STACK_TOP is currently defined in libmaple.h).
Of course, that's a runtime answer; if you want a static answer and are avoiding dynamic memory allocation, then the number of free bytes on Maple Mini should be 17kB - (sizeof(.data) + sizeof(.bss)); the latter sizes are given to you by the libmaple Makefile after each compile, like so:
Final Size:
text data bss dec hex filename
27588 1488 664 29740 742c build/maple_mini.elfRe: what happens when you run out of RAM, if you overflow the ram memory region defined by your linker script, then your program should refuse to compile. I seem to recall that you're using a custom Makefile, so I can't guarantee that for your system. If you overflow it at runtime, then I suppose as usual it depends on your/newlib's error handling.
HTH, sorry I can't give you more definite answers right now.
Incidentally, it seems to me that there's a bug in _sbrk() -- I believe that line 46,
if ((STACK_TOP - (unsigned int)heap_ptr) >= 0) {
should actually be
if ((STACK_TOP - (unsigned int)heap_ptr) >= nbytes) {
Will confirm w/ Perry.
I noticed something unexpected.
All my "const" variables (not __flash__) are not counted in "data". Are they loaded in RAM at run time ? Or do they stay in flash memory ?
Also when i remove "const" they show up in the "data" column even with __FLASH__ (????).
What about the read latency access, is the RAM faster then FLASH ?
Where can i find details on this ?
Thanks,
Xavier
mbolivar
LeafLabs
I've been messing with this a bit; here's what I've found out so far.
For reference, these tests were all performed with today's libmaple master, which has SHA 3887713e693967983b4247dbb7dd3318a57f73c5.
This is my test rig:
#include "wirish.h"
<define an array of uint32 named 'array'>
int main(void) {
while (true) {
for (unsigned i = 0; i < sizeof(array)/sizeof(array[0]); i++) {
SerialUSB.write(array[i]);
}
}
return 0;
}I used uint32 so that the numbers wouldn't get confused by padding issues. I print the entire array to defeat any optimizations that might prune it out of the final binary, in whole or in part. Here are some sizes I get for various declarations of "array":
With "uint32 array[4] = {1, 2, 3, 4};"
-------------------------------------
Object file sizes:
text data bss dec hex filename
36 16 0 52 34 build/main.oAs expected, 16 bytes of initialized, mutable data. This will be the baseline for later comparisons.
With "uint32 array[8] = {1, 2, 3, 4, 5, 6, 7, 8};"
-------------------------------------------------
Object file sizes:
text data bss dec hex filename
36 32 0 68 44 build/main.oAs expected, data goes up by 16 bytes, and the other sizes remain the same. This is consistent with non-const initialized variables living in the .data section.
With "const uint32 array[4] = {1, 2, 3, 4};"
-------------------------------------------
Object file sizes:
text data bss dec hex filename
52 0 0 52 34 build/main.oInterestingly, compared to the baseline, text increases by 16 bytes, and data goes down by the same amount. I took a look at the file build/maple_mini.disas (produced by our Makefile); it had this to say:
08007f2c <_ZL5array>:
8007f2c: 00000001 00000002 00000003 00000004 ................0x08007f2c is an address in Flash! Interesting.
To dig further, I got GCC to give me its assembly output for main.cpp; here's the relevant excerpt:
.section .rodata._ZL5array,"a",%progbits
.align 2
.set .LANCHOR0,. + 0
.type _ZL5array, %object
.size _ZL5array, 16
_ZL5array:
.word 1
.word 2
.word 3
.word 4This excerpt from the linker file common_rom.inc explains what happened:
SECTIONS
{
.text :
[ ... irrelevant text omitted ...]
*(.rodata .rodata.* .gnu.linkonce.r.*)Whenever GCC sticks something into an .rodata section, the linker shoves it into Flash. No idea if this happens for all definitions qualified with const. If so, we might want to deprecate the __FLASH__ macro in favor of just using const, especially given the situation explained in the following section.
With "uint32 array[4] __FLASH__ = {1, 2, 3, 4};"
-----------------------------------------------
Object file sizes:
text data bss dec hex filename
36 16 0 52 34 build/main.oThis reproduces your results concerning __FLASH__, namely, that allocations with __FLASH__ appear in data when size output is determined. Confusingly, array no longer shows up in the .disas!
All's not lost, though; from main.cpp's assembly:
.global array
.section .USER_FLASH,"aw",%progbits
.align 2
.set .LANCHOR0,. + 0
.type array, %object
.size array, 16
array:
.word 1
.word 2
.word 3
.word 4It correctly is in section .USER_FLASH, so it will definitely get stored in Flash on the STM32, since common_rom.inc says this:
/* expose a custom rom only section */
.USER_FLASH :
{
*(.USER_FLASH)
} >romAnd Maple Mini's Flash linker script (support/ld/maple_mini/flash.ld) says this:
MEMORY
{
ram (rwx) : ORIGIN = 0x20000C00, LENGTH = 17K
rom (rx) : ORIGIN = 0x08005000, LENGTH = 108K
}I'm not sure why arm-none-eabi-size is reporting that it lives in data. However, here's a guess: __FLASH__ just ends up expanding into __attribute__((section (".USER_FLASH"))), and that's just a section which we handle specially in our linker scripts. Since that's all information that arm-none-eabi-size doesn't have, it seems like it's just ignoring the __attribute__(), with the result that array is assumed to live in data.
That obviously really sucks when trying to figure out how much RAM you're using. As a workaround, I'd recommend using both const and __FLASH__ for the time being. (I checked; all the usages of __FLASH__ in libmaple are also accompanied by 'const', so if the compiler's .rodata behavior is consistent, we shouldn't be giving you any false readings in that regard).
*Whew*! Not sure how many people are still reading by this point, but hopefully this should clarify things a bit.
mbolivar
LeafLabs
Xavier,
What about the read latency access, is the RAM faster then FLASH ?
Where can i find details on this ?
setupFlash() in boards.cpp (which is called from init()) uses FLASH_WAIT_STATE_2:
static void setupFlash(void) {
flash_enable_prefetch();
flash_set_latency(FLASH_WAIT_STATE_2);
}I'm not sure how much help you get from prefetching on this. For more references, I guess I'd check out ST PM0042, the flash programming manual. Impossible to find on ST's website like everything else, but here's a link:
http://flyingfox.googlecode.com/svn-history/r164/trunk/flight/doc/stm32-flash-programming.pdf
robodude666
Member
Embedded Signals, the guys who wrote an assembly-optimized FFT library for the STM Cortex M3, has a couple benchmarks up:
http://www.embeddedsignals.com/FFTlibrary2bench.pdf
The benchmarks represent the number of CPU cycles required to perform a task. What the specific task is is irrelevant (more or less), just the performance change between the different memory used is important to note.
From the benchmarks, LAT2 performance is slightly worse than LAT1 or LAT0 performance. Loading coefficients from RAM vs FLASH shows another small boost in performance as well.
Thanks a lot Marti, very interesting informations.
I'm going to use both const and __FLASH__.
And thanks robodude for the benchmark link.
The good news for me, is that with my wavetables in FLASH, my synth can still handle the same number of voices (but must be closer to the audio pop/glitch limit).
And as i have more space i could add 2 other bandlimited waveforms: square and sawtooth...
And they sound good :-)
Xavier
StephenFromNYC
Moderator
Hello,
In an earlier post mbolivar suggested reading PM0042. He could not find the file on the st.com web site, so he gave a link to an October 2009 (revision 7) of PM0042 found on a googlecode site.
Yes, it is hard to find stuff on the st.com site, but I have a very simple explanation for the missing file. For some reason, PM0042 was replaced by PM0075. This is confirmed on the past page of the revision history for PM0075. Rev 1 of PM0075 (August 2010) has the same content as Rev 8 of PM0042.
robodude666 provided a direct link in this topic:
http://forums.leaflabs.com/topic.php?id=995#post-6064
Time to update the bookmarks (again).
Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)
hans leuthold
Member
Hello,
Xavier asked "What about the read latency access, is the RAM faster then FLASH ?
Where can i find details on this ?"
Maybe there is a tidbit here: I am using a Maple Rev5 to decimate a bit stream coming in at 273.6kHz with 4 filters each 256 words long
the filter coefficients are set up as tables like
int sinecoeffs[256] = { all the CSV integer values };
Having read all the posts above I tried to declare that table as const to save RAM.
What I notice is that the loop time is impacted to such a degree that the 273.6kHz throughput cannot be achieved anymore.
gbulmer
Moderator
hans leuthold - "Xavier asked "What about the read latency access, is the RAM faster then FLASH ?
Where can i find details on this ?"
RM0008 Reference manual for STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced ARM-based 32-bit MCUs
Edit: http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf
3.3.3 Embedded Flash memory
"The wait states represent the ratio of the SYSCLK (system clock) period to the Flash memory access time:
zero wait state, if 0 < SYSCLK ≤ 24 MHz
one wait state, if 24 MHz < SYSCLK ≤ 48 MHz
two wait states, if 48 MHz < SYSCLK ≤ 72 MHz"
AFAIK RAM is zero wait states at 72MHz (unless DMA is competing).
You must log in to post.
