"The AVR datasheet talks about it as being an incomplete reset cycle as the pin won't stay low long enough before the reset process turns all I/O pins to input mode."
which I don't really care. Or should I?
My setup does set all pins and writes low or high whatever I need them to be. If the reseting does not complete itself and lets my pins latest statues, won't it be reseted with my setup? Or this cut process only resets main function, and cannot deport back to setup?
Would be great if anyone knows and tells me the magic behind reseting.
The magic is in the datasheet.
Hardware reset does more than a software reset (jump to 0 basically), and has to be applied for some minimum time.
Hardwareeset also puts the IO pins into Input - and if that occurs fast enough, Reset won't be applied long enough and you could end up in some weird state.
Try it yourself, see what happens. If you have a 'scope, capture the transition and see what it looks like.
Generally you should just do a watchdog reset. The only limitations of that approach are:
Some bootloaders (such as the stock ones for Pro Mini and Nano) have a bug that causes the Arduino to go in an endless reset loop after a watchdog reset.
Some bootloaders (such as optiboot) are not activated after a watchdog reset. This is an issue if you're trying to upload to your Arduino via a non-standard communications method such as an ESP8266 module.
For a proper self hardware reset you're going to need extra components, such as the DS1232 recommended in that thread. I'd be interested to hear the most minimal solution for just getting a reset pulse of sufficient duration.
You can use the DS1232 (sweet chip) or the IRFD110, a diode, and 10K resistor.
Wire Pin 9 on UNO -> diode -> Gate -> Gate to 10k -> GND and Source -> GND and Drain -> reset pin
Write pin 9 HIGH in the loop to initiate a RESET. This quickly brings the gate high turning on the FET grounding the RESET pin. Setup runs and reinitializes everything. You may want to add 50pf capacitance to the gate to make sure things work as expected. I've had this setup looping for 30mins.
You need a much bigger cap than 50pF.
What happens is as soon as the reset goes high the I/O pins are set to be inputs which stops driving the FET and so removing the reset. This happens very early in the reset cycle. So the reset must be held low for the minimum time as stated in the data sheet.
The fact that one setup appeared to work is neither here nore there, if the reset is not held low for the required time.
The diode prevents the gate from discharging at the input. This will work with no capacitor at all using the FET. If you want a longer RC time constant sure increase the resistor or capacitor values, but it is not needed to reliably trigger a reset on the UNO. You can probably use any FET with a gate threshold of 2-4v.
Data sheet indicates min reset pulse of 2.5us. Would need a larger cap. or that 10k should be 100k. Probably not a good idea to rely on gate capacitance as this will likely change from FET to FET.
Grumpy_Mike:
Yes you should. Only an idiot ignores what it says in the data sheet.
What I mean was not "whatever duuuude I do want duuude". The talked answer was all about "pin setup reseting may not be done within time", which as I said I don't care IF the first process of reseting teleports me to "setup" configuration. I set all pins, as I should.
Another question is, bigger cap means charge time. Can I burn an IO pin if I do resets frequently? IO should feed the cap at short-cut amount of current, isnt?
afebe:
What I mean was not "whatever duuuude I do want duuude". The talked answer was all about "pin setup reseting may not be done within time", which as I said I don't care IF the first process of reseting teleports me to "setup" configuration.
If you don't cair to learn then why should anyone cair to try and teach you?
Grumpy_Mike:
If you don't cair to learn then why should anyone cair to try and teach you?
You know much less than you think you do.
I don't know why you don't understand. If I put it clear; easier, simplier;
IF resetting process works as;
Jump to 0 > reset pins as input
Then absolutely I don't care either process cut in second step or not. I need to jump 0, which is done. I set all pins in software, so I don't need any pin resetting. The resetting I need is completely done. No more. If cutting process lead me to unwanted situations as CrossRoads said I need to observe on run. But manor_royal says how much reset I need. If cutting no problem, I have no problem.
HOWEVER, if resetting occurs as;
Reset pins as input > jump to 0
Yes, I have big trouble.
OK now?
I may not know much not even much you thought. I'm here because I don't know well as I need. However I did nothing wrong, said nothing wrong, but your reply was rude.
If you only need to jump to 0 then just do that in software. If you need a proper hardware reset then add the components to make sure you get a long enough pulse. If you don't need the bootloader to be enabled after reset and are running (or can install) a bootloader without the watchdog bug, or are not using a bootloader then do a watchdog reset. I don't understand the benefit of using a pin and adding wiring just to get a possibly incomplete hardware reset. Maybe there's something I'm missing here.
pert; thanks for info.
Can I safely trust soft reset? Project got 2 arduinos talking over bluetooth and have a messed up environment. Lots of AC disturbation and I sometimes loose the info or got corrupted data.
I used a "wait in setup before a trusted serial info come, than run" as said in setup. Using a sub function same as setup, and trigger the endless loop with incoming corrupted data will probably work. Does waiting in sub or in setup changes anything?
afebe:
Project got 2 arduinos talking over bluetooth and have a messed up environment. Lots of AC disturbation and I sometimes loose the info or got corrupted data.
I used a "wait in setup before a trusted serial info come, than run" as said in setup. Using a sub function same as setup, and trigger the endless loop with incoming corrupted data will probably work. Does waiting in sub or in setup changes anything?
I don't understand what you mean. If you have a situation where the Arduino could lock up or the program could hang then using the watchdog timer is helpful because it will automatically do a reset if the timer isn't reset before the end of the timeout duration you have set. I had considered using a supervisor chip like the DS1232 in one of my projects but after doing some research it sounded like the watchdog is pretty reliable. Which Arduino board are you using?
sorry, jumping to 0 is what I mean. Or locking the arduino in an endless sub loop till meaningful info comes, and runs back to regular routine. similar to;
void waitTill(){ // called when an error occurs (corrupted data)
bool i = 0;
do{
if Serial.availabe(){
char O = Serial.read();
char K = Serial.read();
Serial.flush()
if (O == "O" && K == "K" )
i = 1;
}while (i !=1);
(there could be syntax error above)
2 megas and yes, what I'm afraid is communication errors may disturb the secondary arduino and break things.
System has a extended keypad and hc-05 in controller box, using mega. And the secondary mega uses shift registers to run relays, leds, motors, etc. on different pcbs. I have to set all registers to 0, and disable all relays connected to IO pins with transistors. Reseting does this, and I thought it would be the easiest solution to put a jumper cable to unused IO.
It doesn't sound like a reset is required at all but since the Mega's bootloader doesn't have the watchdog bug you can use the watchdog to reset the Arduino if you like:
#include <avr/wdt.h>
void setup() {
resetMCU();
}
void loop() {}
void resetMCU() {
wdt_enable(WDTO_15MS); // Enable the watchdog timer with a 15 millisecond timeout duration
while (true); // Wait for the watchdog to timeout and reset the microcontroller
}
It does take 15 ms for the watchdog timer to time out but you are guaranteed to get a full reset with no wiring necessary.
The watchdog can also be used to reset the microcontroller if the program ever hangs. To do this you will call wdt_enable() in setup and then make sure in your code you always call wdt_reset() before the timeout value you set via wdt_enable() expires. The code shouldn't hang under normal circumstances but this provides a level of automatic recovery in case of a bug or other issue in applications where you need to be sure the code will keep running.