On 8/24/2015 9:02 AM, Andrew P. Lentvorski wrote:
>
> The assembly code looks optimal at 4 instructions per toggle (I'm using
> clang):
> .loc 2 80 2 @ gpi.c:80:2
> ldr r1, [sp, #28]
> str r0, [r1]
> .loc 2 81 9 @ gpi.c:81:9
> ldr r1, [sp, #32]
> str r0, [r1]
> .loc 2 82 2 @ gpi.c:82:2
> ldr r1, [sp, #28]
> str r0, [r1]
> .loc 2 83 9 @ gpi.c:83:9
> ldr r1, [sp, #32]
> str r0, [r1]
That is not optimal, loads are expensive (although I would have
thought the stack would be cached).
Optimal would be a sequence of successive stores to the set and clear
register, with the addresses pre-calculated and sitting in registers
(or with a base address and use the str instruction with an immediate
offset). You can probably coerce the C compiler into doing this for
you if you setup a struct or array pointer for the set/clear registers
instead of using the two volatile pointers. You might also need to
move the volatile on the variable definitions. I'm not a "C" guru,
but I think:
uint32_t volatile * gpio_setdataout_addr
...is different from:
volatile uint32_t * gpio_setdataout_addr
...you want the uint32_t to be volatile, not the pointer to it.
I'd still set this up more like:
struct reg {
clr uint32_t;
set uint32_t;
}
volatile reg * gpio_reg = NULL;
...
gpio_reg.set = PIN_17;
gpio_reg.clr = PIN_17;
...but I write C code like a hardware guy who programs in VHDL. :)
Regardless, note that the maximum toggle rate of a GPIO pin using the
PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a
write by the on-chip communication fabric (which means 80 nS period
for a high/low toggle of the pin). This assumes the CPU and the PRU
have similar bandwidth to the L4 fabric, which may or may not be the
case (but I suspect is true).
So it looks like you've got some room for improvement, but you're not
off by an order of magnitude or anything.
--
Charles Steinkuehler
[email protected]
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
