I’d like to see some type of non-volatile storage available to user programs for parameter storage and/or data logging.
This could take many forms. Some possibilities are:
[LIST=1]
*]Enhance EasyC and/or ROBOTC to allow data storage to the user processor flash memory. This is discussed a bit on this thread, but concerns about the 10K write cycle lifetime make this approach risky, and the capacity is potentially too small for some data logging applications.
*]MicroSD Card reader that attaches via the I²C port.
*]A HUB/USB extension cable that allows the use of a standard USB thumb drive in conjunction with the VEXnet module.
*]Update the LCD to provide some storage (possibly EEPROM-like for parameter storage, or MicroSD slot for data logging). If this approach is taken, then the LCD firmware could be updated to provide some generic parameter browsing/setting functionality without requiring the user program to handle the full UI.
[/LIST]
I think that this would be a great idea too. Config Information could be save for the Controller’s State, plus Logging or Dynamic Look-Up Tables.
<== ==>
[LIST=1]
*] Only 10K write cycle lifetime, is 1/10 the PIC18F8520 lifetime. That is a Trade-Off… Most Micro Controller I have worked with support Writing smaller Blocks of the Flash Memory, so this is possible, but would not be Desirable.
*]MicroSD Card reader that attaches via the I²C port, would require another Microcontroller, because Micro SD cards are SPI devices in the MMC mode. Unless the other SD Modes could be accessed by the STM32. ( See Embedded SD Card/MMC Card and Interfacing to an MMC or SD Card via SPI Version 1.0 )
*]A standard USB thumb drive might be possible, but the Host Logic is way more complex than the Micro SD card.
*]Updated LCD with a more advance Microcontroller that could support the Hardware needed for Items #2 of #3. That might be the best all around option…
[/LIST]
I talked to a ROBOTC guy at worlds this year, and I recall him mentioning that something along the lines of writing to the cortex from the user code is in the works. I might have that mistaken for multiple program slots though :-/
I have been able to read/write from/to Microchip SPI 25LC1024 Serial EEPROMS using a VEX 0.5 Microcontroller and EasyC Pro or PIC18C. In addition, I was also able to interface an SPI based SSRAM from TI to VEX. The SSRAM has a much longer life span than EEPROM.
I wanted to bump this thread and put a slightly different spin on it. One problem that keeps cropping up is…
“why didn’t my robot work during the match? It was OK when I tested it before”
So the idea is to have storage that can be connected to either the cortex or the joystick that will collect telemetry data for post analysis. The type of data it would collect would include
Time of day - so joystick and cortex data could be correlated
firmware version
Battery voltages
Status of LED’s red/green/orange, no flash/slow flash/fast flash
VEXnet status, signal strength, errors etc.
competition switch status.
any other available internal error conditions
I would suggest it connects to the serial port on the cortex, normal operation uses at most one for the LCD, and to the program port on the joystick. This would give a common interface for both platforms.
Storage could be to SD card or internal flash memory.
The unit should be self powered so problems with cortex or joystick batteries do not stop operation. Obviously if the cortex/joystick battery was completely dead so that communications did not take place nothing could be recorded, however, the most common problem seems to be low battery rather than no battery.
The unit does not need any form of display or user controls other than perhaps a power switch (although that debatable as it’s another source of user error).
A PC application would allow recorded data to be downloaded for post match analysis. Multiple sets of data should be able to be recorded before needing to be deleted.
The cost of such an item may be an issue, it’s probably going to be around $30-$40, it could perhaps be based on something like this.
So I made the previous post knowing that part of the solution already exists. There is no official documentation on the protocol for the programming port on the cortex, however, this type of communication is quite trivial to reverse engineer. Much of the communication is passed on the the user processor in the cortex for interpretation by the user firmware, the code written in either RobotC or EasyC. Some commands are replied to directly by the IFI firmware. Two commands in particular give us some of the information we would like to record. Here is an annotated dump of an exchange between software running on a PC and the joystick.
The TX messages starting with C9 go from PC to joystick (using the normal programming cable), the RX messages are from joystick to PC. (or in reality a Mac as that’s what this code was running on).
Firmware versions, battery voltages for joystick, cortex and backup are available, the state of the competition switch and VEXnet communications and more I don’t have time right now to decode.
Unfortunately home made data loggers are I’m sure not competition legal.
I know this is an old thread, but I think having the ability to store data for analysis would greatly help enhance the STEM aspect of Vex. The robots could even be used as a physics demonstration. For example, the robot is driven up to speed S, at which time the motors are turned off. Yet, the robot will continue moving, which could be seen by the encoders still turning, etc. Perhaps control issues could be evaluated - for example, overshoot phenomena could be seen, etc. Another possibility might be to examine the thermal behavior of the robot, its motors, etc. Some people have asked *Where is the math or science in vex? * Having the ability to detail the behavior of the robot given various inputs would help make the connection between theory and practice. It would be a quantum leap in the robot’s educational value.
Check out SparkFun’s OpenLog module. If I remember correctly, you power it with 5-12V and then feed it data via UART; the results are stored on a standard SD card.
Can’t use it in competition, but you can log data to it for testing, trials, etc…
easyC V4 and V5 already lets you save to flash memory in the Cortex. The only catch is easyC only writes the data to flash when the mode changes enable/disable or operator control/auto. We do this to protect the flash memory from being burned out by too many writes.
Here our help file notes.
easyC V5 for Cortex Fundamentals Global Data Function
Note:
This feature is for advanced users with programming experience. If you do not feel comfortable with advanced programming techniques, do not use this feature.
The purpose of Global Data is to pass information from autonomous to operator control. This includes sensor readings, timers, and more. For example:
Passing a sensor reading (such as gyro, accelerometer, encoders)
Passing a timer value
There are 20 GlobalData addresses available (1… 20). For example:
Fundamentals