Has anyone experimented with the LCD screens? Our club got some and I have just currently started trying to use it and I have a brief idea on what they are all about. I do know that you can store mulitple programs within it, thus replacing the jumper cables for multiple autonomous. Does anyone have a slight idea on how I do that? Or does anyone have a sample code that they are willing to share with me? Does it get programmed the same way the jumper clips do? Thank You everybody.
Hi devinc,
You don’t really store programs in the LCD. It is just a display and three momentary buttons. I highly recommend that you review the examples that are available for RobotC or EasyC, as they will show you how to go about writing to the screen and reading from the buttons.
Your goal of using the LCD to select between multiple programs or modes is a bit more challenging. The problem is that the LCD doesn’t store any information while it is powered off, so the next time the robot is turned on, you can’t tell which button had been pressed last time. For that to work, you need some form of non-volatile storage to keep track of that for you, and as far as I know, that isn’t available on any current Vex microcontroller *]. Check out this thread for a fairly lengthy discussion.
Jumpers and potentiometers are commonly used to select between modes since they retain their state even when the robot is switched off.
Cheers,
- Dean
*] I believe you could read/write the user processor EEPROM memory on the old PIC microcontroller using MPLAB, but I don’t think there is an equivalent service available to user code on the Cortex.
As Dean replied, you can store multiple programs on the cortex, not in the LCD. There is an example called “program chooser live template” in the Advanced folder of the sample programs, it does not compile in RobotC V3, you will need to change the constants kLeftButton etc. which changed in V3 wrt V2. The accompanying program “program chooser” now seems to be missing from the samples but from memory was more or less the same code without perhaps the 'MyCode" function, I can dig it out from an old RobotC version if you really want it. You save additional programs into the cortex using the “File Management” menu item under the “Robot” menu in the IDE.
I experimented with this during the summer and decided for competition code there was no real advantage to the program chooser over in program selection for things like autonomous modes. It may be useful to have old versions of code available without needing to download or for perhaps having different demonstration programs available.
Having said this I think the LCD is one of the most useful accessories available. Once you start using it for displaying, for example, the operational state of autonomous routines, encoder values etc. you will wonder how you managed without it.
Would the code for RobotC be similar to EasyC V4? I am currently using EasyC for programming.
More or less, there are examples included with EasyC but in essence all the LCD does is display text (including numbers etc.) and provide feedback through the buttons. If you get stuck I will find you an example later.
This is an outstanding example that I somehow missed on my previous sweep of the examples!
I was looking for some details on RobotC file operations, but there seems to be precious little documentation available. For instance, the function setProgramFile() in this example seems to be the way to load and run other program files, but I don’t see any documentation about it at all. A Google search was fruitless, as was a search of the RobotC forums.
Are you aware of any documentation regarding RobotC file management, or is it just an exercise of going through the examples and headers, and experimenting?
Cheers,
- Dean
Documentation for ROBOTC? That funny 
Nice 
I’ll spend some time this weekend digging and experimenting, and will post back everything I discover about ROBOTC files, thus creating something documentation-like. I’ll even post it on the Wiki so others can comment, correct, and contribute.
Cheers,
- Dean
There are really only a couple of commands, the setProgramNumber as you have found, you pass a number that indexes the file saved in the File Management dialog, normally when we download the default slot 0 is used but you can manually download to others. Its a bit of a workaround to get executables loaded as you first have to download to slot 0 then upload back to the PC to get the executable. There is also the command bValidFile that you can use to see if any program exists at a certain index. Looks like there are also commands to get file name and file type but I’ve never tested those out. I had concluded that it wasn’t that useful for my coding until the ability to read and write files from user code was added.
Right; I’ve seen those, and I know you can play a sound from a sound file. None of these functions are described anywhere AFAICT, other than a few examples.
Ahh, that is exactly what I was thinking as well. If read()/write() are not available, then that severely limits its usefulness. Saving persistent state across runs (to be used as a replacement for jumpers), and/or data logging are what I had in mind.
Thanks,
- Dean
I have searched high and low for a way to do this without success so far, not completely given up but it’s been on the back burner for a while now.
The flash in the cortex does have a limited lifetime, 10,000 erase/program cycles if I remember correctly. There is always the danger that flash could be damaged by code writing to it that gets out of control, lets say constant writing by code in a tight loop. As there is no flash translation layer to implement wear leveling, ie. spreading the writes out over the entire flash not just a limited number of sectors, I imagine CMU has deliberately chosen not to offer this functionality. I have ideas on how to implement this safely but have not given this feedback to CMU yet.
And with all the program and firmware downloads, that limit is probably a lot lower on most cortexs.
Yep, the Coretex M3 manual states the endurance is 10,000 write cycles (minimum). The block size appears to be 2K.
Yep, there are a variety of rate-limiting techniques that could be used, depending on the expected access patterns. Regardless, I agree that they aren’t likely to expose generic read()/write() like interfaces.
Cheers,
- Dean