Yes, LDRB and LDRW will load bytes and halfwords (16-bit) respectively.
There's no penalty on doing byte access at any address, so no advantage to storing byte values in word-sized memory.
The thing that does incur a penalty is accessing something larger than a byte on an address which is not a multiple of that size: on RP2040 (CortexM0+) that will not work and gives an exception; on RP2350 (CortexM33) it will work fine and give the expected result, but takes an extra cycle since behind the scenes it is doing two reads at rounded addresses and then splicing the results together to give the value you asked for.
You might find it informative to look at the code the compiler is generating (more useful in most cases to do that and if you don't like it tweak the C to give something you like better, rather than launching into hand-written assembler). The standard SDK build gives you a .dis file alongside the output .uf2 etc, though I think you need to enable it:
Alternatively you can use arm-none-eabi-objdump -r -S <one_of_my_files>.o to disassemble an individual object file.
If you have -g in your compile options, that will (without changing the code generated) allow the disassembly to show the source code interleaved with the generated instructions - though that sometimes looks rather odd when the compiler has optimised your code and done things in a different order.
There's no penalty on doing byte access at any address, so no advantage to storing byte values in word-sized memory.
The thing that does incur a penalty is accessing something larger than a byte on an address which is not a multiple of that size: on RP2040 (CortexM0+) that will not work and gives an exception; on RP2350 (CortexM33) it will work fine and give the expected result, but takes an extra cycle since behind the scenes it is doing two reads at rounded addresses and then splicing the results together to give the value you asked for.
You might find it informative to look at the code the compiler is generating (more useful in most cases to do that and if you don't like it tweak the C to give something you like better, rather than launching into hand-written assembler). The standard SDK build gives you a .dis file alongside the output .uf2 etc, though I think you need to enable it:
Code:
pico_add_extra_outputs(my_project_name)If you have -g in your compile options, that will (without changing the code generated) allow the disassembly to show the source code interleaved with the generated instructions - though that sometimes looks rather odd when the compiler has optimised your code and done things in a different order.
Statistics: Posted by arg001 — Wed Oct 16, 2024 11:40 am