Visual studio code is *not* Visual Studio. Visual Studio code is a text editor meant for web development, but *can* be used for other languages. Just as any other text editor can be used as such.
Visual Studio on the other hand is a full blown IDE that has had features in the past that no other IDE's could rival, or even compare to. If Eclipse can index this stuff you're talking about. So can Visual Studio. As Visual Studio is light years ahead of Eclipse, no doubt. The problem with Visual Studio however, is that once you stray outside of cl.exe( in the context of C/C++ ), setup increasingly gets more difficult. But the compiler *can* be "changed out", and the debugging system can be made to work with gcc tools if you understand how. Honestly though, I personally do not find the effort worth it anymore. grep works just fine if you understand how to use it correctly. On Sun, Feb 21, 2016 at 1:42 PM, John Syne <[email protected]> wrote: > Not true. The Kernel supports so many architectures and most indexers > cannot deal with this in an intelligent way. BTW, I use Visual Studio Code > which support Typescript and runs on any platform. I have used cscope and > several other indexers in the past, but there is no way to teach them about > that you are using the ARM architecture. So when you look for the source > for a function, you get dozens of references and that just slows things > down. Using “git grep”, grep, ack, etc also produce multiple references and > that is unacceptable. > > Regards, > John > > > > > On Feb 20, 2016, at 11:35 PM, William Hermans <[email protected]> wrote: > > *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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[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. >>> >>> >>> >>> -- >>> 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.
