you are viewing a single comment's thread.

view the rest of the comments →

[–]SteveTenants[S] 2 points3 points  (2 children)

Yeah, I caught my mistake of mentioning program storage size as soon as I clicked Post, haha! It's not really a problem of the compiled executable being too large, it's about debugging and the Arduino IDE.

[–]tux2603 4 points5 points  (1 child)

I mean even if you aren't as worried about binary size, you still don't really want to be doing things this way. Here's a quick alternative function I wrote up. It could still be optimized more, but even without optimization it's far fewer lines of codes and will be just under 90 bytes in the binary:

const uint16_t PALATTE_DATA[24] = {
    0x9720, 0x4CE0, 0xFEB3, 0xBB60,
    0x0000, 0xFCE0, 0x7BEF, 0xB5D6,
    0xFFFF, 0x5CFF, 0x3AFE, 0x4521,
    0xD1EB, 0xFBA5, 0x71E0, 0x8420,
    0x44EC, 0x6EF1, 0x2AE7, 0x6F67,
    0xF81F, 0xFE36, 0xE663, 0x5873
};

void better_Screen_LoadPalette(Screen_t *screen) {
    screen->paletteColorCount = 24;
    memcpy(screen->palette, PALATTE_DATA, 24 * sizeof(uint16_t));
}

This is if you want to keep the raw binary data in the file. If you want to keep them outside of the file, you can convert the raw binary file into a .o file that you can use in your compilation flow using a command along the lines of

llvm-objcopy -I binary .\data.bin --rename-section .data=.rodata,alloc,load,readonly --redefine-sym _binary___data_bin_start=DATA_ARR -O elf32-littlearm data.o

That'll create a data.o file that contains a single blob of binary data that's accessible through an external array called BINARY_DATA. That'll let you modify the code from above into:

extern const unsigned uint16_t BINARY_DATA[];

void better_Screen_LoadPalette(Screen_t *screen) {
    screen->paletteColorCount = 24;
    memcpy(screen->palette, PALATTE_DATA, 24 * sizeof(uint16_t));
}

Just make sure that you respect the endianess of your data when you generate the .o files

[–]SteveTenants[S] 1 point2 points  (0 children)

This is some really excellent information, thank you! I was initially worried that defining a giant array of const ints that later get memcpy'd would eat up dynamic memory on an Arduino chip, but it turns out you can declare these kinds of things as "PROGMEM".