Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-18 Thread William Hermans 
Anyway, you can find the history behind the different toolchian for the
MSP430's, and all that on the 43oh.com forums. From which I've been a
member since around January 2013. All the gory details of TI, gcc, and
redhat etc and all that.

On Mon, Jul 18, 2016 at 6:15 PM, William Hermans  wrote:

> Well, it replaced both CCS and the old MSP430 GCC, and I think the
>> concensus is that it's for the good. There were issues in the
>> beginning, but now it's being worked on by both RedHat and TI, and
>> nobody recommends the old stuff for use any more.
>>
>> The usual argument for GCC is that it's relentlessly getting better;
>> proprietary alternatives tend to lose their initial advantage because
>> GCC contributors have a look at the differences and implement the
>> improvements. Look how far Dimitar got it, working on his own.
>>
>
> Well the msp430-gcc-4.6.3 is still the go to to tool chain for many in the
> gcc cap for the msp430G2 family MCU's. At least the ones meant to be used
> in the MSP430G2 v1.5 launchpad. There are some newer MCU's like the
> MSp430G2955 that have more flash and more RAM than the older G2's, end
> require the newer compilers. Something to do with memory addressing I
> believe, but it's been a long time since I've worried about all that. My
> personal favorite MSP430 is the G2553 . . .
>
> This is also the same compiler that comes with Debian I believe but
> perhaps that one was also P.A. Bigot's. The compiler I prefer to use
> actually comes with Energia, which also may be a port of P.A. Bigot's
> original project? Not sure.
>
>
> On Mon, Jul 18, 2016 at 5:47 PM, Przemek Klosowski <
> przemek.klosow...@gmail.com> wrote:
>
>> On Wed, Jul 13, 2016 at 11:09 AM, William Hermans 
>> wrote:
>> >
>> > Granted, now, I've read that redhat was contracted to build a newer gcc
>> port
>> > a few years back, and that this gcc is actually used by CCS now days(
>> for
>> > the MSP430 toolchain ). It is purported to support the newer MSP430G2
>> > variants, among others, but still is not as reliable as the gcc
>> toolchain it
>> > was meant to replace.
>>
>> Well, it replaced both CCS and the old MSP430 GCC, and I think the
>> concensus is that it's for the good. There were issues in the
>> beginning, but now it's being worked on by both RedHat and TI, and
>> nobody recommends the old stuff for use any more.
>>
>> The usual argument for GCC is that it's relentlessly getting better;
>> proprietary alternatives tend to lose their initial advantage because
>> GCC contributors have a look at the differences and implement the
>> improvements. Look how far Dimitar got it, working on his own.
>>
>> --
>> 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 beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.com
>> .
>> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORruUQG6mib1Yevf98MSedePGGKMSfmxJZUZRXCspwLtRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-18 Thread William Hermans 
>
> Well, it replaced both CCS and the old MSP430 GCC, and I think the
> concensus is that it's for the good. There were issues in the
> beginning, but now it's being worked on by both RedHat and TI, and
> nobody recommends the old stuff for use any more.
>
> The usual argument for GCC is that it's relentlessly getting better;
> proprietary alternatives tend to lose their initial advantage because
> GCC contributors have a look at the differences and implement the
> improvements. Look how far Dimitar got it, working on his own.
>

Well the msp430-gcc-4.6.3 is still the go to to tool chain for many in the
gcc cap for the msp430G2 family MCU's. At least the ones meant to be used
in the MSP430G2 v1.5 launchpad. There are some newer MCU's like the
MSp430G2955 that have more flash and more RAM than the older G2's, end
require the newer compilers. Something to do with memory addressing I
believe, but it's been a long time since I've worried about all that. My
personal favorite MSP430 is the G2553 . . .

This is also the same compiler that comes with Debian I believe but perhaps
that one was also P.A. Bigot's. The compiler I prefer to use actually comes
with Energia, which also may be a port of P.A. Bigot's original project?
Not sure.


On Mon, Jul 18, 2016 at 5:47 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Wed, Jul 13, 2016 at 11:09 AM, William Hermans 
> wrote:
> >
> > Granted, now, I've read that redhat was contracted to build a newer gcc
> port
> > a few years back, and that this gcc is actually used by CCS now days( for
> > the MSP430 toolchain ). It is purported to support the newer MSP430G2
> > variants, among others, but still is not as reliable as the gcc
> toolchain it
> > was meant to replace.
>
> Well, it replaced both CCS and the old MSP430 GCC, and I think the
> concensus is that it's for the good. There were issues in the
> beginning, but now it's being worked on by both RedHat and TI, and
> nobody recommends the old stuff for use any more.
>
> The usual argument for GCC is that it's relentlessly getting better;
> proprietary alternatives tend to lose their initial advantage because
> GCC contributors have a look at the differences and implement the
> improvements. Look how far Dimitar got it, working on his own.
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.com
> .
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqJewKXHCfm%2BJx5rA61_MyadfCh73ZeA6340Xw89K3WqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-18 Thread Przemek Klosowski 
On Wed, Jul 13, 2016 at 11:09 AM, William Hermans  wrote:
>
> Granted, now, I've read that redhat was contracted to build a newer gcc port
> a few years back, and that this gcc is actually used by CCS now days( for
> the MSP430 toolchain ). It is purported to support the newer MSP430G2
> variants, among others, but still is not as reliable as the gcc toolchain it
> was meant to replace.

Well, it replaced both CCS and the old MSP430 GCC, and I think the
concensus is that it's for the good. There were issues in the
beginning, but now it's being worked on by both RedHat and TI, and
nobody recommends the old stuff for use any more.

The usual argument for GCC is that it's relentlessly getting better;
proprietary alternatives tend to lose their initial advantage because
GCC contributors have a look at the differences and implement the
improvements. Look how far Dimitar got it, working on his own.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-13 Thread William Hermans 
>
>
> Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right
> now CCS generates a bit more optimized code than pru-gcc. And CCS has
> received more testing than pru-gcc.
>
>
This is also true for the MSP430 port of gcc versus CCS' compiler. It's
been this way for years, and I do not see it changing. Well especially now
that the better gcc toolchain that I use is old ( built back in 2012 or
longer ago ). It's also a very good and solid gcc port, but TI always seems
to know their processors just  bit better ;)

Granted, now, I've read that redhat was contracted to build a newer gcc
port a few years back, and that this gcc is actually used by CCS now days(
for the MSP430 toolchain ). It is purported to support the newer MSP430G2
variants, among others, but still is not as reliable as the gcc toolchain
it was meant to replace.

On Wed, Jul 13, 2016 at 12:14 AM,  wrote:

> Hi William,
>
> I have marked the release as "ready for cautious usage" merely because I
> seem to be the only user so far :) Once I see enough non-trivial projects
> using it, I will remove that wording. While it may not yet have matured
> into a production quality toolchain, I wouldn't call pru-gcc a toy compiler.
>
> I admit the pru-gcc port had a rough start. But I corrected this by
> writing real-world examples and running the GCC testsuite through a
> simulator. Bugs were found and fixed.
>
> The pru-gcc test results you pointed are actually pretty good. The 31
> unexpected failures are due to reasons like: broken features that are not
> applicable to PRU, code optimizations that were not applied. I am not aware
> of any wrong-code-generation bugs. I'm also working on cleaning up the
> report to avoid further confusion (issue #16
> ). You can compare the pru
> results against the mainline gcc test report for x86:
> https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00235.html
>
> Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right
> now CCS generates a bit more optimized code than pru-gcc. And CCS has
> received more testing than pru-gcc.
>
> Regards,
> Dimitar
>
> On Tuesday, July 12, 2016 at 4:47:50 AM UTC+3, William Hermans wrote:
>>
>> heh I forgot that "readme dot md's" actually link to some random github
>> project heh. So . .
>>
>> The release is ready for cautious usage. A simulator is used to execute
>>> the GCC C regression test suite. Results for this release are:
>>>
>>> # of expected passes   81497
>>> # of unexpected failures   31
>>> # of unexpected successes  1
>>> # of expected failures 97
>>> # of unsupported tests 1974
>>>
>>>
>> This message has changed some since the last time I read it but pretty
>> much the same result. In my mind - Don't use it.
>>
>>
>> On Mon, Jul 11, 2016 at 6:44 PM, William Hermans 
>> wrote:
>>
>>> 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.
>>>
>>> On Mon, Jul 11, 2016 at 6:39 PM, William Hermans 
>>> wrote:
>>>
 Hi Mark,

 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.


 On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder 
 wrote:

> Greg:
>   I tried removing the symbolic links and I get the following error
> when running make on a BeagleScope example.
>
> Invoking: PRU Compiler
> /usr/share/ti/cgt-pru/bin/clpru
> --include_path=/usr/share/ti/cgt-pru/include
> --include_path=../../../include --include_path=../../../include/am335x -v3
> -O2 --display_error_number -

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-13 Thread dinuxbg 
Hi William,

I have marked the release as "ready for cautious usage" merely because I 
seem to be the only user so far :) Once I see enough non-trivial projects 
using it, I will remove that wording. While it may not yet have matured 
into a production quality toolchain, I wouldn't call pru-gcc a toy compiler.

I admit the pru-gcc port had a rough start. But I corrected this by writing 
real-world examples and running the GCC testsuite through a simulator. Bugs 
were found and fixed.

The pru-gcc test results you pointed are actually pretty good. The 31 
unexpected failures are due to reasons like: broken features that are not 
applicable to PRU, code optimizations that were not applied. I am not aware 
of any wrong-code-generation bugs. I'm also working on cleaning up the 
report to avoid further confusion (issue #16 
). You can compare the pru 
results against the mainline gcc test report for x86: 
https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00235.html

Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right 
now CCS generates a bit more optimized code than pru-gcc. And CCS has 
received more testing than pru-gcc.

Regards,
Dimitar

On Tuesday, July 12, 2016 at 4:47:50 AM UTC+3, William Hermans wrote:
>
> heh I forgot that "readme dot md's" actually link to some random github 
> project heh. So . . 
>
> The release is ready for cautious usage. A simulator is used to execute 
>> the GCC C regression test suite. Results for this release are:
>>
>> # of expected passes   81497
>> # of unexpected failures   31
>> # of unexpected successes  1
>> # of expected failures 97
>> # of unsupported tests 1974
>>
>>
> This message has changed some since the last time I read it but pretty 
> much the same result. In my mind - Don't use it. 
>
>
> On Mon, Jul 11, 2016 at 6:44 PM, William Hermans  > wrote:
>
>> 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.
>>
>> On Mon, Jul 11, 2016 at 6:39 PM, William Hermans > > wrote:
>>
>>> Hi Mark,
>>>
>>> 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.
>>>
>>>
>>> On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder >> > wrote:
>>>
 Greg:
   I tried removing the symbolic links and I get the following error 
 when running make on a BeagleScope example.

 Invoking: PRU Compiler
 /usr/share/ti/cgt-pru/bin/clpru 
 --include_path=/usr/share/ti/cgt-pru/include 
 --include_path=../../../include --include_path=../../../include/am335x -v3 
 -O2 --display_error_number --endian=little --hardware_mac=on 
 --obj_directory=gen --pp_directory=gen -ppd -ppa -fe 
 gen/PRU_gpioToggle.object PRU_gpioToggle.c
 make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
 Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed

 The error goes away when I put the link back.  Maybe the BeagleScope 
 makefiles aren't set up right.

 --Mark

 On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:
>
> One note on the compiler set-up:
>
> *ln -s `which lnkpru` .*
>
> I haven't found a reason to use the lnkpru command.  The linking is done 
> with clpru with the -z option.
>
> Compile and link processes all done with a single command.  The 
> PRU compiler manual explains the options reasonably thoroughly.
>
> Regards,
> Greg
>
 -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message bec

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-12 Thread William Hermans 
>
> One of the things I learned is if you use printf() out of the box you will
> run out of instruction memory.
> Instead you have to use the --printf_support=nofloat flag on clpru.  It
> uses a smaller printf library that fits.
>

Hi Mark,

Just thinking of this from an alternative angle. The PRU are essentially a
Cortex M3 with no instruction cache. So in the Linux world, the Cortex
M0/M0+, M3's, and M4's all use the eabi compilers in the gcc camp. Which is
to say, soft float compilers. So that makes sense that using the clpru
compiler that soft float should be made implicit. Well actually, I think it
should be a given. but it makes sense that the clpru compiler should be
using soft float versus hard float.



On Tue, Jul 12, 2016 at 6:28 PM, Mark A. Yoder 
wrote:

> I made some progress today.  I modified one of the BeagleScope examples
> (pru_pin_state_reader[1]) to use sprintf() to
> send and print debug info to the ARM[2].  One of the things I learned is
> if you use printf() out of the box you will run out of instruction memory.
> Instead you have to use the --printf_support=nofloat flag on clpru.  It
> uses a smaller printf library that fits.
>
> I'm beginning to get a feel for what's happening on the PRU side, but the
> ARM is a mystery to me.  I'm sure I can figure out mmap() and read the
> shared memory, but I don't think that's the proper way to do it.  Rather I
> think you are supposed to go through the kernel drivers, but I haven't found
> any simple examples.
>
> Does anyone know how the ARM side of remoteproc works?
>
> --Mark
>
> [1]
> https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_pin_state_reader
> [2]
> https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/pru/beagleScope/pru_pin_state_reader
>
> On Monday, July 11, 2016 at 2:58:46 PM UTC-4, Mark A. Yoder wrote:
>>
>> It looks like the new way to talk to the PRUs is via remoteproc and
>> RPMsg.
>>
>> Does anyone have pointers to some good tutorials?  Or some good debuggers?
>>
>> ZeekHuge has a Google Summer of Code project (2016)
>> that has some nice remoteproc
>> examples, and he
>> built some nice tools.
>>
>> I'm putting together a wiki
>>  that
>> shows how to setup your Bone to run his examples. (
>> http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg).
>> I'm open for additions/corrections so we can have a one stop place for
>> those using the PRUs with remoteproc.
>>
>> --Mark
>>
>>
>>
>> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/57a174ab-5696-46fb-b886-80a1d3906eb8%40googlegroups.com
> 
> .
>
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpQnt55TsRwck_r4EMNm_kCWwmFXV1aH%3DiBh0HnyYz-MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-12 Thread Mark A. Yoder 
I made some progress today.  I modified one of the BeagleScope examples 
(pru_pin_state_reader[1]) to use sprintf() to
send and print debug info to the ARM[2].  One of the things I learned is if 
you use printf() out of the box you will run out of instruction memory.
Instead you have to use the --printf_support=nofloat flag on clpru.  It 
uses a smaller printf library that fits.

I'm beginning to get a feel for what's happening on the PRU side, but the 
ARM is a mystery to me.  I'm sure I can figure out mmap() and read the
shared memory, but I don't think that's the proper way to do it.  Rather I 
think you are supposed to go through the kernel drivers, but I haven't found
any simple examples.

Does anyone know how the ARM side of remoteproc works?

--Mark

[1] 
https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_pin_state_reader
[2] 
https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/pru/beagleScope/pru_pin_state_reader

On Monday, July 11, 2016 at 2:58:46 PM UTC-4, Mark A. Yoder wrote:
>
> It looks like the new way to talk to the PRUs is via remoteproc and RPMsg. 
>  
>
> Does anyone have pointers to some good tutorials?  Or some good debuggers?
>
> ZeekHuge has a Google Summer of Code project (2016) 
> that has some nice remoteproc 
> examples, and he
> built some nice tools.  
>
> I'm putting together a wiki 
>  that 
> shows how to setup your Bone to run his examples. (
> http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg).
> I'm open for additions/corrections so we can have a one stop place for 
> those using the PRUs with remoteproc.
>
> --Mark
>
>
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/57a174ab-5696-46fb-b886-80a1d3906eb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-12 Thread Mark A. Yoder 
Greg:
  Thanks for looking into the Makefile magic.  I was just happy I had 
something working, without really trying to understand it.

--Mark

On Monday, July 11, 2016 at 10:37:49 PM UTC-4, Greg wrote:
>
> I see what he did differently compared to the TI example's Makefiles.  It 
> is a matter of using the -z option with clpru or a distinct command using 
> lnkpru.
>
> How TI does it:
> *$(PRU_CGT)/bin/clpru $(CFLAGS) -z* -i$(PRU_CGT)/lib -i$(PRU_CGT)/include 
> $(LFLAGS) -o $(TARGET) $(OBJECTS) -m$(MAP) $(LINKER_COMMAND_FILE) 
> --library=libc.a $(LIBS)
>
> How the BeagleScope Makefile does it:
> *$(PRU_CGT)/bin/lnkpru* -i$(PRU_CGT)/lib -i$(PRU_CGT)/include $(LFLAGS) 
> -o $@ $^ $(LINKER_COMMAND_FILE) --library=libc.a $(LIBS)
>
> So what BeagleScope is doing is "clpru -z" which is equivalent to the 
> lnkpru command.
>
> So to be able to handle this when it appears in a Makefile, it is indeed 
> good to have the lnkpru link to /usr/bin/lnkpru.
> Makes sense now!
>
> Regards,
> Greg
>
> On Monday, July 11, 2016 at 9:14:48 PM UTC-4, Mark A. Yoder wrote:
>>
>> Greg:
>>   I tried removing the symbolic links and I get the following error when 
>> running make on a BeagleScope example.
>>
>> Invoking: PRU Compiler
>> /usr/share/ti/cgt-pru/bin/clpru 
>> --include_path=/usr/share/ti/cgt-pru/include 
>> --include_path=../../../include --include_path=../../../include/am335x -v3 
>> -O2 --display_error_number --endian=little --hardware_mac=on 
>> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe 
>> gen/PRU_gpioToggle.object PRU_gpioToggle.c
>> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
>> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed
>>
>> The error goes away when I put the link back.  Maybe the BeagleScope 
>> makefiles aren't set up right.
>>
>> --Mark
>>
>> On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:
>>>
>>> One note on the compiler set-up:
>>>
>>> *ln -s `which lnkpru` .*
>>>
>>> I haven't found a reason to use the lnkpru command.  The linking is done 
>>> with clpru with the -z option.
>>>
>>> Compile and link processes all done with a single command.  The PRU 
>>> compiler manual explains the options reasonably thoroughly.
>>>
>>> Regards,
>>> Greg
>>>
>>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8302bfc9-a6aa-4562-b8c4-08a5834463a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread Greg 
I see what he did differently compared to the TI example's Makefiles.  It 
is a matter of using the -z option with clpru or a distinct command using 
lnkpru.

How TI does it:
*$(PRU_CGT)/bin/clpru $(CFLAGS) -z* -i$(PRU_CGT)/lib -i$(PRU_CGT)/include 
$(LFLAGS) -o $(TARGET) $(OBJECTS) -m$(MAP) $(LINKER_COMMAND_FILE) 
--library=libc.a $(LIBS)

How the BeagleScope Makefile does it:
*$(PRU_CGT)/bin/lnkpru* -i$(PRU_CGT)/lib -i$(PRU_CGT)/include $(LFLAGS) -o 
$@ $^ $(LINKER_COMMAND_FILE) --library=libc.a $(LIBS)

So what BeagleScope is doing is "clpru -z" which is equivalent to the 
lnkpru command.

So to be able to handle this when it appears in a Makefile, it is indeed 
good to have the lnkpru link to /usr/bin/lnkpru.
Makes sense now!

Regards,
Greg

On Monday, July 11, 2016 at 9:14:48 PM UTC-4, Mark A. Yoder wrote:
>
> Greg:
>   I tried removing the symbolic links and I get the following error when 
> running make on a BeagleScope example.
>
> Invoking: PRU Compiler
> /usr/share/ti/cgt-pru/bin/clpru 
> --include_path=/usr/share/ti/cgt-pru/include 
> --include_path=../../../include --include_path=../../../include/am335x -v3 
> -O2 --display_error_number --endian=little --hardware_mac=on 
> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe 
> gen/PRU_gpioToggle.object PRU_gpioToggle.c
> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed
>
> The error goes away when I put the link back.  Maybe the BeagleScope 
> makefiles aren't set up right.
>
> --Mark
>
> On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:
>>
>> One note on the compiler set-up:
>>
>> *ln -s `which lnkpru` .*
>>
>> I haven't found a reason to use the lnkpru command.  The linking is done 
>> with clpru with the -z option.
>>
>> Compile and link processes all done with a single command.  The PRU 
>> compiler manual explains the options reasonably thoroughly.
>>
>> Regards,
>> Greg
>>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/015209d3-f033-473c-8abd-967009206d26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread William Hermans 
heh I forgot that "readme dot md's" actually link to some random github
project heh. So . .

The release is ready for cautious usage. A simulator is used to execute the
> GCC C regression test suite. Results for this release are:
>
> # of expected passes   81497
> # of unexpected failures   31
> # of unexpected successes  1
> # of expected failures 97
> # of unsupported tests 1974
>
>
This message has changed some since the last time I read it but pretty much
the same result. In my mind - Don't use it.


On Mon, Jul 11, 2016 at 6:44 PM, William Hermans  wrote:

> 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.
>
> On Mon, Jul 11, 2016 at 6:39 PM, William Hermans 
> wrote:
>
>> Hi Mark,
>>
>> 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.
>>
>>
>> On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder 
>> wrote:
>>
>>> Greg:
>>>   I tried removing the symbolic links and I get the following error when
>>> running make on a BeagleScope example.
>>>
>>> Invoking: PRU Compiler
>>> /usr/share/ti/cgt-pru/bin/clpru
>>> --include_path=/usr/share/ti/cgt-pru/include
>>> --include_path=../../../include --include_path=../../../include/am335x -v3
>>> -O2 --display_error_number --endian=little --hardware_mac=on
>>> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe
>>> gen/PRU_gpioToggle.object PRU_gpioToggle.c
>>> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
>>> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed
>>>
>>> The error goes away when I put the link back.  Maybe the BeagleScope
>>> makefiles aren't set up right.
>>>
>>> --Mark
>>>
>>> On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:

 One note on the compiler set-up:

 *ln -s `which lnkpru` .*

 I haven't found a reason to use the lnkpru command.  The linking is done 
 with clpru with the -z option.

 Compile and link processes all done with a single command.  The PRU
 compiler manual explains the options reasonably thoroughly.

 Regards,
 Greg

>>> --
>>> 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 beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com
>>> 
>>> .
>>>
>>> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqdb4dP1Kd8iX7SG-VTUmx1nTNALqqRFJkceQaTThCRrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread William Hermans 
>
> 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.

On Mon, Jul 11, 2016 at 6:39 PM, William Hermans  wrote:

> Hi Mark,
>
> 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.
>
>
> On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder 
> wrote:
>
>> Greg:
>>   I tried removing the symbolic links and I get the following error when
>> running make on a BeagleScope example.
>>
>> Invoking: PRU Compiler
>> /usr/share/ti/cgt-pru/bin/clpru
>> --include_path=/usr/share/ti/cgt-pru/include
>> --include_path=../../../include --include_path=../../../include/am335x -v3
>> -O2 --display_error_number --endian=little --hardware_mac=on
>> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe
>> gen/PRU_gpioToggle.object PRU_gpioToggle.c
>> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
>> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed
>>
>> The error goes away when I put the link back.  Maybe the BeagleScope
>> makefiles aren't set up right.
>>
>> --Mark
>>
>> On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:
>>>
>>> One note on the compiler set-up:
>>>
>>> *ln -s `which lnkpru` .*
>>>
>>> I haven't found a reason to use the lnkpru command.  The linking is done 
>>> with clpru with the -z option.
>>>
>>> Compile and link processes all done with a single command.  The PRU
>>> compiler manual explains the options reasonably thoroughly.
>>>
>>> Regards,
>>> Greg
>>>
>> --
>> 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 beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com
>> 
>> .
>>
>> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpsh5j72Bdp%3DgWYr6gngvxW2FuRL4yFDJAeRkGBiMoRXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread William Hermans 
Hi Mark,

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.


On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder 
wrote:

> Greg:
>   I tried removing the symbolic links and I get the following error when
> running make on a BeagleScope example.
>
> Invoking: PRU Compiler
> /usr/share/ti/cgt-pru/bin/clpru
> --include_path=/usr/share/ti/cgt-pru/include
> --include_path=../../../include --include_path=../../../include/am335x -v3
> -O2 --display_error_number --endian=little --hardware_mac=on
> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe
> gen/PRU_gpioToggle.object PRU_gpioToggle.c
> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed
>
> The error goes away when I put the link back.  Maybe the BeagleScope
> makefiles aren't set up right.
>
> --Mark
>
> On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:
>>
>> One note on the compiler set-up:
>>
>> *ln -s `which lnkpru` .*
>>
>> I haven't found a reason to use the lnkpru command.  The linking is done 
>> with clpru with the -z option.
>>
>> Compile and link processes all done with a single command.  The PRU
>> compiler manual explains the options reasonably thoroughly.
>>
>> Regards,
>> Greg
>>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com
> 
> .
>
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpvkn77V971NqutzzobtzukHJ6r%2BcOEHE7UVxTzLARRgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread Mark A. Yoder 
Greg:
  I tried removing the symbolic links and I get the following error when 
running make on a BeagleScope example.

Invoking: PRU Compiler
/usr/share/ti/cgt-pru/bin/clpru 
--include_path=/usr/share/ti/cgt-pru/include 
--include_path=../../../include --include_path=../../../include/am335x -v3 
-O2 --display_error_number --endian=little --hardware_mac=on 
--obj_directory=gen --pp_directory=gen -ppd -ppa -fe 
gen/PRU_gpioToggle.object PRU_gpioToggle.c
make: /usr/share/ti/cgt-pru/bin/clpru: Command not found
Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed

The error goes away when I put the link back.  Maybe the BeagleScope 
makefiles aren't set up right.

--Mark

On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote:
>
> One note on the compiler set-up:
>
> *ln -s `which lnkpru` .*
>
> I haven't found a reason to use the lnkpru command.  The linking is done with 
> clpru with the -z option.
>
> Compile and link processes all done with a single command.  The PRU 
> compiler manual explains the options reasonably thoroughly.
>
> Regards,
> Greg
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread William Hermans 
>
> Hi William-
>
> Regarding the .bss .data etc., this may be helpful:
>
> https://training.ti.com/pru-compiler-tips-tricks
>

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:
>
> http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer
>

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


Regards,
Greg


On Mon, Jul 11, 2016 at 5:24 PM, Greg  wrote:

> A "future" remote-proc project, last commit 2015, probably not active:
>>
>
>  https://github.com/deepakkarki/pruspeak
>
> Note the system flow diagram on the above page.
> I really like the way to diagram is split into three domains.
> Nicely done!
>
> Regards,
> Greg
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3472d70e-6064-406b-a109-c8ec7d0a3892%40googlegroups.com
> 
> .
>
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpr4muDikpe_NeBNHeJoVdosTrnnAqVAxWZ0myJyzMftQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread Greg 

>
> A "future" remote-proc project, last commit 2015, probably not active:
>

 https://github.com/deepakkarki/pruspeak

Note the system flow diagram on the above page.
I really like the way to diagram is split into three domains.
Nicely done!

Regards,
Greg

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3472d70e-6064-406b-a109-c8ec7d0a3892%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread Greg 
One note on the compiler set-up:

*ln -s `which lnkpru` .*

I haven't found a reason to use the lnkpru command.  The linking is done with 
clpru with the -z option.

Compile and link processes all done with a single command.  The PRU 
compiler manual explains the options reasonably thoroughly.

Regards,
Greg

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/591fc335-e07c-4bdf-ae74-09201ea18743%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc Tutorial

2016-07-11 Thread Greg 
The TI training site is a bit confusing, and I'm still not sure this is the 
latest:

http://software-dl.ti.com/public/hpmp/sitara/building_blocks_for_pru_dev_summary/index.html

The above is a good starting point.  Homework 1?

Greg


>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ad68b56c-8aac-4e5f-b051-ed94de4308cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.