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 > <mailto: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 >> <mailto: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 >> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 <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 >>>> <przemek.klosow...@gmail.com <mailto:przemek.klosow...@gmail.com>> wrote: >>>> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans <yyrk...@gmail.com >>>> <mailto: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 >>>> <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 >>>> <mailto:beagleboard%2bunsubscr...@googlegroups.com>. >>>> 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 beagleboard+unsubscr...@googlegroups.com >>>> <mailto:beagleboard+unsubscr...@googlegroups.com>. >>>> 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 beagleboard+unsubscr...@googlegroups.com >>> <mailto:beagleboard+unsubscr...@googlegroups.com>. >>> 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 beagleboard+unsubscr...@googlegroups.com >>> <mailto:beagleboard+unsubscr...@googlegroups.com>. >>> 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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.com>. >> 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
