This video series by Eric Wilbur explains some the things the TI C Compiler does so well that you cannot do with GCC:
https://training.ti.com/introduction-c6000-architecture-1-15?cu=96517 <https://training.ti.com/introduction-c6000-architecture-1-15?cu=96517> You need to view all of them to see that advantage. BTW, the C66xx DSP on the AM5728 is way more powerful than the C64/C67 DSP described in the videos. Regards, John > On Feb 20, 2016, at 10:47 PM, William Hermans <[email protected]> wrote: > > BTW, I believe CCSV6 doesn’t need a license for code that is less than 16K. > > I believe that any TI dev board is supported in CCSv6 for free so long as the > code is not used for commercial purposes. This also includes various other > dev boards, which I believe includes the beaglebone boards. > > However, that is not the point. I have a considerable amount of time invested > into using gcc based tool chains and prefer to stick with gcc. period. I do > not need all that instrumentation fluff to write code, and in fact do not > require, or even want an IDE of any sort most of the time. Let alone a buggy, > poor performing IDE written in java . . . > > Also do us both a favor. Don't try and tell me that CCS isn't buggy, and > isn't poor performing, You're not the only one whose been exposed to CCS for > years . . . > > On Sat, Feb 20, 2016 at 11:40 PM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > Ah, so I just use CCSV6 which has all the scripts that take the CortexM4s out > of reset and configures their memory map so that I can write code and debug > pretty quickly. Now if you don’t use CCSV6, you have to do all that via the > CortexA15s and that is going to be very difficult for development. I’ve been > doing this on the OMAP5 for several years, which has many of the same > features as AM5728. I also use CCSV6 for the DSPs, which have the same > issues. The TI DSP C compiler is highly optimized for the C66 DSP which has > many cores that operate in parallel. Also, the instrumentation provided by > CCSV6 makes it possible to do very accurate measurements while running live > code. This is especially important for multithreaded applications. BTW, I > believe CCSV6 doesn’t need a license for code that is less than 16K. > > > Regards, > John > > > > >> On Feb 20, 2016, at 10:30 PM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> >> I think more correctly said. They're similar to a Cortex M4 that sits on an >> Lx host processor interconnect. So you can not just use the eabi-none gcc >> port to make them work . . . >> >> On Sat, Feb 20, 2016 at 11:22 PM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> The IPU’s are CortexM4 processors. >> Regards, >> John >> >> You're just now figuring that out ? >> >> On Sat, Feb 20, 2016 at 11:20 PM, John Syne <[email protected] >> <mailto:[email protected]>> wrote: >> The IPU’s are CortexM4 processors. >> >> Regards, >> John >> >> >> >> >>> On Feb 20, 2016, at 9:53 PM, William Hermans <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I do expect that TI will improve the documentation on their implementation >>> of remoteproc / rpmsg sometime in the future though. As in the case of the >>> X15, there are not only 4 on die PRU's, but there are 4 IPU's( 2 usable for >>> general purpose ), and two DSP's( on the dual core A15 ). I've no idea what >>> TI has compiler / assembler wise for these DSP's but the IPU's from what I >>> understand are fairly new( in the context of general purpose ). So I'd >>> assume this is where remoteproc / rpmsg will make the most sense. the on >>> die IPU's >>> >>> On Sat, Feb 20, 2016 at 10:39 PM, William Hermans <[email protected] >>> <mailto:[email protected]>> wrote: >>> William, >>> >>> I must be missing something, because I see remoteproc as a >>> communication and management mechanism for code on CPUs other than the >>> main processor. The actual code that you are running on those >>> subsidiary processors does not depend on the mechanism you use for >>> talking to it (other than the parts that do the talking, of course). >>> >>> In particular, running ADC, I2C or GPIO should be the same, regardless >>> whether you use remoteproc or not---what changes is how you tell this >>> code what to do. >>> >>> Does it make sense to you? >>> >>> What it is suppose to do hs always made sense to me. How exactlyit is done, >>> is another story. >>> >>> with uio_prussdrv, you have a driver module, which sets various things up, >>> loads the PRU binary, and then enables / runs the PRU(s). On the PRU side, >>> the code runs, communicates with various peripherals as needed( usually >>> one, if any ), and then the PRU code performs it's function as specified in >>> assembly. Sometimes, dumping data into ddr3( as per the example ), and >>> sometimes not. >>> >>> Anyway, the above is a fairly rough description, but how each aspect >>> communicates with the other is abundantly clear in code. Some have even >>> attempted to describe what happens, but if you ask me inadequately. No >>> matter though the code is pretty clear. >>> >>> With remoteproc, the Documentation/*txt documentation is very minimal, and >>> does not describe the process in which it works very well. However, the >>> code is fairly clear as to how the ARM, and PRU sides communicate with one >>> another( rpmsg ). However, what is not clear, is how the PRU code actually >>> manipulates the physics on system hardware. Additionally, to confuse >>> matters even more, the assembler has changed to a compiler( C - clpru ), >>> and there is something like "map" files for hardware configuration that do >>> not seem to be very well documented. Just some examples, that are not very >>> clear as to how, or why these are even needed. >>> >>> So here I am, attempting to learn a few things new to me. Documentation is >>> very poor, TI refuses to answer any questions in relation to PRUs on their >>> e2e forums(" go to beagleboard.org <http://beagleboard.org/> google groups >>> . . ." ). I spend several days learning about everything PRU related, and >>> immediately pick up the concept of uio_prussdrv. Still having a hard time >>> with the TI C compiler on the PRU side of things, largely due to these >>> mysterious configuration files. But no matter, the TI Assembler is fairly >>> straight forward, the PRU instruction set is a minimal Cortex M3 set, and >>> easy. >>> >>> Anyway, for context of my competence level. Not long ago I wrote a set of >>> processes / applications to read from the CANBUS in realtime, decode the >>> CANBUS data, and shuffle this decoded data out over a websocket. This >>> required me learning several aspect of Linux systems programming from >>> scratch. Including POSIX shared memory files, socketCAN, and process >>> spawning / management. All from scratch, since this was my first major >>> Linux application. All of this including reverse engineering parts of the >>> high level CANBUS protocol took me around a month. The point here is, I >>> have no problem picking up / understanding technologies, and / or API's, >>> libraries, and such that I've previously have had no experience with. *So >>> long* as there is at least a little decent documentation on the subject, or >>> I can talk to someone who does understand things that may be confusing to >>> me. >>> >>> Additionally, I'm not saying exactly that remoteproc can't be made to work, >>> because obviously it can. What I am saying is that since the concept is so >>> poorly documented, is still in experimental phase, and now I learn that it >>> is slower than traditional prussdrv drivers / methods. That it's just not >>> worth my time to even attempt to get working. >>> >>> That and I *have* spent some time ( roughly a week ), *just because* I'm >>> the type that does not mind experimenting with new technology in software. >>> But only new technology that is not too argumentative. As my time is far >>> too valuable to me than to screw around with technology that honestly makes >>> very little sense to me. >>> >>> Also for what it is worth. remoteproc / rpmsg in my own mind is far more >>> useful in cases where a processor may have multiple application / general >>> purpose cores. In that one core can be made to run Linux, while the others >>> can be made to run bare metal - Simultaneously. Less useful on the case of >>> the PRUs since we already have a software layer that is well documented, >>> works very well, and quite honestly far superior to remoteproc / rpmsg in >>> this case. If nothing else. Speed. >>> >>> >>> On Sat, Feb 20, 2016 at 9:45 PM, Przemek Klosowski >>> <[email protected] <mailto:[email protected]>> wrote: >>> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <[email protected] >>> <mailto:[email protected]>> wrote: >>> > Is it really so much to ask for example code to demonstrate how to >>> > interact >>> > with the on die hardware ? Without having to download 1GB of pretty much >>> > useless library . . . >>> >>> William, >>> >>> I must be missing something, because I see remoteproc as a >>> communication and management mechanism for code on CPUs other than the >>> main processor. The actual code that you are running on those >>> subsidiary processors does not depend on the mechanism you use for >>> talking to it (other than the parts that do the talking, of course). >>> >>> In particular, running ADC, I2C or GPIO should be the same, regardless >>> whether you use remoteproc or not---what changes is how you tell this >>> code what to do. >>> >>> Does it make sense to you? >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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] >>> <mailto:beagleboard%[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> <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] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
