I’ve been working on a neat little program that, among other things, can pass variables between the autonomous and driver control. However, I’ve found that every time I move the competition switch between driver and autonomous, every variable I have now has a value of 0, even when said variable is global. Does anyone know a way around this? Does it have anything to do with the fact that I’m using EasyC? (Our school is looking at getting RobotC next year)
Also, this is my first post on the forums. Am I doing everything correctly and in the right area? I don’t want to break any rules on accident.
From my experience with both easyC and RobotC, easyC may not allow you to transfer variables too easily. RobotC should be better with that, but I haven’t tested it out personally.
Would you have any way of knowing what your values will be for the variables at the end of autonomous? If so, you could just set the variables to those values at the start of driver control.
EasyC is supposed to have 20 global variables that can be used to pass parameters between auto and driver control. There is a sample included with EasyC IIRC, not sure if it works correctly, I seem to remember trying this and having problems. I will have a look tonight if I have time.
If I remember correctly, this is because EasyC causes the program to reset when the competition state changes between autonomous and driver control. The idea behind this is that it prevents you from accidentally getting stuck in a loop in autonomous, however it’s quite annoying when you have to transfer data. As was said in the previous replies, you have to write to the flash memory if you want to transfer variables. It’s definitely something you can do, I can’t remember how to do it since it’s been a few years since I’ve used EasyC, but I’m sure somebody else will be able to help you out getting that working.
So the problem is EasyC, the way you would normally use global variables in any other C compiler just doesn’t work the same way in EasyC. The reason, as PYRObotics explained, is that every time the competition state changes back to disabled the cortex processor is reset (EasyC is monitoring this using a timer that generates an interrupt). Although this is not desired behavior, the developers of EasyC really had no choice as they do not run any sort of operating system and that was the only way to force the user code to stop running. Their solution was to provide some special “global data” that is stored between resets, you assign your values to these globals and they can then be recovered after driver control or autonomous starts. See the sample program included with EasyC called “Global Data”. It does work, I don’t like the way they do this, but it is what it is.
There are also some unofficial slightly more tricky ways to do this, one is to use what are known as the backup registers within the STM32, an area of memory that could in theory be protected by a backup battery but even without that provides 84 bytes that are not destroyed between resets. I created a ROBOTC library to access these a couple of years ago, it could be ported to EasyC but the programming is a little advanced.
The final way would be to use an area of high memory that is unused by your code or the EasyC stack, however, it’s a little difficult to explain how to do that and is program dependent.