Oh yeah, I have no complaints about the BBAI64’s performance. But with that performance comes a lot of heat, even when the processor is just sitting idle. And that’s a level of power consumption you cannot tolerate in an automotive environment when the engine is OFF. So a low-power mode is needed. And when the ignition is turned ON, a quick-power-from-sleep is needed to return the processor to full power and speed is needed to be ready to do the control necessary with minimal sleep->wake transition lag.
So as much as I like about the BBAI64, there are just as many things that are, essentially shortcomings. The scattered and incomplete documentation on TI’s side, the lack of support and example code for features that TI claims are possible, and as you said, the differences in peripheral capabilities. Just to give an example, look on the beagleboard.org website’s home page. The BBAI64 is listed to have 4 PRUs, which is not incorrect, but is incomplete. The J721E/TDA4VM has 2 PRU_ISCSSG subsystems, each of which have 2 PRUs, 2 RTUs, and 2 TX cores. Each of those cores are similar-but-different, and while I did find the documentation on what exactly those differences are, it’s not easy to come across…especially given the TDA4VM documentation doesn’t even mention the presence of those subsystems. (why TI, why?) And you have to just know to also look for J721E documentation (a processor that doesn’t actually exist as far as I can tell). And when you don’t know, you have to go glean that knowledge via forums like this.
So there’s a lot of good, bad, and ugly as it relates to the BBAI64, BB’s relationship with TI, and what TI has offered as support & guidance. And as good as the good is, the bad and ugly are where we, as developers live.
Yes, that is so very true. They do have a big TRM, we were going to use Khadas VIM boards but amlogic is way too secretive for us to use. No TRM and they would not let me have developer access to the good stuff. TI on the other hand does provide MANY points of entry into the device. It must be working very well for others or they would not be where they are at. If you have a large pool of researchers, developers, programmers, hardware people it would be much easier. When you have limited this and that plus trying to find an employee that even knows what an ARM processor is, the other major hurdle.
From what I have read so far the PRU is a home run in theory. All I am doing is getting tired of connecting the missing dots. This is actually way worse than in college. My prof. would give us a “black box” projects all the time. He would sketch an input waveform and an output waveform. We had to do the rest and also said every one’s homework better be different. Point I am getting at is you can always use a scope and signal generator to characterize and experiment with the device. This stuff is purely invisible. Back in the old days we had an ICE (in circuit emulator) that would plug in the SOCKET of the processor and then work on it. This SoC stuff is for the birds.
I read this thread for the first time today… the topic is very specific, and not one that I am particularly interested in. HOWEVER if you are interested in gomer’s $.02 you might abandon your quest to decipher remoteproc.
If your project is at the prototype / poc stage (just my guess), you might consider revisiting the trusty BBB. It still has a lot going for it despite its’ age, like coherent documentation.
At the risk of being a Johnny one note, I’m going to suggest that you abandon remotemsg, and look into ring buffer(s) for your communication between ARM and PRU. At minimum, you could put up your poc without dealing with the poor documentation for more current BB products.
if you take a look at the app that I’ve made available, you’ll see that its’ ARM utilization is barely measurable even though the most complex processing is done there. it takes very few ARM cycles to do the ring buffer processing. While this clock app has no feedback from PRU to ARM, it would be trivial to implement (as a poc).
Ring buffers have lot’s of advantages over even the vaporware speak of remotemsg. They are always async, low overhead, and don’t rely on interrupts.
this gif is the best explanation of how they work, the text of the wikipedia article sadly is meh.
@FredEckert has recently posted that he successfully implemented this application. This gives me confidence that I haven’t missed any critical code or instructions to get it running. Thanks again Fred.
For your timing needs, I’m going to suggest this approach that I use routinely in other projects:
set up a 1mhz pwm signal into a pru fast input
increment a register for each pulse of the pwm (accurate 1uS timer)
segment your pru code into instruction blocks < 200 instructions (run in < 1uS)
block (waste) the remainder of the uS waiting for the pwm pulse.
the math of this approach is 4G / 1M = 4K. 4K seconds is about 68minutes 15 seconds then you have to code for rollover.
Might very well work good in bare metal, but with a linux kernel. Just way too much going on. The part I like about the PRU is according to docs it should run totally autonomous from the main A53 cores running linux. Have I gotten to that point yet, no, other than playing with the “hello world” and testing JTAG has been my reach on the issue. It does seem like it is worth trying to get going. Just assuming the docs are being truth full.
For some reason the docs appear to be written from developers notes. Whomever is writing them does not understand what is going on or they would be able to fully articulate to others what is going on.
Your gif did not load, it seems like many years ago we did implement ring buffers using the old ttl / cmos logic chip designs. That stuff was locked in place so everything was predictable. Its has been many years ago so please forgive me if this is not correct.
again, not a fan of this article, but the gif is excellent. The main advantage of a ring buffer is that it allows BOTH processors to run simultaneously if sufficiently large. The clock app demonstrates this in code, which is MUCH better than I can describe in english.
HA! The whole reason I poked this thread was to see if it was feasible to port gomer’s PRU clock over to the BBAI-64. I figured it would be a good learning experience. However, as a wise man once said, I am not up to the skill level to be the BBAI-64 PRU pioneer… In fact, I hope I never have to use the PRUs. Hope to stay with the R5F processor.
Since I managed to derail yet another thread, we might as well keep the derailment going… As part of my RF5 research, I have been trying to find the time to study RemoteProc and RPMsg. Aren’t vrings ring buffers? I have gotten TI’s RPMsg ipc_echo_baremetal_test program to work Linux to R5F baremetal.
Gomer why are you so against remoteproc?
If I keep all my realtime code in the R5F, it shouldn’t matter. However, I need to dump over more that 512 bytes of data in some sort of a double buffering mechanism. My very preliminary research indicates that DMA-BUF may be what I may need… Any comments?
Gomer thinks not. ring buffers do not use interrupts to ‘kick’ their fellow processors, alerting them that they have a msg. This seems to gomer to be synchronous. Ring buffers are asynchronous, and if sized adequately, neither writer nor reader needs to concern itself with the status of the contra processor. Of course, gomer could be wrong about anything.
Gomer isn’t against remoteproc, although there was a period of annoyance porting from the earlier UIO code. To make the sample clock app turnkey, gomer uses remoteproc to load and start the PRU(s). Remoteproc does this fine.
Gomer doesn’t understand RPMsg and sometimes has thought RPMsg and written remoteproc or remotemsg. Sorry for the confusion gomer is.
Gomer likes the PRU asm coding and has not found any documentation to guide using RPMsg with asm.
R5F baremetal is a new term which gomer does not grok. BUT, since the raw url for this link includes the string ‘ccs’, gomer will ignore.
Realtime code and R5F and bare metal… gomer seems to have strayed into a realm that gomer has NO experience in. Better to remain silent and be thought a fool, than to open your mouth and remove all doubt.
You’ve gotten a CCS based, TI provided, demo for the BBAI-64 running!? For the BBAI-64, I’ve only been able to use the makefile demos. Is there a particular device you selected in the wizard or did you have to manually load something? What OS is your host? I need to see this demo!
I tried using their Ubuntu 18 build instructions for ccs and yocto. Both turned into a headache.
Now I am running yocto on Ubuntu 22.04 build server that is a dedicated to TI builds. Did get it up on 20.04 then wiped it out and went upto 22.04. I am building images that boot beagleplay, AM62, BBB. Also have ccs up on 20.04 and 22.04 desktops. Not sure if I kept notes on the ccs and yocto. It will run, did have to hunt for some dependencies. I will check my cherrytree files and see I have any notes. Started a to do a write-up for 20.04 and then changed to 22.04 so that is only in a primative note state at the moment.
Pretty sure if you start out with ccs on 22.04 it will only be trivial issues. Keep in mind they have that loaded with tons of different products some of that stuff might not build. I have only tried it on AM62, also have the wifi evm too but have not gotten to that one yet.
I am doing it on the AM62 EVM board with JTAG probe XPS110, if you get the EVM board you don’t need the probe. The debugger is on the board so it is just a USB cable.
I should also learn to read, just noticed you are on AI64… we are currently with the Beagleplay / AM62.
I had the opposite experience. I had to revert FROM 22.04 to 18.04 after having trouble with getting CCS installed. When I went back to 18.04, all went well and I was able to get CCS along with the C-compiler for PRUs up and compiling. It took some doing, but I eventually got it working. I even wrote myself some makefiles that would build the code I had written and deploy it onto the BBAI64 for me. It’s not perfect code, but it worked for my purposes at the time. Although this was my own code, not demo code. It was absolutely imperative I get the C-compiler for PRUs working because I wasn’t about to try writing assembly or hinge a potential product on maintaining assembly…even as simple as the PRU assembly is, I ain’t about that assembly-life.
Glad you got it up and running. One thing that was an issue is firefox snap version. That was the reason some of the stuff on the resource page would not open.
Programmable Real-time Unit (PRU) Software Support Package v6.1.0
DESCRIPTION
The PRU Software Support Package (PSSP) is an add-on package that provides a framework
and examples for developing software for the Programmable Real-time Unit
sub-system and Industrial Communication Sub-System (PRU-ICSS) in the supported
TI processors. The PRU-ICSS achieves deterministic, real-time processing, direct
access to I/Os and meets ultra-low-latency requirements.
This software package contains example PRU firmware code as well as application
loader code for the host OS. The examples demonstrate the PRU capabilities to
interact with and control the system and its resources.
See Release_Notes.txt for details about this specific PSSP version.
For more details about the PRU, visit
https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components_PRU_Subsystem.html
This package includes the following resources:
DIRECTORY CONTENTS
--------- --------
examples Basic PRU examples
include PRU firmware header files
labs Source code for step-by-step labs
lib PRU library files and library source files
pru_cape Demo software for the BeagleBone PRU Cape
ADDITIONAL RESOURCES
For more information about the PRU, visit:
PRU-ICSS/PRU_ICSSG docs - https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components_PRU_Subsystem.html
Support - http://e2e.ti.com
Thanks for refreshing my memory on this TI PRU support repo. I looked at this a while back but, didn’t pursue it at the time. I am going to bookmark it for future reference. Way back when I was just getting started with the AI-64, I purchased a PRU-CAPE. As I got into looking at it, it looked like TI (or maybe BB) dropped devicetree support for the PRU-CAPE after a certain point. As I learned more about the AI-64 hardware, I found that even though the header pinout is the same as the BBB, they are not 1:1. So, this made me even less interested in looking at the PRU-CAPE.
I recently purchased a SK-AM64B evaluation kit from TI. When I get some time, using this eval kit, am going to dive into learning CCS and the TI MCU+ SDK. With my understanding at this point, I think this is as close as I am going get to having a TI guided learning experience that will apply to the AI-64. If anyone knows better, please give me some advice.
I am also going to use the cherrytree note system that you have mentioned several times. I need to keep better track of this stuff.
Best,
FredE
EDIT: I just clicked on the pru-software-support-package link and see that there are recent commits for AM62x, AM64x/AM65x!
My SK-AM64B are the red boards with M2 sticker on the bottom and neither board will boot. Just curious if yours boot? If it works what version is it. Also mine have a red LED illuminated on the bottom, that seems to be mystery to the e2e support group.
Did get the AM62x evm and that one is fine.
Not sure if ccs is worth the time, might be better to start with eclipse and try to emulate what they did in ccs. It seems futile trying to make sense of that mess, then to find out it does not integrate GDB into it so the entire system can be built. Pretty much appears to be just a marketing tool for the C suite presentations, the developers out in the shop have to deal with the short comings.
Might look into the GP and HS versions issue, they are dropping support for GP in SDK 9. I took all the TI stuff home for now. When they get their act together I might take it all back to work, at this point it is a total waste of our time developing against dead product.
Alongside cherrytree, you can build your own private git server and if you do web stuff the AI64 (headless) handles a LAMP stack very well.
You can still use git with your cherrytree files, you will not have all the git diff and such functionality since those are not pure text files. But, you can push and pull the .ctb files onto the server. I keep a doc package on the server and just pull when I am on a different workstation, now my files are upto date. Then just push my notes to the server.
I haven’t tried powering up my SK-AM64B yet. It is the exact same M2 you have. I think I saw your boot issue report from about a month ago on e2e. There is another report from just last week: SDK8.6 WIC prebuilt image, the SK-AM64B cannot boot. I’ll just be monitoring e2e until I see that someone has gotten it working. Then I will start looking at it.
I have CCS 12.2.0.00009 installed and running on Debian 11, the same bullseye release that we use on the AI-64. Do you think I will be OK with this setup, or should I use Ubuntu? I’d rather just stay with Debian if it will work.
It works fine on Debian, that is my preferred OS for desktop. Had to use Jammy due to issues with an NVIDIA driver for the A2000 card and dual monitor setup.
There is a couple more that I have seen. I got tired of it, we are now trying out NXP stuff. Maybe the folks at NXP will not tell me to turn on the power switch and try numerous SD cards. One of the TI guys did get them to send another board and it would not boot.
The NXP has an M4 running in real time so that might turn into something or not. Just don’t know until the stuff is actually up and running. Just ordered the dev board from them and it comes with a display so that will be nice too.
Thanks for the CCS works with Debian confirmation. I was bummed out learn that the board doesn’t boot.
I am really wanting to see what the CCS debugging experience is like with the SK-AM64B built in on-board XDS110 JTAG Emulator -vs- the BBAI-64 off-board TIAO TUMPA and gdb experience.
