If you can tell your C compiler to reliably put some label (or variable) buffer_end
immediately after the uint32_t buffer[32];
, your assembly language code can just use that buffer_end
reference instead of awkwardly having the linker add two values.
It is easy to do something like that if you define your buffer in a .S
file, but not so easy in a .c
file.
FWIW, it may be possible that .o
files contain some size information. I generate a .o
file from a with with binary data for one of my systems:
$ avr-objcopy -B avr -I binary -O elf32-avr --readonly-text --rename-section .data=.text,contents,alloc,load,readonly,code foo.bin foo.o
This gives me a foo.o
which produces the following after nm foo.o
:
00000c00 T _binary_foo_bin_end
00000c00 A _binary_foo_bin_size
00000000 T _binary_foo_bin_start
The type of _binary_foo_bin_size
might be useful if it can be adapted to your case - if you do need the size over the buffer_end
label after all.
BTW, if you are writing for one of the AVR chips which have more than 256 bytes of SRAM, your code will probably need to make proper use of the lo8
/hi8
macros to test all 16 address bits.