s occuring.
Zach
On Monday, December 5, 2016 at 9:05:36 AM UTC-5, laurel.a.watts wrote:
>
> Hi Zach,
>
> Are you compiling with the -V3 switch? This should enable the scratch pad
> correctly. I've had not problems with it this way.
>
> Laurel
>
> On Sun, Dec 4,
Thanks Jason, those were two great examples.
Has anyone had any trouble with the scratch pad between PRUs? I'm using it
to pass values between the two systems and it doesn't appear to be working
at all. I even created a test script that has a PRU load a value into bank
0 and then read it back o
Thanks Jason, those were two great examples.
Has anyone had any trouble with the scratch pad between PRUs? I'm using it
to pass values between the two systems and it doesn't appear to be working
at all. I even created a test script that has a PRU load a value into bank
0 and then read it back o
Greg,
Thanks for the info. That linker primer helped a bit with what is exactly
going on inside of the linker, at least to the level that I can understand.
I'm still working through getting a single assembly file to work but for
now I figured out a workaround with an empty c file. What is asmpr
s the
answer yet. I'm still working my way through "PRU Optimizing C/C++ User
Guide".
On Sunday, November 27, 2016 at 5:36:15 PM UTC-5, Zach B wrote:
>
> Has anyone compiled a straight assembly file for the PRU? I know you can
> program in C but I can't accurately pre
ake sure
> no other board file is left uncommitted after this line. Otherwise it may
> load at boot instead.
>
> Once that is done, you should be able to configure the pin via config-pin
> to mux the pin for mode 5, or 6 depending on whether you want GPI, or GPO
> through the
d stop the PRUs. I ended up not having to mess around with
any custom device trees. Hopefully that information helps someone else
struggling with the same thing I was.
On Sunday, November 20, 2016 at 7:25:06 PM UTC-5, William Hermans wrote:
>
> On Sun, Nov 20, 2016 at 4:31 PM, Zach B >
&
red devices are
there to start and stop the PRUs. I ended up not having to mess around with
any custom device trees. Hopefully that information helps someone else
struggling with the same thing I was.
On Sunday, November 20, 2016 at 7:25:06 PM UTC-5, William Hermans wrote:
>
> On Sun, Nov
ore complex
> than anything I have seen so far.
> I wonder if it represents something close to the upper limit of how much
> code you can jam in a single PRU? I'll get it to github, hopefully pretty
> soon.
>
> On Saturday, November 19, 2016 at 9:27:38 PM UTC-5, Zach B wrote:
I think if you work through this, you will have
> a good introduction to Linux embedded system design. Be warned that it
> can really eat up hours and hours of your time!
>
> On Friday, November 18, 2016 at 10:39:06 AM UTC-5, Zach B wrote:
>>
>> h that's my prob
code in the firmwares, and if it is not
> there, nothing will happen.
>
> On Friday, November 18, 2016 at 10:06:07 AM UTC-5, Zach B wrote:
>>
>> 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 prop
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:
>
>
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?
Zach
On Friday, November 18, 2016 at 8:56:36 AM UTC-5, Zach B wrote:
>
> Greg,
>
> Thanks for the link I to t
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 f
You could switch the pin mode
> to pruout after the firmware is running and the pruout is deterministically
> set to LOW. Might work, easy enough to try.
>
> On Tuesday, November 15, 2016 at 1:16:43 PM UTC-5, Zach B wrote:
>>
>> I understand that bringing up GPIOs low is g
overlaps some of the labs. Good stuff in there,
> you can dig into the C code and see how to get things done.
>
> A good start is the usual LED blinker, this will show how to manipulate
> the __R30 register to make the header pins go HIGH and LOW programatically
> from the PRU
g the above image, don't touch device tree files (except
> one very trivial change to activate Remoteproc) and use config-pin to
> change pin modes to PRU. All ready to go on this image.
> Get Remoteproc activated and see if you can get the Remoteproc related
> kernel modul
ipt to run the PRU but I keep getting the
error pruss/prussdrv.h: no such file or directory. Are the pruss files
something that needs to be included on my LIBRARY path or LD_LIBRARY path
or is it an extra package I need to download?
On Tuesday, November 8, 2016 at 11:42:25 AM UTC-5, Zach B wrote:
> On Fri, Nov 11, 2016 at 2:14 PM, Zach B >
> wrote:
> > Thanks Robert! That solved the problem I have been having. The overlay
> > loaded and everything looks to be working. One follow up question I do
> have
> > is what is the proper way to load a custom overlay
Thanks Robert! That solved the problem I have been having. The overlay
loaded and everything looks to be working. One follow up question I do have
is what is the proper way to load a custom overlay on startup? Is there a
way to enable multiple overlays as long as they don't try to use the same
11, 2016 at 1:53:16 PM UTC-5, Zach B wrote:
>
> wow that is incredible useful, I didn't even realize that is what dmesg
> did. Here is the output I got:
> [ 2117.571792] bone_capemgr bone_capemgr: part_number 'PRU-GPIO-BLINK',
> version 'N/A'
> [ 2117.
27; in my dts file.
On Friday, November 11, 2016 at 1:44:22 PM UTC-5, RobertCNelson wrote:
>
> On Fri, Nov 11, 2016 at 12:42 PM, Zach B >
> wrote:
> > I wanted to add on to this that when I switch the Device Tree Blob file
> > extension to ".dtbo" instead of &q
I wanted to add on to this that when I switch the Device Tree Blob file
extension to ".dtbo" instead of ".dtb" I get the error:
-bash: echo: write error: File exists
instead of the file not found error I was getting previously.
On Friday, November 11, 2016 at 1:27:22 PM
/syslog"?
Zach
On Thursday, November 10, 2016 at 9:27:47 AM UTC-5, Greg wrote:
>
> Once you get everything solid, please take a look at dmesg after boot.
> I'm curious to see if you get successful PRU firmware start-up.
>
> Greg
>
> On Thursday, November 10, 2016
ecause it's easier and less error prone than
> doing it manually.
>
> For reference because it's not especially easy to find, the pinmux
> register bits are defined in the AM335x TRM section 9.2.2, page 1356. My
> version is dated Feb. 2015, TI doc # SPRUH73L.
>
> On
On Tuesday, November 8, 2016 at 11:50:35 AM UTC-5, RobertCNelson wrote:
>
> On Tue, Nov 8, 2016 at 10:39 AM, Zach B >
> wrote:
> > I have spent a solid 12 hours trying to get the PRU's on the beaglebone
> to
> > work. So far I seem to be completely stuck at the get
I have spent a solid 12 hours trying to get the PRU's on the beaglebone to
work. So far I seem to be completely stuck at the getting the device
overlay to work as well as enabling the remoteproc. I have tried to piece
together all of the information I have found on the internet but it is
either
27 matches
Mail list logo
