> > > 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, <[email protected]> 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 > <https://github.com/dinuxbg/gnupru/issues/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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/08fbb391-c5c7-4f99-a1bd-74f0b5143dfd%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/08fbb391-c5c7-4f99-a1bd-74f0b5143dfd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORq9U3fapw8oaC7b7pKLaQ-picVk%2B%2BZt-GPKFKE9P4D49w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
