I am now resetting using "asm volatile (" jmp 0"); and it works but I would like to leave the variables as is. I want to leave the LCD backlight off. I can supply the code if necessary.
Thanks, Bill
I am now resetting using "asm volatile (" jmp 0"); and it works but I would like to leave the variables as is. I want to leave the LCD backlight off. I can supply the code if necessary.
Thanks, Bill
Hi Bill,
A software reset can (sometimes) be a good thing to do to handle situations as you describe (program runaway for instance).
I was just addressing that second point in you original question, i.e, regardless of the way the reset occurs (jmp zero, watchdog programmed reset, or forcing a pin as mcb1 mentions), the variables can not be assumed to remain the same (despite power not having been removed from the chip), because in-between the reset and the Arduino main/loop etc, there is a bit of invisible code (called C startup or similar) which will force some variable storage to zero. Any that are not forced to zero cannot be presumed to be uncorrupted anyway, due to the program runaway which might have caused the reset (so that was the only reason I wanted to confirm why the reset was to occur, because we have to presume loss of all state information upon reset (regardless of the way the reset occurs) unless state can be inferred from elsewhere (e.g. logic levels on pins or non-volatile memory).
It seems that watchdog timer, Interrupt, reset button, and asm volatile (" jmp 0") , will do the same thing except that watchdog timer and Interrupt sends code execution to a specified place. Also the interrupt requires a physical connection. Maybe I should add a MC switch on the reset pin? The case is already built but that is also a possibility. Please also see my response to shabaz.
Bill
Thank you. My comment was not meant in any way to be criticizing. Quite the opposite. I can't thank you and the others on the forum enough for all the help. I take every comment in the way it is intended, that is, to be helpful.
Hi Bill,
You're too kind, it was no problem at all to help. I just wasn't sure if the second part (regarding the state of variables had got lost in the discussion since the thread had grown a bit since I last saw it!).
I don't know much recent stuff about Arduino, but I learn a lot from following what you and others do with it. From that I gather it
has underlying C compiler, just the compiling/building of the code is hidden from the user to a degree.
Not that I am a software programmer, but I tend to force/set variables either during the initial declaration or during void setup().
Call me stupid but I always imagined it was better to be sure.
Mark
Hi Mark,
I do too, it would be thrown out in a code review if it wasn't, so I agree. I interpreted Bill's query to be whether there was a way to maintain variable content across a reset regardless of whether it was wise or not. The answer being no, not all variables will be persistent (some data spaces are).
Better than using them with garbage. Otherwise GIGO (garbage in, garbage out).
Clem
I think more specifically it would be fare to say you "Can Not Guarantee" the preservation of volatile RAM through a reset condition so therefor should NEVER rely on it happening
If you need variables preserving across resets either software invoked or Power Cycle then you need to use None Volatile RAM, either the EEPROM or an external SD Card
Hi Peter,
In theory if you're careful, the behaviour is guaranteed. The JMP 0 won't corrupt memory, it is a legal instruction. However, as mentioned several times, the compiler and C-startup code will have defined behaviour, and it depends on the scope of the variables. That part is outside of our control (unless we rewrite it, or use a different language or just write in assembler).
In real life, the answer is obviously no for a couple of reasons, primarily because if you've had program runaway then you cannot assume your important variables have not been corrupted either, and secondly in real life no-one would ever be allowed to have such code in a shipping product since it won't pass any code review.
But it may not take much to mess that up, for instance a pin state (Input) being different during the power on first time run causing the order of the variable creation to be different, now your really messed up.
Yes there are ways around it to improve the odds of the ram to be intact but is it worth the headaches, and it still does not help you with a power on reset as here there are no guarantees and the code really does not know the difference.
Though some MPU;s have a flag to indicate if the reset was a POR or Soft but i'm not sure if the AMEGA328 has that