>
> *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.

On Wed, Aug 19, 2015 at 10:06 AM, Carlos Novaes <[email protected]> wrote:

> Le mardi 18 août 2015 23:51:38 UTC-3, William Hermans a écrit :
>>
>> *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.
> 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?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to