This isn't a pissing contest John. Go out and look into it on the VS front
if you want to. Otherwise don't worry about it.
On Sun, Feb 21, 2016 at 3:55 PM, John Syne <john3...@gmail.com> wrote:
> 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 <yyrk...@gmail.com> 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 <john3...@gmail.com> 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 <yyrk...@gmail.com> 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 <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.
>>
>>
>>
>> --
>> 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.
