vergiss das.
Wenn du "millis" verändern würdest, hast du EINEN neuen Testfall abgedeckt
Fehler können - wenn man sich nicht genau an Blink Without Delay hält - aber auch zu jedem anderen Millisstand auftreten.
"millis" Rollover kann man gut mit einer Byte Variable beweisen dass es kein Problem ist.
echt testen kannst du nur mit echten millis und 49 Tage lang beobachten ob Fehler auftreten.
Googeln wird dir helfen um Sicherheit zu bekommen: wenn deine if's richtig sind, ist der Rollover kein Problem.
Die if-Abfragen sind schon so gestrickt, dass es passen sollte, z.B.
if ((millis() - millis_antenne_alt > 500)) // alle halbe Sekunde die Antenne ein-/ausschalten (= Zeichen, dass Aktualisierung möglich ist)
{
millis_antenne_alt = millis();
Wenn ich das Setzen des timers gleich zu Beginn in setup() einbaue, wird der Sketch erst einmal gebremst (keine Ahnung warum), dann läuft er aber los und die millis() laufen auch brav über.
(a-b < 0) ist genau so ein Ausdruck, wie auch beim "Blink Without Delay" verwendet wird.
Wenn man das mit byte veranstaltet, und darum drehte es sich ja, dann beweist mein Beispiel, dass der Unterlauf bei der Subtraktion eben NICHT den Überlauf kompensiert.
Das "Blink Without Delay" Prinzip ist somit nicht so einfach auf byte als Datentype übertragbar.
Erst ein Cast byte(a-b) würde die Situation retten if(byte(b-a) < 0) Serial.println(F("b-a") );
warning: comparison is always false due to limited range of data type [-Wtype-limits]
Ich weiß, bei "Blink Without Delay" wird meist > oder >= verwendet. Aber das würde das Problem nicht so deutlich in den Vordergrund drücken.
Teste mal, nur so zum Spass:
byte a = 200;
byte b = 200;
if(a+b >= 300) Serial.println(F("Aua!") );