SukkoPera:
Funziona perché lasci le graffe. Quel do{}while(0) è un costrutto particolare per far sì che quella macro possa apparire ovunque come se fosse una normale istruzione ed evitare cose come quella che è successa a te. Probabilmente è un po' "esagerato" in questo contesto ma fa quel che deve.
In effetti mi sembrava strano che non ci fossero le graffe nel primo codice che usavo; nel pomeriggio provo, ma a logica direi che ci sarebbero dovute essere pure li, giusto?
A me però succedeva una cosa ben più strana: freezava tutto non solo quando sceglievo di fare il reset, ma anche quando confermavo da altre voci di menu, cioè quando la if ( MenuPos == 10 ) NON avrebbe dovuto consentire le due istruzioni successive.
Se non dico una castroneria troppo grossa (che però ci sta nella sequenzialità senza graffe che racchiudono) è come se le tre righe che riporto qui venissero:
1.- la prima valutata e deciso di non eseguire la successiva
2.- la seconda valutata (percorsa?) comunque anche se non eseguita
3.- la terza idem, valutata e non eseguita
E poi a ruota la chiamata a Reset_AVR(); faceva "percorrerre" anche wdt_enable(WDTO_30MS); ma la sequenzialità di istruzioni non eseguite per la 1.- si interrompeva e il successivo while (1) {} bloccava il tutto.
if ( MenuPos == 10 ) // --- Conferma il Reset // *****
if ( D2Set[20] == 1 ) // *****
Reset_AVR(); // *****
Non mi torna dalla parte in rosso in poi.
Se ho ragionato bene fin li, la sequenzialità degli if() senza le graffe dovrebbe interrompersi e proseguire alla riga successiva alla 3.-
Perché verrebbe "percorsa" anche la riga nel #define?