> > *That isn’t to say there are no bugs, but they do fix them pretty quickly. > I have a pretty fast desktop with lots of memory so Eclipse performs quite > well for me. * >
i7 4710HQ with 16GB RAM, with 2GB dedicated 860M. So it's a laptop, and the only reason why I mention dedicated graphics. It is very, very fast. But again, that's not the point. heh. The point is, even something that is Visual Studio Code ( not the IDE but editor ) that is IDE like, can perform very much faster than any IDE. I've also stopped using VS( the IDE ) because it is also sluggish any more. and it's native code. As it is, I actually prefer writing much of my code in sublime text. As I like many of the features is has, including dark themes I can live with . . . VIM classic mode, snippets, customizable code complete, etc. On Sat, Feb 20, 2016 at 11:54 PM, John Syne <[email protected]> wrote: > On the contrary, I have personal connections with the CCSV6 developers for > many years. I have helped them fix several bugs, especially related to > debugging Linux kernel code back in CCSV4. After CCSV5, TI went a different > directions and I could no longer use CCS for kernel debugging and went the > Lauterbach route. However, for DSP development, there is nothing better > period. For all the other embedded processors, TI do a pretty decent job > with CCSV6. That isn’t to say there are no bugs, but they do fix them > pretty quickly. I have a pretty fast desktop with lots of memory so Eclipse > performs quite well for me. > > 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]> 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]> 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]> >> 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]> wrote: >>> >>>> The IPU’s are CortexM4 processors. >>>> >>>> Regards, >>>> John >>>> >>>> >>>> >>>> >>>> On Feb 20, 2016, at 9:53 PM, William Hermans <[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]> >>>> 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 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]> wrote: >>>>> >>>>>> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <[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 >>>>>> --- >>>>>> 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. >>>> >>>> >>>> >>>> -- >>>> 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. >> >> >> >> -- >> 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. > > > -- > 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.
