> How to compile C programs with Code Composer Studio
Oh god! Ack, ew, retch.
I've had to use CCS a few years ago, and it was a buggy monstrosity. I don't understand why silicon vendors have to wrap their dev tools into such horrid IDEs. One reason I loved working with AVRs is that I could get a gcc-like interface, so that I knew exactly which options and parameters were used rather than some godforsaken IDE do some magic for me and get in my way. Having to hunt down options in modal windows and tabs is enough to make my blood boil just thinking about it.
Embedded development requires very precise control and knowledge about what you're doing, and IDEs more often than not get in the way of doing that.
For a while I worked with Bada, the Korean smartphone OS pushed by Samsung which nobody has ever heard of.
(It was actually not bad; apps written in C++ with a Java-like class library which all ran inside a single process, targeted at fairly small devices. Our test hardware was this massive plastic brick with daughterboards poking out in all directions all wrapped round this utterly gorgeous curved OLED screen.)
You developed on it using a custom IDE which totally wasn't Eclipse (despite being Eclipse) which used gcc as the backend compiler and a bunch of custom tools to generate the deployment packages. Naturally, we ignored the IDE and just used makefiles, so that we could integrate the Bada build into our existing build automation.
...then one update they removed the custom tools and moved their functionality into Eclipse.
This meant that the only way to create applications was to open Eclipse, load the project, and then manually press the 'build' button.
Naturally, we complained, along with everyone else who used it, and never got an answer. The platform died soon after.
I use CCS and the TI compilers for a processor at work. It's not bad. I was able to move us to a Make-based build system for the pile of artifacts that we use that compiler and gcc for in less than a week. TIs command line tools are pretty useful.
(Yes, I have tried CMake, and it is entirely the wrong kind of cross-platform.)
I visited Samsung HQ in Suwon, Korea during that period. As I entered I recall being shown "that building is Bada OS", "that building is Windows", "that building is Android". (We were preparing the flagship application for the Galaxy device series launch in the US market, an on-device DRM'd digital video market with pre-loaded/licensed content and carrier billing integration). I guess that was 2010.
Hey I used Samsung Wave, because it came with Bada OS which looked pretty nice (and run much better) compared to Android on similar hardware! Too bad it was pretty much DOA as ecosystem. Interesting story anyway. :)
We could run gcc fine. The problem was (from memory, this was a while ago) the bespoke tool which bundled up the binary and resource data and signed it to create the installable package. Previously it had been an external binary; but they rewrote it in Java and linked it into the Eclipse binary, and the only hooks were from the Eclipse project build system. The generated makefiles didn't call this because there was nothing to call.
However --- good news! I've just found references from 2012 to a thing called MakePackage.jar, which seems to do exactly what we wanted. There certainly wasn't any such thing while I was working on it, so it looks like they changed their mind later. Which would be great, but we'd abandoned the platform by then.
Here's what seems to be left of the Bada documentation.
I was also intrigue after reading that. I wondering if gcc and friends were integrated directly into Eclipse? It is possible, but it would be a complete waste of engineering resource.
I think a problem is with a lot of eclipse based embedded studio's is the driver and board support package code is generated from templates via an eclipse plugin written in Java. Also good luck trying to figure out an Eclipse project file without retching.
CCS has come a long way since version 3. Ever since TI started using Eclipse as the base for CCS things have been getting better. Out of all the IDE's I've used over the past 5 years CCS is my favorite.
> Embedded development requires very precise control and knowledge about what you're doing, and IDEs more often than not get in the way of doing that.
Embedded development requires precise control and knowledge about what you're doing, and that's precisely why you would want to use the manufacturer's recommended IDE. Have you ever tried managing development with an RTOS? Or streaming data out of RAM while your code was running? Or fiddling with the processor registers when debugging? IDE's make all that much simpler, you may want to give CCS an other chance, it's a really powerful IDE.
> Have you ever tried managing development with an RTOS? Or streaming data out of RAM while your code was running? Or fiddling with the processor registers when debugging?
Yes to all of the above, and had to script it too, which I couldn't do with an IDE at the time.
I indeed haven't used CCS-Eclipse in years. Has it finally eliminated its lag and RAM usage? I was always amazed how it managed to continuously stay just ahead of Moore's Law in terms of resource usage.
> I indeed haven't used CCS-Eclipse in years. Has it finally eliminated its lag and RAM usage? I was always amazed how it managed to continuously stay just ahead of Moore's Law in terms of resource usage.
You're right, the lag was bad. Recently I haven't noticed it much, maybe I got used to it, or maybe it's been improved. Currently my instance of CCS 6.0.1 uses around 286MB of RAM, CCS 6.1.0 uses about 480MB of RAM. In comparison PyCharm (2016.1.4) is using 927MB of RAM :(
How did you debug code running on the hardware without an IDE? Is there an easy-ish way to do that?
What you don't want is a bunch of opaque gnosis in the IDE itself. You want the process to be transparent, in an SEI Level 2 sort of way.
I used to use ObjecTime, and it added random stuff to its C++/'C' code generation process that meant you were never fully SEI Level 2. We had to keep a Golden Build machine alive because of it.
I worked on a project about a year ago on a TI TMS470M using CCS and thought it was pretty nice. It had live RAM view which was really useful for the project I was working on at the time and it was stable.
my dream for the beagle bone was to be able to develop for the PRU (and why not cpu) from within the very linux distro running on the beagle itself.
just give me a gcc and header files.
all those IDEs will do nothing other than drive away novice and experienced devs alike. only the ones that evaluated every other option and still think you hardware is the best will stick around. and for the beagle, a fully hobbyist board with no dream of being used in a product, that amounts to nobody.
Oh god! Ack, ew, retch.
I've had to use CCS a few years ago, and it was a buggy monstrosity. I don't understand why silicon vendors have to wrap their dev tools into such horrid IDEs. One reason I loved working with AVRs is that I could get a gcc-like interface, so that I knew exactly which options and parameters were used rather than some godforsaken IDE do some magic for me and get in my way. Having to hunt down options in modal windows and tabs is enough to make my blood boil just thinking about it.
Embedded development requires very precise control and knowledge about what you're doing, and IDEs more often than not get in the way of doing that.