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 Subsystem.- 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 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?
Good stuff Thanks! and I am guessing the ICCS_SDK just provides examples/ and sw support of how to implement the various various protocols like DeviceNet and CAN?
I got two Bones today and the CAN capes should be shipped soon so this caught my attention thanks.
Now if I just knew where I could get the JTAG adapter installed I would be elated. The link posted earlier by Gerald suggests an RMA but I was NOT sure if this referred to after being damaged adding the JTAG by a novice or I could just either pay for it or request it by RMA.
Present(paid) Well I am doing a CAN device drivers for TI C2000 for RTOS(SYSBIOS) at work so the peripherals(CAN controller) are what I am focused on and interested in
Relavent to this group Future(hobby/career enhancement) for Sitara the can controller is called DCAN this code that talks to this is provided in starterware(bare bones no OS). From what have read the kernel for Bone supports the network driver for CAN developed by Volkswagen so I start with getting two bones talking study/tweek linux device drivers
Non relavent to opensource Sysbios or barebones OS running the starterware./sdk CAN code on A8 of Bone using JTAG and codecomposer. spend $78 for xds100 CCS is free. JTAG shortens debug of complez hard real time bugs
Email me anytime if you think I can be of help for general firmware questions. its not that I dont want to share here I have little experience presently doing Linux device drivers but 28 years doing other RTOS drivers hope to change this and help out the cause as a driver is driver for most OS . Linux drivers are SLIGHTLY different than LynxOS and QNX cpmmercial RTOS
One last comment I saw the first consulting opening for a Sitara job this means people are using the chip beyond handsets and opensource tinkering. the chip has all the peripherals and low power so I think this chip is here to stay. also linux is making inroads into more embedded systems where hard realtime RTOS have been used(now I better go as I dont want to step on any toes). They both have a place and it looks like Gerad and Jason have ensured that TI is the best choice for support in open arena and the E2E forum is OK for TI SYSBIOS help
> From: Max lisarden@gmail.com > Subject: Re: [beagleboard] PRU FAQ 2013-05-15 > To: “beagleboard@googlegroups.com” beagleboard@googlegroups.com > Date: Thursday, May 16, 2013, 2:15 AM > > Hi Mark! > > 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
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.
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.
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.
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?
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
and operation.
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?
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.
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
the code:
...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.
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.
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.
Or, examples of the PRU talking to things on the i2c or SPI buses.
Has anyone gotten the PRU to control a quadcopter?
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?
Phong
Vào 04:12:39 UTC+7 Thứ năm, ngày 16 tháng năm năm 2013, Jason Kridner đã viết:
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).
What Charles mentioned about the different states is correct (i wonder
why people
complain the TRM is impossible to parse
Search for Starterware if you want really non-Linux stuff. You'll need
to probably
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.
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.
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:
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
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 ?
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.
