|PRU FAQ 2013-05-15||Jason Kridner||5/15/13 2:12 PM|
Frequently asked questions regarding "PRU":
|Re: [beagleboard] PRU FAQ 2013-05-15||lazarman||5/15/13 2:35 PM|
|Re: [beagleboard] PRU FAQ 2013-05-15||Max||5/16/13 12:15 AM|
I think the classic Bone has JTAG integrated in it. BBB does not
Anyway it would be great if you could share some info how you worked with CAN
Отправлено с iPad
16.05.2013, в 1:35, Mark Lazarewicz <laza...@yahoo.com> написал(а):
|Re: [beagleboard] PRU FAQ 2013-05-15||lazarman||5/16/13 8:07 AM|
|Re: PRU FAQ 2013-05-15||WenZhan Song||8/8/13 7:03 AM|
Can the PRU runs while the main CPU and most peripherals sleeps?
What we intend to do is: let PRU read sensor data from an ADC board through SPI interface, and GPS data through UART and GPIO interface, then timestamp sensor data with GPS timestamp and write to flash or SD card. During this process, we hope to put the main CPU in sleep to save power.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Charles Steinkuehler||8/8/13 7:09 AM|
Yes. If you read through the TI documentation, there are some comments
about power domains and using the PRU to manage power-on events and
decide if the ARM core needs to be brought out of power-down mode.
>> - What is a "PRU"?
>> - PRU stands for Programmable Real-time Unit. The overall subsystem
>> is typically called the ICSS, PRU-ICSS or PRUSS. ICSS stands for>> - What does a PRU do?
>> - A PRU is a 200MHz microcontroller that is really useful at
>> "bitbanging" and has some peripherals attached to it that make it well>> - What are the processing elements within the AM33xx PRUSS used on
>> BeagleBone and BeagleBone Black?
>> - 2 32-bit 200MHz PRU cores
>> - Each with 8KB of program memory
>> - Direct access to general purpose I/O
>> - Single cycle operations without cache or pipelines (instructions
>> *always* 5ns)
>> - Shared 12KB data memory
>> - Scratch pad registers
>> - Parallel and serial capture modes
>> - 32-bit port to memory and other peripherals outside of the PRUSS,
>> including external memory
>> - What are some example things built out of PRUs?
>> - DMX512 lighting protocol:
>> - 6502 memory interface:
>> - Emulated memory interface on an Atari 600XL with BeagleBone
>> decoding video directly into Atari 600XL display memory:>> - Nixie tube interface: https://github.com/mranostay/beagle-nixie
>> - Software UART:
>> - Sine wave generator using PWMs:
>> - 3D printer stepper motor driver:
>> - Camera interface:
>> - Where do I get some more details?
>> - https://github.com/beagleboard/am335x_pru_package is the official
>> location for documentation and tools for the PRUSS on BeagleBone and>> - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Charles Steinkuehler||8/8/13 7:26 AM|
More specifically, it looks like the PRU is powered by the PD_PER
domain, which means you can put the chip into Deepsleep1 and the PRU is
still active but the ARM core is shut down, the main oscillator is
disabled, and all DPLLs are in bypass. The PRU is probably running at a
pretty low frequency, but it should be running. There are still a
couple deeper sleep modes you can use for further power savings.
If you need the PRU running at speed, the Standby mode leaves the clocks
operating normally but powers down the ARM and graphics cores.
This is all covered in Section 8 (Power, Reset, and Clock Management) of
the AM335x Technical Reference Manual from TI.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||WenZhan Song||8/8/13 7:53 AM|
Thanks for prompt reply, Charles!
This is a great news for us! We are newbies of BBB. Do you know any source code for us to start with, including drivers of SPI and UART and power management between PRU and main CPU?
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Charles Steinkuehler||8/8/13 8:09 AM|
On 8/8/2013 9:53 AM, WenZhan Song wrote:I don't off-hand know of any power management code examples other than
the Linux kernel itself.
There are probably some examples available from TI if you dig around, I
have mostly worked only with the PRU (to do real-time step/dir
generation for LinuxCNC), but being a hardware designer I skimmed
through most of the TRM reviewing the various available features and
some implementation details. I leave the power management code to the
Linux kernel gurus! :)
Note that unless you are running on bare metal, you'll probably need to
coordinate your power management with the Linux kernel somehow. If you
need help with this I would refer you to TI for part-specific support,
and the usual Linux channels for help with the kernel code. I'm way
beyond my depth in trying to write suspend/resume code for Linux...I can
just tell you what power states the PRU runs in.
As for the SPI and UART, there are Linux drivers available for these, or
you can talk to the hardware directly via the PRU if you're trying to do
something while the ARM core is asleep. Hardware details are in the
TRM, and while you probably won't find PRU code examples, the Linux
drivers for these peripherals should provide examples for proper setup
Good luck on your project!
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Mark A. Yoder||9/25/13 2:48 PM|
What's the current status of the PRUs? Has anyone produced some tutorials on how to do simple things on it? I've looked at the examples in Jason's post, but more examples on how to do simple things would be helpful.
For example, how does on set up a double buffer between the ARM and the PRU with the PRU interrupting the ARM when it's finished with one buffer and is working on the next so the ARM can refill the buffer.
Or, examples of the PRU talking to things on the i2c or SPI buses.
Has anyone gotten the PRU to control a quadcopter?
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Charles Steinkuehler||9/25/13 3:05 PM|
On 9/25/2013 4:48 PM, Mark A. Yoder wrote:I have some basic example code I tried to comment very well for use as
an example of the PRU debugger available with LinuxCNC. It mostly just
sets up the timer portion of the industrial Ethernet controller (the
only part that's documented) and blinks some LEDs. I tried to provide
examples of various assembler features (like using records/structs) as
well as use a variety of coding techniques (including a jump table for
case logic). Perhaps you might find something useful reading through
...or if you've got a copy of my MachineKit image you can try running it
with the debugger and single-stepping through the code.
That is totally *NOT* simple and has a *LOT* of places where things can
go wrong (race conditions, deadlocks, cache management, etc). I'll
probably have code that deals with all of this at some point, but I
wouldn't expect it to be a newbie oriented HOWTO code example.
No to both of the above, AFAIK.
|Re: PRU FAQ 2013-05-15||dthph...@gmail.com||9/30/13 6:40 AM|
Is it possible to use these two PRU (pru0 and pru1) simultaneously to control fast GPIO in direct PRU - output mode? If yes, how can we do that with only r30?
Vào 04:12:39 UTC+7 Thứ năm, ngày 16 tháng năm năm 2013, Jason Kridner đã viết:
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Gerald||9/30/13 6:47 AM|
PRU0_R30 and PRU1_R30. They are different.
|Re: PRU FAQ 2013-05-15||Brandon I||9/30/13 9:53 AM|
Yes it is. The PRUs are independent and have 1 tick access to their gpio pins, and something like 3 to 8 ticks (I can't remember exactly) access for regular gpio pins (they are in system memory, accessible by the pru).
You can find documentation, compiler, and examples here: https://github.com/beagleboard/am335x_pru_package
And here's a list of the pru-gpio header pins: https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Vaibhav Bedia||9/30/13 8:01 PM|
On Thu, Aug 8, 2013 at 11:09 AM, Charles SteinkuehlerWhat Charles mentioned about the different states is correct (i wonder
complain the TRM is impossible to parse ;)
Search for Starterware if you want really non-Linux stuff. You'll need
implement the wake from PRU functionality but i think that should be
not too hard
provided you know how to program the PRU. If you do decide to implement this
and get stuck somewhere feel free to ask me the low level PM details.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Charles Steinkuehler||10/2/13 1:03 PM|
On 9/30/2013 8:40 AM, dthph...@gmail.com wrote:Each PRU has it's own r30, which drives the direct outputs (assuming you
have the pinmux setup properly). You can only drive a limited number of
the BeagleBone header pins using PRU direct I/O, and a lot of the pins
are shared with the LCD/HDMI interface.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Brandon I||10/2/13 4:16 PM|
> and a lot of the pins are shared with the LCD/HDMI interface.
Which can be made available by disabling the hdmi framer by adding the following to uEnv.txt on the fat32 partition:
|Re: PRU FAQ 2013-05-15||Nicola F.||10/10/13 9:27 AM|
Thanks Jason for the links and all the others for their further questions and suggestions.
I'm a BBB new user and I think that PRUs really set the BBB apart from most of other boards.
I'm looking forward doing things with them as well.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||u.pel...@srett.com||10/22/13 8:23 AM|
Thanks for these informations.
But I would like to use the PRU to get data from a fast ADC connected by SPI. I get that there is no example of SPI connection but is it possible ?
It seems that the PRU can only access to UART, CFG, eCAP interfaces. Am I right ?
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Christopher Hopwood||1/21/14 5:34 PM|
Where can I find the correct pinmux settings for the PRU as well as which pru gpio port maps to which header bin? I don't see it on Derek Molloy's header table.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Charles Steinkuehler||1/21/14 5:40 PM|
On 01/21/14 19:34, Christopher Hopwood wrote:The details are all in the TI manuals, or you can reference an excellent
compilation from various official sources on github:
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Christopher Hopwood||1/21/14 6:08 PM|
I need to make sure I'm understanding correctly. If I want to use PRU1's pin 8 as an input, should I use the address 0x8e0 or 0x0e0? Should I set the mode to 0x26 to use input and enable the receiver? Thanks for the help!
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Brandon I||1/21/14 10:54 PM|
In the pru, R31 is for input, so in that table you're looking for pin "pr1_pru1_pru_r31_8". That's on P8.27, which is used by the HDMI framer. If you *need* to use this pin, instructions on disabling the hdmi framer can be found by searching this group.
Of course you'll have to enable the receiver, otherwise the state of the pin couldn't be measured!
Also, here's a easier to digest table for the pru header pins: https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c#gid=0
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||alexis.ma...@gmail.com||5/6/14 7:29 AM|
I am also very interesting about this.
I need to complete a fast ADC / DAC with some numeric matrix calculation. I thought about using a BBB, and the PRUs seemed to be a very interesting point. The numeric part could be done using Xenomai.
Apparently the use of SPI with the PRUs is possible. So can I use SPI ADC / DAC with the PRU?
Could anyone be more precise on how to do it? Write SPI drivers for the PRU?
If I was not clear enough, tell me :)
Thank you very much
|Re: PRU FAQ 2013-05-15||brian larochelle||5/7/14 6:37 AM|
We've seen talk of a closed beta C compiler for the PRU's. I've seen that it could come out of closed beta any day now, and looking for it has become a daily routine.
I've found the below, which links to information/download of a c compiler for pru from TI. Would anyone know if this is the same as the closed beta Jason has hinted at here and there?
|Re: PRU FAQ 2013-05-15||Christopher Hopwood||5/7/14 6:47 AM|
It sounds legit to me. My team had access to the closed beta, but as my team's lead pru programmer, I decided not to use it because the calling convention I made up (in the absence of any standard for PRU) wasn't compatible with the compiler's.
|Re: PRU FAQ 2013-05-15||Christopher Hopwood||5/7/14 6:47 AM|
|Re: PRU FAQ 2013-05-15||Christopher Hopwood||5/7/14 6:47 AM|
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Jason Kridner||5/7/14 7:44 AM|
On Wed, May 7, 2014 at 9:37 AM, brian larochelle
> We've seen talk of a closed beta C compiler for the PRU's. I've seen that
> it could come out of closed beta any day now, and looking for it has become
> a daily routine.
> I've found the below, which links to information/download of a c compiler
> for pru from TI. Would anyone know if this is the same as the closed beta
> Jason has hinted at here and there?
It is a slightly updated version from the one I've been providing in
beta. I've been waiting for a response to my request for a direct
download, rather than needing to download all of CCS, before I posted
something. Seems the cat is out of the bag!
> On Wednesday, May 15, 2013 5:12:39 PM UTC-4, Jason Kridner wrote:
>> Frequently asked questions regarding "PRU":
>> What is a "PRU"?
>> PRU stands for Programmable Real-time Unit. The overall subsystem is
>> typically called the ICSS, PRU-ICSS or PRUSS. ICSS stands for Industrial
>> Communications Subsystem and PRUSS stands for Programmable Real-time Unit
>> What does a PRU do?
>> A PRU is a 200MHz microcontroller that is really useful at "bitbanging"
>> and has some peripherals attached to it that make it well suited for
>> building real-time interfaces to all types of digital electronics.
>> What are the processing elements within the AM33xx PRUSS used on
>> BeagleBone and BeagleBone Black?
>> 2 32-bit 200MHz PRU cores
>> Each with 8KB of program memory
>> Direct access to general purpose I/O
>> Single cycle operations without cache or pipelines (instructions *always*
>> Shared 12KB data memory
>> Scratch pad registers
>> Parallel and serial capture modes
>> 32-bit port to memory and other peripherals outside of the PRUSS,
>> including external memory
>> What are some example things built out of PRUs?
>> DMX512 lighting protocol:
>> 6502 memory interface:
>> Emulated memory interface on an Atari 600XL with BeagleBone decoding video
>> directly into Atari 600XL display memory:
>> Nixie tube interface: https://github.com/mranostay/beagle-nixie
>> Software UART:
>> Sine wave generator using PWMs: http://elinux.org/ECE497_BeagleBone_PRU
>> 3D printer stepper motor driver:
>> Camera interface: http://www.hitchhikeree.org/beaglebone_capes/interacto/
>> Where do I get some more details?
>> https://github.com/beagleboard/am335x_pru_package is the official location
>> for documentation and tools for the PRUSS on BeagleBone and BeagleBone
>> http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page.
> 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 beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||brian larochelle||5/7/14 8:37 AM|
>It is a slightly updated version from the one I've been providing inVery cool, thanks Jason. Hopefully you get a response to the direct download request, that would be preferable over all of CCS.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||William Hermans||5/7/14 9:51 AM|
For me personally, it is not just preferable, it is a requirement. As I refuse to use CCS.
--For more options, visit http://beagleboard.org/discuss
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Mark Grosen||5/7/14 11:09 AM|
After installing CCS with the PRU compiler, you can simply just use the compiler as a command-line compiler (like all the other TI compilers) and ignore the CCS IDE. The installer is only about 20MB download to start with and then it downloads the rest as needed. It's a quick install on Linux (YMMV on Windows).Mark
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||William Hermans||5/7/14 1:04 PM|
Mark, it is not CCS specifically that I have a problem with. I have a very strong aversion to having JRE on any of my Windows machines. So, if the tool is not made available as a separate native windows ( or perhaps *NIX ) binary, I probably wont even give it a second look.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Mark Grosen||5/7/14 2:46 PM|
Well, install it, copy the PRU directory somewhere else and rm -rf the CCS directory - no more JRE. There is no dependency on the CCS IDE from the compilers.Mark
|Re: [beagleboard] PRU FAQ 2013-05-15||Jason Kridner||5/21/14 4:59 AM|
Direct download link: http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||karlka...@gmail.com||5/27/14 6:18 AM|
Am Mittwoch, 2. Oktober 2013 22:03:29 UTC+2 schrieb Charles Steinkuehler:
I afraid this is the part I didn't understand with PRU. Assumed Pin-Mux is correct for usage of plain GPIOs - is PRU able to access all of them? If not: which ones are accessible?
And I already stumbled upon this r30 thingy...how can I set/read GPIOs with it?
Thanks for helping me with these stupid questions!
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Brandon I||5/27/14 1:38 PM|
You can access all regular gpio, but those will be slower than the one tick pru gpio access.
Check out the PRU documentation at https://github.com/beagleboard/am335x_pru_package , it explains how to use R30 and R31, section 5.2.2.
Here's an explanation on accessing main memory from the pru: http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru
To control the regular gpio blocks, you would access them through their registers. You can find the gpio registers and their addresses in the processor manual at http://www.ti.com/lit/pdf/SPRUH73 , section 2.1 for addresses of gpio blocks, and section 25 for offsets of the different gpio registers for each block.
|Re: PRU FAQ 2013-05-15||euerka||6/1/14 9:21 PM|
As i understand it is impossible to implement PRU, ethercat slave on Beagleboard, since i refer to ( https://groups.google.com/forum/#!searchin/beagleboard/ethercat|sort:relevance/beagleboard/EiiZ4rwo9q0/ZvqUXIKAS28J ) and ( https://groups.google.com/forum/#!searchin/beagleboard/ethercat|sort:relevance/beagleboard/1_yqmvkguZY/y-mrwkY7IJsJ).
I am still wondering that is it possible to use PRU as ethercat or powerlink master on Beagleboard? Because in my opinion, i can purchase commercial motor driver such as yaskawa or panasonic as slave?
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Gerald||6/2/14 5:15 AM|
No. It is not possible.Signals are missing on the expansion headers to implement ether-cat.
It cannot be done.
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||euerka||6/3/14 5:05 AM|
Thanks for your reply. Sorry that i am not very clear about Signals are missing on the expansion headers? you means the signals suppose to link to Ethernet PHY, now link to expansion headers(P8,P9)? if so it means it possible rewire the signals? Because i saw this https://www.youtube.com/watch?v=M1LxQBjttWg , please take a look; it seems Sascha rewire it.
Even though it is impossible to implement this, may i know what signals i need if i want to implement etherCat Master by PRU on BBB, which signals are missing now? Any clues, documentations, links will be appreciated.
Thank very very much!
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Gerald||6/3/14 6:05 AM|
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Brandon I||6/3/14 12:44 PM|
And a quick google search "pru ethercat am335x" provides a nice overview: http://www.ti.com/lit/wp/spry187c/spry187c.pdf
|unk...@googlegroups.com||8/13/14 2:02 PM||<This message has been deleted.>|
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||Brandon I||8/13/14 6:58 PM|
You have to enable the ocp master port (section 10.1.2) to access main memory. Here's an explanation.
And, the resulting code is (if you want to do it in the pru):
// clear STANDBY_INIT bit in syscfg register so memory between pru <-> system can be accessed (enable ocp master)
LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4
See section 3.1.2 in the pru reference for limitations (accessing memory below main memory 0x00080000 requires enabling an offset, section 10.1.10).
On Wed, Aug 13, 2014 at 2:02 PM, rakesh.safir <rakesh...@gmail.com> wrote:
|Re: [beagleboard] Re: PRU FAQ 2013-05-15||rakesh.safir||8/20/14 1:51 AM|
Appreciate your help. I was able to resolve the issue.
|Re: PRU FAQ 2013-05-15||woody stanford||1/30/17 11:28 AM|
This is gold, Jason. Thank you so much for sharing this with us. I personal was wondering what a lot of this stuff was.
Have to admit that I was somewhat unclear as to quite a few of these concepts, but I was especially encouraged when I read the term "industrial". It is good to know we have that level of strength in our little SBC's. The assurance is comforting.
|Re: PRU FAQ 2013-05-15||woody stanford||1/30/17 11:42 AM|
Still I am a fan of my little K150 PIC programmer. I wish I could say that I soldered it myself however I pussed out this time and got a nice little jobby from Hong Kong or somewhere. Cased it myself. I can even carry it with me if I wanted to and its USB cable is just the right length.
My issue with PRU is this: Why would I learn yet another microcontroller language when I can just electrically load from hex file with my beloved K150 to a $1 PIC?
|Re: [beagleboard] PRU FAQ 2013-05-15||Rick M||1/30/17 4:56 PM|
Jason, the Nixie Cape and Camera Interface project links are 404.
> --> 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 beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/37abb769-2526-4420-bf06-d2a4af1beee9%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.--