2010-08-26 05:16 AM
Assembler parameters for routine
2011-05-17 05:04 AM
Not sure your first example is correct. The value in R0 would be the integer ''i'', it is not a pointer. And loading from an address like ''5'' would cause a bus fault as it is unaligned.
For your second LDR r1,[R0, #0] ; ar[0] LDR r2,[R0, #4] ; ar[1]2011-05-17 05:04 AM
ldr r1,[r0]
ldrh r1,[r0] ldrb r1,[r0] ldr r1,[r0],#n ldrh r1,[r0],#n ldrb r1,[r0],#n The first 3 instructions are the basic memory loads. The second 3 add n to the address register after the instruction. The corresponding stores work the same way. I don’t know if #-4 would work. See if the assembler likes it. I believe the last 3 are 32-bit instructions but don’t know for sure. My guess is that instructions with the #n take no longer to execute than those without #n.2011-05-17 05:04 AM
To my first example:
If I write LDR r1,r0 i get a compiler error To the second: Great thanks it works fine :) Is there a an other way to incremet the pointer? Something like r0++? Or other said is this LDR r1,[r0,#0] the fastest way to access the array element 0? Thank your for your great help! :)2011-05-17 05:04 AM
The LOAD/STORE class instructions typically act on memory, long immediate values are usually loaded from a ''literal pool'' in memory. For register to register (CPU) stuff the MOVE class instructions would be more appropriate, but with 3 operand instructions one usually performs some operation on the register as it's being moved to more effectively use the processor.
To step through the array, consider LDR R0,[R1,#0] ADDS R1, R1, #4 ; ADDS R1,#42011-05-17 05:04 AM
For documentation look at STM32F10xxx_ProgrammingManual.
Fastest way should be: LDRD r1, r2, [r0] or LDMIA r0, {r1,r2} In both ways r1 is loaded with [r0] and r2 with [r0, 4]; r0 is unchanged. You can change the ''index'' in many ways (pre, post, up, down) in the same instruction as the load itself. If you have a loop, you can read i.e. 8 values in one command and increment r0 to the next unread value: LDMIA r0!, {r1-r8} LDMIA has better performance in STM32 because the mcu doesn't have a real pipeline infrastructure (the pipeline is blocked in many commands). This command is one of the exceptions that uses the pipeline in fact.