Hallo Forum,
ich möchte vor dem Überlaufen einen Reset machen,
kann aber nur
...
resetzeit = millis()
if ( resetzeit > 2147483646 )
{
digitalWrite(resetpin,High); // Reset aktiv HIGH
}
else
{
digitalWrite(resetpin,LOW);
}
...
eingeben was
2147483647msec / 86400000msec/Tag = 25 Tage
einen Reset nach der Halben Zeit ergibt.
Auch damit kann ich bequem leben, aber interessehalber:
Wie löst man das?
Angehängte Dateien:
:
Gesperrt durch Moderator
Vergleich mit (2^32 - BisschenWas) machen Also z.B. 4290000000ul Das "ul" ist vielleicht wichtig.
1. Warum willst du das? Hört sich etwas irre an, deine Problemstellung. (ein Irrweg) 2. Wenn wirklich, dann baue einen endlichen Automaten, welcher das für dich abhandelt.
Arduino F. schrieb: > Warum willst du das? Weil ich das kann und das sehr gut funktioniert. Arduino F. schrieb: > baue einen endlichen Automaten Was ist denn das? LG old.
Jetzthabensieihn I. schrieb: > Wie löst man das? Indem man das Programm so schreibt, daß der Überlauf keine Rolle spielt. Dann hat man das Problem erst gar nicht und muss es auch nicht lösen.
Thomas E. schrieb: > Indem man das Programm so schreibt, daß der Überlauf keine Rolle spielt. > Dann hat man das Problem erst gar nicht und muss es auch nicht lösen. Indem man vorher einen Reset macht. Dann hat man nicht das Problem ein Programm so zu schreiben zu müssen, dass der Überlauf keine Rolle spielt. LG old.
Hi
>Weil ich das kann und das sehr gut funktioniert.
Lern einfach richtig programmieren.
MfG Spess
Jetzthabensieihn I. schrieb: > Indem man vorher einen Reset macht. > Dann hat man nicht das Problem > ein Programm so zu schreiben zu müssen, > dass der Überlauf keine Rolle spielt. Merksatz: Irren ist menschlich. Im Irrtum verharren ist Dummheit. Ich helfe dir gerne auf die Sprünge, .... Aber ich helfe dir nicht bei dieser Dummheit.
Jetzthabensieihn I. schrieb: > Indem man vorher einen Reset macht. Das ist keine Lösung, sondern ein Notbehelf, wenn einem nichts besseres einfällt. Ist ja wie in frühen Windows-Tagen, wo wegen jedem Pipifax eine Box aufging mit der Meldung "Starten Sie Ihren Computer neu" Jetzthabensieihn I. schrieb: > Dann hat man nicht das Problem > ein Programm so zu schreiben zu müssen, > dass der Überlauf keine Rolle spielt. Das ist kein Problem, sondern der richtige Lösungsansatz.
:
Bearbeitet durch User
Jetzthabensieihn I. schrieb: > Weil ich das kann und das sehr gut funktioniert. Dann ist doch alles in Ordnung. Glückwunsch! Thema kann geschlossen werden.
Jetzthabensieihn I. schrieb: > Dann hat man nicht das Problem Beratungsresistenz ist eine Zier, doch weiter kommt man ohne ihr.
Andreas S. schrieb: > Thema kann geschlossen > werden. Kannst ja vorher kurz noch meine Frage beantworten, hihi. LG old.
Jetzthabensieihn I. schrieb: > Weil ich das kann und das sehr gut funktioniert. Dein Satz ist ein einziger Widerspruch! Deswegen möchtest du Hilfe? Weil du es kannst, brauchst du Hilfe? Weil es sehr gut funktioniert, brauchst du Hilfe?
Jetzthabensieihn I. schrieb_ >> baue einen endlichen Automaten >Was ist denn das? Jetzthabensieihn I. schrieb: > Kannst ja vorher kurz noch meine Frage beantworten, hihi. > baue einen endlichen Automaten Was ist denn das? ich ziehe die deterministischen endlichen Automaten vor: https://de.wikipedia.org/wiki/Deterministischer_endlicher_Automat Aber ein Suchsystem wirft hunderte Antworten aus, wenn man es nutzen möchte.
Jetzthabensieihn I. schrieb: > Hallo Forum, > ich möchte vor dem Überlaufen einen Reset machen, > kann aber nur warum nur? du kommst mir dickköpfig und schwer belehrbar vor, wie ich vielen deiner Beiträge, wo viele dir helfen wollten und dafür nur negative Bewertungen bekamen, lesen durfte. Wozu fragst du wenn du alles weisst und nur auf Antworten wartest die dir scheinbar passen?
Jetzthabensieihn I. schrieb: > Wie löst man das? millis Überläufe sind vollkommen schnuppe, und wenn Du korrekt rechnest, dann brauchst Du NIEMALS einen Reset durchführen, sondern läßt den Controller monatelang durchlaufen, einschließlichmillis() Überläufe alle 50 Tage. Aufgrund de Tatsache, dass Ganzzahlen intern im Zweierkomplement dargestellt werden, brauchst Du nur Subtraktionen richtig anzuwenden, um über die millis überläufe hinweg korrekte Zeitdifferenzen zu ermitteln. Vom Ablauf her, weist Du die erste Zeit einer "unsigned long Variablen zu, und die Zeitdifferenz kannstDu (für Zeiträume bis ca. 25 Tage an eine long Variable zuweisen und für Zeiträume bis ca. 50 Tage an eine unsigned long. Beispiele: unsigned long startZeit long kurzeZeitDifferenz; unsigned long langeZeitDifferenz Beim Starten eines Vorgangs setzt Du dann: startZeit=millis(); Und dann kannst Du Zeitdifferenzen jederzeit so ermitteln: kurzeZeitDifferenz=millis()-startZeit; langeZeitDifferenz=millis()-startZeit; Die 'long'Variable kurzeZeitDifferenz enthält dann immer die korrekte Differenz, solange di Differenz weniger als ca. 25 Tage beträgt. Und mit der unsigned long' Variablen langeZeitDifferenz funktioniert das bis zu ca. 50 Tage Zeitdifferenz. Egal, ob zwischendurch ein millis()-Überlauf stattfindet oder nicht. Nur Zeitdifferenzen über 50 Tage kannst Du mit dem millis() Zeitzähler durch einfache Differenzbildung nicht ermitteln, und der Grund dafür ist nicht, dass in der Zischenzeit ein Überlauf stattfindet. Also wenn Du mit der internen Zeitmessung Differenzzeiten von mehr als 50 Tagen brauchst, dann mußt Du stückeln und die Differenz in anderen Einheiten als Millisekunden darstellen. Zum Beispiel immer nach Überschreiten einer Zeitdifferenz von 1000 Millisekunden eine Sekunde auf einen Sekundenzähler draufaddiren, dann kommst Du mit einer long Variablen auf über 50 Jahre bis zum Überlauf des Sekundenzählers. Und für kürzere Zeitdifferenzen als 25 bzw. 50 Tage, brauchst Du immer nur die Differenz aus einem späteren und einem früheren Stand von millis() zu bilden, und egl ob ein Überlauf dazwischen stattgefunden hat oder nicht,bekommst Du automatisch die korrekte Zeitdifferenz heraus. Abgesehen davon, dass die interne Zeitbildung mitmillis() recht ungenau ist, seit Aruino-Boars mit recht ungenauen "keramischen Resonatoren" statt mit viel genaueren Schwingquarzen getaktet wedeen. Mit keramischen Resonatoren habe ich schon Abweichungen bis zu 0,8%von der "wahren zeit" bei der internen Zeitmessung mit Arduino-kompatiblen Boards erlebt.
Joachim B. schrieb: > Beitrag "Re: Timer Probleme mit meinem Arduino UNO" Demnach ist meine Software überlaufsicher. Die Frage im Startbeitrag aber nach wie vor unbeantwortet. LG old.
Beitrag #5028387 wurde von einem Moderator gelöscht.
Jürgen S. schrieb: > Zum Beispiel immer nach > Überschreiten einer Zeitdifferenz von 1000 Millisekunden eine Sekunde > auf einen Sekundenzähler Und was schreibt man damit er statt Millisekunden Sekunden zählt? LG old.
Jetzthabensieihn I. schrieb: > Und was schreibt man damit er statt Millisekunden Sekunden zählt? > > LG > old.
1 | unsigned long secondCount,lastSecondChangeTime; |
2 | |
3 | void loop() |
4 | {
|
5 | if (millis()-lastSecondChangeTime>=1000) |
6 | {
|
7 | secondCount++; |
8 | lastSecondChangeTime+=1000; |
9 | }
|
10 | |
11 | }
|
Und schon hast Du einen Sekundenzähler(secondCount), der über 60 Jahre lang über alle millis() Überläufe hinweg hochzählt, wenn Du Dein Arduino-Board so lange ohne Reset unter Strom halten kannst.
Wg. delay(), Aufholjagt verkürzt:
1 | unsigned long secondCount,lastSecondChangeTime; |
2 | |
3 | void loop() |
4 | {
|
5 | while(millis()-lastSecondChangeTime>=1000) |
6 | {
|
7 | secondCount++; |
8 | lastSecondChangeTime+=1000; |
9 | }
|
10 | |
11 | }
|
Top, so funktioniert das. Auch Minuten, Stunden und Tage kann man so direkt eingeben. Vielen Dank. LG old.
Angehängte Dateien:
Nun kommt der Reset alle vier Tage. Habe das zuvor mit fünf Sekunden getestet. Bin begeistert. Nochmals Danke. :-) LG old.
Hi
>Nun kommt der Reset alle vier Tage.
Manche lernen es nie und andere noch später.
MfG Spess
CO2 ist ihm N. schrieb: > digitalWrite(resetpin,High); // Reset aktiv HIGH Ach ja. Noch die Antwort auf die Frage, die sich der mitdenkende Leser komischerweise nicht zu stellen traut: Nach dem Resetpin kommt noch eine kleine Schaltung die den RESET auf dem Arduinoboard ansteuert. Beitrag "Re: Atmega16 Flash leergeröntgt?" LG old.
CO2 ist ihm N. schrieb: > die sich der > mitdenkende Leser komischerweise nicht zu stellen traut Irgendwas falsches gefrühstückt? Traut? Tipp: Das interessiert einfach keinen!
CO2 ist ihm N. schrieb: > Ach ja. Noch die Antwort auf die Frage, die sich der > mitdenkende Leser komischerweise nicht zu stellen traut: > Nach dem Resetpin kommt noch eine kleine Schaltung > die den RESET auf dem Arduinoboard ansteuert. So viel ich hier auch suche, ich finde keine Frage. Also kann es ja auch nicht sein, dass ich mir nicht traue, diese Frage zu stellen...
Ein CPU-Reset kommt für mich überhaupt nicht in Frage. Es wäre ja ein Eingeständnis, daß ich in der Software Pfusch abgeliefert habe. Ich habe zwar ein Remotekommando, um einen Watchdog-Reset auszuführen. Das dient aber ausschließlich zum Starten des Bootloaders für ein Update.
Peter D. schrieb: > Ein CPU-Reset kommt für mich überhaupt nicht in Frage. Es wäre ja ein > Eingeständnis, daß ich in der Software Pfusch abgeliefert habe. Von der Einstellung solltest Du wegkommen. Ein Plus an Sicherheit geht vor Eitelkeit. LG old.
CO2 ist ihm N. schrieb: > Peter D. schrieb: >> Ein CPU-Reset kommt für mich überhaupt nicht in Frage. Es wäre ja ein >> Eingeständnis, daß ich in der Software Pfusch abgeliefert habe. > > Von der Einstellung solltest Du wegkommen. > Ein Plus an Sicherheit geht vor Eitelkeit. > > LG > old. Ordentliches Programmieren bezeichnest du als "Eitelkeit"? Lieber ziehst du in regelmäßigen Abständen den Stecker... Es würde dir garantiert nichts ausmachen, wenn dein Auto bei Tempo 140 auf der linken Spur plötzlich mal kurz ausgeht mit der Display-Anzeige "Steuergerät wird neu gestartet". Und das, weil der Programmierer seinen Job nicht beherrschte und statt dessen das Steuergerät in regelmäßigen Abständen resettet. Und das dann noch als "Plus an Sicherheit" bezeichnet. Na danke...
Sehe ich auch so. Einen Reset zu provozieren kommt auf keinen Fall in Frage.
Was erwartet ihr von jemanden, der jeden Monat seinen Namen resetet?
npn schrieb: > Es würde dir garantiert nichts ausmachen, wenn dein Auto bei Tempo 140 > auf der linken Spur plötzlich mal kurz ausgeht mit der Display-Anzeige > "Steuergerät wird neu gestartet". Genau dieses Problem hatte vor ein paar Jahren ein bekannter Zulieferer eines Wolfsburger Autoherstellers. Allerdings gab es während des Watchdog-Resets keine schicke Anzeige auf dem Display, sondern der alleine durch einen Elektromagneten aus der Lenkradsperre gezogene Bolzen fiel während des Neustarts kurzzeitig wieder ab und blockierte das Lenkrad. Der Hersteller sah aber das Risiko juristischer Konsequenzen als ausgesprochen gering an, da es keinem Gutachter gelinge, gerichtsfest nachzuweisen, dass das blockierte Lenkrad den Fehler verursacht habe und der Bolzen nicht erst nach dem Unfall ins Lenkradschloss zurückgefallen sei.
Andreas S. schrieb: > Der Hersteller sah aber das Risiko juristischer Konsequenzen als > ausgesprochen gering an, da es keinem Gutachter gelinge, gerichtsfest > nachzuweisen, dass das blockierte Lenkrad den Fehler verursacht habe und > der Bolzen nicht erst nach dem Unfall ins Lenkradschloss zurückgefallen > sei. Ist das tatsächlich der selbe Hersteller, der das Risiko, mit einer Softwaremanipulation am Motorsteuergerät erwischt zu werden, als ausgesprochen gering ansah? Und ist nicht die Automobilindustrie die Branche, die sich mit teils absurden Normen als leuchtendes Vorbild bei der Softwarestabilität hinstellt? Ich muss raus... :-(
npn schrieb: > Ordentliches Programmieren bezeichnest du als "Eitelkeit"? Nein. Das suggerierst Du um einen hinkenden Vergleich zu bringen. npn schrieb: > Lieber ziehst du in regelmäßigen Abständen den Stecker... Das muss ich mit Kunden häufig durchexerzieren. Ein regelmässiger Reset würde das Gerät selbst "reparieren". npn schrieb: > Es würde dir garantiert nichts ausmachen, wenn dein Auto bei Tempo 140 Ich möchte gar keinen uPC in der Steuerung vom Auto haben. Wie lange ich mir das noch leisten kann, entscheidet die KFZ-Prüfstelle. LG old.
CO2 ist ihm N. schrieb: > npn schrieb: >> Ordentliches Programmieren bezeichnest du als "Eitelkeit"? > > Nein. Das suggerierst Du um einen hinkenden Vergleich zu bringen. Irrtum. Der Begriff "Eitelkeit" kam von dir, um einen regelmäßigen Reset als "Plus an Sicherheit" verkaufen zu können! > > npn schrieb: >> Lieber ziehst du in regelmäßigen Abständen den Stecker... > > Das muss ich mit Kunden häufig durchexerzieren. > Ein regelmässiger Reset würde das Gerät selbst > "reparieren". Sind die Geräte ebenfalls von dir gebaut worden? Ich für meinen Teil würde ein Gerät, welches ich durch regelmäßiges Steckerziehen "reparieren" muß, schleunigst zurückbringen und mein Geld wiederhaben wollen. Du solltest endlich mal einsehen, daß das grober Pfusch ist und du nur einen Krückstock dafür bauen willst. > > npn schrieb: >> Es würde dir garantiert nichts ausmachen, wenn dein Auto bei Tempo 140 > > Ich möchte gar keinen uPC in der Steuerung vom Auto haben. > Wie lange ich mir das noch leisten kann, > entscheidet die KFZ-Prüfstelle. Und warum möchtest du das nicht? Überleg mal. Könnte eventuell daran liegen, daß du der Software nicht traust? Was ist das überhaupt für ein Auto? Meiner ist schon 25 Jahre alt und selbst da ist schon längst ein elektronisches Steuergerät drin.
npn schrieb: >> Ich möchte gar keinen uPC in der Steuerung vom Auto haben. > Und warum möchtest du das nicht? Überleg mal. Könnte eventuell daran > liegen, daß du der Software nicht traust? Bestimmt hat er da so eine Ahnung...
Beitrag #5029661 wurde von einem Moderator gelöscht.
Lothar M. schrieb: > Ist das tatsächlich der selbe Hersteller, der das Risiko, mit einer > Softwaremanipulation am Motorsteuergerät erwischt zu werden, als > ausgesprochen gering ansah? Nein. > Und ist nicht die Automobilindustrie die Branche, die sich mit teils > absurden Normen als leuchtendes Vorbild bei der Softwarestabilität > hinstellt? Ja. > Ich muss raus... :-( Diese extremen Widersprüchlichkeiten, gepaart mit der unglaublichen Überheblichkeit von "Autobastlern", sind die wichtigsten Gründe, warum ich in den meisten Fällen Aufträge aus der Automobilindustrie oder von der "großen" Zulieferern ablehne. Ich halte diese völlig einseitige Fokussierung der deutschen Wirtschaft auf ein einziges Themengebiet für eine volkswirtschaftliche Katastrophe, insbesondere weil auf politischer Ebene diese Ausrichtung nicht nur abgenickt, sondern gutgehießen und gefördert wird.
:
Bearbeitet durch User
Der Vollständigkeit halber wird hier eine Möglichkeit vorgeschlagen den AVR jederzeit in den RESET zu bringen: http://www.instructables.com/id/two-ways-to-reset-arduino-in-software/ void(* resetFunc) (void) = 0;//declare reset function at address 0 resetFunc(); //call reset Diese Methode funktioniert einwandrei.
:
Bearbeitet durch User
Gerhard O. schrieb: > Diese Methode funktioniert einwandrei. Hmm... Die Funktion stellt nicht den Resetzustand her. Nee, das würde mir in der Praxis nicht reichen. Dann doch eher den WDT nutzen. Der sollte bei solchen Anwendugen sowieso laufen. Oder? void halt() { for(;;); }
Gerhard O. schrieb: > void(* resetFunc) (void) = 0;//declare reset function at address 0 > > resetFunc(); //call reset > > Diese Methode funktioniert einwandrei. Bitte nicht. Das hat genau gar nichts mit einem Reset zu tun. Das Programm wird von vorne gestartet. Sämtliche Peripherie bleibt aktiv, Interrupts ebenso. Im schlimmsten Fall handelt man sich sogar Race Conditions ein. Diese Methode ist absolut nicht zu empfehlen. Einen Reset bei AVRs führt man über den Watchdog aus und solange man nicht weiß was man macht nicht anders! Das ändert aber nichts an der Tatsache, dass Programme welche periodisch Resets benötigten einfach nur Pfusch sind.
ok, "meine" scheint zu kompliziert zu sein, funzt aber trotzdem schön
1 | else if( !strcmp(serial_in_command, "reset") ) |
2 | { // "reset" |
3 | my_i2c_eeprom_wait_ready(); |
4 | delay(250); |
5 | {asm("ldi r30,0"); asm("ldi r31,0"); asm("ijmp");} |
6 | } // if( !strcmp(serial_in_command, "reset") ) |
Joachim B. schrieb: > ok, "meine" scheint zu kompliziert zu sein, funzt aber trotzdem > schön > else if( !strcmp(serial_in_command, "reset") ) > { // "reset" > my_i2c_eeprom_wait_ready(); > delay(250); > {asm("ldi r30,0"); asm("ldi r31,0"); asm("ijmp");} > } // if( !strcmp(serial_in_command, "reset") ) Auch das ist nur ein Neustart des Programmes, keine Spur von Reset. Es gilt das gleiche, was "avr" schon im vorigen Artikel sagte!
Joachim B. schrieb: > ok, "meine" scheint zu kompliziert zu sein, funzt aber trotzdem schön > >
1 | > else if( !strcmp(serial_in_command, "reset") ) |
2 | > { // "reset" |
3 | > my_i2c_eeprom_wait_ready(); |
4 | > delay(250); |
5 | > {asm("ldi r30,0"); asm("ldi r31,0"); asm("ijmp");} |
6 | > } // if( !strcmp(serial_in_command, "reset") ) |
7 | >
|
Das ist auch nur ein Jump auf Adresse 0, und somit kein Reset.
Harry L. schrieb: > Das ist auch nur ein Jump auf Adresse 0, und somit kein Reset. und der Unterschied? es tut das Gewünschte wenns mal nötig sein soll und sei es nur testweise um zu sehen ob Änderungen wieder aus dem I2C EEPROM übernommen werden
Joachim B. schrieb: > funzt aber trotzdem schön Ist aber ebenso kein Reset, denn im Datenblatt des Controllers stehen die Werte der Register, die bei einem Reset eingenommen werden. Die sind vermutlich deutlich anders als die, die später drin stehen. Und so kann es passieren, dass sofort nach dem "Pseudoreset" ein Interrupt kommt und ausgeführt wird, obwohl das neu gestartete Programm den SEI noch gar nicht erreicht hat. So einen Fehler findest du nie. Der tritt viel zu selten auf. Also allerwenigstens vor dem Sprung nach 0 noch die Interrupts abschalten...
Joachim B. schrieb: > Harry L. schrieb: >> Das ist auch nur ein Jump auf Adresse 0, und somit kein Reset. > > und der Unterschied? > Der Unterschied ist, daß nichts resettet wird. Die Hardware bleibt im gleichen Zustand wie vorher. Die Interrupts auch. Nur das Programm beginnt wieder von Adresse Null, mehr nicht.
Lothar M. schrieb: > Und so kann es passieren, dass sofort nach dem "Pseudoreset" ein > Interrupt kommt und ausgeführt wird, obwohl das neu gestartete Programm > den SEI noch gar nicht erreicht hat. > So einen Fehler findest du nie. Der tritt viel zu selten auf. > > Also allerwenigstens vor dem Sprung nach 0 noch die Interrupts > abschalten... guter Hinweis, kann ja noch nachgerüstet werden! npn schrieb: > Die Hardware bleibt im gleichen Zustand wie vorher. bei mir hängt keine HW dran die nicht neu initialisiert wird, deswegen lese ich ja auch aus dem I2C EEPROM ist billiger zu tauschen als der Atmel. > Die Interrupts auch, eben geklärt worden!
:
Bearbeitet durch User
Beitrag #5029739 wurde vom Autor gelöscht.
Joachim B. schrieb: > bei mir hängt keine HW dran die nicht neu initialisiert wird, deswegen > lese ich ja auch aus dem I2C EEPROM ist billiger zu tauschen als der > Atmel. Hast du bei all deinen Initialisierungen bedacht, dass eben nicht die Standardwerte in den Registern stehen könnten? Wenn etwas schief geht, dauert die Fehlersuche bedeutend länger als einfach den Watchdog zu benutzen. Was du letztendlich machst ist mir egal, so lange du deine Lösung hier nicht als Allheilmittel verkaufst.
Joachim B. schrieb: > bei mir hängt keine HW dran die nicht neu initialisiert wird Du setzt also beim Programmstart ALLE Speicherstellen/Register des Controllers auf den Stand, wie sie nach einem Reset auch sind? Ich gehe nach einem Programmstart (Reset!) davon aus, dass alle Speicherstellen/Register ihren Resetwert haben und spare mit ein ohnehin durch den Reset auf 0x00 gesetzten Wert nochmal mit 0x00 zu überschreiben. Brumm...
avr schrieb: > Bitte nicht. Das hat genau gar nichts mit einem Reset zu tun. Das > Programm wird von vorne gestartet. Sämtliche Peripherie bleibt aktiv Atmel gibt in der Link ein paar Hinweise über die richtige Methode eines softresets beim AVR: http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_softreset.html http://web.engr.oregonstate.edu/~traylor/ece473/lectures/reset.pdf Übrigens, wie machte man so etwas früher mit diskret(ICs) aufgebauten Mikrocomputer Systemen wo ein RESET nur minimal den Mikroprozessor zurückstellte? Die RESET Schaltung war damals bestenfalls irgendein Supervisor IC, idealerweise mit WDT Rückstelleingang oder sonstige spezifisch entwickelte RESET HW, welcher einen Gesamt Hardware RESET bewerkstelligen konnte; sonst blieb ja auch nichts anderes übrig als die ganze Peripherie neu in der FW zu konfigurieren, wenn ein physischer RESET der Peripherie nicht direkt möglich ist. Jedenfalls, scheint die Literatur zu bestätigen, daß WDT initiierter RESET beim AVR die "Methode der Wahl" ist.
:
Bearbeitet durch User
John D. schrieb: > Was erwartet ihr von jemanden, der jeden Monat seinen Namen resetet? Vor allem sind seine Namen einfach nur dämlich, entsprechend ist die Erwartung. Schade, dass überhaupt jemand auf diesen Kasper eingeht.
Hallo Gast, melde Dich doch erstmal mal an, damit Du einen Namen bekommst. Meiner lautet nach wie vor oldeurope. Übrigens: Klar gestellte Frage im Startbeitrag und Top-Antwort: Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" LG old.
CO2 ist ihm N. schrieb: > Übrigens: > Klar gestellte Frage im Startbeitrag und Top-Antwort: höre bitte auf die Leute zu veräppeln: CO2 ist ihm N. schrieb: > Hallo Forum, > ich möchte vor dem Überlaufen einen Reset machen, > kann aber nur > 2147483647msec / 86400000msec/Tag = 25 Tage > einen Reset nach der Halben Zeit ergibt. > Auch damit kann ich bequem leben, aber interessehalber: > Wie löst man das? 1. falsche Augabenstellung 2. Die Antwort berichtigt nur die Sache mit dem Überlauf und dann > Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" > > LG > old. und was ist daran besonders? wenn das Zählen mit den 10 Finger nicht mehr ausreicht dann nimmt man eben die 10 Zehe dazu, oder "leiht" sich 10 Finger vom Nachbarn, auf jeden Fall braucht es weitere Zähler. Alles nichts Neues, hat man doch schon vor dem Computer gemacht.
Joachim B. schrieb: > und was ist daran besonders? Der einzig interessante Beitrag von Dir hier ist dieser: Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" Übrigens hast Du dafür auch von mir auch ein "lesenswert" bekommen. Aber geholfen hat mir tatsächlich nur dieser: Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" Lernt draus wenn Ihr helfen wollt. Sonnst ärgert Euch nur weiter darüber, dass mir hier geholfen wurde. LG old.
Hi >Aber geholfen hat mir tatsächlich nur dieser: >Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" Wenn dem wirklich so ist, dann würde ich sagen: Deine Programmierkenntnisse sind eher rudimentär entwickelt. Das erklärt natürlich auch die krude Idee den Controller periodisch in den Reset zu schicken. Daher noch mal mein Tip Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" denn du kannst es nicht. MfG Spess
spess53 schrieb: > Deine > Programmierkenntnisse sind eher rudimentär entwickelt. Sind etwa drei Wochen alt und aus dem Internet zusammengesucht. Beitrag "Re: Elektrische Rollosteuerung" Ich kann Euch die Hard- und Software in einem neuen Thread gerne zeigen, wenn Ihr mir dafür Verbesserungsvorschläge geben wollt. LG old.
CO2 ist ihm N. schrieb: > Ich kann Euch die Hard- und Software in einem > neuen Thread gerne zeigen, wenn Ihr mir dafür > Verbesserungsvorschläge geben wollt. Hast du es nach diesen vielen Hinweisen immer noch nicht verstanden? Es geht nicht um die Hardware, die du an den Prozessor angeschlossen hast, sondern um die interne Hardware, deren Register bei einem Neustart NICHT auf die nötigen Defaultwerte gestellt werden, wie es bei einem richtigen Reset der Fall wäre.
CO2 ist ihm N. schrieb: > spess53 schrieb: >> Deine >> Programmierkenntnisse sind eher rudimentär entwickelt. > > Sind etwa drei Wochen alt und aus dem Internet zusammengesucht. > Beitrag "Re: Elektrische Rollosteuerung" > > Ich kann Euch die Hard- und Software in einem > neuen Thread gerne zeigen, wenn Ihr mir dafür > Verbesserungsvorschläge geben wollt. > > LG > old. Was bringen denn sämtliche Verbesserungsvorschläge, wenn du sie in den Wind schlägst? Oder willst du hören, wie clever du das doch gelöst hast?
Hi >Sind etwa drei Wochen alt und aus dem Internet zusammengesucht. >Beitrag "Re: Elektrische Rollosteuerung" Danke für die Bestätigung Meinung. Wieso erinnert mich das alles an TdB (Thomas der Bastler)? MfG Spess
Na, oldeurope ... Ich hoffe, Du erlaubst mir, mal einen etwas familiären Ton anzuschlagen. Ich habe von Dir, - hoffentlich verwechsle ich Dich nicht -, schon längere Zeit viele Beiträge gelesen und sie kamen mir in Bezug auf HF und Elektronik durchaus kompetent vor. Nun habe ich vor einigen Wochen zur Kenntnis genommen, dass Du anfängst Dich mit Mikrocontrollern und Programmierung zu beschäftigen. Das ist ein spannendes und interessantes Thema. Allerdings, - und ich hoffe Du erlaubst mir die Äusserung, da ich vermutlich nicht wesentlich jünger bin als Du -, besteht dann doch die Möglichkeit, dass man seine bisherigen Erfahrungen und Urteile, in unzweckmäßiger Weise auf das neue Thema überträgt - vielleicht auch das eine oder andere Falsche, dass aus den falschen Gründen scheinbar funktioniert hat. Da hilft es, sich selbst wieder einmal in Frage zu stellen, und was man bisher als sicher angenommen hat. Eine nicht ganz einfache Sache, zugegeben. Es kommt mir nun so vor, als wenn Du hier an so einer Stelle bist. Es ist z.B. nicht ganz einfach einzusehen, warum ein Reset eines Gerätes abgelehnt wird. Tatsächlich muss man, wie ich meine, einräumen, dass das in einem gewissen Sinn ein philosophischer Gedanke ist. Technisch scheint es (unter gewissen Voraussetzungen) keinen Unterschied zu machen. Technisch hat aber eine Sender-Schaltung viel weniger und vor allem andere Arten von Zuständen als ein Computer und er kann als eine Anordnung von dynamischen Gleichgewichten relativ vollständig erfasst werden. Das ist eine Sichtweise. Ein Rechner geht nicht in irgendwelche dunklen Gefilden von Zuständen "verloren", wenn man nicht ab und zu an der Leine ruckt und ihn zurück zu Herrchen holt. Es geht hier eher darum, dass im Idealfall immer gesagt werden kann, was er gerade tut und was er als nächstes tut - und darum bemüht man sich zuerst und vor allem. Das ist, wie gesagt, alles vor allem eine Frage der Anschauung - in Deinem Fall die einer neuen Anschauung. Hier haben einige Antworter, darunter einige der bekannterermaßen populären und kompetenten ständigen Foren-Mitglieder, sich dagegen ausgesprochen und da sie eben kompetent und erfahren sind, sind sie eine wertvolle Quelle, die man, auch als erfahrener Mensch, nicht einfach in den Wind schlagen sollte - auch wenn man das nicht auf den ersten Blick einsieht oder sogar der festen Meinung ist, im Recht zu sein. So was kann einen dann doch ab und zu täuschen. Das ist an sich nicht schlimm und berührt auch Deine bisher erworbene Kompetenz nicht wirklich. Du kennst doch den Spruch: "Man wird so alt wie eine Kuh, und lernt immer noch dazu". :-) Ich will sagen: Gibt Dir doch einen Ruck und versuche neue Gedanken zuzulassen - bei einem neuen Thema ist das ohnehin notwendig und abgesehen davon eine gute Gelegenheit was Neues zu lernen - neue Gedankengänge und Auffassungen. Falls Du Wert darauf legst, kann ich (oder ein anderer) versuchen, die Geschichte mit dem Reset mal ein wenig ausführlicher zu erklären. Auch wenn Du das am Ende für Dich nicht annimmst, so ist es doch wertvoll, diese Gedanken wenigstens zu kennen. Versuch mal über Deinen Schatten zu springen. Es wird Dir sicher Freude machen, was sich da an Möglichkeiten ergibt. Ich hoffe ich habe Deine Situation richtig eingeschätzt und die passenden Worte gefunden.
Kuno schrieb: > richtigen Reset Was macht so ein (Gast), wenn er sehen muss, dass der Reset ein "richtiger" ist? War eine rethorische Frage, die Antwort kenne ich. Beitrag "Im Startbeitrag vergessen zu erklären." LG old.
CO2 ist ihm N. schrieb: > Was macht so ein (Gast), wenn er sehen muss, dass der > Reset ein "richtiger" ist? > War eine rethorische Frage, die Antwort kenne ich. Es wurde dir schon oft genug versichert, daß ein Restart auf der Adresse Null nichts mit einem Reset zu tun hat. So wenig wie eine "rethorische" Frage etwas mit einer rhetorischen. Aber eigentlich könnte es mir auch egal sein. Wenn ich sehe, wie du jeden Ratschlag in den Wind geschlagen hast. Da hat Theor (Gast) völlig recht mit dem, was er schrieb. Wenn man auf einem neues Gebiet unterwegs ist und da logischerweise noch Denkfehler macht, wäre es schon besser, auch mal eine andere Meinung von Leuten zu akzeptieren, die sich schon länger mit der Materie beschäftigen. Das ist besser, als auf seinem (vermeintlich richtigen) Standpunkt zu beharren.
CO2 ist ihm N. schrieb: > die Antwort kenne ich Mich würde eher die Frage bzw. der Hintergrund der Frage interessieren. Wozu brauchst Du das? Wenn millis() nicht überlaufen darf, dann musst Du halt den Überlauf abfangen und und mit neuen Werten starten. Aber erklärt hast Du hier nichts (soweit ich das sehe ...). Einen "undefinierten" Reset würde ich nicht unbedingt ausführen wollen - Du weisst nicht, was da genau passiert und welchen Stand der MC nach dem "Reset" hat -> kann in die Hose gehen.
Dieter F. schrieb: > Einen "undefinierten" Reset würde ich > nicht unbedingt ausführen wollen Ich auch nicht, aber der CO2 ebenso wenig.
Dieter F. schrieb: > Einen "undefinierten" Reset würde ich > nicht unbedingt ausführen wollen - Du weisst nicht, was da genau > passiert und welchen Stand der MC nach dem "Reset" hat -> kann in die > Hose gehen. [ironie] Dann darf ich das Teil weder ein- noch ausschalten? USV davor? [/ironie] LG old.
CO2 ist ihm N. schrieb: > [ironie] > Dann darf ich das Teil weder ein- noch ausschalten? > USV davor? > [/ironie] Dieter F. schrieb: > Mich würde eher die Frage bzw. der Hintergrund der Frage interessieren. > Wozu brauchst Du das
Weil nach einem Reset die Software (ggf. wieder) korrekt arbeitet. LG old.
CO2 ist ihm N. schrieb: > Weil nach einem Reset die Software (ggf. wieder) korrekt arbeitet. > > LG > old. Kannst Du bitte antworten? Dieter F. schrieb: > Mich würde eher die Frage bzw. der Hintergrund der Frage interessieren. > Wozu brauchst Du das?
Beitrag #5030539 wurde von einem Moderator gelöscht.
CO2 ist ihm N. schrieb: > Weil nach einem Reset die Software (ggf. wieder) korrekt arbeitet. > > LG > old. Genauso wie auch dein Auto nach dem Reset der Elektronik wieder anspringt. Falls dich inzwischen niemand über den Haufen gefahren hat.
npn schrieb: > Genauso wie Vielleicht sollte man sich nach 70 Beiträgen doch mal für die Hard- und Software interessieren. LG old.
CO2 ist ihm N. schrieb im Beitrag #5030539: > Dieter F. schrieb: >> Kannst Du bitte antworten? > > quakquak Schön - Du hast also nur rumgeschwallt - merk ich mir :-) - nur blubb nix Hintergrund :-) -
CO2 ist ihm N. schrieb: > Vielleicht sollte man sich nach 70 Beiträgen > doch mal für die Hard- und Software interessieren. Ja, wäre praktisch ... für Dich
CO2 ist ihm N. schrieb: > npn schrieb: >> Genauso wie > > Vielleicht sollte man sich nach 70 Beiträgen > doch mal für die Hard- und Software interessieren. > > LG > old. Eben...
Hi
>Weil nach einem Reset die Software (ggf. wieder) korrekt arbeitet.
Ach. Wenn die Software am Anfang der im ersten Beitrag genannten 25 Tage
spinnt dann wartest du tagelang auf einen Reset? Auch wenn ich in meinen
Programmen keinen Watchdog verwende, solltest du mal darüber nachdenken
wozu der da ist.
MfG Spess
CO2 ist ihm N. schrieb: > Vielleicht sollte man sich nach 70 Beiträgen > doch mal für die Hard- und Software interessieren Wenn ich Deine Beiträge hier lese und mit Deinen (vermutlich !) Blog-Beiträgen vergleiche frage ich mich, was wohl in der Zwischenzeit passiert ist ... ? Nichts Gutes, wie mir scheint ... :-(
Ich kann überlaufsicher programmieren. Wenn man es einmal kann (Differenz klammern, dann Vergleich), passieren auch keine Fehler mehr. Letzte Woche saß ich in einem Code-Review für Extern, wo sowas mehrere Minuten falsch auf dem Bildschirm leuchtete, ohne dass jemand schwitzte oder darauf ansprang. --> Wenn ich nicht jede Zeile Code selber schreibe oder absegne, werde ich vor 2^31 Ticks einen Reset provozieren (bei 32-Bit als größtem nativen atomare Wert). --> Ein Reset nach 42 Tagen (2^32-ms-Ticks) macht keinen Sinn, da der Mehraufwand für ^32 fast genauso wie für unendlich ist.
CO2 ist ihm N. schrieb: > Beitrag "Re: Arduino unterprogramm aufrufen und nicht verlassen" > > LG > old. Passt nicht zu Dir ...
Dieter F. schrieb: > Passt nicht zu Dir .. Doch finde ich schon! Ähnlich bockig. Ähnlich angefahren worden. Beides kein Fall für eine Siegessäule, würde ich mal sagen.
Alles nach diesem Beitrag: Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" ist Spam und Trollfüttern. Arduino F. schrieb: > kein Fall für eine Siegessäule Beitrag "Re: Arduino unterprogramm aufrufen und nicht verlassen" Das war ein klarer Moderationsfehler. Aussagekräftig auch der Folgbeitrag. >> Arduinogegner Warum es die gibt ist mir klar und deshalb laufen die Threads hier so. Aus der Sicht der Arduinogegner hat der Moderator sicher alles richtig gemacht. LG old.
CO2 ist ihm N. schrieb: > Alles nach diesem Beitrag: > Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" > ist Spam und Trollfüttern. Du sollst doch nicht hungern. Perlen vor die Säue und unnötig waren übrigens eigentlich schon alle Beiträge ab Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" , aber spätestens ab Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" . Dass du die Leute nur verrarscht und keine einzige hilfreiche Antwort wert bist zeigst du in allem, was du danach geschrieben hast. Ich hoffe, dass dich ab jetzt alle mit deiner Scheiße, die du da fabrizierst alleine sitzen lassen. Beste Grüße Ein Arduino-User
:
Bearbeitet durch User
Beitrag #5031894 wurde von einem Moderator gelöscht.
CO2 ist ihm N. schrieb: > Aus der Sicht der Arduinogegner > hat der Moderator sicher alles richtig gemacht. Ein "Leck mich am Arsch" darf nicht geduldet werden. Ich stimme dem Moderator zu. Und das hat nichts mit Arduino Fan, oder Gegner zu tun. Bedenke: Der Weg vom Programmieranfänger bis zum Genie, dauert mindestens 10 Jahre. Im ersten Drittel, des Weges, schlägt dann oft der Dunning Kruger Effekt zu. Das ist in diesem Thread so, und in dem anderen auch.
Beitrag #5031900 wurde von einem Moderator gelöscht.
npn schrieb: > Sind die Geräte ebenfalls von dir gebaut worden? Schau mal da: Beitrag "Re: Fernseher schaltet sich selbst für 5s ohne Bild ein" Johannes S. schrieb: > oder die Software bei den modernen Dingern hängt sich im > Dauerbetrieb > auf und macht vorsorglich nach 24 h einen Reset :) So abwägig ist das also gar nicht. LG old.
CO2 ist ihm N. schrieb: > npn schrieb: >> Sind die Geräte ebenfalls von dir gebaut worden? > > Schau mal da: > Beitrag "Re: Fernseher schaltet sich selbst für 5s ohne Bild ein" > Johannes S. schrieb: >> oder die Software bei den modernen Dingern hängt sich im >> Dauerbetrieb >> auf und macht vorsorglich nach 24 h einen Reset :) > > So abwägig ist das also gar nicht. > > LG > old. Ich denke eher, du hast das Augenzwinkern vom Johannes nicht gesehen ;-)
@CO2 Ich glaube, bei dir ist nicht nur der Ironiedetektor kaputt.
@TE: Wenn's dir nur darum geht, dass "millis()" nicht zu groß wird, weil du Angst vor korrekten Subtraktionen im Zweierkomplement hast: Man kann den "millis"-Wert auch zurücksetzen/reduzieren, in dem man die "Geheime-1337-Haxxor-Variable" timer0_millis beschreibt.
1 | cli(); //Interrupt-Sperre ist nötig, weil der Wert auch vom timer0 geschrieben wird. |
2 | timer0_millis=0; |
3 | sei(); |
Vorsicht: Das ist, genau wie dein Automatik-Reset, riesengroßer Pfusch. Wenn du sowas machst, zeige deinen Code niemanden.
AntiMaker schrieb: > Man kann den "millis"-Wert auch zurücksetzen/reduzieren, Was soll denn diese verarsche? Sauber programmieren ist ok, aber gefährlich (ein Fehler reicht). Reset ist Pfusch, aber sicher. Dein Vorschlag ist Ironie, Dummheit, Hinterlist oder sarkastisch. Aber ganz sicher nicht hilfreich.
Achim S. schrieb: > Aber > ganz sicher nicht hilfreich. Natürlich ist er hilfreich. Gesucht ist der schlechtestmögliche Workaround, um ein eingebildetes Problem zu umgehen. Da geht meine Lösung einen Schritt weiter als die Reset-Lösung. Ironie und Sarkasmus soweit abgehakt? Achim S. schrieb: > Hinterlist Ich Habe extra die magischen Zusatzworte beginnend mit "extern unsigned..." in meinem Codeschnippsel eingespart. Gibt also beim stupiden Einsetzen einen compiler-error, und auf der Suche nach der Ursache wäre der TE hoffentlich unweigerlich auf viele viele Warnhinweise im Arduino-Forum und anderswo gestoßen. Nachdem er Sachen die hier geschrieben werden scheinbar aus Prinzip ablehnt und hier nichts lernen will, dachte ich: So hat er wenigstens eine Chance, woanders was zu lernen. Also, ja, "Hinterlist" war im Spiel.
CO2 ist ihm N. schrieb: > Weil nach einem Reset die Software (ggf. wieder) korrekt arbeitet. Warum sollte die Software nach einem Reset anders arbeiten als vorher. Mit einem Reset hat doch alles angefangen und wenn sie korrekt arbeitet, gibt es keinen Grund für einen Reset.
Ich finde das schon OK timer0_millis zu manipulieren. In manchen Situationen kann das hilfreich sein. Aber hier, zwecks Überlaufvermeidung ist das Unsinn. Denn der Überlauf macht ja nichts anders, als die Variable ebenso wieder auf 0 zu stellen. Also ist es hier flüssiger als Wasser! Überflüssig.
Angehängte Dateien:
-
arduino_reset_schema_029.PNG
2,1 KB
AntiMaker schrieb: > dein Automatik-Reset, riesengroßer Pfusch. Läuft ja nun schon eine Weile Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" und ich kann das nur weiterempfehlen. > Wenn du sowas machst, zeige deinen Code niemanden. Dort habt Ihr den ganzen Sketch mit Beschreibung. http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html Die Beschreibung zur Hardware folgt noch im Blog. Nach der Erfahrung dort, Beitrag "Arduino Lüfterdrehzahlsteuerung mit niederfrequenter PWM" ist das, mindestens für die H-Brücken, erforderlich. CO2 ist ihm N. schrieb: > Nach dem Resetpin kommt noch eine kleine Schaltung > die den RESET auf dem Arduinoboard ansteuert. Die Resetschaltung habe ich ausgeschnitten und hier angehängt. Sie funktioniert nur im Zusammenhang mit dem zugehörigen Sketch und löst einen echten Hardwarereset aus. LG old.
CO2 ist ihm N. schrieb: > Die Resetschaltung habe ich ausgeschnitten und hier > angehängt. Sie funktioniert nur im Zusammenhang mit > dem zugehörigen Sketch und löst einen echten > Hardwarereset aus. Der Watchdog schafft das ganze auch ohne zusätzliche Hardware. Einfach einschalten und nicht füttern und schon zieht er intern von ganz alleine an der Reset-Leine ohne jegliches Hühnerfutter draußen herum. Btw. Das als Lösung (Lösung triffts nicht ganz - eher extreme dirty Workaround) für ein Problem mit Integer-Überläufen ist "Murks". Wenn ich so etwas in der Arbeit versuchen würde, könnte ich mir sicher gleich meine Papiere holen. :D Hoffentlich ist Dir das mittlerweile auch bewusst. Grüße Oliver
Oliver J. schrieb: > Papiere holen Die Schaltung ist simpel, hat es jedoch in sich. Bis die Erklärung im Blog* kommt, kannst Du Dir ab da Beitrag "Re: Atmega16 Flash leergeröntgt?" bis zum Thread-Ende schonmal etwas Hintergrundwissen anlesen. Schade, dass der link #2 tot ist. LG old. * http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html
Man könnte natürlich auch einfach die Systemzeit mit nem int64_t machen. Auch bei Millisekunden-Auflösung reicht das dann für die nächsten 290 Millionen Jahre.
1 | Man kann ein Gefäß nicht füllen, das schon voll ist. |
Zitat aus irgend einem Film - aber sehr passend, wie ich finde. Bin weg ...
CO2 ist ihm N. schrieb: > Die Resetschaltung habe ich ausgeschnitten und hier > angehängt. Wer so etwas braucht oder auch nur sein Programmierleben dadurch zu vereinfachen meint, der sollte mal seinen Programmierstil gründlichst überarbeiten. So einen Watchdogmurks hat ein Programm, das auf einem Andruino Platz findet, garantiert nicht nötig, wenn man nicht nur "inkrementell", sondern eine ganz klein wenig "strukturiert" arbeitet. Nur, weil man einen üblichen Windows PC mindestens 1mal pro Woche neu booten muss, bedeutet das nicht, dass so gute Software aussieht.
:
Bearbeitet durch Moderator
Oliver J. schrieb: > Man kann ein Gefäß nicht füllen, das schon voll ist.Zitat aus irgend > einem Film Avatar (der 'dumme' Soldat (als genetischer Ersatz für Seinen verstorbenen Zwilingsbruder) entgegnet den Eingebohrenen, daß Er von Seinen eigenen Leuten für dumm gehalten wird und kein Wissenschaftler, sondern ein Krieger (des Stammes von ...kA, vergessen) wäre)
Lothar M. schrieb: > So einen Watchdogmurks ok. Das ist jetzt der zweite Thread in dem Du an einer einfachen Transistorschaltung scheiterst. Beitrag "Arduino Lüfterdrehzahlsteuerung mit niederfrequenter PWM" Lothar M. schrieb: > Wer so etwas braucht ... Programmierleben dadurch zu > vereinfachen meint, der sollte mal seinen Programmierstil gründlichst > überarbeiten. Dann schau Dir den Sketch doch erstmal an. Als Hilfe gibt es eine Sketch-Beschreibung dazu: http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html LG old.
CO2 ist ihm N. schrieb: > Dann schau Dir den Sketch doch erstmal an. Gemacht! Für einen Anfänger, schon ok. Aber mehr auch nicht. Die schlimmsten Auffälligkeiten: Schalter analog gelesen. Überflüssiges Reset Gedöns. Ungünstige Bezeichner. Keine Struktur, endliche Automaten nicht voll ausgebildet, die 2 Fenster/Rollos nicht sauber getrennt Ein if Grab. Beispiel:
1 | // Kurzschlusstrom Stoppschaltung
|
2 | if (analogRead(shunta) >= k) |
3 | {
|
4 | kurzschlussa = HIGH; |
5 | }
|
6 | else
|
7 | {
|
8 | kurzschlussa = LOW; |
9 | }
|
Dieses macht das gleiche:
1 | // Kurzschlusstrom Stoppschaltung
|
2 | kurzschlussa = analogRead(shunta) >= k; |
my2ct schrieb: > Warum sollte die Software nach einem Reset anders arbeiten als vorher Dann nochmal das Problem kurz repetiert: Die meisten Programme verwenden einen free running counter als "Herzschlag", meist im 1ms-Takt und meist 32 Bit. Der zählt etwa 4 Mrd Takte vor sich hin und läuft dann über auf 0. Das passiert nach etwa 42 Tagen. Die Variable heisst meist irgendwie Timer, z.B. t_now oder timer oder t32. Hier einfach mal t_now. Für Zeitmessungen oder Überwachungen wird die Zeit jetzt in einer Variablen gespeichert (z.B. t_start = t_now beim Einschalten eines Ventils). Später wird mit der Differenz (t_now - t_start) ausgewertet. Beispiel:
1 | if((t_now-t_start) > 1000) SchalteVentilAus(); |
Das ist völlig sauber und braucht keinen Reset, arbeitet auch beim Überlauf von t_now (bei unsigned definiert, bei signed meist auch, ist aber nicht Standardkonform). Das Problem ergibt sich erst, wenn man, wie bei uns, auch Labertaschen und Blender eigentständig programmieren lässt (weil doch alle erfahren sind). Die haben dann keine Scheu, den Code "zu verbessern".
1 | //.. beim initialisieren:
|
2 | t_start = t_now + 1000; |
3 | .....
|
4 | if(t_now > t_start) SchalteVentilAus(); |
Sieht "genauso" aus, spart ein paar Takte und ... schlägt irgendwann fehl. Das Ventil geht dann frühestens nach 42 Tagen (vielleicht) aus, manchmal auch nie (wenn t_start genau 0xffffffff). Wir machen professionelle Industrie-Automation. Da unsere Steuergeräte aber in der Regel im Mittel einmal pro Tag abgeschaltet werden, und über den Code verteilt überall solche Blitzbirnen programmiert haben, werde ich in der nächsten Generation ebenfalls die Reißlein ziehen und einen (geordneten) Reset machen bevor schlimmeres passiert. Lieber ein ärgerlicher, unerwarteter Neustart als ein gefährliches unerwartetes Verhalten.
CO2 ist ihm N. schrieb: > ok. Das ist jetzt der zweite Thread in dem Du > an einer einfachen Transistorschaltung scheiterst. Danke fürs Mitzählen. Aber: ich habe mir die Schaltung hier gar nicht angesehen, denn schon die Einstellung dahinter ist Murks. Wie der dann umgesetzt wird, ob mit Transistor oder sonstwie, ist dann nur ein kleines Murksdetail. > ok. Das ist jetzt der zweite Thread in dem Du > an einer einfachen Transistorschaltung scheiterst. Ok, ich habe mir die Schaltung jetzt doch noch angesehen und komme zum Schluss: mit ein ganz wenig Nachdenken ginge diese Reset-Funktionalität ganz ohne Transistor und vor allem ohne Kondensator. Einzig und allein ein Pullup würde ausreichen (und nicht mal den braucht man, weil im Resetpin schon einer eingebaut ist). Wenn ich sowas machen würde (z.B. weil mein Chef es neuerdings unbedingt möchte, und ich die darauf begründetete Kündigung noch nicht schreiben konnte), dann würde ich einfach einen hochohmigen Ausgangspin verwenden, den ich im Resetfall aktiv schalten würde. Und wenn der Controller dann mitbekommen hat, dass ein Reset aktiv ist, dann setzt er den Pin zum Glück wieder hochohmig. Dieser Mechanismus ist im Datenblatt ausführlich beschrieben. > Dann schau Dir den Sketch doch erstmal an. Und warum brauchst du in diesem Programm einen Reset nach 4 Tagen? Einfach so? > Dann schau Dir den Sketch doch erstmal an. > if (tagezaehler > 4) // Reset alle vier Tage Ohne Angabe eines Grundes. Genug gesehen. > Beitrag "Re: Arduino Lüfterdrehzahlsteuerung mit niederfrequenter PWM" Da noch eine Anmerkung zu deinem letzten Beitrag in diesem Thread: auch in dem verlinkten Programm sind keine Zeilennummmern. Deshalb ist die im Text angesprochene Zeile 169 auch ganz schlecht zu finden. Und wenigstens macht die Foren-SW hier nicht sowas: > steuer = (!putzen && sonneverz) != puls;
:
Bearbeitet durch Moderator
Danke für das Ansehen. Arduino F. schrieb: > Die schlimmsten Auffälligkeiten: > Schalter analog gelesen. Kein digitaler Eingang mehr frei, deshalb hängt der am analogen Eingang. Arduino F. schrieb: > Überflüssiges Reset Gedöns. Ist nicht überflüssig, Erklärung folgt im Blog. Arduino F. schrieb: > Ungünstige Bezeichner. > Keine Struktur, endliche Automaten nicht voll ausgebildet, die 2 > Fenster/Rollos nicht sauber getrennt Für mich ist das so günstig. Arduino F. schrieb: > // Kurzschlusstrom Stoppschaltung > kurzschlussa = analogRead(shunta) >= k; Top! Danke für die Erklärung. :-) Das spart if und else. Werde ich beim nächsten Sketch so probieren. Arduino F. schrieb: > Ein if Grab. Kann bisher nur if, else und algebra. Damit kann ich schon mehr machen als ich je zu träumen wagte. http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html LG old.
Lothar M. schrieb: > Schluss: mit ein ganz wenig Nachdenken Dann denk mal weiter nach. Auch darüber warum Resetschaltkreise sonnst ein Monoflop integriert haben. An den Reset sind einige Bedingungen geknüpft die man im Datenblatt findet: Beitrag "Re: Atmega16 Flash leergeröntgt?" https://www.mikrocontroller.net/attachment/331834/atmega328_reset.JPG Lothar M. schrieb: > auch in dem verlinkten Programm sind keine Zeilennummmern. Deshalb ist > die im Text angesprochene Zeile 169 auch ganz schlecht zu finden. > Und wenigstens macht die Foren-SW hier nicht sowas: >> steuer = (!putzen && sonneverz) != puls; Ein Elend ist das. Muss das alles von Hand machen und bei jeder html Umwandlung ist das wieder so. Bleibt also nur den Sketch in der Arduinosoftware zu öffnen und natürlich die Nummerierung einzuschalten. Der Sketch ist im Blog bei workupload hinterlegt. Deshalb kann ich den in Textform im Blog eigentlich löschen. Ich hoffe noch immer darauf, dass hier mal eine Codeansicht mit Nummerierung kommt. Dann verlinke ich ganz frech vom Blog auf die Codeansicht hier. LG old.
CO2 ist ihm N. schrieb: > An den Reset sind einige Bedingungen geknüpft > die man im Datenblatt findet Die einzige Bedingung für einen Reset ist, dass er ausreichend lang ansteht. Dazu das Kapitel 15.4 des mega328 Datenblatts:
1 | Reset pulses longer than the minimum pulse width will generate a reset, |
2 | even if the clock is not running. |
Dafür braucht man also das Monoflop: dass der Reset Puls "mindestens maximal 2,5µs" lautanliegt (Datenblatt tRST Minimum pulse width on RESET Pin MIN - TYP - MAX 2.5 μs). "Mindestens maximal"? Seltsame Formulierung! Licht bringt der Satz:
1 | Shorter pulses are not guaranteed to generate a reset. |
Aha, es könnte auch weniger ausreichen, aber dann ist es nicht "garantiert", dass der interne Reset-Automat seine Arbeit beginnt. Und jetzt zurück zu meiner Direktverbindung des IO-Pins (der im Reset hochohmig geschaltet wird) mit dem Reset-Pin (der einen Pullup hat): wenn dein Controller am Ausgangspin selbst den Reset ausgibt und der Reset-Automat anläuft und die Pins hochohmig schaltet, dann hat der Controller den Reset erkannt und die Bearbeitung begonnen. Garantiert. Und diesen Ablauf unterbricht er nicht mehr, biss der gesamte "Resetapparat" durchlaufen ist.
:
Bearbeitet durch Moderator
Patrick J. schrieb: > Avatar (der 'dumme' Soldat (als genetischer Ersatz für Seinen > verstorbenen Zwilingsbruder) entgegnet den Eingebohrenen, daß Er von > Seinen eigenen Leuten für dumm gehalten wird und kein Wissenschaftler, > sondern ein Krieger (des Stammes von ...kA, vergessen) wäre) Merci :). Ich glaub es war der Stamm der Ledernacken oder so ähnlich ;) Grüße Oliver
CO2 ist ihm N. schrieb: > Für mich ist das so günstig. Und muss dann sofort in die Öffentlichkeit gekippt werden... Wie gesagt, als Anfänger Code, schon ok.. Aber als Beispiel, wie man es tut, einfach Kot. Ich kann nur hoffen, dass das kein Anfänger je zu Gesicht bekommt. CO2 ist ihm N. schrieb: > Ist nicht überflüssig, Erklärung folgt im Blog. Wann denn? Nächste Woche? CO2 ist ihm N. schrieb: > Kein digitaler Eingang mehr frei, > deshalb hängt der am analogen Eingang. Kein Grund ihn auch analog zu nutzen. Und ein Mensch mit einer so großen Klappe sollte das wissen. Zumindest, hätte ein aufmerksamer Mensch, auf meine doch sehr klare Ansage, anders reagieren können. Z.B. mit Neugier, statt Ablehnung. Tja... So kann man sich irren. Bedenke: Arroganz und Kompetenz, ist für Außenstehende/Unwissende schwer zu unterscheiden. Zum Glück schaffst du da Klarheit. ---------- So, und ab jetzt stehst du auf meiner Ignorierliste, wegen Uneinsichtigkeit und maßloser Selbstüberschätzung, gepaart mit dem ungerechtfertigtem anbaffen kompetenter Forenmitgliedern.
CO2 ist ihm N. schrieb: > Arduino F. schrieb: >> // Kurzschlusstrom Stoppschaltung >> kurzschlussa = analogRead(shunta) >= k; > > Top! Danke für die Erklärung. :-) Arduino F. schrieb: > Bedenke: > Arroganz und Kompetenz, ist für Außenstehende/Unwissende schwer zu > unterscheiden. > Zum Glück schaffst du da Klarheit. > > ---------- > > So, und ab jetzt stehst du auf meiner Ignorierliste, wegen > Uneinsichtigkeit und maßloser Selbstüberschätzung, gepaart mit dem > ungerechtfertigtem anbaffen kompetenter Forenmitgliedern. ??? Ist dann halt so. LG old.
Lothar M. schrieb: > Die einzige Bedingung für einen Reset ist https://www.mikrocontroller.net/attachment/331834/atmega328_reset.JPG Da steht in der 4.Zeile Mindestimpulslänge für den Resetpuls 2,5µs. Und die bekommt er von mir*, mindestens. Was passt Dir da jetzt nicht ? LG old. * http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html
Arduino F. schrieb: > So, und ab jetzt stehst du auf meiner Ignorierliste, wegen > Uneinsichtigkeit und maßloser Selbstüberschätzung, gepaart mit dem > ungerechtfertigtem anbaffen kompetenter Forenmitgliedern. Ich glaub da bist Du nicht allein. Hier hat man ganz klar gesehen, wie man sich ganz schnell mit Arroganz, Ignoranz und ungerechtfertigter Frechheit in kürzester Zeit eine Menge Freunde macht. P.S. Es gibt leider Leute, die meinen sie wissen schon alles und alle die was anderes behaupten können einfach nicht recht haben. So etwas kann einem in Diskussionen den letzten Nerv rauben. Hab ich schon oft erlebt. Grüße Oliver
CO2 ist ihm N. schrieb: > Mindestimpulslänge für den Resetpuls 2,5µs. > Und die bekommt er von mir*, mindestens. Ohne Nachzudenken. > Was passt Dir da jetzt nicht ? Schon in Ordnung. Alles gut. Offensichtlich hast du meinen Post mit dem Reset-Automaten, der den Reset erkennt und die nötigen Schritte abarbeitet entweder nicht gelesen oder nicht verstanden. > Was passt Dir da jetzt nicht ? Dass du "Denken" auf "Datenblatt lesen", und "Datenblatt lesen" auf 1 einzige Zahl reduzierst. Schon die Note "1. Values are guidelines only" in dem von dir geposteten Screenshot spricht Bände. > Was passt Dir da jetzt nicht ? Dass da jetzt schon wieder so eine halbgare "Arduino-Bastlerlösung" im Netz herumgammelt, wo ohne sinnvolle Erklärung irgendwas gemacht wird und jeder andere "Arduino-Bastler-Anfänger" macht es einfach nach. > Was passt Dir da jetzt nicht ? Das Geplenke! Mein Vorschlag für deinen 4-Tages-Reset:
1 | Vcc |
2 | o |
3 | | |
4 | 1k |
5 | | |
6 | IO-Pin ----o----- /Reset |
Der Pullup macht den Reset-Pin etwas resistenter gegen Störungen. Und dann ist der Ablauf so: 1. durch den PowerUp-Reset wird der IO-Pin hochohmig geschaltet 2. nach dem Reset wird der IO-Pin von der Software auf Eingang belassen 3. es wird 4 Tage abgewartet 4. der IO-Pin wird auf Ausgang geschaltet und Low ausgegeben 5. wenn der Controller den Resetablauf angestoßen hat, wird der IO-Pin hochohmig geschaltet --> weiter bei 2. Das funktioniert garantiert, weil da keine Zeit beteiligt ist, sondern der Reset genau so lange Low ist, bis der Controller die Reset-Prozedur gestartet hat.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und jetzt zurück zu meiner Direktverbindung des IO-Pins (der im Reset > hochohmig geschaltet wird) mit dem Reset-Pin Bitte nicht denn so schrottest Du den Arduino. Mache bitte noch eine Diode dazwischen, aber: Lothar M. schrieb: > Garantiert. Dabei habe ich kein gutes Bauchgefühl. Und die Unterspannungsabschaltung hast Du dann auch nicht. LG old.
CO2 ist ihm N. schrieb: > Lothar M. schrieb: >> Garantiert. > Dabei habe ich kein gutes Bauchgefühl. Das hat mit Gefühlen nichts zu tun. Das ist reine Hardware. > Und die Unterspannungsabschaltung hast Du dann auch nicht. Der BrownOut läuft komplett selbständig und löst bei Spannungsunterschreitung ganz unabhängig vom Reset Pin einen Reset aus. Sonst könnte man nicht den Reset Pin per Fuse deaktivieren. > Bitte nicht denn so schrottest Du den Arduino. Wie begründest du diese Annahme? Deine Schaltung zieht doch auch einfach den Reset Pin mit dem Q18 auf Masse.
:
Bearbeitet durch Moderator
Hi Lothar M. schrieb: >> CO2 ist ihm N. schrieb: >>> Bitte nicht denn so schrottest Du den Arduino. >> Lothar M. schrieb: > Wie begründest du diese Annahme? Deine Schaltung zieht doch auch > einfach den Reset Pin mit dem Q18 auf Masse. Denke, beim Programmieren des Arduino könnte es fatal sein, wenn ein normaler I/O die Spannungen des Reset-Pin abbekommt - wenn mit >5V gearbeitet wird (kA, da der Arduino, meines Wissen, komplett per USB bespielt wird, sollte Das eigentlich egal sein). Die Diode schadet nicht, hilft aber in dem genannten Fall. MfG
Wäre es nicht viel einfacher, das eigentliche Problem zu lösen, als sich über irgendwelche Resetlösungen in die Haare zu kriegen? Man muss nur die Timerauswertung so gestalten, daß ein Timerüberlauf keine Probleme verursacht. Aber ... anscheinend wurde das bereits vor anderthalb Monaten verworfen. Die Vorgehensweise lässt sich natürlich auch bei beliebigen anderen Problemen anwenden; statt es einfach richtig zu machen, werden krustige Workarounds erfunden. Speicherlecks? Machen nix, wir machen zyklisch einen Reset. Programmm friert wegen eines Fehlers ein? Mach nix, wir machen zyklisch einen Reset. Wenn ein System sich auf derartige Mechanismen verlässt, dann ist es kaputt. Vorschlag zur Güte: Poste doch bitte mal den Code, der Deiner Ansicht nach Probleme beim Überlauf bekommt. Den können wir uns ja mal ansehen, die vielleicht fünf Minuten investieren, um das Ding wasserdicht zu bekommen ... und das Thema ist Geschichte.
Rufus Τ. F. schrieb: > Code, der Deiner Ansicht nach Probleme beim > Überlauf bekommt. Kalter Kaffee weil: CO2 ist ihm N. schrieb: > Demnach ist meine Software überlaufsicher. Rufus Τ. F. schrieb: > Poste doch bitte mal den Code http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html Kannst aber gerne trotsdem mal drüberschauen. Lothar M. schrieb: > Der BrownOut Beitrag "Re: Atmega16 Flash leergeröntgt?" Eigentlich solltest Du das schon lange gelesen haben, weil: Beitrag "Re: Arduino Reset" Patrick J. schrieb: > da der Arduino, meines Wissen, komplett per USB > bespielt wird, sollte Das eigentlich egal sein) Und wie soll das USB-IC da einen Reset machen wenn der IO-Pin vom Atmega den hochhält? Der Reset-Taster wird sicherlich gegen den Atmega gewinnen. Aber das ist doch brutal in elektronischer Hinsicht. Lothar M. schrieb: >> Bitte nicht denn so schrottest Du den Arduino. > Wie begründest du diese Annahme? Siehe oben. > Deine Schaltung zieht doch auch > einfach den Reset Pin mit dem Q18 auf Masse. Bei meiner Resetschaltung ist die Diode natürlich vorhanden. Schau mal genau hin ... Patrick J. schrieb: > Die Diode schadet nicht, hilft aber in dem genannten Fall. ... Die Basis-Emitterdiode von Q18 LG old.
CO2 ist ihm N. schrieb: > Rufus Τ. F. schrieb: >> Code, der Deiner Ansicht nach Probleme beim >> Überlauf bekommt. > Kalter Kaffee weil: > CO2 ist ihm N. schrieb: >> Demnach ist meine Software überlaufsicher. > > Rufus Τ. F. schrieb: >> Poste doch bitte mal den Code > http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html > Kannst aber gerne trotsdem mal drüberschauen. Das ist zwar Arduino-Code, aber es besteht keine Pflicht den als Nudel auszuführen. So wie der aussieht, will man den eigentlich nicht analysieren müssen. Und wo schon die ganzen eingebauten Sachen für "Unterspannng" (BOD) und "Alphateilchen/Käferchen" (WDT) nicht benutzt werden dürfen, warum dann überhaupt ein Mikrocontroller? Geht das nicht auch analog, oder gleich luftfrei, passend zum Rest der Auslage?
CO2 ist ihm N. schrieb: > Und wie soll das USB-IC da einen Reset machen wenn der > IO-Pin vom Atmega den hochhält? > Der Reset-Taster wird sicherlich gegen den Atmega > gewinnen. Aber das ist doch brutal in elektronischer > Hinsicht. Mannooo.... Deiner Ansicht nach, ist es völlig unmöglich, dass I2C mit einem AVR funktioniert! Habe ich das richtig verstanden? Nein? Dann erkläre dir selber, warum I2C doch funktioniert, obwohl die Leitungen hart von einem Pin runter gezogen werden. Man, man, du bist echt blockiert....
CO2 ist ihm N. schrieb: > Bin gespannt ob lkmiller da mitspielt. Nachdem ich das letzte Mal einen AVR vor etwa 20 Jahren (das war der AT90S1200) mit HV Programming programmiert habe, bin ich hier raus. Seither war es schlicht nicht mehr nötig. Und in keiner meiner zigtausend Schaltungen mit AVR µC ist eine Diode am Resetpin. Einen letzten Tipp hätte ich noch: eine BE-Diode ist der denkbar schlechteste Schutz vor einer hohen Spannung...
:
Bearbeitet durch Moderator
Beitrag "Re: Atmega16 Flash leergeröntgt?" M. schrieb: > eine BE-Diode ist der denkbar > schlechteste Schutz vor einer hohen Spannung... Das ist nicht die Aufgabe dieser Diode. Lothar M. schrieb: > Und in keiner meiner > zigtausend Schaltungen mit AVR µC ist eine Diode am Resetpin. Wie Du den IO-Pin open-collector-like machst, software oder hardwaremässig bleibt Dir überlassen. Du musst es nur richtig machen. Lothar M. schrieb: > bin ich hier raus Denk ich mir, weil: CO2 ist ihm N. schrieb: > Lothar M. schrieb: >> Der BrownOut > Beitrag "Re: Atmega16 Flash leergeröntgt?" > Eigentlich solltest Du das schon lange gelesen haben, weil: > Beitrag "Re: Arduino Reset" Beitrag "Re: Atmega16 Flash leergeröntgt?" Dann unterstelle ich Dir mal, dass Du das Problem, nach dem Lesen, jetzt erkannt hast und kneifst. LG old.
CO2 ist ihm N. schrieb: > Beitrag "Re: Atmega16 Flash leergeröntgt?" Mit 0,1 Vcc kommt deine Resetmonoflopgeneratorkollektorschaltung um den Q18 aber zumindest theoretisch nicht klar. Denn selbst wenn die Basis dort 0V hat (was sie aber nicht aht, weil ja der Basisstrom darüber auch nocht einen Spannungabfall produziert) kommt der Emitter bestenfalls auf 0,6..0,7V. Und kratzt damit ständig an der Grenze der Erkennbarkeit herum. Meine direkte Ankopplung schafft es aber, denn das Datenblatt garantiert bei 10mA Last maximal 0,6V am IO-Pin. Das ergibt einen Rdson des LowSide FET des IO-Treibers von 60 Ohm. Und zusammen mit dem 1k-Pullup des Arduino reicht das bei 5mA locker für weniger als 0,5V am Reset-Pin. Aber jenseits der ganzen Diskussion um diese absolut unnötige Reset-Schaltung geht es ja darum, dass der Reset bei halbwegs sachgemäßer Programmierung gar nicht nötig ist. > Dann unterstelle ich Dir mal, dass Du das Problem, nach > dem Lesen, jetzt erkannt hast und kneifst. Ja, tu das.
CO2 ist ihm N. schrieb: > Rufus Τ. F. schrieb: >> Poste doch bitte mal den Code > http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html > Kannst aber gerne trotsdem mal drüberschauen. Ich will nicht Deinen kompletten Code ansehen. Ich meinte natürlich die Stelle, die Deiner Ansicht nach Probleme beim Überlauf macht. Das dürften nur ein paar Zeilen sein, die Du doch wohl sicherlich raussuchen kannst, oder? CO2 ist ihm N. schrieb: > CO2 ist ihm N. schrieb: >> Demnach ist meine Software überlaufsicher. Wäre sie das, bräuchtest Du Dein Reset-Gehampel nicht.
Jetzt ist er beleidigt und vergibt nur noch Minspunkte. Dabei ist er doch der Erfinder des Reset-Monoflops mit BrownOutDetection. Wie schon des Spartransformators zur Spannungsanpassung. BTW, was macht eigentlich so ein Reset-Programm, wenn der MC abgeschmiert ist und keinen Triggerpuls mehr an der AußenWachhund schicken kann? Auf den internen, echten WatchDog hoffen?
:
Bearbeitet durch User
Carl D. schrieb: > BTW, was macht eigentlich so ein Reset-Programm, wenn der MC > abgeschmiert ist Das "Abschmieren" kann bei Unterspannung auftreten. Die uvlo-Schaltung verhindert das. http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html LG old.
CO2 ist ihm N. schrieb: > Die uvlo-Schaltung verhindert das. Der BrownOut verhindert das besser. Denn er verhindert auch, dass das EEPROM im Controller zerhackstückt wird. https://www.google.de/search?q=eeprom+avr+korrupt
Wenn es nicht auf jede Millisekunde ankommt kann man doch den Überlauf einplanen, registrieren und neu berechnen.. wo ist da das Problem, Simple Logik, Simple Lösung ohne Rechenaufwand? Man kann sich auch einen zweiten Timer basteln, im Core eine eigene Variable mithochzählen und und und.. wozu braucht man dann noch einen Watchdog und lange Diskussionen über mehr als bescheidene Lösungen?
Rufus Τ. F. schrieb: > Aber ... anscheinend wurde das bereits vor anderthalb Monaten verworfen. Also, noch 2 1/2 Monat bis zum reset, und dann fängt der Fred wieder von vorne an. SCNR
Lothar M. schrieb: > CO2 ist ihm N. schrieb: >> Die uvlo-Schaltung verhindert das. > Der BrownOut verhindert das besser. Lothar M. schrieb: > Mit 0,1 Vcc Alles hier im Forum mehrfach durchgekaut. Habe Dir mindestens zwei mal einen Link zu Holm's Thread gesetzt und Dich gebeten das zu lesen. Warum soll ich auf Deine falschen Behauptungen anspringen, wenn Du die Antworten doch immer wieder ignorierst. Reine Zeitverschwendung. Ich habe das trotsdem getan, weil Du hier als Moderator schreibst. Die nächste Erklärung erfolgt im Blog, spam- und werbefrei. http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html Ich weiss ja nun welche Punkte ich da ansprechen muss. LG old.
Du willst hier also nur eine Teildiskussion führen und verweist sonst ständig auf Dein "Blog". Willst Du uns mit Deiner letzten Mitteilung erklären, daß Deine externe Beschaltung sowohl der BOD als auch dem WDT der AVRs überlegen ist, die Atmel vorgesehen hat?
Rufus Τ. F. schrieb: > Willst Du uns Stellt Eure Fragen im passenden Thread und erst lesen, dann fragen!!! LG old.
CO2 ist ihm N. schrieb: > Rufus Τ. F. schrieb: >> Willst Du uns > > Stellt Eure Fragen im passenden Thread und erst lesen, dann fragen!!! > > LG > old. Wenn schon nicht hier, wo sonst?!?!
CO2 ist ihm N. schrieb: > Rufus Τ. F. schrieb: >> Willst Du uns > > Stellt Eure Fragen im passenden Thread und > erst lesen, dann fragen!!! > > LG > old. Ich sehe weit und breit keinen anderen Thread von dir, der sich mit diesen beiden Themen beschäftigt. Also: Das hier IST der passende Thread! Deshalb auch von mir nochmal die Frage: Willst du uns damit sagen, daß deine Schaltung besser funktioniert als der BOD und der WDT, die von Atmel hardwaremäßig auf dem AVR implementiert wurden?
CO2 ist ihm N. schrieb: > Ich habe das trotsdem getan, weil Du hier als Moderator schreibst. Ich habe nicht als Moderator, sondern als User geschrieben, der AVR einsetzt, seit es die Dinger gibt. Oder habe ich irgendwo mit einer "Moderatorenkeule" gedroht oder was geändert? Hätte ich mich abmelden und anonym schreiben sollen? > Die nächste Erklärung erfolgt im Blog, spam- und werbefrei. Und ohne Widerrede. Du solltest wenigstens in deinem Blog diese Diskussion hier auch verlinken. Ich mache das, wenn es dem Verständnis dient, auch wenn ich dabei den Kopf gewaschen bekomme wie z.B. da: http://www.lothar-miller.de/s9y/categories/14-Entkopplung
Beitrag #5079857 wurde von einem Moderator gelöscht.
Toto mit Harry schrieb: > Wenn es nicht auf jede Millisekunde ankommt kann man doch den Überlauf > einplanen, registrieren und neu berechnen.. Dann hast Du schon verloren! Du must Deine Zugriffe auf den Timer so gestalten, dass sie trotz Überlauf perfekt funktionieren. Oder halt den Reset, wenn Du Dich nicht auf wirklich alle Programmierer verlassen kannst.
Achim S. schrieb: > Dann hast Du schon verloren! Oder Du hast es nicht verstanden.. nochmal für ganz Dumme: https://playground.arduino.cc/Code/TimingRollover
Toto mit Harry schrieb: > Achim S. schrieb: >> Dann hast Du schon verloren! > > Oder Du hast es nicht verstanden.. nochmal für ganz Dumme: > > https://playground.arduino.cc/Code/TimingRollover Das ist doch genau das, was schon ein paarmal hier in diesem Thread gepredigt wurde! Und das ist auch das, was Achim gesagt hat: Achim S. schrieb: > Du must Deine Zugriffe auf den Timer so > gestalten, dass sie trotz Überlauf perfekt funktionieren. Was bringt dich dazu, längst bekannte und zitierte Lösungen als neu verkaufen zu wollen und dann noch jemanden auf's übelste zu beschimpfen? Toto mit Harry schrieb: > nochmal für ganz Dumme:
Sorry, nicht gesehen..mir war das einfach zuviel Text ohne Inhalt zum durchlesen. Man könnte auch in einem kleineren Teiler des angestrebten Wertes zählen.. zum Beispiel 432000 anstatt 43200000 und überprüfen wie weit man sich vor einem Overflow befindet um den Rest des Teilers zum Overflows zu benutzen.
Das Problem ist doch schlicht, daß man nicht mehr als knapp 2^32ms warten kann, indem man auf millis()+wartezeit wartet. Und das ist natürlich ein echtes Drama. Wenn ich fast 50Tage warten muß, dann ist die Arduino-Umgebung vermutlich eh nicht die richtige Grundlage. Alles kürzer 49.x Tage ist nur ein Problem vor dem Bildschirm. Oft hat das sogar einen bekannten Namen. Wären die anderen Probleme (HE) tatsächlich so wie manche hier meinen, dann müßten wir uns über AVR's nur noch im historischen Kontext unterhalten. Offenbar gibt es aber Großabnehmer, die das ohne Vodo im Griff haben.
Carl D. schrieb: > Und das ist natürlich ein echtes Drama. > Wer will, findet Wege. > Wer nicht will, Gründe! Zeiten über 49,X Tage sind kein Problem mit der Arduino IDE. Auch, wenn sie nicht von Hause aus unterstützt werden. Man muss nur wollen und tun. Die Strategie ist immer die selbe: 1. Problem erkennen 2. Lösung entwickeln 3. Anwenden(Lösung durchsetzen)
Arduino F. schrieb: > Carl D. schrieb: >> Und das ist natürlich ein echtes Drama. > >> Wer will, findet Wege. >> Wer nicht will, Gründe! > > Zeiten über 49,X Tage sind kein Problem mit der Arduino IDE. > Auch, wenn sie nicht von Hause aus unterstützt werden. > Man muss nur wollen und tun. > > Die Strategie ist immer die selbe: > 1. Problem erkennen > 2. Lösung entwickeln > 3. Anwenden(Lösung durchsetzen) Was ich meinte war: Wartezeiten von 50Tagen riechen nach Ultra Löw Power, da würde ich keine Arduino Lib verwenden. Die sind ok für schnelle Ergebnisse, aber eher nicht auf Sparsamkeit getrimmt. Aber egal, so lange warten würde man eh nicht durch "Millisekunden zählen".
Vielleicht wird der TO überrascht sein wenn er um 0 Uhr startet, immer um 0 und 12Uhr etwas erwartet und es sich immer weiter verschiebt.. Dann war die ganze Diskussion hier umsonst und er greift zu einem D3231 haha..
Toto mit Harry schrieb: > Vielleicht wird der TO überrascht sein wenn er um 0 Uhr startet, > immer > um 0 und 12Uhr etwas erwartet und es sich immer weiter verschiebt.. > > Dann war die ganze Diskussion hier umsonst und er greift zu einem D3231 > haha.. Der TO hat ganz andere Probleme. Das mit dem Millis() Überlauf ist schon längst bei ihm angekommen.
Arduino F. schrieb: > Toto mit Harry schrieb: >> Vielleicht wird der TO überrascht sein wenn er um 0 Uhr startet, >> immer >> um 0 und 12Uhr etwas erwartet und es sich immer weiter verschiebt.. >> >> Dann war die ganze Diskussion hier umsonst und er greift zu einem D3231 >> haha.. > > Der TO hat ganz andere Probleme. > Das mit dem Millis() Überlauf ist schon längst bei ihm angekommen. Vermutlich BDS, Bewunderungs-Defizit-Syndrom, die Altersvariante von AD(H)S.
Hier gibt es eine sehr ausführliche Diskussion zum Thema eines Überlauf-sicheren Timers: Beitrag "Re: rollover save timer in c"
Beitrag #5081103 wurde von einem Moderator gelöscht.
@oldeurope: Deine Beiträge sind hier offtopic. Wenn Du ein persönliches Anliegen hast, dann kläre das auch bitte durch eine persönliche Nachricht, sprich PN. Ja, ich habe Deinen sinnfreien Beitrag gelöscht, nicht Lothar.
:
Bearbeitet durch Moderator
Beitrag #5081134 wurde von einem Moderator gelöscht.
Frank M. schrieb: > kläre das auch bitte durch eine persönliche Nachricht Nachricht ja. Aber nicht persönlich. LG old.
CO2 ist ihm N. schrieb: > Nachricht ja. Aber nicht persönlich. Dann lass es. Du magst dich vielleicht mit Röhren auskennen, ich finde es auch nach wie vor gut, dass du dir neue Gebiete wie Programmierung erschließt. Wenn dir aber hier jeder, der schon ein paar Zeilen mehr in seinem Leben programmiert hat als du, von so einer „Holzhammer-Methode“ abrät, dann tätest du wohl gut daran, zumindest mal über die Argumente nachzudenken. Auf jeden Fall tust du gut daran, nicht den Programmiergott zu spielen, der du einfach mal nicht bist. (Was nicht ist, kann natürlich noch werden, das würde ich dir nicht abstreiten. Wir haben schließlich alle mal klein angefangen.)
Jörg W. schrieb: > Auf jeden Fall tust du gut daran, nicht den > Programmiergott zu spielen Äh was? CO2 ist ihm N. schrieb: > Kann bisher nur if, else und algebra. > Damit kann ich schon mehr machen als ich je zu träumen wagte. Aber freut mich, wenn mein allererstes Arduinoprojekt schon solch einen Eindruck bei Dir hinterlässt, hi hi. http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html Und danke für Deinen Teil am Arduino. Habe beim aufspielen der Sketche Deinen Namen gelesen. LG old.
CO2 ist ihm N. schrieb: > Habe beim aufspielen der Sketche Deinen Namen gelesen. Das dürfte am AVRDUDE liegen, dem Programm, mit dem das Flashen ausgeführt wird. ;-) Mein Name hängt ansonsten auch noch in der avr-libc, aber da ist er natürlich nicht so vordergründig präsent. Bitte, keine Ursache, weiterhin viel Erfolg! Back to topic: dass ein einfaches Ziehen der „Notbremse“ (also ein Reboot) keine wirkliche Lösung ist, sollte einem spätestens klar werden, wenn der Timer mal nicht mehr mit 1 kHz, sondern mit 1 MHz getaktet wird: dann läuft er (als 32-bit-Zähler) nach weniger als 2 Stunden schon über … Übrigens bist du mit dem Problem nicht allein: Windows 95 konnte nach 49,7 Tagen seine Maus nicht mehr bewegen, weil sie den Überlauf der Millisekundenzählung nicht berücksichtigt haben. OK, shit happens, bezeichnend ist nur, dass der Bug erst ca. 2000 repariert worden ist. Das lässt den Umkehrschluss zu, dass davor noch niemand ersthaft so lange einen Windows-Computer durchlaufen lassen hatte. :/
Jörg W. schrieb: > Übrigens bist du mit dem Problem nicht allein: Windows 95 konnte nach > 49,7 Tagen seine Maus nicht mehr bewegen auch atariST (TOS 1.0) nach 128 malloc Aufrufen Bomben warf, Raidsonic NAS2001b Logfile Überlauf oder der TP Link Router der nach einigen Wochen einen Neustart braucht weil man nicht mehr ins Netz kommt. Alle haben irgendwie ein Resetbedürfnis, oder anders gesagt, es wird BananenSW ausgeliefert.
:
Bearbeitet durch User
Das sind aber andere Baustellen. Hier geht's um Timer, und bei denen ist zumindest klar, dass das Problem lösbar ist, wenn man die Sache richtig angeht. (Sogar Win95 konnte nach dem Bugfix länger als 50 Tage am Stück laufen und mit der Maus bedient werden. ;-)
CO2 ist ihm N. schrieb: > Joachim B. schrieb: >> Beitrag "Re: Timer Probleme mit meinem Arduino UNO" > > Demnach ist meine Software überlaufsicher. Jörg W. schrieb: > Übrigens bist du mit dem Problem nicht allein Auch lkmiller hat das mit dem Reset schon zigtausendmal gemacht und seine Software ist doch wohl über jeden Zweifel erhaben! Lothar M. schrieb: > Und in keiner meiner > zigtausend Schaltungen mit AVR µC ist eine Diode am Resetpin. Sein Vorschlag den I/O-Pin open-collector-like zu programmieren ist auch clever. Man kann das ja in Verbindung mit dem MCP130T anwenden. Beitrag "Re: Atmega16 Flash leergeröntgt?" Und wenn das zigtausendfach funktioniert, brauche ich mir ja auch keinen Kopf um die Resetpulslänge zu machen. LG old.
CO2 ist ihm N. schrieb: > Auch lkmiller hat das mit dem Reset schon > zigtausendmal gemacht Nein, hat er nicht, und er hat (wie viele andere auch) die Intention hinter deiner Resetschaltung als Murks bezeichnet. Er hat nur geschrieben, dass er solch eine Direktverbindung zwischen Pin und Reset machen würde, allerdings nur, wenn sein Chef das von ihm dringlichst so verlangt, und auch nur, wenn er nicht bereits zuvor seine Kündigung (wegen des verlangten Murkses) eingereicht hätte … Dass man sowas für einen popeligen Timerüberlauf nicht macht, haben dir dagegen unisono hier alle gesagt. Du willst es nur nicht wahrhaben.
Meine größte Bewunderung haben die Menschen, die auch eingestehen können, sich geirrt zu haben.
Carl D. schrieb: > geirrt zu haben Das lkmiller den Pin wie einen open collector programmiert, Lothar M. schrieb: > 2. nach dem Reset wird der IO-Pin von der Software auf Eingang belassen hatte ich völlig ignoriert weil das für meine Schaltung nicht notwendig ist. Nach dem I2C-Hinweis von ufuf ist dann der Groschen gefallen! Meine Bedenken wegen der Resetimpulslänge, ist ja eher ein Glitch als ein Puls, bestehen aber (noch) weil: Jörg W. schrieb: > CO2 ist ihm N. schrieb: >> Auch lkmiller hat das mit dem Reset schon >> zigtausendmal gemacht > > Nein, hat er nicht LG old.
Und wer nicht dazu gehört dürfte klar sein.
CO2 ist ihm N. schrieb: > Meine Bedenken wegen der Resetimpulslänge, > ist ja eher ein Glitch als ein Puls, bestehen aber (noch) Der Reset ist in diesem Fall exakt genau so lang low, wie der µC-interne Reset-Automat braucht, um seinen Ablauf zu starten und in diesem Verlauf den Pin wieder hochohmig zu setzen. Das Reset-Signal wird also bei dieser Schaltung bis maximal 2,5µs aktiv sein. Die 2,5µs aus dem Datenblatt ist die Zeit, die man "maximal mindestens" braucht, dass der Automat den Reset-Low-Pegel garantiert erkennt, wenn man diese eben beschriebene Rückkopplung nicht verwendet. Das war jetzt aber die letzte Wiederholung des Themas. Für detailierte Informationen empfehle ich hierzu ein Buch zum Thema Prozessordesign.
:
Bearbeitet durch Moderator
> einen Reset nach der Halben Zeit ergibt. > Auch damit kann ich bequem leben, aber interessehalber: > Wie löst man das? Baue dir deine eigene time() Funktion... z.b. einen IRQ jede Sekunde und dann Sekunden zählen - wenn die Auflösung nicht das Problem ist. Ansonsten ist es sehr einfach den Überlauf zu behandeln. Musst einfach nur gegen den alten Wert vergleichen.
CO2 ist ihm N. schrieb: > Jörg W. schrieb: >> Auf jeden Fall tust du gut daran, nicht den >> Programmiergott zu spielen > > Äh was? > > CO2 ist ihm N. schrieb: >> Kann bisher nur if, else und algebra. >> Damit kann ich schon mehr machen als ich je zu träumen wagte. > > Aber freut mich, wenn mein allererstes > Arduinoprojekt schon solch einen Eindruck > bei Dir hinterlässt, hi hi. Hier ging es wahrscheinlich darum, dass Du andere (wohlgemerkt besseren) Lösungen für dein Problem kategorisch abgetan hast. Ein bisschen mehr Demut würde Dir beim erschließen einen neuen Themengebiets nicht schaden. Preisfrage: Wenn viele hier im Thread Dir mitteilen, dass Deine Lösung Murks ist. Ist deine Lösung vielleicht dann doch Murks oder sind die anderen mit zum Teil einigen Jahrzehnten Programmiererfahrung im Embeddedbereich einfach nur viel dümmer als jemand mit ähnlich viel Erfahrung im Analogbereich? Grüße Oliver
:
Bearbeitet durch User
Oliver J. schrieb: > Preisfrage: Wenn viele hier im Thread Dir mitteilen, dass Deine Lösung > Murks ist ... Antwort: Ist kein Murks und arbeitet ufb. Sollen sie doch mal Verbesserungen vorschlagen, die was bringen. Bisher kam nur if...else abzukürzen von ufuf. Werde ich probieren. Bringen tut das rein gar nichts. Sonnst noch etwas? Oliver J. schrieb: > Hier ging es wahrscheinlich darum, dass Du andere (wohlgemerkt besseren) > Lösungen für dein Problem kategorisch abgetan hast. Wo? link? LG old.
CO2 ist ihm N. schrieb: > Wo? link? So langsam nähert sich dein Diskussionsstil an den von Kurt... ;-)
CO2 ist ihm N. schrieb: > Bisher kam nur if...else abzukürzen von ufuf. Halte mich bitte aus deinen schwachsinnigen Argumentationen raus.
CO2 ist ihm N. schrieb: > Wo? link? Diese wurden hier gepostet und lösen das Problem des Rollovers perfekt: https://www.mikrocontroller.net/topic/goto_post/4325694 https://playground.arduino.cc/Code/TimingRollover Der Witz ist einfach: Wenn man die Differenz zweier aus millis() gewonnenen Zeiten als unsigned-Differenz betrachtet, kegelt sich ein eventueller Überlauf von selbst raus.
CO2 ist ihm N. schrieb: > Antwort: Ist kein Murks und arbeitet ufb. Ach, weil du in der Grundschule grad an dem Tag, als das "Minus-Rechnen" durchgenommen wurde, krank warst, und deshalb seitdem mit nur drei Grundrechenarten auskommen musst, ist dein Reset jetzt die "Supertolle Vorzeigelösung", für die du auch noch gelobt werden willst? Wie machst du das im Supermarkt, wenn dir die Kassiererin Geld rausgeben will? Alles wegwerfen, schreiend Nachhause rennen, frisches Geld holen, nochmal zum Einkaufen in der Hoffnung, dass du es diesmal passend zahlen kannst? Vielleicht versuchst du einfach mal, die vorgeschlagenen "überlaufsicheren" Lösungen nachzurechnen. Papier und Bleistift, ganz altmodisch. Hoffentlich geht dir dann ein Licht auf, und du verstehst, warum hier alle so aggressiv auf deine "Ich bin ein Volldepp — resettet mich hier raus" - Lösung reagieren. Oder, halte deine Lösung geheim, so dass niemand (vor allem keine leicht zu beeindruckenden Anfänger) sie sehen kann. Also weg vom Blog, raus aus dem Internet. Damit tust du der Allgemeinheit was Gutes, kriegst dann auch ein Lob von mir.
Frank M. schrieb: > Der Witz ist , dass Du weder meine Beiträge gelesen, noch den Sketch angesehen hast. Beitrag "Re: Arduino zu millis() long und Reset vor dem Überlaufen" LG old.
Nein, der witz ist, dass seine Antwort mehr zur Lösung als alle Antworten deiner beiträgt.
Beitrag #5082577 wurde von einem Moderator gelöscht.
CO2 ist ihm N. schrieb: > noch den > Sketch angesehen hast Ich hab ihn ganz kurz angesehen. Und dann hab ich ihn weggeklickt. Einen so mies formatierten und willkürlich eingerückten Code lese ich nicht.
Lothar M. schrieb: > Nur 1 Name pro Thread. Steht so in den Nutzungsbedingungen Hier schreibt eh nur eine Hand voll Leute. Meinetwegen können die ihren Nick mit jedem Beitrag wechseln. LG old.
CO2 ist ihm N. schrieb: > Antwort: Ist kein Murks und arbeitet ufb. > Sollen sie doch mal Verbesserungen vorschlagen, > die was bringen. > Bisher kam nur if...else abzukürzen von ufuf. > Werde ich probieren. Bringen tut das rein gar nichts. > > Sonnst noch etwas? Sorry, aber ab jetzt kann ich Dich einfach nicht mehr ernst nehmen. Wahnsinn! [Ironie] Also wenn es unbedingt die Reset-Lösung sein muss, dann doch bitte in spektakulär: Wie wäre es mit einem Servo, der einen ResetTaster drückt? Für Servos gibts bestimmt gute Bibiotheken für Arduino. [/Ironie] Wünsche noch viel Spaß beim Finden weiterer uneleganter und unnötig komplizierter Lösungen. Grüße Oliver
Md M. schrieb: > lese ich nicht Damit andere lesen können was Du nicht liest: http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html LG old.
Hi >Damit andere lesen können was Du nicht liest: >http://meinearduinoprojekte.blogspot.de/2017/07/so... Wie oft willst du diesen Mist noch anpreisen. Das kann ein zwölfjähriger zehnmal besser. Oder must du das "Interesse" an deinem sog. Blog mit diesem Thread hier künstlich hochhalten weil sonst niemand dort vorbeikommt? MfG Spess
spess53 schrieb: > Hi > >>Damit andere lesen können was Du nicht liest: > >>http://meinearduinoprojekte.blogspot.de/2017/07/so... > > Wie oft willst du diesen Mist noch anpreisen. Das kann ein zwölfjähriger > zehnmal besser. Oder must du das "Interesse" an deinem sog. Blog mit > diesem Thread hier künstlich hochhalten weil sonst niemand dort > vorbeikommt? > > MfG Spess Wie heißt es so schön: Alles hat einen Sinn, notfalls als abschreckendes Beispiel. Und der konkrete Fall ist einer in Not.
Beitrag #5083573 wurde von einem Moderator gelöscht.
Beitrag #5083588 wurde von einem Moderator gelöscht.
Carl D. schrieb: > ist einer in Not Weil Ihr den link verfuddelt habt. http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html LG old.
CO2 ist ihm N. schrieb: > Weil Ihr den link verfuddelt habt. NEIN du verfuddelst alle Links (schrieb ich ja schon mal) man weiss nie worauf du dich beziehst, in deinem Blog wird einfach mitten in den µC.net Thread gesprungen, Informationsgehalt was du sagen wolltest = NULL Was ist so schwer für dich die Links dahin zu setzen wo sie hinzeigen sollen? Das muss also Satire oder Eigenwerbung sein!
:
Bearbeitet durch User
CO2 ist ihm N. schrieb: > Lothar M. schrieb: >> CO2 ist ihm N. schrieb: >>> Die uvlo-Schaltung verhindert das. >> Der BrownOut verhindert das besser. > > Lothar M. schrieb: >> Mit 0,1 Vcc > > Alles hier im Forum mehrfach durchgekaut. > Habe Dir mindestens zwei mal einen Link zu Holm's > Thread gesetzt und Dich gebeten das zu lesen. > Warum soll ich auf Deine falschen Behauptungen anspringen, > wenn Du die Antworten doch immer wieder ignorierst. > Reine Zeitverschwendung. Ich habe das trotsdem getan, > weil Du hier als Moderator schreibst. > Die nächste Erklärung erfolgt im Blog, > spam- und werbefrei. > Ich weiss ja nun welche Punkte ich da ansprechen muss. Für den Reset habe ich das jetzt getan: http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html LG old.
Ich habe mir jetzt echt mal die Zeit genommen und in dein Code reingeschaut... 1) Wie schon oft erwähnt, ich bin ebenfalls der Meinung: Der Reset muss nicht sein, er zeigt lediglich auf, dass der Code ein Design-Problem hat. 2) Ist es beim Arduino eigentlich sichergestellt, dass globale Variablen mit 0 Initialisert werden? Denn eine Initialisierung deiner verwendeten Variablen existiert nicht. Somit könnte es zum Fehlverhalten führen. z.B.:
1 | // Reset
|
2 | if (millis() - startreset >= 86400000) // 86400000ms = 1Tag |
oder
1 | if ( millis() - startp >= 1000) |
Angenommen millis() liefert in der Anfangszeit einen "kleinen" Wert und in startreset oder startp steht per Zufall eine "große" Zahl, schon hast du eine positive if-Abfrage: if(1550 - 4000567 >= 86400000) // Ja, wäre hier der fall 3) Wenn der Code so funktioniert ist OK, aber zu lesen ist es schrecklich! Nicht einmal 1 Leerzeile. Als hätte man den Code zu einem riesen Klumpen zusammen gequetscht. Schöner wäre eine Timer-ISR und vllt. eine Time-Struct, mit millis, Sekunden, Min. usw. bis hin zum "Datum" vllt.?! Dann könntest du elegant auf Tage prüfen und nichts würde jemals überlaufen. z.B.:
1 | /* Uptime des Systems */
|
2 | typedef struct |
3 | {
|
4 | uint32_t days; |
5 | uint8_t hour; |
6 | uint8_t min; |
7 | uint8_t sec; |
8 | uint16_t ms; |
9 | } sys_uptime_t; |
Und wenn man nun noch "days" durch ein Datumsformat ersetzt, dann würde das System auch nicht nach 2^32 Tagen ein überlauf haben (> 11 Mio. Jahre) :-D Gruß
:
Bearbeitet durch User
Adam P. schrieb: > 2) Ist es beim Arduino eigentlich sichergestellt, dass globale Variablen > mit 0 Initialisert werden? Bitte die C/C++ Sprachdefinition lesen. Für die faulen: Ja!
CO2 ist ihm N. schrieb: > CO2 ist ihm N. schrieb: >> Lothar M. schrieb: >>> CO2 ist ihm N. schrieb: >>>> Die uvlo-Schaltung verhindert das. >>> Der BrownOut verhindert das besser. >> >> Lothar M. schrieb: >>> Mit 0,1 Vcc >> >> Alles hier im Forum mehrfach durchgekaut. >> Habe Dir mindestens zwei mal einen Link zu Holm's >> Thread gesetzt und Dich gebeten das zu lesen. >> Warum soll ich auf Deine falschen Behauptungen anspringen, >> wenn Du die Antworten doch immer wieder ignorierst. >> Reine Zeitverschwendung. Ich habe das trotsdem getan, >> weil Du hier als Moderator schreibst. >> Die nächste Erklärung erfolgt im Blog, >> spam- und werbefrei. >> Ich weiss ja nun welche Punkte ich da ansprechen muss. > > Für den Reset habe ich das jetzt getan: > > http://meinearduinoprojekte.blogspot.de/2017/07/so... > > LG > old. Was soll das denn? Was willst du uns damit mitteilen? Möchtest du damit behaupten, dass deine Resetschaltung zuverlässiger ist, wie der eingebaute WDT? Dass dein Programm, auch während eines Hängers, zuverlässig einen Reset ausführt? Das der BOD, auf 4,3V eingestellt, nicht für deine Zwecke reicht? Das alles möchtest du uns damit sagen, oder? ???
Arduino F. schrieb: > Was soll das denn? > Was willst du uns damit mitteilen? Einfach seinen inhaltsleeren Beitrag zur Überprüfung melden. Würde mich wundern, wenn der nicht gegen Forenregeln verstösst.
Arduino F. schrieb: > Bitte die C/C++ Sprachdefinition lesen. Erledigt. Sorry, hatte ich gar nicht dran gedacht.
Arduino F. schrieb: > Das der BOD, auf 4,3V eingestellt ... Das will ich mal nicht hoffen. https://de.wikipedia.org/wiki/Universal_Serial_Bus#Spannungsversorgung und da hängt noch eine Diode zwischen. Deshalb meine Bemerkung im Blog. OK, die konntest Du nicht lesen weil Dein Link nicht geht. ;-) Hier der korrekte link zu meinem Blog: http://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html oder von Hand in die Browserzeile kopieren: meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefens ter.html hänge ich deshalb ab jetzt an jeden meiner Beiträge. :-) LG old.
Thread beobachten
Seitenaufteilung abschalten