Observations moving from easyC to ROBOTC

I formerly developed Windows desktop applications with AutoItScript.com. I used easyC for the entire first year of my VEX programming. I have since moved to ROBOTC (more on that at bottom of post). Below are my observations of both “studios”, if you will.

  1. easyC has a smaller set of functionality that can be added to user programs, BUT that smaller set is documented very, very well.

  2. ROBOTC has a larger feature set, but the documentation is poor. (Note: the forums are very helpful.)

  3. easyC is easier to use for beginners. Those VEX programmers coming from a more traditional IDE would be far more comfortable with ROBOTC.

  4. ROBOTC has a more open platform, meaning system-included files can be read, analyzed, and (I believe) edited entirely at the programmer’s discretion.

  5. Because easyC is more closed and restricted, (theoretically) the possibility of programmer error is reduced.

  6. ROBOTC has a FAR faster compile and download time, as in 3-4 seconds for a large program. I think this is due in part to their code optimizer, which can trim hundreds of unneeded bytes off of a program. easyC can take anywhere from 10-30 seconds to compile and download even an small program, although I understand this has been improved in recent versions.

  7. It is easier to share ROBOTC code, because it’s text-based. With easyC projects, you essentially must zip the entire project.

  8. I am aware of the text-based editing capability of easyC, but ROBOTC (as mentioned) has a larger feature set to begin with.

  9. ROBOTC has (simulated) multi-tasking support.

  10. I understand easyC is more expensive.

  11. ROBOTC has an excellent debugger.

  12. easyC has a graphical display transmission from robot to PC. Interesting, but I have yet to find a practical use for it…

I prefer ROBOTC and I plan to use it for the rest of my VEX Robotics programming. However, for people who have never written a line of code in their lives (and VEX programmers like this do exist), I would recommend easyC.

Regarding my ROBOTC experience: I wrote a test program for the prototype we made with these wheels. It was working in maybe 15 minutes. I then took a two-week vacation up in the mountains, brought the team’s laptop (with ROBOTC installed), and coded for maybe 3-4 hours a day. In those two weeks, I completed both header files linked in my signature. That is the sum total of my ROBOTC experience.

I mean no offense to either platform or its users. These are solely my opinions based on my experience with both.

For those future viewers of this thread:
Both ROBOTC and easyC are fantastic programs, and both offer free trials for those deciding which to use.


Some feedback for you

EasyC uses a traditional compiler model under the hood. It is based on the Sourcery C++ compiler from Mentor Graphics. Intelitek have created a library of functions for the cortex which, along with standard C libraries, your program is linked with to produce a binary that is downloaded. ROBOTC on the other hand is based on a virtual machine model. The ROBOTC firmware is downloaded once and includes the functionality that your code uses as well as the debugging, file system and communications support. The ROBOTC program you write is compiled to byte code (a sort of machine code that has been defined by CMU), this is a much smaller amount of data and downloads much faster. The use of a VM allows ROBOTC to be compatible with other robot controllers as well as have the emulation functionality under windows.

True until you start using “user functions” and then things like pointers, it’s very easy to crash EasyC.

Why do you say simulated? There are many flavors of multi-tasking but all of them when running on a single core processor are illusions, the processor can only do one thing at a time.

Same price for a single user perpetual license (well $5 difference through VEX).

Both development environments can achieve the same results when used for a competition robot. I can do things with EasyC that will never be possible in ROBOTC as we have no ability to change the functions provided by the VM (for example, I added support for the sound output that Intelitek still has not done for us). With EasyC you have all of the features (and issues) of a standard C compiler, ROBOTC is not a full implementation of the C language which can be frustrating at times. ROBOTC does have better debugging support and I find the multi-tasking to be a valuable feature as I don’t have the time or energy to add that functionality to EasyC.

So as JVN said, new programmers should evaluate both and choose the one they feel most comfortable with to create the programs they need, remember both are just tools and are a means to an end.

That’s what I meant. It’s not true multitasking, it just appears to be so, i.e. simulated.

I should note that the LCD header file in my signature was originally (poorly) implemented with ROBOTC. Rather than a true background task, I just inserted a call to the updater function in every loop. Generally this allowed it to update often enough to be acceptable, but you can imagine the issues.

I personally prefer ROBOTC, but that’s just me. I may be a bit biased :slight_smile:


There is one point I would like to touch on that WCHS hit right on the head; our documentation is still a work in progress. That being said, it is something we realize could use some improvement and are working hard to correct. There’s a lot of data that needs going through and it’s going to take some time, but you, the users, deserve it.

On that note, if you anyone sees or comes across any errors, flaws, typos, crashes, bugs, or odd behavior in ROBOTC or any of our related community tools (forum, wiki, etc), please do NOT hesitate to let me or one of the other ROBOTC guys know. We take these things seriously and are constantly trying to perfect our program.

The good news, though, is that we do have several resources in place (such as our forums, wiki, and online curriculum) that are designed to help new and older programmers alike. We are continually updating those as well, so check back often.

Forums: http://www.robotc.net/forums/viewforum.php?f=11
Wiki: http://www.robotc.net/wiki/Main_Page
Curriculum (there is also a set for the PIC, it’s under the Education tab at the top): [http://www.robotc.net/education/curriculum/cortex/

Thank you all for all you do, and keep up the good work (we appreciate it).

John](http://www.robotc.net/education/curriculum/cortex/ )

Are you referring to the online window? Because if you are, then boy do I have a list of practical uses for you.

I am not referring to the online window. I do like that window, myself, but similar capabilities are also in ROBOTC.

I was referring to the graphical display, which is contained in the loader next to the terminal tab. The robot can send frames and text to be displayed within the tab.

Something about EasyC that I found suprisingly useful is the blocks. I write all my functions with the text editor and then make it so that my teammates can drag 'n drop them with blocks without any programming knowledge. This, I think, is an incredible advantage. With this, I can also make simple routines in a matter of minutes and it ends up easily readable by anyone. It allows me to involve everyone in something that would normally be a very solitary task.

Also, being a C programmer, I prefer writing code in pure C. RobotC’s differences with C are sometimes frustrating. I’ve already found myself using several features that are only available in pure C.

Interesting point of view on easyC. I have only used the 7-day trials on my home computer, but I’ve found easyC really difficult and slow to use. That could have been my lack of experience with it though. Coming from someone who has learnt a variety of programming languages, C, C++, C#, Java, Javascript, HTML, python, php, blitz, ect., I found adapting to RobotC fairly easy, but that could just be me.

The way I’ve gotten around my teammates lack-of-programming-knowledge before is creating functions my self that are easily readable and easily editable by my teammates. For instance, I could write “DriveForward(1000)” and they would understand that fairly easily. In fact, I couldn’t make it to the last competition, so I had the senior on the team program his own autonomous run the day before the competition who had never programmed before.

That is a notable difference and I can understand that being a frustration. However, I have never actually written pure C, so I have no expectations.

I have had a similar experience.

None of my team-mates are interested in writing any code, whatsoever. You, sir, are lucky.

I’m a no-life programmer :cool:; I can get to all of the events. No problem there. :smiley:

I’m intrigued. Are you writing an IDE? :eek:

Drat you still quoted that haha. I edited that out of my last post because I had second thoughts of posting something like that when I remembered someone saying “when you have a good idea, just shut up!” haha. But no it’s not an IDE, and I don’t believe it’s been done in Vex before. :smiley:

Typically mine aren’t either, but they’ll occasionally walk over and ask what I’m up to, and it’s easier to explain to them whats going on with the code that way. Also if I ever need to debug something, I’ll have someone at the computer editing encoder values, while I’m at the robot fixing something up.

What exactly do you mean? I use EasyC’s text editor mode, and I’ve found the API to cover just about everything I need.

easyC has spotty LCD support compared to ROBOTC. One feature of my LCD.h is scrolling text. The algorithm is actually very simple, but it requires being able to draw one character on the LCD at a particular location. I admit (after some consideration) that this could be done by tacking on one character at a time onto a temp string variable, then updating the LCD all at once, but IMHO it’s more elegant to do it one character at a time. You don’t need the temp variable that way.

One other item that constantly irritated me when I was working with easyC is the ability to display only up to one variable at a time on the LCD. (This may not apply to the text editor; I’ve never tried that function in there.) My LCD.h code displays 3 (again, by drawing characters on screen at location X).

Also, ROBOTC has pseudo-multitasking, which makes certain features easier to implement. For instance (back to LCD.h), I included a background task which displays the running time, competition status, and battery voltages for main battery, power expander, and backup battery.

It’s started once and runs for the rest of the program. (Naturally, it can be paused as needed.)

easyC does not have native sound support.

I didn’t see any serial link functions in the function tree, but I may be wrong.

ROBOTC has far better string support.

I can’t think of any other functional differences ATM…

You just add them in the Set Display Text window. For example, two variables.


Please stop calling it Pseudo or simulated, it’s real multi-tasking implemented in a similar way to many other RTOS such as FreeRTOS, VxWorks, Kadak AMX etc. slightly less featured in that it does not include things like message passing but in terms of the task scheduler it’s perfectly OK.

True, but it’s coming and I posted an interim library.

They are there but I’ve never tried to use them, from API.h

//------------------ Serial Port ------------------------------------------------------
#define USART_WORD_LENGTH_8B ((unsigned short)0x0000)
#define USART_WORD_LENGTH_9B ((unsigned short)0x1000)

#define USART_STOP_BITS_1 ((unsigned short)0x0000)
#define USART_STOP_BITS_0_5 ((unsigned short)0x1000)
#define USART_STOP_BITS_2 ((unsigned short)0x2000)
#define USART_STOP_BITS_1_5 ((unsigned short)0x3000)

#define USART_PARITY_NO ((unsigned short)0x0000)
#define USART_PARITY_EVEN ((unsigned short)0x0400)
#define USART_PARITY_ODD ((unsigned short)0x0600)

#define USART_HARDWARE_FLOW_CONTROL_NONE ((unsigned short)0x0000)
#define USART_HARDWARE_FLOW_CONTROL_RTS ((unsigned short)0x0100)
#define USART_HARDWARE_FLOW_CONTROL_CTS ((unsigned short)0x0200)
#define USART_HARDWARE_FLOW_CONTROL_RTS_CTS ((unsigned short)0x0300)

#define USART_MODE_RX ((unsigned short)0x0004)
#define USART_MODE_TX ((unsigned short)0x0008)

#define RX_QUEUE_SIZE 64
#define TX_QUEUE_SIZE 64

void OpenSerialPort(unsigned char ucPort, unsigned long ulBaudRate);
void OpenSerialPortEx(unsigned char ucPort, unsigned long ulBaudRate,
unsigned short usWordLength,
unsigned short usStopBits,
unsigned short usParity,
unsigned short usHardwareFlowControl,
unsigned short usMode);
unsigned char ReadSerialPort(unsigned char ucPort);
void WriteSerialPort(unsigned char ucPort, char cData);
unsigned char GetSerialPortByteCount(unsigned char ucPort);

Again, not true, you have everything that a normal C dev system has, strlen, strcpy etc.

Both Easy C and Robot C may be used to code a champion robot - but for any novice programmers Robot C is the way to go. Being able to type your code and easily integrate multiple files will really speed up development. When you need to write/change multiple proportional control loops and autonomous routines, Easy C may begin to feel congested just because you must double click on each line of code to edit.

Again, you won’t lose functionality with Easy C - it will just take a bit longer to write your code.

That is the Default Mode of Easy C Pro ( 3.x ) and Easy C 4.x, but you can write Code “free form” as well…

Easy C Pro ( PIC )
Options–>Add New File to Project: ( radio button select .C or .H )

Easy C 4.x ( Cortex )
Project–>Add New File to Project: ( radio button select .C or .H )

Ah. Thanks for the tip!

Yes, I did read about that somewhere on the forums.

I stand corrected.

Where are they in the function tree? I didn’t see them. :confused:

EasyC supports the C standard library, that’s one of the main reasons I like it.

Oh. Well, I suppose that counts. :rolleyes: