ROBOTC 3.5 Beta now live!

Just wanted to give everyone a heads up, ROBOTC 3.5 Beta is now live. This is the Beta for the 3.5 version that will launch on September 7th. We have a blog post up with a listing of full features and download links here:

Please note that this is still in the Beta stage, and as such may contain unforeseen errors (it’s why we test these things so rigorously, after all). While we do appreciate any and all feedback from the community, we do not recommend using the 3.5 Beta in competitions. You have been warned :slight_smile:

Also please note that PID control and targeting with the integrated motor encoders is still under developement and will be included with the September 7th release.

Happy coding and remember: Program Smart!

Edit: This is an update that is free for all current ROBOTC 3.x licensed users.

To add to John’s comments. I’ve tested the beta slightly over the last few days and there are some differences in the way certain things are now done due to the availability of pointers, a certain amount of my old code does not compile without modification. I will have a closer look this weekend and make some recommendations next week as to the best approach to address the differences.

Looks good! I must say that with pointers, recursion, and the local-variables monitor, that makes life a lot easier.

Hmm… could you elaborate? (or if you’d prefer after you do your testing)

Is there a list of all the changes made in RobotC? I can’t find any.

Full ANSI-C support to support pointers, recursion, and stacks with an updated compiler and updated robot firmware.
New and Updated Debugger Windows:
    “Local Variables” to monitor variables in the current task or function.
    (Note: Local variables are only available when your program is suspended)
    “Global Variables” to monitor variables available to your entire program.
    “Call Stacks” to monitor function calls in the currently selected task.
Updated Documentation and Wiki ( – Still in progress!
Support for Standard C commands – sprintf(), sscanf(), support for character arrays, unsigned variables, etc.
Support for the Arduino family of controllers (Uno, Mega, Mega 2560) with future support and expanded functionality for the Arduino Leonardo and Due controllers.
Updated Robot Virtual Worlds support to include additional sensors and motors.
Improved Robot Virtual Worlds performance to simulate more realistic physics and robot behaviors.
Support for the new MATRIX building system with the NXT.
Many general enhancements and bug fixes – more in-depth change log to come with the ROBOTC 3.5 official release.

That’s the majority of them, there are some major and minor bug fixes as well. I’ll check with the dev team and see if I can get a full listing for you.

Passing strings to functions is not working, probably need to use char * from now on, don’t know yet. For example, this would have worked before.

#pragma config(UART_Usage, UART1, uartVEXLCD, baudRate19200, IOPins, None, None)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

void PrintToLcd( string s )
    displayLCDPos(1, 0);

task main()
    bLCDBacklight = true;

    PrintToLcd( "hello " );

But to be honest I have not had time to really evaluate the new version yet, just been too busy.

awesome, when is the new version of robot c due to be released ???

It was in the original post.

One thing I did forget to mention (but it’s in the blog); this is an major update, not a full-fledged new release. Meaning, if you have a licensed copy of ROBOTC 3.x you will get the update for free. I will update the OP with this information.

Outstanding! Cann’t wait to put it to test.

“Full ANSI-C support to support pointers, recursion, and stacks with an updated compiler and updated robot firmware.”
Function pointers don’t seem to be supported in RobotC yet, so it doesn’t seem to have Full ANSI-C support for pointers.

Aside from the full listing of new features, I’d like to have a list of ANSI-C features that aren’t supported yet before the official version of RobotC 3.5 is out. That way, if I decide to use RobotC, I could move my EasyC code to RobotC without any suprises.

sorry … what u get when u skim read …

Pointers to functions are not supported.

Most other things are but “standard” code will not port over without some modifications, for example, as yet there is no automatic conversion of complex variables to pointers, this will crash the cortex.

char  myarray[20];
sprintf( myarray, "This is myarray ");

This works.

char  myarray[20];
sprintf( &(myarray[0]), "This is myarray");

Remember this is still a beta release so give CMU a chance to address these issues. I will release some code showing some extreme pointer use perhaps later today.

Any information about when v3.5 will be out? Just wondering; I was hoping that we could start playing around with the PID functions and all that fun stuff at our meeting a bit later today.


It was released this morning.

I don’t see any support for PID with the integrated motor encoders. :frowning:

I am so excited that RobotC finally has pointer support, it will make some of the code I was writing before so much more straightforward.

Are there any plans to have support for function pointers any time in the future?

I’m sure John will give you the official answer, however, my understanding is that there are no plans for this in the near future. In other words, don’t expect them for this season.

One minor bug that I’ve found is that there is an issue with const strings and LCD display. For example, this does not work.

    displayLCDString(0, 0, "Hit button to   ");
    displayLCDString(1, 0, "continue...     ");

Short term workaround is to assign to a string as follows.

    string s  = "Hit button to   ";
    displayLCDString(0, 0, s);
    s = "continue...     ";
    displayLCDString(1, 0, s);

I’m sure that will be fixed soon.

On Embedded Systems, with the Compilers that directly targeting the hardware with the Harvard Architecture, this issue occurs because the ( string ) Constant is kept in different memory than the ( string ) Variable. e.g. Flash or (E)(E)PROM verses RAM.

The Function like [FONT=“Courier New”]displayLCDString( … );[/FONT] is expecting the Data in a given Bank when it really is another Bank.

The Keil C51 compiler uses the [FONT=“Courier New”]code[/FONT] directive to let you declare and initialize a Value that is a Constant in the Flash Memory, rather than use up your RAM Memory.

When you invoke a Function, it must be able to determine which Memory Type your Data is in… Or you must give it a hint of which Memory Type to use.

Agreed, but it was working in all previous versions including the beta I tested on Thursday before release. displayLCDString is an overloaded intrinsic with the following definitions from RobotCIntrinsics.c

intrinsic void displayLCDString(const int nLine, const int nPos, compileConst string &sString)
intrinsic void displayLCDString(const int nLine, const int nPos, const string &sString)

It’s just broken at present, not a big deal.