In trying to test my code for the PRUs is there a good way to check and see
if binary is being loaded into the PRU properly and check whether or not it
is executing. I have a simple LED circuit running some basic blink code but
nothing seems to be occurring. Also with everything activated, the
pru_rproc running and the devices showing up as they should I still
sometimes get "no such device" when I try to bind pru0, have you ever run
into this issue?
When attempting to bind pru0 I get the following outpur from dmesg:
[ 697.537395] remoteproc1: 4a334000.pru0 is available
[ 697.537435] remoteproc1: Note: remoteproc is still under development and
considered experimental.
[ 697.537450] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and
backward compatibility isn't yet guaranteed.
[ 697.537926] remoteproc1: Unsupported class: 254
[ 697.546973] pru-rproc 4a334000.pru0: booting the PRU core manually
[ 697.547013] remoteproc1: powering up 4a334000.pru0
[ 697.547250] pru-rproc 4a334000.pru0: rproc_boot failed
[ 697.557946] remoteproc1: releasing 4a334000.pru0
[ 697.559696] pru-rproc: probe of 4a334000.pru0 failed with error -12
does this mean it's an error in the code I am trying to load into it?
Below is a copy of the assembly code that I am attempting to load if it
helps
Enter code here...; blink.p: demonstration of PRU on the BeagleBone Black
; blink LED connected to P8_11 ten times
.origin 0
.entrypoint TOP
TOP:
MOV r1, 10 ; blink counter
BLINK:
SET r30, r30, 15 ; set GPIO output 15
MOV r0, 0x00a00000 ; delay counter
DELAY:
SUB r0, r0, 1
QBNE DELAY, r0, 0 ; loop until r0 == 0 (delay)
CLR r30, r30, 15 ; clear GPIO output 15
MOV r0, 0x00a00000 ; delay counter
DELAY2:
SUB r0, r0, 1
QBNE DELAY2, r0, 0 ; loop until r0 == 0 (delay)
SUB r1, r1, 1
QBNE BLINK, r1, 0 ; loop until r1 = 0 (blink counter)
MOV r31.b0, 32 + 3
HALT
Zach
(Deleted the old one because I forgot to include the error messages)
On Friday, November 18, 2016 at 8:56:36 AM UTC-5, Zach B wrote:
>
> Greg,
>
> Thanks for the link I to the motor controller. I actually ended up
> figuring out late last night what was preventing remote_proc from running
> properly. I had the line
> dtb=am335x-boneblack-overlay.dtb
> uncommented in my "uEnv.txt" file. I guess that device overlay prevented
> the remote_proc from properly loading. When I commented that line out and
> left the standard boot file "universaln" it came right on at startup no
> problem. The proper devices also show up in "/sys/bus/platform/devices" now
> that I fixed the issue. Without that extra overlay to disable the HDMI is
> there any way to reclaim all of the PRU pins on header 8? Is that something
> that config-pin will handle or will it require a custom overlay or altering
> the main overlay that is loaded at boot?
>
> Zach
>
>
> On Friday, November 18, 2016 at 7:33:30 AM UTC-5, Greg wrote:
>>
>> Zach I think you mentioned you were interested in motor controllers:
>>
>> http://www.ti.com/lit/ug/tidubj6/tidubj6.pdf
>>
>> I just finished the Coursera course "Control of Mobile Robots".
>> The course has some info on a Beaglebone based robot.
>> I want to implement some, but probably not all. I'm going to be drilling
>> into the PID controller project with the Remoteproc and see how far I can
>> get.
>>
>> Regards,
>> Greg
>>
>
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/1dd12093-b1ec-48e4-bf6f-6d5dc989be14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
