ROBOTC vs easyC confusion

I know the pros and cons of each have been discussed to death on this forum, but I’m not sure which info applies to which version. I’m considering easyC V4 and ROBOTC for the Cortex, and I’m a bit confused as to features. For instance, on this forum, it seems to come down to the fact that easyC has a visual drag-and-drop interface and text editor while ROBOT C has no visual interface but has other features such as multitasking and real-time debugging.

The product pages say different things, though. Those pages say that they both have a drag-and-drop GUI, both have multitasking, and both have real-time debugging, and that the only main difference is that ROBOTC has sound output and single-step debugging, while easyC does not.

Can someone explain to me what the actual differences are? Are those pages inaccurate? (I’m talking about this and this)


It’s hard to make an apples to apples comparison and at the end of the day comes down to personal preference as to which is considered better. They can both create software suitable for competition with the skill of the programmer being the main factor as to how successful it will be.

Both use an integrated development environment, however, when the spec says that EasyC has a drag and drop interface they are referring to the flowchart like method of entry, it looks something like this.
It is possible to revert back to traditional text entry in EasyC but it seems most do not do this.

RobotC has multitasking, EasyC does not. EasyC can create a repeating timer but (IMHO) this is not nearly as useful as the multitasking that RobotC provides.

Both are available as trials, the best thing to do is download them and do your own evaluation based on your needs and past experience.

What do you mean by multi-tasking? I’ve heard it many places, but never understood what multi-tasking in RobotC does.

One MASSIVE difference as well to note between EasyC and RobotC is that EasyC runs natively on the cortex processor while robotC uses an interpreted byte code which wastes so much processing time. This was one of many reasons why we switched from RobotC to EasyC.

Tasks are similar to subroutines/voids, but they don’t wait until they complete before moving to the next step in the program. If you wanted to raise an arm while driving forward, for example, tasks could be used to do that.


EasyC has that support, 1103 could do two things at once and he uses EasyC. My robot can do two things at once and I use EasyC. Just run the tasks through a while loop.

I think that is what you mean by multi-tasking.

Independent threads of execution. Different functionality can be separated into what are essentially independent programs sharing the processor. One task can be used for driving, another for manipulating say an arm, another handling feedback on an LCD etc.

I have to take issue with this. It is true that EasyC compiles to native STM32 assembly and RobotC is running a virtual machine that interprets byte code, however, I see no performance problems when using RobotC for control of the VEX system. There are other limitations to the cortex, for example, the very fact that RC style control is used for the majority of the motors therefore limiting their update speed to around 50Hz. Most code I write in RobotC is spending 90% of the time waiting for events to happen.

Edit: This is aimed at the cortex, the PIC may be a different case as it has far less resources.

This is classic round robin scheduling, if one of these subroutines were to wait for an event (say a limit switch or something) everything else will stop. The workaround has always been to use interrupts in the background, the closest thing to this is the repeating timer in EasyC. As I said in the first post, the skill of the programmer can overcome the limitations of both development environments as neither is perfect. True multi tasking will allow tasks to continue running even when one of them blocks waiting for IO. It really does make programming easier.

My opinions/observations:

-Drag and Drop interface with flowchart-style thingy (no good words to describe it other than flowchart-style thingy)
-Can compile in native C code
-Builds to native Cortex code - Larger downloaded code size (core libraries are linked statically, so you are always re-downloading the core library code)
-Tasking through RepeatingTimers - I’ve heard they don’t like long execution time functions (e.g. Serial stuff), so I would guess that they are essentially software interrupts. They always run at the specified interval, and are useful. I think the OS does not support preemption, but am not sure

-Drag and Drop functions into the text code
-Can compile RobotC code (C + RobotC specific stuff)
–Pragma compiler directives control IO and controller stuff
–Task structure is not part of C, but is much easier than using something native to C like pthreads, and makes sense.
–Has shown to be fully C compliant otherwise (I haven’t done an in-depth study, but everything I have used worked)
-Core libraries are essentially dynamically linked, so you don’t have to re-download them each time
-(huge) real-time debugging features are awesome. I cannot stress the usefulness of real-time debugging in embedded systems.
-(huge) Tasks with preemption and priority - Essentially a full RTOS.

I’ve (until now) been using easyC to compile actual C code (written in Notepad++), but just recently got a copy of RobotC to use. Since I never used the drag and drop editor of easyC, the more advanced features of RobotC (especially the debugger) are very useful to me.

It is important to note that asynchronous execution of things can happen in single-threaded code, using iteration counters/timers and state-machines. In fact, the old IFI FRC control system, and the MPLAB environment for the Vex PIC controller operated in only this way, and you could rely on master SPI updates to count time.

I think that jpearman summed up ROBOTC multitasking vs EasyC repeating timers pretty well. At to what multitasking should ideally be used for (at least in VEX), I would recommend reading this post on the ROBOTC forums:

I also had a whole series of posts discussing multitasking in detail a few weeks ago, best to read in order.


Alright, thanks for the info everyone.

I am not talking about driver control at all. Where I had noticed the speed difference was in the autonomous especially when we were experimenting with more complicated algorithms.