EasyC knowledge translated to RobotC

Hi everyone,
After searching extensively I am still unable to find an answer so I am just going to ask. -
The last three years I have used EasyC. Next year I would like to give RobotC a try, but I am wondering how similar they are. I.E.- I know how to program most sensors in EasyC, but I am not too sure how well that knowledge will translate. Jij’s Guide to RobotC has been a great help, but I am wondering if I will have to learn a lot to program in RobotC.

The second part of my question is: Does anyone have screenshots of programming RobotC? Like the sensors and user functions and everything, what the programming window looks like.
THANKS!!!

You can rewrite most of the code you’ve written in EasyC in RobotC so you will not have to learn a lot to use RobotC.

Here’s a quick screenshot:
http://i40.tinypic.com/35asnki.png

This guide has lots of ROBOTC code examples. I haven’t actually used the code, because I haven’t purchased ROBOTC yet. But I plan to use the guide when I get around to it. Another project for another day…

You can learn the basics from this document: http://www.robotc.net/education/curriculum/vex/pdfs/chapter_document_compilation.pdf

Unless you’ve really gotten down deep with easyC, the two will transfer quite well. However, if you’ve gotten deep into the subject of C programming - you will find some design-patterns will not transfer smoothly to robotC.

EasyC is unmanaged where as RobotC is managed - this introduces some rather dramatic changes in both the method of programmig & the functionalty of the code. Though you probably wont ever need to know of or even reach the limitations imposed by a manged environment, you should know there are some very annoying limitations in RobotC’s managed environment in particular.

In robotC, you give up:
-Recursive calling(all ‘local’ variables are declared as (virtually) static local variables - they are treated as global variables by the compiler, opposed EasyC which stores these variables on the stack-frame)
-String length limits (20 chars)

  • Max of 160 allowed sub-routines r functions (you probably wont hit this limit - but it is very annoying to reach - basically throw using more than one simple library out the window)
    -No pointers or native dynamic memory allocation (there are hacky ways around dynamic memory allocation)
    -No linker exists for multiple source files, so you have to include the source files
    -IDE for managing multiple source files seems rather messy when compared to easyC
    -No linking to other libraries.
    -I find a lot of RobotC code tends to stick in one source file and this creates rather messy and cryptic code - though comments do help in large modules.

However RobotC is much easier to program in versus programming in C. While what is done in RobotC is definitely doable in easyC - it would take a little more work to do somethings like multi-threading or OOP in easyC. Though the way RobotC implements multi-threading makes it very prone to misuse (Treat them as seperate programs and not threads in the same module)

Most people I have talked to have trouble looking past the block-editor and exploring the code text editor of easyc where they are able to freely program code in C.

Being experienced in C, C++ and C# .Net, I tend to stick towards C as it allows me to apply a lot of what I already know; beginners (rather, I should say, people introduced to programming via vex) tend to preffer robotC.

Basically,

For common use:
-Virtually no difference at all. I like the API based interface to the sensors found in easyC.

Speaking more technically:
RobotC:
-IDE a little cluttered (personal preference.)
-Virtual simulator good for testing code.
-Debugger makes it much easier to debug code.
-Cheaper than EasyC, at roughly $49 (opposed to easyc, $75)
-MUCH easier to implement multi-threading (though it is prone to misuse, see above)
-Subject to all the restrictions above.

EasyC:
-More difficult, but a Drag & Drop interface is accessible for new-comers.
-More control over the cortex
-IDE is very well organized and is very easily adaptable to if you’ve used something like MSVC++
-Implements anything you’d ever use in the C standard library, so if you’ve worked with C before, you’ll be very comfortable with the environment.
-Unmanaged
-Void of the above limitations
-Does not have classes - though an OOP system is not hard to implement with a bit of practice.
-Supports linking and compiling of object files.
-Potential for multi-threading, but not implemented via the API as seen in RobotC. One would have to program the interrupt timer. (keeping in mind 99.99% of the time, if you know how to and you can, you should never multi-thread)
-No debugger (this is a very big con for easyC.), HOWEVER, doing software based tests by literally plugging this code in to a C++ or C compiler is very easy to do and monitor its performance. I usually write the code in to Microsoft Visual C++ 2010 IDE, compile & resolve any logic errors and then load it in to my easyc project.

^^ After reading that post, I might want to look into easyC… :rolleyes: Thanks for the info!

//Andrew