I don't believe the reads/writes to the GPIO registers would have worked
without the OCP master being enabled.
Thanks, I'll check out the library to see what magic is missing from that
code.
On Jun 21, 2014 8:20 AM, TJF jeli.freih...@gmail.com wrote:
A miss click and a miss post ...
The PRUSS
You have 100% full control over anything the PRU can access.
This pru code seems to disproves this. The PRU cannot modify the
configuration registers.
// enable ocp master.
LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4
// turn on gpio
mov r1, 0x4000
mov r0, 0x44E07194
SBBO b, a, 0, 4
//
I apologize, a miss click posted that...full code below.
*// enable ocp master.*LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4
*// try to set gpio address*
*// gpio on*mov r1, 0x4000# gpio 0, bit 14, p9.29
mov r0, 0x44E07194 # gpio 0 set register
SBBO r1, r0, 0, 4
*//
A miss click and a miss post ...
The PRUSS can access the Control Modul pin mux registers. It's working for
a lot of libpruio users. Did you enable the OCP master port?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the
On 5/30/2014 6:16 PM, foreverska wrote:
What is with P9.41 and P9.42? They don't have pruout status even though
they have an assigned bit in R30? That cuts this core down to 8 outputs...
You are likely referring to P9.41.1 and P9.41.2, these are special case
pins and are accessed using
Well it's straight-forward to craft a device tree overlay for just the
pins you need. I'll try to get the missing HDMI overlay added soon, but
no guarantees. I've got a bunch of other stuff I'm working on right now.
On 5/23/2014 9:54 PM, foreverska wrote:
Oh... I'm barely getting by with what
I understand man and no rush. Heck I may tackle it one weekend. For the
time being I've disable the eMMC and used it's pins for inputs and I'm
using pru0 for the heavy lifting. pru1 is still just slightly better for
that purpose.
On Saturday, May 24, 2014 2:07:46 PM UTC-5, Charles
On 5/22/2014 11:14 PM, foreverska wrote:
There we are. I got it working using C24. That's incredibly confusing.
What's config pin's deal here:
debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.15
P8_15 Mode: pruin
debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.45
I thought we disabled the HDM in the first place... it's disabled in my
uENv.
Note that you can access almost as many PRU0 pins (11 out, 10 in)
without needing to disable either eMMC or HDMI.
Unfortuantely I need both processors. If I could even find two inputs on
PRU1 I would just move that
Oh... I'm barely getting by with what I'm doing much less figuring that
out. I really really really would love it done or any sort of work around
that would allow me to assign those pins to the PRU config-pin or not.
This project is very cramped without those pins. Doable on entry level
There we are. I got it working using C24. That's incredibly confusing.
What's config pin's deal here:
debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.15
P8_15 Mode: pruin
debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.45
Pin is not modifyable: P8_45 lcd_data0
Code never seems to work out of the box for me on these things. Now that I
have operational code looking at R31 I have issues putting the results int
datamemory which is just absurd. Here's the code:
#define CONST_PRUDRAM C3
#define TOOTH_COUNTER R5
lpe:
ADD
On 5/21/2014 1:16 AM, foreverska wrote:
Code never seems to work out of the box for me on these things. Now that I
have operational code looking at R31 I have issues putting the results int
datamemory which is just absurd. Here's the code:
#define CONST_PRUDRAM C3
#define
Use the real TRM and data sheet. The page you linked to is for an
earlier version of the PRU. At the top it says:
This arcticle is part of a collection of articles describing the PRU
subsystem included in OMAP-L1x8/C674m/AM18xx devices (where m is an even
number).
The PRU cores are upgraded in
On 5/19/2014 4:06 PM, Brandon I wrote:
The pin mux registers require privileged memory access, which is why
the kernel space is usually required. The pru can write these!?
Of course. The PRU is directly wired into the on-chip bus, and bypasses
all ARM side sanity checks like memory page
15 matches
Mail list logo
