Hi Jon,
Thank you for your reply. There were a few instructions between the SET
and CLR operations which did allow for a longer pulse. I added a loop in
there to delay it for 250ns which should be sufficient for my test
equipment as it samples at 100Ms/s. To clarify further you can see that my
device tree overlay is enabled without conflict, but still no output from
the pin.
root@beaglebone:~/# cat /sys/devices/bone_capemgr.8/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_27_d
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-PRU-01
9: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_28_d
10: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_17_f
11: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_29_2e
12: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_30_d
13: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_39_2e
14: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_40_2e
15: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_41_2e
16: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_42_2e
17: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_43_2e
18: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_44_2e
19: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_45_2e
20: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_46_2e
21: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P9_31_d
If the pins were already allocated I believe that upon loading the overlay
I would have received an error message but received none.
I need to find a way to interrupt PRU0 correctly as to manipulate this
data. I tried to follow the PRU0 to PRU1 interrupt example and believe
that I have the syntax correct. I would just like to find a way to confirm
that the program is cycling correctly by toggling that pin.
I am calling my interrupts from PRU1 with
SET r31.t31
and then receiving my interrupts with
WBS eventStatus, 31 //Wait for bit set for Interrupt
LDI regVal.w2, 0x0000 //Clear the status of Interrupt
LDI regVal.w0, SYS_EVT_PRU0
SBCO regVal, CONST_PRUSSINTC, SICR_OFFSET, 4
where eventstatus is r31 and regVal is r17.
During all of this I set r30.t0 (P9_31) and run a loop for 50 intervals and
then clear r30.t0.
When running this code on PRU0 it never reaches its halt statement. I have
the halt statement as I believe it would be necessary to keep PRU0 from
getting stuck at the interrupt in the code and to interrupt the ARM. I am
going to move forward with removing the HALT statement at the end as well
as the ARM interrupt and just have it always branch and have PRU1
responsible for ARM interrupt and taking care of disabling both PRU's.
Then I will just QBA in the PRU0 code to take care of just waiting for the
next interrupt.
I don't believe I need to setup any enables for these system events as it
is not shown in the PRUtoPRU example code or in the Reference Guide.
On Wednesday, January 20, 2016 at 4:06:11 PM UTC-5, jmelson wrote:
>
>
>
> On Wednesday, January 20, 2016 at 2:08:44 PM UTC-6, Tyler Turcotte wrote:
>>
>>
>> SET r31.t0 //Toggle pin 31 on header 8
>> CLR r31.t0
>>
>>
>>
>>
>> That will only cause a 5ns pulse on that pin. Are you sure you can
>> detect a pulse that narrow?
>>
>
> Jon
>
--
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.
