When you have made VS index the Linux Kernel, then we can talk, but speculating that it can be done is senseless. Here is a simple exercise to prove my point. In two minutes, can you define the call sequence for say the ti_am335x_adc probe function. In other words, how does the tiadc_probe function get called? Start with the "module_platform_driver(tiadc_driver)” on line 594.
Regards, John > On Feb 21, 2016, at 2:41 PM, William Hermans <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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] >> <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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 >>> <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 > <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.
