[dcbrown]

Team 1073 was one of the beta-test teams that had the privilege to play with EasyC during school vacation. We broke into two groups with 1 mentor and 2-3 students in each group.

One group got the motors/joystick/optical wheel encoders up in running. It was real easy and the interface was very intuitive to use. We ran into a problem where we wanted to pass arguments to a #define macro and couldn't through the globals menu... so just used the add user code which allows you to type in anything you want.

The 2nd group used the built in camera code to find and track a tetra (ok, the mentor's shirt too). At the end of the day, the camera was coupled into the motors and did a rudamentory follow the mentor around the room. Our robot is somewhat unstable (spins real easily), but it managed pretty well.

We ran the tool in "Pro" menu mode.

That was after 5 hours of work. It tooks us many days last year to get to the same point in that we had to write the interrupt routines and device driver specifics for each of the sensors used.

Experienced programmers will likely hate it. As a mentor I love it because it removes all the syntax and much of the structure of the program from the novice programmers interaction and you just concentrate on the algorithm instead. It was much easier, as a mentor, guiding someone through the steps of developing routines and robot code via the visual interface than via a text editor. Seeing the result of our actions as regular text C in the side window allowed talking points and discussions.

EasyC has lots of built in drivers for stuff, but I could see a point at which the environment might
a) become unwieldy as groups try to collaborate on a large & growing set of code/modules/routines and
b) become difficult to get around limitations either within the existing set of device drivers or user written ones.

Only time and experience will tell whether the above actually happens or not.
We expect to lean heavily on EasyC this year to help boost our programmers experience base. We might consider then porting the code to MPLAB at some future point, but they'd have to be a compelling reason to do so.

Regards,
DCBrown
Team 1073
Controls/Electronics Mentor