ROBOTC.net Blog  

ROBOTC News

Archive for the ‘PIC’ Category

New Time for RVW Google Hangout Today! 6pm EST!

with one comment

Google HangoutHey everyone! Just wanted to let you know we are changing the time for today’s Google Hangout webinar to 6pm EST. We will be talking about the Robot Virtual Worlds’ Level Builder and Model Importer! We hope you’re able to attend and join in on the discussion! Visit http://ROBOTC.net/hangouts to join us and watch the live video stream.

 

 

 

 

 

 

 

 

Written by Cara Friez

April 15th, 2013 at 9:11 am

Webinar – Using the RVW Curriculum Companion

with one comment

CurriculumPackWe will be LIVE at 4pm EST today with our free Robot Virtual Worlds webinar! This is the second in a five part Google + Hangout series that will take place every Monday in the month of April. Today’s topic is how to use the Robot Virtual World’s Curriculum Companion.
 
 
 
 
 
 
 
 
 
If you can’t tune in at 4pm EST, we will update this post later in the day with the YouTube recording. If you are joining us live, make sure to send us your questions …

RVW Questions

 
Video feed:



 
Check out future webinar dates below:

Written by Cara Friez

April 8th, 2013 at 2:00 pm

Sneak Preview: Robot Virtual Worlds Multiplayer Development

with 3 comments

RVW Multiplayer 01

The Robot Virtual Worlds team has been developing a multiplayer game mode, and our group was lucky enough to get a sneak peak last week (and I made sure to record the event for you!)

 

 

 

 

 

 

Check out the video from the preview:

It will work with ROBOTC, have CS2N connectivity for achievements, private rooms so only the people you invite will be allowed in, structured chat rooms, and a lot more!! Look for it to be released at the end of the summer.

What do you think? What features would you like to see included in it?

Written by Cara Friez

April 3rd, 2013 at 8:00 am

Single and Team Perpetual Licenses Now Available for Robot Virtual Worlds

with 3 comments

OperationReset3 copy

We are thrilled to announce the new Single and Team perpetual licenses available for Robot Virtual Worlds!! Previously, we only offered Classroom licenses for perpetual users, but due to user requests, we have now added Single and Team options. Read the rest of this entry »

Written by Cara Friez

March 27th, 2013 at 2:15 pm

FREE Robot Virtual Worlds Webinars on Google Hangouts

with one comment

RVW WebinarsWe understand the challenges robotics classrooms face every day in terms of cost, number of robots, batteries, and homework. That is why we created Robot Virtual Worlds (RVW). With RVW, every student can experience the same benefits of learning robots, right on their computer. RVW currently simulates popular real-world VEX, LEGO, and TETRIX robots in a 3D environment; while using the same language, ROBOTC, to program both your virtual robot and your physical robot.

To help you get started and get a better understanding of what RVW can do, we are offering five FREE webinars on Google Hangout every Monday in April at 4pm EST with project manager, Jesse Flot, and some members of his team! We will show you a brief tutorial on the specific topic of the day then take a few questions from the Google Hangout chat or on twitter using hashtag #RVWHangout.

At each webinar, we will be giving out a discount code for Robomatter, the robotics education store, and a chance to win a one-year license for ROBOTC 3.6!!! To tune in live, follow Robomatter on Google+ or visit ROBOTC.net/hangouts the day of the event (you will need a google+ account or twitter account to submit questions.)

Listed below are the specific dates with topics that we will be covering …

 


 
 

Written by Cara Friez

March 21st, 2013 at 9:25 am

Official Release of ROBOTC 3.60!

with 5 comments

ROBOTC 36

We are very excited to announce that today is the first day of Spring and …. the first day of ROBOTC 3.60! ROBOTC is the premiere robotics programming language for educational robotics and competitions. ROBOTC is a C-Based Programming Language with an Easy-to-Use Development Environment. We are really proud of this release and can’t wait to hear what you think! Remember, we could not do this without your support and feedback. We hope you’ll continue to share your comments with us, either in the forums or on our Facebook or Twitter page.
Read the rest of this entry »

Written by Cara Friez

March 20th, 2013 at 3:13 pm

ROBOTC 3.59 BETA is Here!

without comments

The ROBOTC team is happy to announce the ROBOTC 3.59.0 BETA release. We’ve made a number of enhancements and repaired a number of user issues. Some of the major updates are:

    • Added support for proxy server when activating ROBOTC.
    • Add watchdog timer support to VEX Cortex to alleviate processor crashes that can occur with static.
    • Fixed a bug in the NXT color sensor that now allows you to read individual RGB values.
    • Updated with the latest version of the 3rd party sensor drivers for NXT. (Thanks Xander!)

See below for the more detailed changelog. You can download ROBOTC 3.59.0 here!

Remember, we could not do this without your support and feedback. We hope you’ll continue to share your comments with us, either in the forums or on our Facebook or Twitter page.

3.54 to 3.59 BETA Changelog

VEX:

  • Add watchdog timer support to VEX Cortex. This will allow the VEX Cortex User Processor to “restart” automatically once the processor crashes/is halted. Useful for any potential static issue that may cause the User Processor to “crash”.
  • Change watchdog implementation from “windowed” watchdog to standard watchdog (no window, reset any time). Increase watchdog timeout to 0.75 seconds.
  • In Debugger Motors display the last motor was not always properly updated. Fixed.
  • Enable emulator for VEX PIC. Fix subsequent bug with “Motors” debugger display for VEX PIC locking up IDE when emulator is enabled; this bug should be limited to VEX PIC Emulator only.
  • VEX PIC downloading was failing when master firmware was out of date. Getting stuck in a repetitive loop that wasn’t exiting. Fixed.
  • VEX PIC was not executing user programs. Bug was that “start of flash file system VTOC” needed to be aligned on 4-byte boundary. Previous change had added a 1-byte field to the header preamble and there was not a corresponding 3-byte file added for VEX PIC. ARM platforms worked OK. This may also have broken Arduino (i.e. any 8-bit) platform).
  • Added a Conditional Compile flag for tUARTs to avoid confusion between uartOne and UART1
  • There are two separate flags for “allow any serial port for communications” — one for VEX Cortex and one for all other platforms. This was not obvious. Preferences “Environment” tab was only updating flag for non-Cortex; this has been changed to update the appropriate flag based on platform setting. The VEX Cortex flag can also be updated in the “VEX Cortex” tab.
  • User configurable UART setup was screwed up for the platforms whose “uart 0″ is fixed as non-configurable and usable only for system communications port to PC — i.e. VEX Cortex, VEX PIC. The ROBOTC IDE was storing the data in the persistent data table (at start of flash file system) offset by one entry. I.E. data for “uart 1″ on VEX Cortex was stored in “uart 2″, etc.

LEGO:

  • NXT color sensor read RGB individual values broken with pointer implementation. Change “getMemoryParmXXX” function calls to “getCommonParamaterValueXXX” function calls. Check rest of firmware for same mistake.
  • New feature for 3rd Party Sensor Driver Suite to set the two digital I/O lines on NXT sensors. Added two new sensor types (sensorCustom, sensorCustom9V) for this along with two new property intrinsic variables to set I/O line direction and values; these intrinsic variables are bit masks (2-bits) for the two lines.
  • “setPixel” intrinsic (and corresponding “clearPixel” and “invertPixel”) take “unsigned” parameters. But implementation was using “signed” parameters and not properly range checking if parameters were negative. If negative, then should do nothing. Instead they were incorrectly wring to invalid buffer address which eventually caused a firmware crash.

Arduino:

  • Fix issue for “Motors” tab for Arduino in “Motors and Sensors Setup” property sheet. Was incorrectly trying to setup “encoder information for motor”, but Arduino platform does not “associate encoder sensor with motor” — which is currently only a feature for VEX Cortex.

General:

  • Added Support for Proxy Server when activating ROBOTC – Users can set Proxy preferences under “Detailed Preferences – General – Environment”.
  • Incorrect generation of compiler error message when double pointer (i.e. “**”) is used.
  • “Print” a range of pages was not working when the starting page was not ’1′. Fixed.
  • Remove incorrect error message from error “Assignment between two different pointer types” when one side of ‘=’ is a ‘void *’.
  • Compiler was incorrectly generating error message for “Expected a pointer expression in a pointer expression with ‘++’ or ‘-+’ operand. Compiler was incorrectly checking to verify the right operand was an integer value.
  • Compiler was incorrectly generating error message for “Invalid pointer expression” in a pointer expression with ‘+’ or ‘-’ operand. One operand of the expression must be a pointer and the other operand must be an integer (without implied conversion of a pointer to an integer). Compiler was incorrectly checking for the integer — the expression incorrectly had a “!” in it!
  • Change code generation of ‘var arg’ for pointers to be consistent with standard C — i.e. the value of the pointer is placed in the argument. This may result in an additional instruction generated when argument is a ‘string’; previously RobotC got too cute trying to save this extra instruction which only worked for “%s” format codes but was broken for “%d” on a pointer.
  • In ‘sprintf” implementation for “%s” and “%p” format codes– change from  “get Address of parameter” to”get value of parameter” to match corresponding change in compiler code. Also minor cleanup of “%s” and “%p” format codes.
  • Assignment expressions of “<char * variable> = <char constant> were generating compiler error because the “<char constant>” was evaluated as a “string” type. Added code in “get expression type” to check for this and not generate error as the compiler auto converts “string” to “char *” during code generation.
  • Fixes an issue with the Live Start Page and “check for updates” that may have caused crashes.
  • Improved validation of pointer expressions. Fix bug in calculating expression type of pointer expressions like “<ptr sub-expression> + <numeric constant>”; the result was (always?) incorrectly set as “long *”? Also added check that “=” of pointer is from a pointer of the same type – otherwise generate error message.
  • Fixed consistency in implementation of “random” intrinsic property.
  • Eliminate compiler error message in constant expression evaluation of sub-expressions using “*” operator. If either of the two operands is ‘zero’ then result is zero regardless of whether the other operand is a compile time constant.
  • Do not generate additional errors — “too many parameters” specified — when procedure is “compiler generated undefined symbol”.
  • When switch between “real robots” and “emulator”, the function that calculates “size of RAM pointer variable” was not being called. It adjusts between 2-byte (VEX PIC, Arduino) and 4-byte (Emulator, VEX Cortex, NXT) pointer sizes. No issue with VEX Cortex and NXT as they only use 4-byte pointers. But a problem with VEX PIC and Arduino where real robots use 2-byte RAM pointers! Added the appropriate call to function setup.
  • Small code optimization for “postfix –”/postfix ++” operators to avoid temporary. In some cases they can be simplified to prefix operands.
  • Incorrect initialization of static variables in “inner scope” for local procedure. They were initialized every time inner scope block was accessed rather than once on program startup.
  • Debugger Panes for “Locals” and “Globals” (especially Globals) was not properly handling updates to ‘long’ and ‘float’ variables. Globals was completely broke — only lower two bytes of 4-byte variables was being updated which broke ‘long’ and ‘float’ variables. In both, ‘char’ variables were updating a short value — i.e. overwriting following characters.
  • Fix problem with incorrect user code using a “short” variable and “sprintf” format code of “%f”. This can crash ROBOTC VM firmware if the short variable is not aligned on a 32-bit boundary.
  • Add additional entries for StringFind for Character Constants and added test program.
  • Redefine datalog opcodes and intrinsics. Legacy datalog incompatible with 3.5x VM operands which split memory variables and intrinsic properties into separate items.
  • Firmware for all platforms now call “datalogHandlerInit()”. Conditional compile will define as NULL macro if a platform does not support Datalog. Datalog support is now conditionally compiled via “bHasDatalog” define rather than hard-coded as NXT only.
  • Fix incorrect compiler type checking error when string constant is assigned to a char pointer.
  • Fix bug in check for “is this a preprocessor string comparison expression”.
  • Eliminate preprocessor string comparisons in Natural Language and replace with “defined(_Target_XXX_) where “_Target_XXX_” are three new system defined preprocessor variables — “_target_Robot_”, “_Target_Emulator_” and “Target_VirtWorld_”. Sample programs modified appropriately. Legacy user programs using legacy definitions will still work but will generate a compiler warning about non-standard extension.
  • Add registry flag to enable compiler extension to allow preprocessor expressions support for string comparisons. Generate compiler error message if encountered without the flag being set.
  • “cast” code generation fix. Previously when cast changed sign of result the ‘cast’ was applied before expression was converted to ‘int’ size used during a calculation. So casting a “ubyte” to “int” incorrectly converted it to a “signed char”. What should happen is “ubyte” expression gets evaluated into an “int” as part of expression evaluation (all expressions are evaluated at ‘int’ (or higher) level in “C”) and then the cast to “int” has no additional effect.
  • Function to extract numeric “COMxxx”. Expanded syntax to support successful parsing of “(COM99)” previously would not accept extraneous characters.
  • Add improved Dialog for selecting Communications Port. It uses a list box to display information about the port. Add check box to select any communications port.
  • Compiler crash when parsing invalid syntax of ‘?’ expression. Compiler was not handling the case when “NULL” pointer returned from parsing sub-expression. The “NULL” was incorrect.

Written by Tim Friez

February 27th, 2013 at 10:06 am

2013 National microMedic Contest

without comments

2013 National microMedic Contest

Looking for an awesome opportunity to test your ROBOTC skills this spring? Our friends at Parallax have the solution: the 2013 National microMedic Contest. The microMedic contest challenges participants to create cool, open-source medical devices powered by microprocessors and sensors. To motivate inventors to think outside-of-the-box, the microMedic challenge is giving away 100 free contest kits on a first-come, first-served basis and is also offering prizes to the winners of the contest (over $25,000 rewarded across 25 total winners). There are no restrictions on hardware or programming languages, so this is the perfect opportunity to hone your ROBOTC expertise with the VEX, LEGO, or Arduino platforms. For more information, please see the contest’s article on CS2N or the contest homepage on Parallax’s website.

                                                                                                                      

“The U.S. Army’s Telemedicine and Advanced Technology Research Center (TATRC), Carnegie Mellon University Entertainment Technology Center, and Parallax Inc are offering over $25,000 in prizes to inspire the next generation of medical innovation. The 2013 National microMedic contest is an opportunity to show the country what citizens can do with new technology – encouraging technical innovation with significant use of microcontrollers and sensors in the medical industry. This contest is perfect practical application for STEM (Science, Technology, Engineering, Math) students around the nation.

The 2013 National microMedic Contest will create significant interest around new open-source medical applications. TATRC’s Dr. Brett Talbot, Medical Simulation Portfolio Manager, says about the contest “we’re looking for microcontroller-based projects for the health and medical simulation community that combine the latest use of sensors, 3D printing, CNC and science disciplines. This is a call to action for inventive people to put our skills to use for the benefit of Army personnel and civilians.”

Inventors and students are encouraged to participate by creating medical applications and products for possible use in the healthcare industry, medical simulation training, and the battlefield. STEM teachers are encouraged to get their classes involved. Over 100 free contest kits valued at over $40,000 will be given away on a first come first serve basis to qualified applicants. Use your favorite microcontroller or apply to receive a free kit that includes either the Parallax multi-core Propeller chip or a shield for use with the Arduino microcontroller. The kit also contains various sensors, LED displays, infrared emitters, a blood pressure cuff, heart rate monitor and many other components to spark your imagination. Use of the official contest kit is not required to win.

To help get competitors started Parallax Inc. is hosting resources such as mini tutorials with code examples for sensors, lists of application ideas and an online discussion forum specific to the microMedic National contest where contestants can ask questions and collaborate. Applicants have until July 31st, 2013 to submit their microMedic entries. Over $25,000 in prizes will be awarded to 17 educational winners and 8 winners from the public category. The award ceremony will be held in September 2013 at the TATRC Innovation Lab in Fort Detrick, MD. For more information on the 2013 microMedic Contest visit Parallax’s website.”

Written by John Watson

January 24th, 2013 at 3:03 pm

ROBOTC 3.54 Update Now Available!

with one comment

The ROBOTC development team is happy to announce the release of ROBOTC 3.54. This new version adds a number of new features and numerous bug fixes from user reports. Existing ROBOTC 3.xx users can download a free update from inside of the ROBOTC software (Help – Check for Updates) or from the ROBOTC.net website.

In addition to ROBOTC 3.54, the ROBOTC Development team is excited to announce support for PID with the VEX Cortex system (using motors with integrated motor encoders). The new VEX PID functionality will be available in a public BETA to be released in the very near future.

The latest update to ROBOTC also includes a number of new features for Robot Virtual Worlds. The new update includes new support many more motors, encoders and sensors. Look for an update for your favorite virtual worlds in the near future to take advantage of this great new functionality.

A summary of the major changes are below:

LEGO/TETRIX:

  • Support for MATRIX Robotics “Move to Encoder” in NXT firmware using the nMotorEncoderTarget functionality.
  • Fix TETRIX motor control. “Move to encoder position” functionality was not working correctly.
  • New functionality for I2C test program to optionally create message log traces for I2C ‘write’ and ‘read’.
  • TETRIX user defined servo names were not being properly setup by compiler. Fixed.
  • nxtDisplayRicFile intrinsic was broken. Auto downloading of files from PC was disabled. Both are fixed.
  • Xander’s 3rd Party Sensor Drivers (from BotBench.com) are now updated and compatible with ROBOTC 3.54. The new driver are included in the NXT Sample Program’s directory.

VEX Cortex/PIC:

  • Fix bug related to ‘char *’ and ‘string’. It was introduced with fix for “playSoundFile” not working. “playSoundFile” is now working for the Cortex.

General ROBOTC:

  • Support for “Classic Mode” – This mode will disable the “variable stack” and treat all variable as “Global Variables” like ROBOTC used to before version 3.50. This setting is under “view – preferences”.
  • Enhance directories for “Sound” files. There are now three possible choices — “common files” directory, “platform specific” directory and “user specified” directory. Implemented separate “Preferences” tab for “sounds”.
  • Add new “Motors and Sensors Property Page” to configure size of “datalog” and “debug stream” buffers. Applicable to super user level only.
  • Clear highlighted execution line when “Debugger” closes. Previously the line of current execution was left highlighted.
  • Add support for “mouse wheel” with “Debug Stream Window”.
  • Add command to “compile all source files in specified directory. Add separate pane to retain the new “multi-file compilation” errors. The normal error window is erased on next compile and you’ll likely want the multi-file results to hang around.
  • Support for multiple user defined directories for compiler include files. Split “Detailed Preferences” into multiple property sheets when not menu basic and multiple tabs to display.
  • Instead of hiding command for invalid debugger pane during Emulator/Virtual Worlds, the command is shown – When opened a message box will display indicating that window is not supported under emulator/virtual worlds.

ROBOTC Compiler and Other Fixes:

  • Incorrect calculation of expression type of form <condition> ? true : false. Expression type was incorrectly calculated as a “integer type” rather than a “boolean type”. Fixed.
  • Fix type in calculating binary expression numeric type.
  • Fix incorrect calculation of expression types involving float constants. They were being set to “integer” type.
  • Changed a few intrinsic procedure parameters from ‘int’ to ‘short’.
  • Incorrect calculation of compile time constant code was resulting in unnecessary code generation for a complex, but constant value, expression.
  • “Terminate expression parsing priority” comparison was effectively  “>=” instead of “>”.  Priority was being screwed up so that expressions “A + B – C” was generating code for “A – (B + C)”
  • A few cases of “compile time constant” expressions values were not detected by compiler resulting in run-time code calculation for constant expressions. Specifically “0 / XX” is always zero regardless of ‘XX’ value. Also, constant expression of form AA = <numeric one> – <numeric two>” was generating code for run-time calculation even though could be calculated at compile time. Fixed.
  • VM opcode uses 16-bit unsigned constant. But compiler was checking if 16-bit SIGNED value was in range.
  • Incorrect compiler error message about array index out of bounds is possible when index is expression like “<constantVar> + numeric constant>”. The code for checking array bound range was only looking at “<constantVar>” and not including the <numeric constant>”. This is fixed.
  • Fixed an error that did not mark precompiled headers as invalid if the precompiled source file had any errors from the previous compile attempt.
  • Created separate Sample Program Root folders when in Virtual Worlds mode.
  • Benign. Better support for type checking “void” and “void *” expressions to eliminate incorrect compiler warnings.
  • Fix code generation for ‘string’ types. There were issues with “const string” variables having improper memory allocated. Improve code generation for assignment of “&” (address of) operator to avoid an unnecessary temporary.
  • Eliminate legacy code that re-ordered syntax tress to optimize code generation for numeric. This was not “standard C” compliant because it re-ordered the order of how expressions were evaluated. Code generation is nearly as optimal except something like “X = 5 + y +6″ will separately generate instructions to add ’5′ and ’6′ rather than a single add of ’11′
  • Better implementation of “type checking on string expressions”. Old implementation was occasionally generating incorrect compiler errors.
  • Add support (in emulator only) for invalid pointer calculation in “get address of parameter” opcodes. It performs a range check to ensure calculated values are in range. This is not a complete check for invalid pointers but will catch many occurrences of unassigned pointers.
  • Code generation for “large constants” (i.e. doesn’t fit in two bytes) was broken. Fixed.
  • Incorrect calculation of “assign “&’ value to variable”. Bug recently introduced with string fixes.
  • Improve code generation for ‘char string constants’.
  • Add error message when no parameter is specified for nMotorEncoder/Motor/SensorValue/etc.
  • Fix a few small issues in Licensing System for oft-used cases.
  • Add compiler error message when no “main task” is defined.
  • Add compiler error message that “&” is snot supported as part of a ‘cast’ qualifier. This is a C++ feature and not found in ANSI C.
  • Fix bug in code generation for “goto XXX;” statement. Compiler optimization may not emit the unconditional branch and code generation was not handling the case of  a NULL pointer that resulted.
  • Fix code generation problem with large constants (i.e. >16 bits) assigned to long variable. Compiler was incorrectly trying to generate code for optimized short forms (i.e. 16-bits or smaller parm index).
  • “Events” no long work. Delete the sample program that illustrates them.
  • Incorrect calculation of operator parsing priority for “&” (address of unary op) which should be ’3′. Instead it was using the priority for ‘&’ (bit and) which is priority ’10′.
  • Fix incorrect code generation when assigning ‘float’ expressions to ‘int’ (char, short or long) variables.
  • Fix compiler code generation for expressions using pointer subtraction — “<pointer> – <pointer”. also fix “<pointer> – <number>”
  • Fixing an issue when a license is in the “clock rolled back” state and needs to be reset using a 30-day reset key – previously was not updating the “clock rolled back” state.
  • Compiler does not handle ‘const string kConfigName = “FTCConfig.txt”;’ properly. Changed to ‘string kConfigName = “FTCConfig.txt”;’.
  • Fix recent bug where “*” in declaration of type “typedef OBJ *POBJ” was being discarded. Extend typedef parsing to support declaration like “typedef unsigned char ubyte, *PUbyte”; i.e. change single declaration to a comma separated list.
  • Debugger window for NXT Remote Screen in emulator was not properly recognizing the remote buttons. The message sent to emulator should have been a mask of buttons and instead was a index of a single button. Fixed.
  • NULL char in middle of char string constant — e.g. “abc\0def” — resulted in incorrect storage by compiler into constant pool. Only the chars up to the NULL were being stored. Fixed.
  • Char arrays whose array dimensions were initialized with empty bounds were incorrectly assigned one byte too large. The trailing NULL on the end of the char string constant was being included in the array dimension.
  • Token scanner was not properly handling ‘\ddd’ special chars where ‘d’ is octal digit. This is now fixed and the standardized format for hex digits of ‘\xhh’ is also accepted.
  • Complete implementation of new registry toggle to optionally automatically close start page on first user compiler. Also added as a command to the menu “View -> Preferences -> Close Start Page on First Compile”.
  • Compiler was not parsing postfix “++” and “–” properly when they followed an expression. It worked fine on expressions with simple variables — “structVar.NN++” or “pStructVar->NN++” but didn’t work for more complicated expressions like “((TStruct *) &strucVar)->NN++”. It now handles the complicated expressions.
  • Fix incorrect calculation of “useless expressions” for binary opcodes. Compiler detects ‘useless’ expressions and does not generate code for these. It was incorrectly flagging binary “+”, “-”, … operations as useless which is incorrect if one of the parameters has side effects like being a procedure call or an expression like “++” or an expression containing a “=” operator.
  • Compiler crash when “++” or “==” were to expressions that didn’t immediately resolve to a symbol. e.g. “++((&g_obj)->n2);”.
  • Fix code generation for expression like “(&OBJ)->n1″. Was throwing compiler error and generating incorrect code.
  • Clear Debugger “Local Variables” pane when user program is finished or executing (vs suspended). When executing, don’t know which local variables (on stack) are valid.
  • Expanded declaration support for statements like “int A, * B, *C, D;” where A and D are “int” and B and C are “int *”
  • Signed / Unsigned type fixes for pointer variables. Allow “const string” procedure parameters to be matched by char constants (e.g. “ABC”).
  • Fix issue with compiler indicating reference variables are only “read” but not “written”.
  • Compiler was incorrectly assigning the ‘signed’ type of pointer variables to “unsigned” (i.e. the signed value of a pointer) rather than the desired type. Formatting routine for this was also broken.
  • Ignore “find best procedure fit” parameter array checking when “void *”. “Void *” will match any pointer regardless of arrays.
  • Improved calculation of expression result types for binary opcodes.
  • Intermediate expressions were always converted to ‘signed’. Now if both operands (e.g. A + B” are unsigned then the expression result is also unsigned.
  • Calculating best fit procedure was not checking array bounds of parameters for matching indices when the parameter was a pointer variable and an array variable. Fixed.
  • “cast” operator now preserves signed type of typedefs that it references. Previously this information was lost.
  • ‘signed’ and ‘unsigned’ now work properly when used in a “cast”.
  • ‘char strings’ when used as arguments to ‘sprintf’ were broken. Fixed.
  • Eliminate some overly aggressive warning messages about mixed expressions of numeric and ‘enums’. Standard C does not perform this level of checking and allows much more liberal mixed mode without warnings/errors.
  • Better support for arrays. Allow variable to be declared with arrays that is based on a typedef that also specifies arrays. Previously arrays could only be declared in one “item”. Array bounds were not checked for integrity (i.e. the bounds match) when validating procedure parameters and calculating best fit procedure when multiple procedure overloads.
  • Improved generation of “&” (address of) code.
  • Improved type checking to allow equivalent but differently declared operand types to match. Previously had to be exact match.
  • Generate compiler error for ‘&’ operator applied to a “property” (motor, servo, encoder, sensor) variable.
  • Generate compiler error for ‘&’ operator applied to a numeric constant.
  • Fix code generation for expressions like “char *ptr2 = buffer;” where ‘buffer’ is a implied pointer (e.g. a array of char). Previously code generation was assigning the contents of the first element of the array to “ptr2″ rather than the address of “buffer”.
  • If the previous line triggered an “indent” — like a “if (xxx)” or “else” statement then next line was auto indented and when “{” is entered want to “undent” the auto indent. Add check for this case.
  • Minor bug in calculation constant expression with unary ‘-’ with a constant numeric parm. Fixed.
  • Code optimization for conditional branches with trinary opcodes where the trinary condition is a compile time constant.

Written by Tim Friez

November 3rd, 2012 at 2:15 pm

ROBOTC 3.5: Global Vs. Local Variables and the Debugger

with one comment

This is the first in a series of posts that will explain the new functionality behind the latest ROBOTC update. Beginning with ROBOTC 3.5 with all of the new functionality towards becoming an ANSI-C compliant language has brought some changes that may confuse veteran ROBOTC users. This week we’ll take a look at how global and local variables work in ROBOTC.

In previous ROBOTC releases, the compiler (the engine that converts your code from C-language to machine language) would treat all variables as “Global Variables” and would allocate (assign memory to) every variable when the program was compiled. This method caused issues because it would not allow the compiler to understand re-entrant functions (i.e. functions that could call themselves). This functionality was limiting because it prevent a key computer science concept called “Recursion” which is the ability to have a function call itself repeatedly (but not infinitely). Recursion is very useful when dealing with sorting data or calculating a series of data in different algorithms (one example: calculating a Factorial value – 5! = 5*4*3*2*1)

Example of Recursion: Calculating a Factorial Value

In ROBOTC 3.5, the compiler’s functionality has been extended in order to support recursive functions by supporting the concept of “Call Stack” variables. The idea of the Call Stack is that ROBOTC will now store local variables and return addresses of functions onto a Call Stack – This unlocks the ability to have recursive functions and variables that are truly “local”. With the Call Stack, ROBOTC is able to keep track of multiple calls of the same function and coordinate all of the variables so there’s no accidental overwriting of data or multiple copies of the same variables to keep track of – Everything automatically done by the compiler when the program is run!

A visual look at a “Call Stack” (from Wikipedia)

With the call stack, ROBOTC’s firmware assigns the memory address of local variables when they’re declared in the code (as opposed to compile time as before). Variables are allocated and discarded on the stack as needed – users do not need to modify their code to take advantage of this functionality. Programs do still need to specify a variable’s type and size ahead of time however. (i.e. no dynamically sized arrays)

Three different ways to allocate variables.

There is one big difference when it comes to debugging – users will see the old “Variables” display is now split between “Global” and “Local” variables in the ROBOTC Debugger. Because the ROBOTC IDE doesn’t know where the variable will be stored in the “call stack”, there’s no way to accurately know where the local variables are on the stack at any one time. What this means is that you will not be able to view your local variables during run-time like in previous versions of ROBOTC. This is a limitation of professional IDEs (Visual Studio, Eclipse, AVR Studio) that also support recursion and variable stacks. The new extended ANSI-C functionality brings ROBOTC close to the same level as those development environments including the same limitations when debugging.

Hey where are all of my variables?

The good news is that users have two options for debugging their program’s variables:

  1. Suspend your program by using the “Step” button– When the program execution is suspended, the IDE is able to display all of the current local variables for the current function/task selected. This will not display every local variable in your program, but only the currently executing function/task.

    When the program is suspended, ROBOTC can load the “Call Stack” and display Local Variables accurately.

  2. Use Global Variables– Because Global Variables are allocated at compile time, the ROBOTC IDE knows the memory location of every Global Variable and can keep track of these variables in the “Global Variables” debugger window. All Global Variables will be continuously updated as the program is executed.

    With Global Variables, ROBOTC know the address of the Variable at all times, so it is able to always display the value.

We understand some of the frustration that ROBOTC users are experience with the new ROBOTC 3.5 update with all of the new functionality, and we apologize for any issues. Our overall objective is to make ROBOTC as close to a true ANSI-C programming environment to make sure students and users are learning proper coding techniques.

As we continue to refine our implementation with the latest version of ROBOTC, we still are committed to addressing any reported issues and would love to hear from you if you are having any problems – Please send us a note using our Ticketing system at http://www.robotc.net/support/ or directly at support@robotc.net.

Written by Tim Friez

October 24th, 2012 at 5:18 pm