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?
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.
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.
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:> 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.
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.
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.
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...
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...
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.
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.
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.
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!
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!
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.htmlhttp://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.
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.
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.
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.
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 - 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
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?
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.
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.
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.
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
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.
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 ;-)
@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.
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
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.
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.
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)
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:
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;
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.JPGLothar 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.
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.
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.
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.
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 Codehttp://meinearduinoprojekte.blogspot.de/2017/07/sonnenschutz-fuer-nostalgiefenster.html
Kannst aber gerne trotsdem mal drüberschauen.
Lothar M. schrieb:> Der BrownOutBeitrag "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...
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?
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?
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
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.
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.
@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.
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.
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.
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.
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ückkopplungnicht verwendet.
Das war jetzt aber die letzte Wiederholung des Themas. Für detailierte
Informationen empfehle ich hierzu ein Buch zum Thema Prozessordesign.
> 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
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:> 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.
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
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.
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!
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.:
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
typedefstruct
3
{
4
uint32_tdays;
5
uint8_thour;
6
uint8_tmin;
7
uint8_tsec;
8
uint16_tms;
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ß
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.
Also, ich denke, jetzt ist vorerst alles gesagt. Wenn einer meint, es
gäbe noch was Sinnvolles und Sachliches zu sagen: einfach eine PN mit
einer brauchbaren Begründung an mich oder einen anderen Moderator.
Der oft wiederholte Link taucht ja mittlerweile mehr als 10x im Thread
auf. Das dürfte also auch ausreichen...
Thread beobachten
Seitenaufteilung abschalten