easyC vs Hardcoding

To me, easyC seems to be sufficient,

So could anyone tell me the advantages/disadvantages of each?

and what you can do in C, but not easyC?

Last year, Team 228 used WPILib, which is the back-end behind EasyC to do all of our programming for our FRC robot. While we used MPLAB as the primary editor to write our code, you can also use the built-in text editor in EasyC PRO or use Eclipse.

What we really loved about it is the speed at which you can write code, and how quickly we could get very sophisticated code running on our robot. We had closed loop feedback for everything on our robot, with PID control on our elevator and wrist. We used an accelerometer, two gyros, two encoders, and an IR range sensor.

Here’s a video of our “drive-by” autonomous from last year:

I support EasyC and WPILib, because I would much rather see teams tackling more advanced control applications (like closed-loop (sensor) feedback), rather than “just getting their robot to work”.

But of course, if you are familiar with programming in C, and you can write everything you need there, then by all means, go ahead and “hardcode” everything.

We did all our programming in EasyC Pro last year and had a great autonomous mode. I strongly recommend it. But it should be pro not just EasyC.

The real question is: Do those that use the enhanced tools of Easy C understand the operation of the sensors that are so easy to make operational?

FIRST has been about preparing students for engineering. Granted, most students do not have the time to digest all the technical information in the datasheets to understand with 100% clarity. Most of those datasheets are precise, but every sentence counts.

This year, we are experimenting with a cross between the two. Use Easy C to verify sensor operation, then teach the future CS programmers how it relates to a C compiler without the bells and whistles. If understanding is an issue, the Easy C code may accelerate the understanding.

When the competition draws near, perhaps the switch may be made to Easy C for competitive reasons, but at least those students who desired the more in-depth programming experience will have achieved their goals of understanding.

Any novice programmers should use Easy C. Advanced programmers should swallow their pride and recognize that Easy C will make the novices look like they have been coding for years, even if they don’t comprehend the how it all works. I’m not an advocate for Easy C, but there are advantages to using it.

FIRST may be making another attempt to level the playing field for the game.

I think this is a good concern.

I have programmed them all from assembler to MPALB to EasyC Pro. EasyC takes away some of the pain so you can concentrate on the sensors. I would say many who program in MPLAB still don’t understand the sensors.

But as programs mature, more of a burden is taken off the programmer so they can concentrate on accomplishing the goal quickly. Our experience with EASYC vrs MPLAB students could be more involved because some of the heavey lifting is taken off them. Also what they learned in VEX can be transfered easier.

Based on my experience with easyC during the past week and a half: You can create code quickly using easyC, but if you’re even halfway proficient using a keyboard you can modify existing code faster without it.

It takes a very, very long time to make a simple change to a bunch of similar chunks of code in easyC. In a text editor, a find/replace is often sufficient, and when it isn’t, moving a cursor and typing a few characters is a lot faster than mousing and clicking and mousing and clicking and typing and mousing and clicking for every line to be changed.

thats why I order(yes its an order) all of our programmers to make liberal use of #defines that way they are always working with words. no numbers any where. that will cut down on 90% of find/replace.

also plan out how the algorithm is going to work before you put finger to keys.

and as far as what can be done in C that cant be done in easy C . . nothing . . nothing nothing nothing. . . dont believe me Ill email you a variatic macrothat one of our students did in EasyC(he only did it to see if he could)

yes its easier to type the individual line of code in C but for ideas its much easier to be using EasyC.

just my $.02 . .but with the strength of the American dollar these days its not worth as much as it used to.

This was a concern for earlier versions of easyC slow coding by being stuck in drag and drop mode. But, with Pro you can click on the project tab and create your own C and H files that you can type your own code in just like any other IDE. Plus you can drag blocks into the C code to help with formating of the WPILIB functions.

Okay, here’s where EasyC and I are: I used easyC, yes, it works, yes, it makes stuff happen. However, I don’t let my team (software captain here) use it. Yes, things get running faster with easyC, but you gain little if any understanding of the hardware that makes your software happen.

For example, in the pre season, software starts off by learning the architecture of an 18F series processor: the data buffers, internal peripherals, we even write a short bit of assembly code to show how your code looks in machine code (we blink an LED with two busy waits made from everybody’s favorite DECFSZ instruction, but then the programmers can say they know a little assembly when asked :smiley: ).

Also, we do about a week on binary math: handling binary fractions, how the ALU handles addition, how the hardware multiply works, bit shifting, etc. Also in the pre-season we teach all the sensors we’ve used in the past and how they’re used. Over the year’s we’ve compiled quite a library of drivers for various ‘smart’ sensors like cameras and ultrasonic sensors, so we make sure that the team understands how those drivers function, not just ‘call this and it spits out a number’.

Really, the software kids love it. And, if you take the time to teach people and you don’t tell them it’s hard, freshmen understand it just fine.

Again, I’m not claiming C is any faster than easyC, but to me it takes a lot of the learning experience out of the software.

FIRST is supposed to prepare young people for the real world of engineering. At the company where I work, I’m currently writing a very low overhead display driver for a graphics LCD display from the ground up that will go on an industrial generator control… does easyC have a pre canned function for that? Does anyone know of any companies that use easyC?

Just my 2.14 yen.


As with all aspects of FRC, teams resources vary. I give credit to those who can provide extensive pre-season training. Not all teams have the mentors, experience or time, resulting in many robots each year being “left behind” during autonomous play.

EasyC allows programmers without automation or mechanical experience to get the job done. It provides a simpler platform in which more students can participate and succeed while learning the logical flow of programming and experience how to control a machine using a computer.

The closest business associated with robotics is automation/machine building. A large portion of automation control is done using PLC’s programmed with ladder logic which is syntactically completely different from C. The logical thought process behind it though is the same. EasyC also involves this logical thought process.

A real world business will use the most efficient tool for the job. Many machines that are controlled using PLCs could be controlled with a micro controller (Like PIC)…but they’re not. Why? It’s because it is more efficient (and maintainable) to use a higher level language.

It really is not about the language being used.

Pat A. and Aaron (Her automation engineer/ automation business owner hubby)

Its also possible to write your own device drivers and hook them into the interrupt service routine to get executed.

So its possible to start with the default drivers available from EasyC and progress to replacing them with your own (this only works with PORTB interrupts, not the system clock (timer1) or RS232 driver).

I personally view easyC as a form of cheating if used by already experienced programmers and skipping out on the work a bit (This is a personal view and is not necessarily shared by team 2062). I find that it is easier to program in straight C simply because programming algorithms and operations that need to be closely timed are best programmed this way.

Also, I wouldn’t call writing in C hardcoding. I have had experience programming PIC Microcontrollers in Assembler and I tell you that that is hardcoding. C has many optimizations built in and memory management features that ASM compilers simply don’t/can’t have. Another thing: Actually learning the language that you intend to program in is more educational isn’t it?

For people who are new to programming, however, easyC is the way to go as long as an effort is made to try to migrate away from easyC. Once you learn C, C++ comes easy and then more worlds of programming are opened.

This is an interesting discussion.

I believe that easyC (or WPILib if you want to hand-write the C code) raises the level of what teams can accomplish. What it does is provides device drivers, interrupt handlers, and timer support for the sensors used on the robot. The idea is that teams can now concentrate on the “robot problem” not the “how to make a PIC chip work problem”.

The counter-argument is like writing a windows program and saying that if you don’t actually write the disk driver you are not learning how to read files. Nobody writes disk drivers except the operating system developers - and that’s a good thing! You can focus on the data *in *the files - not how to make disk heads move to the right spot on the right platter at the right time. Not that that knowledge isn’t interesting or useful - but most people just don’t need it.

By using easyC or WPIlib you are focusing on different problems, for example motor control, navigation, precise robot control, and interpretation of sensor data. And more important, the global problem you are trying to solve with your robot. These skills are transferable to any platform that you might use in the future.

Writing low level code has some general applicability, but most of those skills are specific to the PIC chip, and even more specifically to the IFI implementation of this platform.

So I’d encourage teams to spend their precious 6 weeks and two days focusing on the high level problems that FIRST gives us and use this opportunity to raise the bar on the complexity of your designs. Make your robots as creative as possible and do cool autonomous and computer assisted tele-operation functions that you might not have been able to do before.

Just my opinion.

I fully agree with you. We made it to Einstein in 2007 and one of the reasons is we concentrated on the goal of getting the job done and thus used EasyC Pro. Kids learned more about controlling the bots because they did not have to learn about insides of MPLAB.

Personally I don’t like how abstracted the interface in EasyC is. I program in a number of languages, but there are always consistent conventions I hold to in how I name things, how I use whitespace, even how I format comments. EasyC takes these and throws them right out the window. I’ve also gotten very proficient at using the keyboard for nearly all my navigation within code. being forced to point and click, to even drag, in order to do ANYTHING is annoying to me.

I’m speaking as an experienced programmer here, but I personal gets quite a bit more satisfaction out of doing things myself. It challenges me and I learn new things. With EasyC, all the difficult work has been done for me. All this discussion about “concentrating on higher logic” confuses me. That’s the easy part. I don’t feel like I really know what I’m doing until I’ve got down to the nitty gritty pieces of a system.

MPLAB for me means complete control over everything the robot does.

However, I fully endorse EasyC as a teaching tool. It’s a wonderful way to show the inexperienced how to use code to make a robot function, without being overwhelmed by single and double equals signs, parenthesis, bracket, or curly brace, and all the rest of C’s admittedly cryptic syntax.

Ahh, but if only people did write their own drivers instead of writing software on top of heap of software, with more software to talk to the other software where you could have just written a more efficient routine to work straight with the device Windows might run more like Mac speed… or better yet, Windows Vista might run at Windows XP speed… :stuck_out_tongue:

Also, if you’re plannning on entering software as a field, people don’t hire you for having great concepts for solving a problem that remains abstracted from the hardware on a piece of paper or on a blackboard. They hire you because you write the fastest way to solve the problem, and espeicially in the field of moble devices that’s what gives you the little edge over your competition… the ability to comprehend the hardware running your code. I realize that we’re talking FRC here not real life… but again… FIRST is supposed to prepare you for real life.


By “fastest way to solve the problem”, do you mean time-to-market or # of CPU clock cycles? Those are VERY different goals.

Actually, I would imagine that many mobile device designers care much more about time-to-market given their typical development cycles.

Speaking from my own experience, engineering is often about understanding the tradeoffs between different approaches. I think that having 2 options available - easyC and C - is an important part of the FIRST “education”.


I agree. Not everyone is going to be happy with EasyC and how it limits great coders.

I am a part time programmer at best. I do the project management and the autonomous mode for our team. I can help the team with EasyC since it takes away having to remember all the particulars of MPLAB. I have programmed in MPLAB but it was difficult for me being a part timer.

I feel EasyC has much growth yet, it frustrates me how it does libraries and other useful items. But it does deliver for us and allows the volunteers coming in to catch on quickly. So I think it is great we have at least two good options.

This is a serious bit of wisdom that every student should read a few times.

When I go on recruiting trips to universities to hire engineers for JPL and my group in particular, I come across way too many electronics and computer engineering majors who think Java and/or Python are all they’ll need in the real world and they’re very wrong. The real fun, money and chance for advancement goes to the engineer who wants to know how everything works and isn’t afraid to work at the hardware/software interface level.

Just another opinion.


I’ll admit it. When it comes to programming, I’m a control freak. I like being able to know what my code is doing, where it’s getting values from, and if it’s doing what I want it to do. I love EasyC for a quick-and-dirty coding tool (though from reading this thread I realize it’s much more than that), but I am hesitant to use functions that I can’t see. That’s why I currently prefer MPLAB, though I’m not a big fan of that either.