Re: [Emc-developers] proof of concept: HAL module/driver for Beaglebone/ARM335x PRU realtime coprocessor

[Bas L. <sj...@xs...>]

On 29-11-2012 13:02, Michael Haberler wrote:
> Am 29.11.2012 um 12:41 schrieb Bas Laarhoven:
>
>> On 29-11-2012 0:56, Michael Haberler wrote:
>>> summary: high-speed HAL I/O without extra hardware & idle main cpu on TI ARM335x omap processors
>>>
>>> ...
>>> I've scoped 50Mhz pin toggle rate by similar code; a qualified rumor in the TI ARM forum says 'this code shows a 200Mhz signal on the scope' - generated by assembly code in the PRU, the main CPU doing nothing at all.
>>>
>>>
>>> - Michael
>> Hi Michael, great job done!
>>
>> Some minor remark:
>> I expect your code to generate a 66.7 MHz signal at 1/3 duty cycle. The rumoured 200 MHz is not feasible, the theoretical maximum is 100 MHz, but will be lower because you'll have to loop, unless you fill the entire program memory with SET and CLR instructions (assuming the programs counter wraps).
> Either way that makes a pretty fast base thread;)
>
>> BTW: Did you use the original assembler or my 'extended' version?
> No, I fact I didnt even read it until today, since it has no license attached
>
> as soon as that becomes clear, I'd happily cheat from your code which is far advanced on PRU interfacing.
>
> just to be clear:
>
> I am talking about the C code in https://github.com/modmaker/BeBoPr
> I am not talking about your proprietary PRU assembly code
>
> --
>
> I saw your worked on the TI assembler - what was the requirement/problem?
TI removed all the new PRU (version 2) functionality (that they didn't 
want to support) from the assembler they published.
I resurrected some of these (documented in TRM rev C, undocumented since 
TRM rev D) instructions in my version of the assembler.
Some are very handy, but I'll leave that for you to discover yourself : )

>
> curious: how do you debug PRU code - do you use the TI CodeStudio thing? that's a bit top heavy and I'm not sure whether that is applicable to remote linux use to start with
I tried CCS a couple of times, and it works almost, sometimes, very slow,...
>
> any other debugging vehicles? I saw the register dump in your code, anything beyond?
Nope, this has proven a reliable way to debug my code. Use halt 
instructions to trigger a dump, or dump a snapshot of a running PRU.
Of course I'm using a NFS mounted file system so that I quickly can 
edit, (cross)compile and run my code.

-- Bas
>   
> -m
>
>> -- Bas
>>
>>> ------------------------------------------------------------------------------
>>> Keep yourself connected to Go Parallel:
>>> INSIGHTS What's next for parallel hardware, programming and related areas?
>>> Interviews and blogs by thought leaders keep you ahead of the curve.
>>> http://goparallel.sourceforge.net
>>> _______________________________________________
>>> Emc-developers mailing list
>>> Emc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers