View Single Post
  #20   Spotlight this post!  
Unread 09-02-2007, 00:56
Shinigami2057 Shinigami2057 is offline
Slackware Is Your New God (Mentor)
AKA: Harry Bock
FRC #1350 (Rambots)
Team Role: Programmer
 
Join Date: Oct 2006
Rookie Year: 2006
Location: Johnston, RI
Posts: 106
Shinigami2057 is just really niceShinigami2057 is just really niceShinigami2057 is just really niceShinigami2057 is just really niceShinigami2057 is just really nice
Re: What is Easy C good for?

Quote:
Originally Posted by Astronouth7303 View Post
I have to weigh in on the con side, here.

I have, in fact, used EasyC. I can see its usefulness at a high level. But as you start drilling down, it becomes more cumbersome.

Examples:
Math - Everything has to be in temporary variables or you inline C code.

Preprocessing - I didn't look much into this, but I'm not sure about EasyC's preprocessor support. I use it extensively, and, frankly, I'm not sure I could do in EasyC what I do in text editors (again, inline C doesn't count).

Inline Assembly - I have, in fact, briefly considered this for real robot code from time to time. I somehow doubt that EasyC supports it.

Now, comparing EasyC to MPLAB is not really a fair assessment. MPLAB is some of the worst software I have had to the misfortune of working with (along with MCC18, CoreChart, and IFI Loader). Comparing EasyC to, say, a well-equipped copy of Eclipse (or some of the other IDE). I doubt EasyC could handle Subversion, compiling for multiple controllers, concurrently open projects, or the search capabilities (Where is this thing declared and defined? Where do I reference it?). That's not even getting into the multiple languages Eclipse can support (I have used python in my FIRST code, and for the Makefile).

The only way I saw myself using EasyC was to write the high-level code and writing the actual hardware "drivers" in a separate library in C.

Of course, this is also with 3 years of code behind me. I don't have a "library", per se, but I do have a set of macros, functions, etc. that I reuse, plus a "standard" code layout. I mean, how many different ways can you implement a PID loop?

As for the "EasyC challenge", there's a difference between "can do in EasyC", "can do easily in EasyC", and "have to use inline C code to do it". eg, You can do some sick stuff in the preprocessor:
Code:
#define LINE(txt) #txt "\r\n"
#define PID_VARS(prefix) int prefix##_pid_p, prefix##_pid_d; static int prefix##_pid_i
#define MSG(fmt) #__FILE__ ":" #__LINE__ ": " #fmt "\r\n"
I have considered using all of these in FIRST code (except the last one, but I really should). (OT: Does MCC18 support variadic macros?)

Please correct me if I'm wrong, here.

My $.02
Great points.

And yes, I believe MCC18 should support them, as it uses the GNU cpp (look for the source code, it comes with every install ).
__________________
One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs.