Archive for the ‘Software’ tag
The ROBOTC Development Team is excited to announce the availability of ROBOTC for VEX Robotics 4.08 – an update for the VEX Cortex and VEX IQ platforms. This new version supports the latest firmware versions provided by VEX Robotics (4.20 for VEX Cortex / 1.09 for VEX IQ) and all of the new features supported by the new firmware updates. Some of these new improvements include:
- Support for the VEXnet 2.0 (white) Radios for the VEX Cortex
- Bug Fixes for the VEX IQ system to prevent “I2C Errors”
- Speed enhancements for VEX IQ for better performance of motors and sensor
- New VEX IQ commands for Gyro sensors
This new version of ROBOTC also supports the VEX IQ “Graphical Natural Language” feature. This new interface allows users to program robots from inside ROBOTC with easy-to-use graphical blocks that can be drag-and-dropped to form a program. Each block represents an individual command from the “text-based” ROBOTC and Natural Language. The new click and drag interface along with the simplified commands of Natural Language allows any robotics user to get up and running with programming their robots as soon as possible. As of today, the Graphical Natural Language commands work with the VEX IQ system, but we’re actively developing support for ALL ROBOTC supported platforms!
Before you can use ROBOTC for VEX Robotics 4.08, you will need to ensure that your VEX devices are up to date. The instructions to update your hardware will be different depending on what hardware setup you may have…
- VEX IQ Users
- Run the “VEX IQ Firmware Update Utility” and update your VEX IQ brain to firmware version 1.09. You will also have to install the latest ROBOTC firmware from inside of ROBOTC.
- VEX Cortex Users (with Black VEXnet 1.0 Keys)
- You will need to update your VEX Cortex and VEX Game Controllers with version 4.20 from inside of ROBOTC. After updating your master firmware, you will also have to install the latest ROBOTC firmware as well.
- VEX Cortex Users (with White VEXnet 2.0 Keys)
- The new VEXnet 2.0 keys have a specific “radio firmware” that you will need to upgrade to enable “Download and Debugging” support. You can find this utility here.
- Download the “VEXnet Key 2.0 Firmware Upgrade Utility” and insert your VEXnet 2.0 key to any free USB port on your computer. Follow the instructions on the utility to update each key individually. All VEXnet 2.0 keys must be running the same version in order to function properly.
- After updating your VEXnet 2.0 keys, you will need to update your VEX Cortex and VEX Game Controllers with version 4.20 from inside of ROBOTC. After updating your master firmware, you will also have to install the latest ROBOTC firmware as well.
- Note that this new firmware version will support download and debugging with both VEXnet 1.0 (black) and VEXnet 2.0 (white) keys.
Here’s the list of changes and enhancements between version 4.06 and 4.08.
- Support for VEX Cortex Master Firmware 4.20 and VEX Game Controller Master Firmware 4.20
- Support for wirelessly download and debugging using the new VEXnet 2.0 2.4Ghz radios.
- Fixed an issue with launching ROBOTC in “Virtual Worlds” mode, which may incorrectly choose the wrong compiler target.
- Fixed issue with Windows XP/Vista/8 where ROBOTC may crash when unplugging/plugging in a device
- Improved motor responsiveness (16ms update cycles as opposed to 50ms today – this was a mitigation for the I2C issues in the current Master FW)
- Improved sensor responsiveness (varies by sensor – this was a mitigation for the I2C issues in the current Master FW)
- Gyro sensors can now return either integer values (getGyroDegrees/getGyroRate) or floating point values (getGyroDegreesFloat/getGyroRateFloat)
- Fixed a bug where the Gyro sensor was not using the “rate” setting to properly return a deg/sec calculation for the getGyroRate command.
- Exposed the ability to calibrate the gyro sensor from the user program and specify the number of “samples” to take during calibration (more samples = less drift = longer calibration time)
- Also added a boolean “get” command to read the gyro calibration status bit to know when calibration is done.
- New PWM adjustment function – allows users to trigger a specific VEX IQ motor to read the current battery voltage from the VEX IQ brain to adjust the PWM scale factor in the motor to ensure consistent performance. This is automatically done each time a program is executed with ROBOTC, but for longer programs end-users might want to readjust the PWM scale factor.
- New “read immediate current” from motor – returns a value in mA
- Modified functions for “motor strength” – renamed these to be “motor current limit” and uses values in mA instead of 0-255 byte value. These commands used to be called “getMotorStrength” and “setMotorStrength” – they’re now renamed to “getMotorCurrentLimit” and “setMotorCurrentLimit”
- Fixed an issue with “Graphical” mode where users may start up in “Cortex” mode and the function library will appear blank
- Fixed an issue when “Natural Language” mode was enabled that normal sample programs may not run properly (using the leftMotor/rightMotor keywords)
- Fixed issue with Windows XP/Vista/8 where ROBOTC may crash when unplugging/plugging in a device
If you have any questions or issues, contact us at firstname.lastname@example.org. Happy Programming!!
After months of work, the ROBOTC Development Team is excited to announce the availability of the first preview release of ROBOTC Graphical Language for the VEX IQ platform. This new interface will allow you to program robots from inside ROBOTC with easy-to-use graphical blocks that can be drag-and-dropped to form a program. Each block represents an individual command from the “text-based” ROBOTC and Natural Language. The new click and drag interface along with the simplified commands of Natural Language will allow any robotics user to get up and running with programming their robots as soon as possible.
The first release of ROBOTC Graphical Language is available for the VEX IQ platform for use with the standard VEX IQ Clawbot and Autopilot Robots. All ROBOTC 4.0 users will receive access to the new Graphical Language interface at no additional cost! Our plans over the next few months are to extend the Graphical Language interface to all of ROBOTC’s support platforms, including the Robot Virtual Worlds technology. You can download the preview version today at http://www.robotc.net/graphical/.
The new ROBOTC Graphical programming environment adds a number of new features we’d like to highlight:
Graphical Language Command List (Drag and Drop)
With the new ROBOTC Graphical Mode, we’ve updated our “Functions Library” to match the style of the Graphical interface. This new mode will allow you to drag and drop blocks of code from the “Graphical Functions” menu into your program to get your program created even faster!
New Language Commands for Easier Programs
We also added some new language extensions to both ROBOTC and Natural Language; such as the simplistic “Repeat” command. Prior to the Repeat command, users would need to copy and paste large sections of code or use a looping structure (like a ‘for’ or ‘while’ loop) in order to have a set of actions repeat a number of times. With the new “Repeat” command, however, users can simply specify how many times they would like the code to run, with no complex coding required. And users who wish to make an “infinite loop” can use the “repeat forever” command to accomplish this task quickly!
Commenting Blocks of Code!
Another awesome tool that we’ve implemented in ROBOTC Graphical is the “comment out” feature. You can now comment out an entire line of code just by clicking on the block’s line number. The robot ignores lines of code that are “commented out” when the program runs, which makes this feature very useful when testing or debugging code. This new tool is unique to ROBOTC’s Graphical interface.
Updated and Simplified Toolbar
Sometimes navigating menus as a new user can be a little overwhelming – so many options to choose from and lots of questions about what each option is used for. To help with this, we’ve redesigned ROBOTC’s toolbar to make getting up and running easier. We put the most used commands on a larger toolbar so new users have an area to easily click to download firmware, send their code to their robot, and run their programs without having to use the standard menu interface.
Convert to Text-Based Natural Language
Because each Graphical Natural Language block corresponds to a real ROBOTC or Natural Language function, users will be able to graduate from Graphical Programming to full text-based programming with the press of a single button. This allows users to naturally transition from Graphical Natural Language to the text based Natural Language (or ROBOTC), without having to worry about manually converting the code line-by-line!
Teacher’s Guide and Sample Programs
The new graphical interface includes over 50 new sample programs to help you get up and running with working examples and demo code. In addition, we’ve also developed a 30+page guide to walk new (and existing) users through the new Graphical Programming interface and getting started with the VEX IQ platform. You can find a link to the programming guide here and also on the ROBOTC Graphical page.
This initial release is only the beginning and we’re planning on improving the software with more features and flexibility over the coming months.
- Copy and Paste
- Undo/Redo Support
- Support for custom robots/configurations via an updated “Motors and Sensor Setup” interface.
- Dynamic Loop and Command Parameters (based on Motors and Sensor Setup / Robot Configuration)
- Tooltips, Contextual Help, and more!
Let us know what you think! If you have any feedback or questions, please send them along via the ROBOTC’s VEX IQ forums.
Robot Virtual Worlds just released a new video all about the software!! Check it out here:
Already using RVW? What do you think? How do you use this software in your classroom? We’d love to hear your feedback!
A curriculum pacing guide is something that teachers have to consider whenever they examine their curriculum. This fact does not escape teachers of <a href=”http://www.robotc.net”>ROBOTC</a>. Whenever I come across teachers who are just starting to use the ROBOTC curriculum, often their first question revolves around how long the curriculum will take. Once again, teachers are used to having some type of pacing guide that delineates how a subject is to be taught. The ROBOTC curriculum is not organized in that fashion. Instead, the curriculum is organized by topic. The topics include basic programming fundamentals, robot movement, robot sensing, etc. The teacher is then free to spend an appropriate amount of time within each topic.
As teachers, this freedom is welcome. It is welcome because the pacing that comes with most textbooks is an impossible guide to follow. In order to create a true pacing guide, student background knowledge would have to be taken into account. Since every classroom is different (sometimes within the same grade, within the same school), it is impossible to gauge how quickly the students are going to master the concepts as they are presented. Additionally, as the teacher becomes more familiar with ROBOTC, they will find that they spend more time on particular concepts then they did the first time they taught the curriculum. For example, when I first taught ROBOTC, I spent 20 minutes discussing Flowcharts and Pseudocode. Experience has now taught me to spend a significant amount of time on these topics. I also spend much more time talking about Errors. Specifically, what should a student do when they get the dreaded compiler errors in their program? Experience has taught me to spend much more time on thinking about the logic of a program before the writing of ROBOTC and on debugging strategies once the code has been written.
Each of the aforementioned sections of the ROBOTC curriculum contains a programming challenge. The programming challenged is designed to showcase the skills that were emphasized in that section. Each section also contains an assortment of “mini challenges”. These challenges can be used at the teacher’s discretion. They all do not have to be completed. However, they can be very useful. For example, after the students have spent a day or two learning a topic, I will begin the following class with one of these mini challenges. They might not know all of the skills needed to complete the section challenge, but the mini challenge is a good assessment of what has been presented so far in that section. This also serves as a good change of pace for the class. Simply, you can’t learn to program without actually programming. In order to really understand the applications of while loops or if/else statements, students need to apply them. The mini challenges found within the ROBOTC curriculum serve as a great opportunity to scaffold skills toward their more challenging applications.
A beginning teacher of ROBOTC could teach the basic ROBOTC curriculum in one semester. By including many of the mini challenges, the curriculum can be stretched easily over a semester. I often tell teachers who are teaching the class for a year to do this, and then to end the year with a larger programming challenge. After the students have made it through the ROBOTC curriculum, I enjoy introducing them to Multi-Robot Communication. The sensor needed (NXTBee) is inexpensive, and there are a lot of great ideas for activities and programming challenges.
If you have a stronger background in computer science, and maybe you are teaching older students, you may be able to navigate through the curriculum much faster. What then do you do with students if you have them for an entire year? Luckily, there are many great ROBOTC projects on robotc.net. Moreover, the ROBOTC forum is also a wonderful place to look for ideas for projects, in-class competitions, and programming challenges.
Teaching robotics and ROBOTC is a lot of fun. The ability to watch your students apply what they learn in the ROBOTC curriculum in such engaging and open-ended activities is one of the main reasons why.
Once the physical hardware (robotics kits) are secured for a classroom, the next step is to install the software (ROBOTC and Robot Virtual Worlds). It would be nearly impossible to cover every single specific setup that could be encountered on a classroom’s computers, but this blog post will cover the basic installation steps and some of the more common installation issues that educators may run into when installing ROBOTC in a classroom.
The first thing you will need to do is install ROBOTC on the computers in your classroom. To do this, always make sure to grab the latest version of ROBOTC that your license supports from the correct ROBOTC download page. If the wrong version is downloaded and installed, or if there is already a different up-to-date version of ROBOTC installed on the computers, you will not need to uninstall and reinstall the program; instead, you will simply need to activate your license in ROBOTC (more on this later). During the download process, ROBOTC will also attempt to install the necessary drivers for communications with physical robots. Depending on the level of security on the computers, you may need to get your IT department involved in order to ensure that the drivers are installed properly.
Once ROBOTC and the appropriate drivers have been installed, you will need to activate ROBOTC on each computer manually. The license activation ‘unlocks’ the ability to download code to either a physical robot or a Virtual World, depending on which license is used. When ROBOTC is installed on a computer, all versions of ROBOTC (including different robotics platforms, such as the VEX and LEGO platforms, and different compiler options, such as Virtual Worlds compiler options) are installed at the same time. Instead of installing additional copies of the software on the same computer (or opening a new program every time you would like to change the compiler target), the additional platforms and compiler options are ‘unlocked’ by activating their respective keys.
Before we move on to the next blog (Setting up the Robots), here a couple more tips that may come in handy when setting up ROBOTC in a classroom:
- Depending on the programs, policies, and restrictions in place on the machines, your school’s IT department may need to be present for the installation or activation of ROBOTC, Virtual Worlds, or the installation of any drivers for the physical robots.
- If your school’s IT department images and deploys the classroom’s computers, make sure they reference the ROBOTC Deployment Guide on the ROBOTC wiki for important help and information.
- Make sure to check the computers’ hardware to the minimum requirements for ROBOTC or Robot Virtual Worlds before
- Always test one computer first! If there is a problem with the installation, it is better to find out about it early and fix it before they same issue appears on a classroom full of computers.
- John Watson
Originally posted on Grow a Generation Blog
I took Grow a Generation to a recent Zumbathon fundraiser for the Yellow Ribbon Girls. Several kids meandered over to the table while the moms were working out. I invited them to play around with the Scratch programming window that was opened on the computer. One girl, I think about 10 or 11, became enamored with Scratch, asking how to make the cat she choose as a sprite move around the screen. I showed her a few command codes and encouraged her to experiment. Intent, she focused as hard on that screen as the 200+ moms focused on their workout. When the workout was over, her mom, exhausted and drenched, came to grab her hand and walk off. It took several attempts by me to convince the mom to actually look, and several more attempts to explain the daughter had not been playing a game, rather programming a new one. She had programmed her cat to dance a Zumba workout. Even then, the mom didn’t seem to understand and finally looked closer to let her child explain the code she had put in place. The mom was incredulous, “You mean my daughter actually programmed this?”
I spent this week working with some brilliant young people as they were introduced to Alice 2, a free drag and drop educational programming language that allows students to create computer animations using 3D models. Our theme was Zany Animals and each student was tasked with inventing a creature and animating it with special qualities. J.K. Rowlings inventive imagination supplied fuel for our creativity while we looked at the etymology and origins of some great Harry Potter creatures (Basilisk, Phoenix, Hippogriff, Boggart, and Thestrals). The Discovery channel demonstrated some very real incredible animals and provided a template for our short nature documentaries. We discussed the ethics of animal experimentation and watch some videos of the current status on cloning, using animal to create pharmaceuticals and synthetic proteins, and grafting technology onto animals.
One of the uncles (a young man in his late twenties) stopped mid-week and looked around at the fun we were having. He shared his remembrances of computer science class in high school, a black screen with detailed code he could not make work. He had walked away from high school convinced Programming was something he could not learn.
His comments, alongside the mom’s at the Zumbathon, have me wondering about marketing. Only five students enrolled in the camp. While other factors played a part, how do I advertise to a generation who cannot conceive a child can begin to write code (and have fun doing it)? How can we work to allow not just the technology teacher and the media lab director, but also the classroom teacher encourage computer programming and the creation of digital artifacts in the creative expression of their students.
I have had to journey my own learning curve this summer. I am taking the CS2N Summer of Learning class in ROBOTC. The Alice 2 tutorials I did in class were adapted from the CS2N Introduction to Alice class that is available free on their website. I learned alongside the kids and eagerly accepted the wonderful help of two area middle school STEM heroes who run their own programming classes in the homeschool network – Fiona and Joseph Chaney.
The camp was such fun. The kids learned to select an environment and create an establishing shot for their animals habitat. They then created their creature by selecting the object of an animal and changing colors, textures, ear size, nose size, arm length, etc. They started animating their animal to demonstrate its incredible abilities and changing camera angles to tell a story. Finally, they added sound and narration to their animation. All of this was done while learning basic computer care, where to save and recover files, and how to deal with constant messaging of “Alice thinks you made an error” and carry on through frustration. The kids will be using the animations they created to enter the CS2N Nature Doc-u-mentary competition.
Two learning leap moments stood out. The first was a child who had originally placed two dragons into the scene and they create a ‘method’ called fight. He dragged the method into the editor box and couldn’t figure out why they weren’t fighting. He had not yet connected the need to write the script for each movement of each dragon to create the method. The rest of his week was spent focused on getting a dragon to flap his wings. It tied in beautifully with a video on the last day about how computer animation team created the Thestral flight scene in the Harry Potter Order of the Phoenix movie. This boy was breaking down the abstract concepts of ‘fight’ and ‘fly’ and beginning to think in terms of modeling, algorithms, and sequence.
Another moment came when a student wanted to have a turtle disappear into his shell. I found a brief tutorial online (the Alice tutorials are out there, but they are not as easy to find as the Scratch tutorials) and he was able to follow it. When I checked back in to examine his code, I was so impressed how he could walk me through the control structures he put in place for sequence, conditions, and parallel execution!
High points included sitting outside on a gorgeous rain free day in the shade under the tree at a picnic table at Baden Academy as students typed away on their netbooks creating their animals, inspired by the new surroundings and summer breeze. Another was the look of such pride as parents and grandparents applauded to see the student creations on the screen in the lab at the end of the week.
Embarrassment of the week – despite a Ph.D., I could not visualize the need to invert the image on the iron on for the shirts – so if you see a smiling child wearing a shirt with a picture of their Zany Animal and all the text is backwards, know that you are looking yet another erratum of Dr. Ellen.
I close with a recent Facebook post from a mom: “John made this video in his computer class this past week. It is short but he has never done anything like this in the past. Wish the class was longer than five days. He loved it.”
Enjoy the kids work – and don’t forget to add your comments!
FireBall the Devious Hamster Crook
We are very excited to share details on ROBOTC 4.0!! This version of ROBOTC will be getting a lot of new features as well as some enhancements to favorite tools already included. Also included in this upgrade will be support for new hardware platforms, including the new VEX IQ and LEGO EV3.
Planned Features in 4.0:
- Overhauled Natural Language functionality to make learning how to program even easier.
- Motors and sensor setup that will automatically detect devices (with supported platforms/devices.)
- Enhanced drag and drop capability with our function library for new users.
- Updated text editor with code collapsing, improved auto-complete, and more user customizability.
- Even more sample programs to help users get started, including samples for new platforms and advanced programming concepts!
- Support for both VEX Cortex and VEX IQ in ROBOTC for VEX Robotics 4.0
- Support for both NXT and EV3 in ROBOTC for LEGO MINDSTORMS 4.0
- No-Cost standalone version of ROBOTC for VEX PIC for legacy users.
Pricing and final availability for 4.0 has not been finalized; however customers can feel secure buying ROBOTC today knowing they will get a full ROBOTC 4.0 upgrade as soon as it is available.
Current ROBOTC Users Upgrade Details:
- 3.0 Perpetual Users (who purchased in 2013): No upgrade fee! Full purchase price will be applied towards same type of license for 4.0.
- 3.0 Annual Users (who purchased in 2013): 50% discount on equivalent 4.0 License
- 3.0 Perpetual Users (who purchase before 2013): 50% discount on equivalent 4.0 License
If you own a license to ROBOTC 3.xx – You can continue to use 3.xx for as long as you would like (assuming you have a perpetual license) – the software will not stop working once 4.xx is released. However, if you wish to use the features and platforms available in ROBOTC 4.xx, you will have to purchase an upgrade at a significant discount.
Upgrades will be available for up to 6 months after the official release of ROBOTC 4.0. Stay tuned to the ROBOTC.net Blog – We will be releasing free beta versions throughout the year and will announce final pricing and availability details in the near future.
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.
Some of the key enhancements are:
- Added support for proxy server when activating ROBOTC (Proxy Support guide can be found here).
- Add watchdog timer support to VEX Cortex to alleviate processor crashes that can occur with static (more information on this issue can be found on the VEX IME Product Page).
- 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!)
- Updated Curriculum Tables included for Robot Virtual Worlds.
See below for the more detailed changelog and download ROBOTC 3.60 here!
To celebrate the official release, we will be having our first Google Hangout! Tim Friez, John Watson, and Xander Soldaat will be there to discuss the new features and answer some of your questions. To tune in live, visit ROBOTC.net/hangouts at 2pm EST tomorrow (Thursday, March 21.)
3.59 to 3.60 BETA Changelog
- New Standard Models Added for PLTW.
- Update VEX Cortex I2C interrupt handler to handle case where interrupt for last received character is not processed until STOP signal has already been sent.
- Add parameter to I2C Device Driver (VEX Cortex) to indicate whether being called for a “timer tick” or for a “message is now complete”. Add a few more statistics to the error collection.
- Increase VEX Cortex I2C message timeout to 6 milliseconds from 3.
- Start sending VEX Cortex I2C polling messages immediately after last poll has finished. Improves I2C responsiveness for VEX Cortex.
- Xander’s 3rd Party Driver Suite updated to version 3.3.1
- New firmware conditional compiles to eliminate the get/set property opcodes for ‘long’ and ‘float’.
- Arduino only. “Copy opcode from flash to RAM” performance improved.
- On Arduino, sensor initialization incorrectly assumed as sensor types had the extra “sensor buffer” structure. But the extra buffer is only linked for complicated sensor types so RAM was being overwritten. Fixed.
- Updated application and desktop icon quality.
- Fix “Multiple overloads match” error introduced with change that did proper validation of pointer expression with point procedure parameter variable.
- Improved validation of procedure parameter matching for function overloads. Previously when parameter was a pointer, only checked to confirm that calling expression was also a pointer. Check was extended to also (correctly) match on the type of pointer as well.
- Could not change “check array bounds” in Compiler Code
Optimization tab. The issue was that after changing the check mark the “code optimization type” would be recalculated and then the “optimization type” radio buttons updated. Array bounds checking is not used in determining the optimization type; but in setting the type it is modified. So the changed check mark was being accepted and then software was overwriting. Fixed.
- Split “auto save” into two individually settable flags: (1) to auto save source files before compile and (2) auto save files when application exits.
- Incorrect code optimization involving ‘struct’ variable offsets and perhaps other cases. For the assignment instruction “<variable2> is assigned address of <variable1>” compiler was replacing references to “<variable2> with “<variable1>. This optimization should only occur for “simple assignments” of “<variable2> = <variable1>”. Fixed.
- Change ‘nSysTime’ and ‘nPgmTime’ intrinsic variables to “unsigned”. ‘unsigned’ intrinsic variables were being converted to ‘signed’ when used in comparison expressions generating a warning regarding mixed ‘signed’ / ‘unsigned’ comparison. Fixed.
- Upper range check for “array bounds check” opcode used “>” instead of “>=” in comparison allowing ‘one past’ array size as valid.
3.54 to 3.59 BETA Changelog
- 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.
- 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.
- 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.
- 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.