I posted this in the wrong section (Unofficial answers) and its awaiting approval there. I meant to post it here, so just don’t approve or delete the last thread.
Anyway, it took me about two hours to track down a bug using EasyC because we haven’t figured out how to do any live debugging(though from what I’ve heard, it doesn’t exist.) So I was curious, those who’ve used the two applications, which is better for programming your robot in C? Actually, I should say, which one do you use and why? Because, to me, a compiler is just as important as the debugger.
I’ve looked at some RobotC programs and it looks like they butchered the C syntax or added new keywords like ‘task’. I don’t mind the change up here and there as we are programming microcontrollers and not large computer systems, but adding new keywords like task(which I assume is like a poor-mans multi-threading?) kind of frightens me. Also, I don’t see why a VeX robot would need multi-threading? I mean, how many cores does the MCU have anyway? It just seems like a way to compensate for poor code design. I have had written an entire game engine before using a single thread (and I only planned on adding another one if I encountered performance issues). I doubt I am going to have any real performance issues that can’t be fixed on the cortex. Further, I can imagine synchronizing the threads on a computer - which is hell already, synchronizing two threads on a MCU could be even worse. Would the robot’s API implement mutex or semaphore objects? How would one even go about implementing these themselves if they aren’t already implemented?
I met someone at our school’s vex meet today(a bunch of schools in our district getting together to talk about vex bots) - one of the schools has over 30 robots (which dominates ours, lol. We don’t even have one completed one yet) and the members of that team suggested that we use RobotC if we are going to program our robot using C. Can someone take an objective perspective on this? Thanks.
The debate as to which is better, EasyC or ROBOTC, depends entirely on your expectations. There are several threads that have discussed this before, I will dig out some links tomorrow if no one else does as it’s getting late.
I would say that multi tasking in an embedded environment is quite different from using multiple threads in an application running on a PC. Tasks are more about handling the issues of blocking IO than increasing performance. If you have not already done so, read through this thread I started last year, it contains some detailed explanation of ROBOTC tasks.
Thanks, that does make sense and I can relate. We typically use threads to handle blocking socket operations (well, there are other less efficient ways around it) in the PC. It just seems that on the cortex, adding multithreading adds a whole new layer of completely unneccacary complexity.
Synchronization objects, gridlocks, a whole host of bugs that could occur with the threading system alone. However, I would be interested to see how long functions like GetJoystickAnalog or SetMotor block. SetMotor shouldn’t block too much. I always assumed GetJoystickAnalog had its joystick states cached on the cortex and it was polled every couple of milliseconds but I haven’t actually looked into it - it just seems to odd to poll every time something like GetJoystickAnalog is called.
Another thing that really bugged me about RobotC is how it doesn’t let you have a project with multiple source\header files. As soon as I came to this realization, I decided I would rather write in native assembly than work in RobotC (but maybe I am mistaken and there is something I have missed in RobotC). I could not live with myself if I used the include directive on a .c source file unfortunately. Is there any particular reason RobotC doesn’t support the linking of object files?
Thanks for your reply and I look forward to other responses. One question I really want answered is:
Is there any live debugging support for easyC?
Err, actually, just to throw one more in there, does EasyC let us link any resources to the code. For example, would we be able to upload a heightmap into the robot and then programatically process it? I’m not expecting a filesystem or anything, but some way to retrieve a pointer to the base a particular piece of data we’ve uploaded into the cortex would be sufficient.
Sorry if I am being a bit ignorant. As you already know, this is my first time programming a Vex bot and I can’t say I have much experience programming microcontrollers.
edit
Also, I admire the fact that RobotC runs our code in a virtual machine. Though, I really wish they did more with this. For example, why must they use C? They could implement something like C#, utilize the fact that its a managed environment and implement garbage collectors etc. (not sure if the processor would run well with that though. Hmm, just a thought…)
One thing to remember is the intended audience for these two development systems. Most users are first time programmers who are still learning the ropes and struggling with basic syntax.
When I evaluated the two last year my first reaction was much the same as yours, ROBOTC is a subset of C and leaves out many of the capabilities I normally use. I’m thinking pointers, recursion, initialized structures, things like that. EasyC on the other hand is using the gcc-arm toolchain under the hood so these limitations do not exist. I chose to primarily use ROBOTC for two main reasons, the real time debugger which allows all systems variables, motors, sensors and many other things to be viewed when the code is running. Secondly the fact that it is running a RTOS and therefore allows different tasks to be running simultaneously. I also reverse engineered much of the communications protocol for both the serial and USB interfaces, this allowed me to write my own debugging front end which has similar but slightly different functionality to the built in debugger. I posted some screenshots of an early version here, it’s been developed a little more since then but is still not publicly available.
It’s also worth remembering that the cortex is quite simple in as much as it only controls 10 motors and has a limited number of sensor inputs. Most robots (for the last two years anyway) can be broken down into drive system, lift/arm system and intake. Add a few pots, encoders, switches and perhaps a more sophisticated sensor such as a gyro and that’s it. Code to control all this is not going to push the limits of either development system. The code for one of the more famous robots from last year when exported as text is only about 2500 lines, a fraction of some of the commercial code I work on. Because of the relative simplicity of the code I can deal with the shortcomings of ROBOTC and simply change my coding style to take advantage of it’s strengths while avoiding it’s limitations.
It doesn’t really add too much complexity and in many ways makes the code easier. For example, code controlling the drive can be completely separated from code controlling the lift/arm and intake. Monitoring a gyro as a tilt sensor or an emergency stop button can be running effectively as a background task and kept nicely out of the way. I see tasks in ROBOTC much more like processes under unix where each has it’s own job to do and can run independently.
Yes, it really only compiles one file, makes using libraries hard.
I don’t know the answer here for EasyC but ROBOTC has a file system of sorts, you can store files of other types on the cortex but support for this is currently very limited.
This is also a plus, ROBOTC has an emulator built in for testing code under windows. They also have the “virtual worlds” add on which lets you write code to control a virtual robot in a 3D environment.
I am Not an Expert, but I am familiar with this topic, in General…
Tasks or Threading are for the most part a good thing… With a Single Processor with a Single Pipeline, adding Tasks or Threading is slightly less effective, because of the Overhead in the Task Switching.
But there can be multiple benefits… #1
If more Processors are added, that efficiency goes up… But Not by the Total of the Individual Processor’s Speed…
IIRC, a 1994 Study of OS/2’s SMP, reported that adding a Second Processor, only increased the overall efficiency by 40%, not %100, because of the Tasking Overhead… Since OS/2 could support up to 64 Processors, each additional processor pushed that Inefficiency Level down, because the Tasks and Threading overhead was pretty much Fixed.
On that Note, the Side Benefit of Tasks or Threading, even with One Processor, is that if more Processors are added in the future, Your Code will automatically take advantage of them… Minimal to No rewrites are needed… Basically, Future Proofing your Program…
#2
To Prevent Sequential Execution of and Blocking of a Process, in your Own Code, you have to Create your Own Threading, Flags and Semaphores to determine What needs to be Handled and What can Wait. The Tasks and Threading provided in the Support Libraries mean that sort of Complexity can be avoided by the less experienced Programmer, but they still can take advantage of the features that it provides.
Since the Input, the Output and the Processing on your Microcontroller, might run at different Rates, Tasks and Threading let each area run at it most efficient, without inhibiting the other areas… I know that on the PIC processor used in the Vex PIC controller, a Settling Time is needed on the Analog Port Reads. You either Block Your Execution, to wait for the proper time to decode the Values, or you write your own Functions with Flags to Start the Decoding Process, and run your Main Loop until its Ready, or you use Tasks that don’t block your Main Loop, to do that for you…
Oh I thought RobotC still had pointers :C I appreciate how they tried to make it simpler, but I don’t think I can learn to adapt to C code like that. I wish they’d used a more appropriate language like C# which is built around references (I assume RobotC is as well if they don’t have any pointers?). Don’t get me wrong, I love using references, and I enjoy programmnig in managed languages, but I never appreciated something like Managed C++, I always stuck with something like C#. Managed C seems a bit more odd.
Wow, thanks for the replies guys
Oh I thought RobotC still had pointers :C I appreciate how they tried to make it simpler, but I don’t think I can learn to adapt to C code like that. I wish they’d used a more appropriate language like C# which is built around references (I assume RobotC is as well if they don’t have any pointers?). Don’t get me wrong, I love using references, and I enjoy programmnig in managed languages, but I never appreciated something like Managed C++, I always stuck with something like C#. Managed C seems a bit more odd.
Edit
Ohhh, I see what you mean by multi-threading. I thought you meant two threads working on a similiar proccess. What you’re describing is a lot more like two seperate processes running on the same machine. That actually makes a lot of sense, its not something I would do, but it does provide a neat way for you to organize your code. Looking at it this way, it actually makes a lot of sense and I can see how it would simplify the coding process.
@MarkO The conflict I have is that we probably won’t ever need another processor on the cortex and I don’t expect to see another one anytime soon. As put in jpearman’s own words:
“Code to control all this is not going to push the limits of either development system. The code for one of the more famous robots from last year when exported as text is only about 2500 lines, a fraction of some of the commercial code I work on.”
Thanks for both of your responses. If EasyC had a live debugger this would be an easy(c) choice, hmm, I’ll think about it. I wonder though, it should be very possible to implement a basic debugger for easyc. Has it just not been a priority?
Actually the Demands placed on Microcontrollers, especially the 32 Bit one, are necessitating Multi-Threading… Just look at the List of RTOS, that will run on the ARM: Click on “RTOS vendors” tab of this Page. ( The Cortex Controller has a Cortex-M3 in it. )
I am more familiar with the PIC Controller, but the SetMotor has Little to No Blocking, the Values for the Motor are sent to the Master Processor, and are Maintained by it, until the Field Controller resumes Control, or your Battery Dies, or Until you change the Value, with another Call to SetMotor. Basically, Fire and Forget…
If done right, GetJoystickAnalog should have Little to No Blocking either… A Thread should be scanning each of the Analog Ports, reading Data and waiting the Appropriate Settling Time for Each Port, then putting the Decoded Value into a Variable, that is used for the Return Value of the GetJoystickAnalog function…
RobotC is different in that it doesn’t compile to machine code… It compiles to a Byte Code… I don’t think that it compiles to an intermediate object code, therefore you can’t link in other modules… I would guess that it is a One Shot Compile to Byte Code… All or Nothing…
No, but you can add your own support… EasyC uses the GCC ARM compiler for the Back End, that means that the Gnu Debugger could possibly be brought in…
RobotC, because of the Run Time Byte Code Interrupter, most likely has “hooks” into it for Real Time Debugging… EasyC would need that at the Hardware Level, because of the Native ARM Code…
You would need to be able to Create a Binary Object, and Load it directly to a Flash Memory Block, or Add it to the End of the Program Hex File and then find it by a Tag or Headder, or by knowing the length of the Code, and looking just after the End of the Code in the Flash, to locate it…
Microcontroller are more like programming a 30 year old Apple ] or Commodore 64 ( which I have some of each and enjoy playing with them frequently… ) You have limited Memory, limited Program Storage Space, and in some cases, limited Processing Power… Buying More, RAM, ROM or Processor, in not always an option… Engineering is about Trade Offs… Here is where, “The Rubber meets the Road”…
Embedded Systems were previously done in Assembler for the given Processor… In the past 15 years, ‘C’ has become the preferred Language on 8 Bit Processors, with Assembly for the Time Critical parts… “C++” has a lot of overhead associated with it, making use of it on an 8 Bit system not very practical… With 16 Bit and 32 Bit Systems, the Processing Speed and Memory Size has made using “C++” an option, although, ‘C’ and Assembler are still very much used… Something like “C#” will happen when there is so much “spare” computing power available, it won’t matter if you wrote it in Interpretive BASIC… And people will Write in Assembler, ‘C’ and “C++”, and Blow the “C#” users out of the Water with Speed…
In any sort of System, Managed Code is fine, that’s why ADA was developed, but Garbage Collection, “won’t fly” on a Real Time System… It is better to handle your Own Garbage, or better yet, ReCycle it yourself and have No Garbage…
The “new” Raspberry PI is going to support Python for the common Programming Language… The Python Interpreter is going to do a lot of the “Garbage Collection” like stuff, plus Vectors and such…
Your Welcome… I like to talk about this kind of “stuff”…
“C#” has too much Overhead… Also it is a Micro-Soft Only Product, so until MS targets the ARM, you won’t have much of a chance to even try it… C++ is supported on the Coretx-M3, but EasyC does not have Direct Support for it… You can use the UserCode “function” to insert your own Code, but I don’t believe there is any way to controller the Compiler Switches in EasyC, so your “stuck” with how EasyC is setting up the Tool Chain…
Yes, it lets less experienced Programmers, do more complex designs…
Well, you never know… But, Multi-Threading has its place… Or you can write your own…
Not Sure… Maybe the Complexity is too difficult to easily implement at a Hardware Level… Need to find out if gdb can be easily routed over a Serial Line…
I am thinking of Tackling this Issue, now that I have a Cortex and EasyC 4.x… I am getting RobotC next… Just so I can see how easy the Debugger is to use… And make Constructive Comments to RobotC Users…
