> I typically use PRU periods around 2-3 uS, so the GPIO read is a 
> bigger chunk of the timing budget. 

> If you make the GPIO reads and timer processing individual "tasklets", 
> I have no issue with merging them into master.  Given the way the PRU 
> code works, there isn't much down-side to having the tasklets 
> available: just a bit more PRU program memory consumed (we're no where 
> near the limit at the moment) and they won't slow down the PRU 
> processing if they aren't being used. 

> I would recommend making the read tasklet configurable so that it will 
> optionally read any/all of the GPIO banks.  I'd probably use the task 
> state registers for the GPIO values (R4-11) and have the read tasklet 
> stash the GPIO values in the scratchpad, similar to what I did with 
> the GPIO address values
thanks for your feedback, what you suggest sounds like a good idea to use the 
scratchpad. I didn't know about it (I'm just starting&learning about the PRU so 
sorry if I have some noob questions).
I also want to implement it in some way that it does not slow down the PRU if 
gpio inputs are not used.

> Sadly, the Decamux code is using state register 6, or you could use 
> registers 4-7 for the GPIO values.  But you can do an offset when 
> performing the XIN/XOUT (set SHIFT_EN in the SPP register), so you can 
> use any other chunk of 4 registers in the scratchpad (maybe R0-3?).
do you know how many PRU cycle it takes to set the SHIFT_EN bit in SPP reg.? 
There is the list of timing here:
http://www.ti.com/lit/sprace8 but I don't know if SHIFT_EN is considered as a 
"PRU CTRL" register, "PRU CFG" or something else..

Also how long does it takes to load data from the PRU DRAM to r0-31, the 
previous link say 3PRU cycles (15ns) but does that depends of how many bytes we 
load? or it takes the same amount of time regardless of the number of bytes?


> Note the XIN/XOUT instructions only take a single clock, so this only 
> adds 2 cycles to your GPIO code vs. consuming 4 registers all the time. 
Good to know

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to