Jump to content
LogicWeavers

If you can't 'C' - then this

Recommended Posts

I got the Launchpad, RobG's 2.2" 240x320 Color LCD, downloaded CCS, got it all running ... realized there was no way to interactively test and debug a port pin, check a running timer, examine a memory location.  Got Energia loaded and working, better interface than CCS.  OK, let me clarify this all - CCS is great in a corporate development environment where multiple gearheads need to access, update and develop the same project, but, is total overkill for the small shop, hobbyist or student.  Energia is cool as I can control the downloads, where as CCS seems to believe it knows best and provides a very frustrating abstraction layer.  This is after all an embedded controller, not an object oriented app where an abstraction layer between data and code means anything.  All in all any development interface that does not let me access the target at all levels is simply a distraction.  You'll find most IDE writers don't actually use the IDE for work. 

 

I found a cool German group, 4e4th, with Brad Rodrigues help, ported a copy of Brad's CamelForth to the MSP430.  It's very close to the ANSI standard and has all the functions for about anything you wish to develop.  It has the standard interpreter allowing you to test code fragments, directly access the hardware, place data or code into ram or flash, twiddle a port bit.  The IDE provided by 4e4th allows you to save the session, edit the code fragments you entered, save them to disk, then, wipe the 430 flash and load the edited code file to the 430 to be compiled into the flash.  When you reboot the 430 the newly loaded program executes.  Easy as programming a Z8 in Forth with a built in ForthROM.

 

What I don't like about "C" IDEs is the abstraction layer.  It's nice not programming in code, but 'C' generated output for the 430 seems to be rather blotted.  Admitted, most apps will not use all the memory provided on a 430.  Speed, however, comes into question, not just the app but the time to code it.  I wrote a small Z8 based control app for Turner Cable that was used to measure antennae tower guys and then put paint marks on the cable where the swags are set.  Trust me, this is not easy, the twist of the cable and stretch must be calculated in.  The hardware eng on the project had three port pins connected different from the schematics.  One was signal inverted and the other two where swapped.  Because of the Forth Buffalo on the Z8 I caught the errors, it didn't therefore require getting new control cards made, I fixed it in code.  Cost me a half hour of tinkering reading and setting port pins via the keyboard, no o-scope required.  Do that in a 'C' IDE.

 

As I'm using RobG's LCD for a project, I'll put the Forth code up here when I'm done.  Let's see how big the compiled version is against the current 'C' code results.  I'm interested to see what the speed difference is also.

 

Yeah, just opened the 'Gates of Hell'. hehehe  Gentlemen, take your positions, ten paces, turn and fire, on my mark!

 

Share this post


Link to post
Share on other sites

Mattias from this forum also wrote a Forth interpreter called "mecrisp."  You can look at that if you like Forth.

 

Forth is great, but it's not always fast enough.  And, it's hard to read other people's Forth moreso than other people's C.

Share this post


Link to post
Share on other sites

I agree with @@chicken, I find your reasoning a little difficult to grasp. C compilers (strictly fully separate from C IDEs) provide no abstraction at all, and any tool kit (IAR/CCS/Energia) allows you to bypass any abstraction layer or have it not enabled by default at all.

C is essentially a "portable assembler"; C provides barely any construction (apart from libraries like stdio) that is not directly translated into machine code, how could this be more bloaty than Forth code?

Also, Energia is specifically ridden with abstractions that do not exist (up to and not including the latest version) in CCS. Do you think things like AnalogWrite() are primitives? They are not, they use a timer, interrupt handling and drive pins using PWM method. CCS/IAR on the other hand (and GCC, which is underlying to Energia) provide simple I/O mapping that is physically available in the processor like P1OUT and P2_VECTOR.

Share this post


Link to post
Share on other sites

how could this be more bloaty than Forth code?

Forth code is extremely dense, in part because it is *not* compiled.  Forth words make up multiple instruction words, quite often. Forth uses a stack, so the register operands go away.

 

I'm not saying that Forth should be used more than it is.  Most of the time, C makes more sense.  There are times, however, where Forth can be pretty useful.  There's another thread about "Bitlash," which I find to be pretty much the same old thing as a Forth interpreter.  I bet the Forth equivalent is smaller and faster, though.

Share this post


Link to post
Share on other sites

@@roadrunner84 I admire that you had a go at this :smile:

 

I think it helps the discussion to first agree on what terms like complexity, bloat, abstraction mean.

 

My personal definitions:

* complexity: what's the amount of knowledge and work required to achieve a given task

* abstraction layer: means to hide complexity from programmer, can be tools (Energia), languages (Forth), libraries..

* bloat: price paid in performance and/or effective code size to abstract complexity

 

From that perspective, Energia and Forth offer an abstraction layer to reduce the complexity of developing on MSP430 (including less complex code) at the price of an overall larger memory footprint (when including Energia core and Forth interpreter) and less powerful tools (e.g. no integrated debugger, no direct access to compiler options and output, cumbersome management of projects spanning many files, ..).

 

This is not good or bad, it's about horses for courses (and riders!).

 

So before the next poster starts bashing CCS, please consider that there are many like me, who find it a great and very productive IDE. Yes, even within the limits of the free version - so far I'm more concerned about running out of MSP430's scarce RAM than the 16K limit of the compiler.

Share this post


Link to post
Share on other sites
From that perspective, Energia and Forth offer an abstraction layer to reduce the complexity of developing on MSP430 (including less complex code) at the price of an overall larger memory footprint (when including Energia core and Forth interpreter) and less powerful tools (e.g. no integrated debugger, no direct access to compiler options and output, cumbersome management of projects spanning many files, ..).

Consider that these aspects are twofold per piece, since both the IDE can be bloated as well as the embedded abstraction layer.

In this case you're saying that the embedded bloat of Energia comes with less features in the IDE. These two are not correlated, except for design philosophy. Energia aims to be easy and simple to learn, as a result (and because of the difficulty to integrate it nicely with the IDE) Energia lacks support for online debugging. This is in no matter related to the simplicity provided by the Sketch/Wiring abstraction layer, since Energia is plain and simple C++, but with some nice libraries to allow you to access MSP430 hardware at a little higher level.

CCS now supports running and importing Energia sketches. However, CCS does also allow online debugging. I am not sure whether CCS allows debugging while in "Energia mode", but there is no technical reason it could not. The only thing is that a user may be confronted with Energia's internals during debugging, which could confuse sketchers.

Share this post


Link to post
Share on other sites

Consider that these aspects are twofold per piece, since both the IDE can be bloated as well as the embedded abstraction layer.

 

Good point about IDE bloat - which often is a symptom of feature-creep, i.e. overwhelming amount functionality crippling the basic operation of a tool. I'm happy with the CCS GUI, but it definitely suffers from installation bloat :smile:

Share this post


Link to post
Share on other sites

Good point about IDE bloat - which often is a symptom of feature-creep, i.e. overwhelming amount functionality crippling the basic operation of a tool. I'm happy with the CCS GUI, but it definitely suffers from installation bloat :smile:

 

IDE's are bloat by definition.  Just let me type "cc" at the command line and I'll be happy :-)

Share this post


Link to post
Share on other sites

IDE's are bloat by definition.  Just let me type "cc" at the command line and I'll be happy :smile:

When llvm+clang makes it to embedded, you might change your mind.  But for now I agree that IDE's don't offer a huge amount of improvement over command line tools.  Inline code debugging is nice, but GDB isn't so bad either.  The main argument I have for IDE-based projects is simply that I can transfer the project to someone else, and I know that I won't have as many questions to answer.

Share this post


Link to post
Share on other sites

When llvm+clang makes it to embedded, you might change your mind.  But for now I agree that IDE's don't offer a huge amount of improvement over command line tools.  Inline code debugging is nice, but GDB isn't so bad either.  The main argument I have for IDE-based projects is simply that I can transfer the project to someone else, and I know that I won't have as many questions to answer.

Haaaaaaa, Old guys like me don't like to ask many questions! How nice it is to have a hammer and bug button on your IDE to experience some 1 else's code working in a Flash...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×