To put it simply. I’m still waiting for someone to write up decent examples, and maybe even documentation for writing host side code using gcc toolchains. All I’ve seen so far is CCS examples, which won’t work for me. See I guess I don’t understand how the two halves work together . . . yet.
Excellent ! I look forward to looking over your course material. Do you plan on giving a deep dive into communications between both sides. Host, and PRU ? Not sure if that fits into your course plans or not but I know I would to learn this myself. Also the PRU config files, hex files . . . not sure I’m remembering that correctly or not. But it’s the config files that seem to layout stuff like .bss .data, etc . . . No idea if you plan on covering that either. But someone needs to.
Well no that’s not what I was getting at. I have a number of concerns. The below with GCC( not CCS ) in mind, as well as remoteproc in place of uio_pruss.
I have not found any example code that demonstrates communications between PRU and ARM
I have not found any example code that demonstrates loading PRU code from the ARM binary
I have not found any example code that demonstrates how to manipulate peripherals from the PRU via remoteproc.
Also I have not seen any coherent documentation explaining this PRU config file that lays out .bss, .data, and code data segments. I think it actually does more than this too, but . . . I’m going from memory here, and I’ve found no documentation on the subject. So. . . I do not really know what else to say about it.
Maybe there is too much assumption happening here ? The assumption that someone should already know what is going on ? But I do not operate that way. If something is not spelled out, I do not necessarily assume anything.
Yes, and no. The talker talks about the different sections, but doesn’t really say anything that matters. However he did mention something about the compiler manual. I’ve read part of this, maybe I missed it in the manual.
Topic 21 and 22? Not sure if this is what you are looking for.
Less specific to the PRU, more like TI general style:
Again. . . yes and no. This explains some of what I’m asking, but it’s no where near complete.
Thanks for the reply Greg, I do appreciate the effort. However, as usual, I’m finding TI’s documentation lacking, as well as spread out all over the place. However, with the last iteration of remoteproc I got the sense that the cmd file( hex file whatever it is ) is less important. I did recognize the MSP430 sections, as I’ve seen the file before in the wild, and in fact I’m working on an MSP430 project right now . . .
Well I do not know, what would be the simplest example that is close enough to the traditional hello world app ? I was thinking perhaps blinking a USR LED, since one would not have to add any additional hardware. But I looked into that a while back, and doing this would not be a trivial matter I think. Well actually . . . it depends on how remoteproc is implemented. If remoteproc can gain direct access to CPU memory addressing as can be done using uio_pruss. Then it should not be too much trouble.
So maybe an external LED example? Which would work out very close to how one would toggle a GPIO( LED ) on a bare metal platform. So anyone having background experience with something like a TI Launchpad or Arduino should be able to understand this very easily.
Passed that . . some kind of communication example. I was thinking perhaps usrspace to PRU core 1, to PRU core 2, then back to userspace. As a way for people to get their feet wet, with something easily verifiable. Then perhaps a shared memory example.
Jason:
I’m using gcc on the ARM and clpru on the PRU. Both are installed.
What would you gain by using gcc on the PRU?
–Mark
Let me answer this for you Mark. You would gain nothing. The contributor of the pru gcc implementation hints that it’s nothign more than a toy, and that code generated with it should be thought of nothign more than experimental. It says this right on the github project page readme.md.