> > *Studio for many years. If for nothing else, "function explorer". Which > works fine with any source even if that source can not be compiled with VS > ;)* >
By the way, sublime text 3 has this built in now too. On Sun, Feb 21, 2016 at 12:31 AM, William Hermans <yyrk...@gmail.com> wrote: > *This help me browse to any Linux Kernel function with a ctrl click.* >> > > This is something Visual Studio has had / done for years, as in since . . > . well as long as I can remember. According to wikipedia, Visual Studio 6 > was released in 1998, and I know it was a feature in VS6 . . . at any rate > it is why I've used Visual Studio for many years. If for nothing else, > "function explorer". Which works fine with any source even if that source > can not be compiled with VS ;) > > Now days. *find*, and *grep* take the place of many tools. As well as > many other command line utilities . . . > > The only "compiler" that I'll put up with and is not gcc. Is actually not > a compiler but is TI's PRU Assembler. I'd also might tolerate clpru in the > future if I ever get around to reading the manual for it. BUt the PRU is a > special case, where I feel that community based open source tools are not > good enough, and probably never will be. > > So, when you use a tool chain based on gcc. As well as all the wonderful > Linux command line utilities. IDE "tools" are no longer necessary, and are > in fact less efficient. GUI's tend to get in the way, in this context. > > On Sun, Feb 21, 2016 at 12:11 AM, John Syne <john3...@gmail.com> wrote: > >> Yep, I like Sublime Text as well. It is clearly my favorite editor, but >> for indexing the Linux Kernel, to include only code for the platform I’m >> using, I use Eclipse. This help me browse to any Linux Kernel function with >> a ctrl click. For Javascript, I use Webstorm and for embedded I use >> CCSV6.1. I use whatever tools get the job done. >> >> Regards, >> John >> >> >> >> >> On Feb 20, 2016, at 11:04 PM, William Hermans <yyrk...@gmail.com> wrote: >> >> *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 <john3...@gmail.com> 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 <yyrk...@gmail.com> 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 <john3...@gmail.com> 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 <yyrk...@gmail.com> >>>> 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 <yyrk...@gmail.com> >>>> 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 <john3...@gmail.com> >>>>> wrote: >>>>> >>>>>> The IPU’s are CortexM4 processors. >>>>>> >>>>>> Regards, >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Feb 20, 2016, at 9:53 PM, William Hermans <yyrk...@gmail.com> >>>>>> 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 <yyrk...@gmail.com> >>>>>> 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 < >>>>>>> przemek.klosow...@gmail.com> wrote: >>>>>>> >>>>>>>> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <yyrk...@gmail.com> >>>>>>>> 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 beagleboard+unsubscr...@googlegroups.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. >>>>>> 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. >>>>>> 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. >>>> 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. >>>> 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. >>> 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. >>> 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. >> 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. >> 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. For more options, visit https://groups.google.com/d/optout.