Jump to content
Sign in to follow this  
yyrkoon

General PRU "news".

Recommended Posts

So, remoteproc, and rpmsg should very soon be a reality for the Beaglebones, and the PRU's. Honestly, I do not know a whole lot about the software technology, but what I *think* I understand seems very awesome. Basically, you get a Linux library / set of API calls, plus kernel modules to start, stop, and manipulate "additional" processor cores. What's even more awesome, is that this can be used on processors with multiple cores ( say a dual core A15 ), where Linux could run on one, and "bare metal" on the second. This should be a huge benifit for real-time projects, that also require Linux.

 

I'll add more information as I pick it up. I'm wanting to run remoteproc + rpmsg right now, but information is sparse. One of the Jason's (Reeder I think ? ) from TI has put up some information for remoteproc / rpmsg on the TI wiki though . . . pretty much a step by step how to - But using CCS, which I'm sort of allergic to ;)

 

*Random thought* The PRU's have *something* I can not think of the name, that can store the whole register set in one go. Called "broadside" - And store / load R0-R30 I believe in one cycle ( 5ns) ! Still not sure what all is possible with that, but the canotation is awesome . . . Anyway, these are called scratchpad or something ? There are actually 3-4 of these . . .

 

Anyway still reading and attempting to absorb all this, but I'm seeing huge potential with the PRU's already. Mostly related to determinism of course . . .

Share this post


Link to post
Share on other sites

That's great news, if confirmed. 

 

The Intel Edison board has a similar MCU bundled in the SOC, along with the MPU.

 

Intel provides all the tools and frameworks on Windows, Linux and Mac OS X. I compared the same blinky example on 3 environments: MPU with Arduino framework, MPU with native Yocto application, and MCU. 

 

However, running the PRU requires booting the board. There's still a lot of work before we can program a dedicated PRU or MCU on the fly, reconfigure it if needed and use it for real-time application.

Share this post


Link to post
Share on other sites

However, running the PRU requires booting the board. There's still a lot of work before we can program a dedicated PRU or MCU on the fly, reconfigure it if needed and use it for real-time application.

I believe this is already a reality on the Beaglebone's and the latest beagleboard X15, but either way that is the whole point of remoteproc / rpmsg to begin with. So according to what I've read recently on the beagelboard.org google groups, this is still experimental, but there is a .config option somewhere in the "kernel hacking" section to compile examples, when you compile the kernel. As far as how functional these examples are . . . I could not say.

 

Me, I normally love to experiment with stuff like this, but I'd really hate for it to be just some text demo, which is what I've read the examples is . . . it spits out 100 "hello world" messages into dmsg's log file . . .  Not very useful. In other words, I do not want to be spinning my wheels for them to "get around to" making this whole thing 100% functional / stable.

Share this post


Link to post
Share on other sites

@@spirilis

 

Here ya go. PRU tools are close to the bottom, the the C compiler, and assembly manuals are down there too.

 

http://software-dl.ti.com/codegen/non-esd/downloads/download.htm

Wow... quick scan of the compiler user's guide has me impressed already.  Even supports "argc/argv" via an .args section! Neat.

 

Gonna have to play with this at some point... possibly soon :-)

(and probably roll a new nRF24L01+ cape that attaches it to the PRU's pins)

Share this post


Link to post
Share on other sites

Wow... quick scan of the compiler user's guide has me impressed already.  Even supports "argc/argv" via an .args section! Neat.

 

Gonna have to play with this at some point... possibly soon :-)

(and probably roll a new nRF24L01+ cape that attaches it to the PRU's pins)

Yeah, it seems pretty complete. The biggest problem I personally was having with the CGT PRU compiler is working out the differences between the PRU code, and the A8 code, and how it all tied together. I'm starting to understand all that better, but I'm slowly learning ASM instead of C for starters. Slowly learning, as I'm just taking my time, and actually not spending so much time each day working at it. But it's on my mind a lot . . .

Share this post


Link to post
Share on other sites

@@spirilis

 

By the way, let me know if you need assistance setting that up, I do have some notes. But I think the biggest hurdle really is understanding the *cmd files that are used to tell the compiler how to setup the code for the device. Which I found kind of odd, in that the compiler is for a specific device . . . Anyway, I do not completely understand the *cmd file "thing" But I have found a setup that works.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×