[apalrd]

My biggest issue with the easyC graphical environment is that it isn't a good graphical environment.

Having worked with embedded C (for PIC, HCS12 and MCP55xx 16 and 32 bit controllers with various degrees of RTOS included), embedded Simulink (run through Embedded Coder and compiled as C), and RT LabVIEW (for FRC), I personally prefer the Simulink/LV graphical implementation as it represents what it happening much better than easyC does.

With easyC, I can SEE the C code right there, and know exactly what I want to type (full of tricks with typedef enums, defines, bitwise logic and such) and type it really fast, with a bunch of logic and math operations on one line. With easyC, I can SEE the code, but I can't type it, and have to search through the library to find the block I want.

The best embedded environment I ever worked with was the HCS12 embedded ECU. The development library had been extended (internally) to include a basic RTOS, with interrupt-based CAN message handling and pre-emptive scheduling. The best part was, that since it was developed internally, I could pull down the source of the RTOS from SVN and see exactly how the library did something if I questioned how it did something, or if I had a big issue, I could just change it in the library (and if it was REALLY big, I could email the guy who wrote it and ask him about it). The easyC library is very black-box to me, and I don't like the inability to change things. There are many things to me which would be much easier for me to implement in the hardware interrupts (such as encoder speed handling), but I can't because I can't modify the library code.

That said, RobotC isn't a lot better on the black-box issue. I like the environment more, though.