I’m not sure I want to know how to write the PRU functions
May I ask if you ever have an example or guide
I want to use C language.
Maybe this will be useful reading http://www.embeddedrelated.com/showarticle/603.php.
There are few topics on PRUs, all are AFAIK related to asm. I am very interested in PRU and knowing more use cases. Can I ask you why do you want to use C language and not bare assembly?
Can I ask you why do you want to use C language and not bare assembly?
I think the more important question would be:
“why use asm when there is a C compiler”
But like with anything else. Everyone is different.
I tend to agree with that most of the time. Maybe I am biasing my question on a limited experience with PRU applications.
I tend to agree with that most of the time. Maybe I am biasing my question on a limited experience with PRU applications.
From my point of view PRU are good for relatively simple tasks, that should be fast and kept independent from ARM and the OS load. C seems to be a logic choice for the majority of the cases, but if (and here I beg to my only experience with PRU), there are some critical timing involved, like ensuring some actions are performed periodically. Is it possible and simple to keep track of the execution time (the number of pru clock cycles) a piece of code written in C takes to execute?
Well I was just being a bit silly with my response - But it does have some truth to it. Right now I’ve been working in C for the past 2-3 months. So my initial feeling for solving and problems programmatically would first be in C. Granted I have far more experience in C than in ASM, and the last time I actually wrote any ASM code was well over 10 years ago . . .so I’m very rusty too.
However since I’ve never actually written anything for the PRU’s, I’d probably want to follow some tutorials for a while to get the hang of things. So initially I might opt for ASM, until I understood things better. This is one of the large benefits of using many different languages over a long period of time. Maybe you’re not an “expert” with any, but you’re able to translate code from one to another fairly quickly . . . the only “hard” part is reading and understanding what documentation you can find.
I think there are a couple of standard things people tend to need from micros like this:
1.) I need something to happen quickly and regularly below the threshold of _____Hz / KHz / MHz. They may not need the timing of anything within that to be perfectly predictable, it just needs to happen fast enough. That is something I prefer to do in C if I can. I simply need the activity to take place more regularly than Linux can get it done. 8K is not much memory to do a ton of stuff in so the program needs to be relatively simple. C can do simple pretty well. ASM makes the simple complex on it’s own.
2.) I need this to happen exactly 200ns after that happens and then I need to repeat that again in 30ns. This is where ASM starts to win. You can mess with C to get that to happen but then it starts to look easier to just write the thing in ASM since the timing is straight-forward. Stuffing ASM inline with the C code is possible too if the rest of the program makes writing it all in ASM daunting. But there I see ASM as an easy way to get the timing needed as long as you can stand the tedious nature of getting anything done in ASM.
From what I understand from the comments of CNC writers, even Linux
(unless the kernel has been tweaked to allow this) does not allow real
time response.
Windows certainly not, Linux has to be specially engineered (IIRC) to
give you *accurate* real time response and freedom from extraneous
events.
What you need is hardware doing this, with software in control. I
might suggest an FPGA or a CPLD, You could also put another
processor in the mix, be it internal or external on a cape, and let it
do the work. It would have to be specifically programmed to do this
particular task within the timing requirements you have.
Otherwise, the OS does what it wants to do, when it wants to do it,
and your request is in a queue....... somewhere......
Harvey
The PRU’s do not run Linux on them . . . So Linux is a moot point in this context.
Think of the PRU’s as something akin to a 200Mhz Cortex M4. With many single cycle instructions. Or even if we expand the acronym . . . Programmable Realtime Unit . . . everything becomes clear maybe ?
@kyle
Well 8k memory may not be a lot, but I think you’d have to write a lot of code to use it all. Unless you get silly and start making obscenely large arrays or something. Remember that bare metal compilers differ largely from compilers for OSes using larger code bases for API’s / ABI’s. Generated code is or can be very compact. So long as you do not use obscenely large library functions, on top of not using an obnoxious amount of memory for things that are not required.
Also if you know the compiler used well enough, technically it should not produce code much, if any larger than pure ASM. In fact it is probably possible to produce code that is larger in ASM than in C - If you do not know ASM well enough. The reverse is definitely possible.
Every compiler / language has it’s gotcha’s / quirks . . .