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 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
This video series by Eric Wilbur explains some the things the TI C Compiler does so well that you cannot do with GCC:
https://training.ti.com/introduction-c6000-architecture-1-15?cu=96517
You need to view all of them to see that advantage. BTW, the C66xx DSP on the AM5728 is way more powerful than the C64/C67 DSP described in the videos.
Regards,
John
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.
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
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.
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.
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
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.
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
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.
You are right, and I didn’t expect you to take on the challenge. I was only making the point that browsing the Linux Kernel isn’t trivial and many of the online indexers have a long way to go to become useful. Anyway, thanks for playing 
Regards,
John