{"id":2479,"date":"2022-08-30T15:25:12","date_gmt":"2022-08-30T15:25:12","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/01\/17\/force-runtime-array-allocation-and-initialization-with-list-syntax-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:25:12","modified_gmt":"2022-08-30T15:25:12","slug":"force-runtime-array-allocation-and-initialization-with-list-syntax-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/force-runtime-array-allocation-and-initialization-with-list-syntax-collection-of-common-programming-errors\/","title":{"rendered":"Force runtime array allocation and initialization with list syntax-Collection of common programming errors"},"content":{"rendered":"

I am working on an atmega328<\/strong> that only has 2K of RAM<\/strong>.<\/p>\n

I use a script to create 10bytes arrays from 10 bitmaps that represent 10 digits of my LCD timer. Those byte arrays are stored in my source code but since I only write one digit at time there is no reason to keep all of them in RAM.<\/strong> This way I can use bigger digits and consume less RAM!<\/p>\n

This is what I am trying to do:<\/p>\n

void load_digit_ba(uint8_t digit, uint8_t digit_ba[]) {\n\n  \/\/ from 0 to 9 I copy the current digit in the byte array form into digit_ba\n  if (digit == 0) {\n    uint8_t digit_ba_tmp[10] = { 24, 40, 0, 0, 0, 224, 240, 248, 252, 254 };\n\n    memcpy(digit_ba, digit_ba_tmp, 10);\n  }\n...\n\n}\n<\/code><\/pre>\n
But it seems that the compiler is statically reserving memory for all the arrays. In my case 122 bytes * 10 digits = ~1K, more than half of my RAM.<\/p>\n
Sketch uses 7,310 bytes (23%) of program storage space. Maximum is 30,720 bytes.\nGlobal variables use 1,695 bytes (82%) of dynamic memory, leaving 353 bytes for local variables. Maximum is 2,048 bytes\n<\/code><\/pre>\n
If I add a cell to the array [11] instead of [10] and just pass 10 value as initializers it will instead allocate the memory at runtime (it seems)<\/em>:<\/p>\n
void load_digit_ba(uint8_t digit, uint8_t digit_ba[]) {\n\n  if (digit == 0) {\n    uint8_t digit_ba_tmp[11] = { 24, 40, 0, 0, 0, 224, 240, 248, 252, 254 };\n\n    memcpy(digit_ba, digit_ba_tmp, 10);\n  }\n...\n\n}\n<\/code><\/pre>\n
Aurdino IDE says:<\/p>\n
Sketch uses 11,396 bytes (37%) of program storage space. Maximum is 30,720 bytes.\nGlobal variables use 597 bytes (29%) of dynamic memory, leaving 1,451 bytes for local variables. Maximum is 2,048 bytes.\n<\/code><\/pre>\n
Same behavior if I do uint8_t digit_ba_tmp[]<\/code> letting the compiler figure the length, it reserves ~1K RAM.<\/p>\n
Why adding a cell does that and is it clean? Doesn’t seem to me. The assumption here is that since the length of the digit array is fixed for every digit, just changes the content, and I send one digit at time over serial to the display, it makes sense to just load the current digit into ram and then send it. I don’t see any heap\/stack memory fragmentation issue here, am I right? smiley-sad<\/p>\n
Originally posted 2014-01-17 07:10:27. <\/small><\/p>","protected":false},"excerpt":{"rendered":"
I am working on an atmega328 that only has 2K of RAM. I use a script to create 10bytes arrays from 10 bitmaps that represent 10 digits of my LCD timer. Those byte arrays are stored in my source code but since I only write one digit at time there is no reason to keep […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2479","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/2479","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=2479"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/2479\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=2479"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=2479"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=2479"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}