Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
Später Gast
Beiträge: 1697
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

jodurino hat geschrieben: Mi 28. Okt 2020, 16:34
Gibts da was einfachres für mich?
Was willste denn anzeigen?

Sehr einfach einzubinden find ich die verschiedenen siebensegment anzeigen, also max7219, tm1637, tm1638, ht16k33, ...

Die mehrzeiligen lcd ( zB. 4x20 character) fand ich auch noch gut machbar. Da geht's dann aber auch schon los, dass man kucken muss, wo im Display man was schreibt und wieviel/wie oft, sonst gibt's Probleme.

Alles, was GFX will ist für mich raus. A) bekomm ich das nicht auf die Pfanne und B) sind Arduinos dafür ne Nummer zu klein. Gut mit dem Mega2560 vllt schon, aber da scheitere ich dann wieder an A). :roll:

Grüße
Moritz
jodurino
Beiträge: 2104
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Später Gast hat geschrieben: Sa 31. Okt 2020, 13:40
jodurino hat geschrieben: Mi 28. Okt 2020, 16:34
Gibts da was einfachres für mich?
Was willste denn anzeigen?

Sehr einfach einzubinden find ich die verschiedenen siebensegment anzeigen, also max7219, tm1637, tm1638, ht16k33, ...

Die mehrzeiligen lcd ( zB. 4x20 character) fand ich auch noch gut machbar. Da geht's dann aber auch schon los, dass man kucken muss, wo im Display man was schreibt und wieviel/wie oft, sonst gibt's Probleme.

Alles, was GFX will ist für mich raus. A) bekomm ich das nicht auf die Pfanne und B) sind Arduinos dafür ne Nummer zu klein. Gut mit dem Mega2560 vllt schon, aber da scheitere ich dann wieder an A). :roll:

Grüße
Moritz
Hi
bin da blauäugig an die Sache heran gegangen, dachte wenn ich schon so ein tft und Mega in der Bastelkiste habe, schnell vertüdeln
Software aufspielen und dann mit dem anderen Arduino Nano über txd rxd verbinden und sich die Daten anzeigen lassen wo der IDE Monitor immer den Reset macht beim Aufrufen.
Das wollte ich eben umgehen.
Soll nix dauerhaftes werden nur jetzt für die Entwicklung der Software mal die Statüssers der Ein und Ausgänge abfragen.
Wenn alles zusammen gechraubt ist komme ich nur noch über USB an den Nano, oder halt über TXD/RXD direkt.
Muss halt eine gewisse Reienfolge bei den Ausgängen einhalten und das möchte ich überwachen bevor ich alles "Scharf" verbinde.

cu
jodurino
Benutzeravatar
Später Gast
Beiträge: 1697
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Ah ok, also für so Development- und Debug - Zwecke. Da hab ich für meinen Wecker so'n 4x20 lcd hergenommen und fand das sehr praktisch. Irgendwann ist mir der Speicher knappgeworden, da isses dann rausgeflogen. war aber auch nur n Nano mit ATmega168, da is wenig Platz drauf.
Benutzeravatar
Lukas_P
Beiträge: 1709
Registriert: Mo 12. Aug 2013, 21:21

Re: Der AVR-/ARDUINO-Faden

Beitrag von Lukas_P »

Hatte von euch schonmal jemand ein Problem das bei Arduino (also ESP8266) das negiern einer Variable 0 zurück gibt ?

ich weis mir absolut keinen helfer mehr :

Code: Alles auswählen

int a = 500;
Serial.println(a); // <-- gibt mir 500 aus (oder auch -500 wenn man das als a definiert)
a = -a; //  ooder a=0-a; 0der a*= -1; funktioniert alles nicht nichtmal wennman a einer ausweichvariable zuweist und die dann invertiert
Serial.println(a); <-- gibt dann immer 0 aus wenn a eigentlich negativ sein sollte
:evil: :evil:
seit dem ich das in nem git hab fuckt der scheiss manchmal echt unerklärlich rum
andreas6
Beiträge: 4152
Registriert: So 11. Aug 2013, 15:09

Re: Der AVR-/ARDUINO-Faden

Beitrag von andreas6 »

Überschreitest Du den Wertebereich von int? Probiere mal einen kleineren Wert, etwa 100.

MfG. Andreas
ch_ris
Beiträge: 3039
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

da wird int wohl auf uint...,zeigen.
nimm doch mal int16t.
oder wie heist das?
IPv6
Beiträge: 2207
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Der Wertebereich von int sollte mit -2147483648 bis 2147483647 eigentlich mehr als ausreichend sein.
Auch wäre es komisch, wenn da irgendwie aus einer int eine uint wird. Selbst bei einem Überlauf sollte da auch keine 0 rauskommen.
Sehr merkwürdig...
Benutzeravatar
Lukas_P
Beiträge: 1709
Registriert: Mo 12. Aug 2013, 21:21

Re: Der AVR-/ARDUINO-Faden

Beitrag von Lukas_P »

da wird int wohl auf uint...,zeigen.
nimm doch mal int16t.
oder wie heist das?
warum sollte mein int Array auf uints zeigen ? ... vor Allem weil vorm negieren die negativen werte tadellos gespeichert werden :evil: :cry:
virtexultra
Beiträge: 130
Registriert: So 9. Dez 2018, 11:30

Re: Der AVR-/ARDUINO-Faden

Beitrag von virtexultra »

Negiere die Variable doch einmal doppelt und lasse sie dann ausgeben. So kann man den Fehler auf die serielle Lib oder die Rechenoperationen eingrenzen.

Die Variable muss dafür aber mit volatile definiert werden, ansonsten wird wegoptimiert.
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Ich finde zwar die Seite nicht mehr, habe aber im Kopf dass der Compiler für die Arduinos int als signed integer interpretiert, für den ESP aber anders.
probiere mal "word" statt "int"

Hintergrund war glaube ich mich erinnern zu können das Thema hier: https://www.esp8266.com/viewtopic.php?f ... 954#p55810
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Sir_Death hat geschrieben: Mo 2. Nov 2020, 15:11 habe aber im Kopf dass der Compiler für die Arduinos int als signed integer interpretiert
WTF?
Sind die geistig behindert?!
Jannyboy
Beiträge: 1412
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Fritzler hat geschrieben: Mo 2. Nov 2020, 15:20
Sir_Death hat geschrieben: Mo 2. Nov 2020, 15:11 habe aber im Kopf dass der Compiler für die Arduinos int als signed integer interpretiert
WTF?
Sind die geistig behindert?!
Nö das tun mittlerweile alle GCC-Compiler neuer Version, der Standard-Typ ist int32_t.
Für einen 8 bit Wert muss explizit nach uint8_t gecastet werden bevor gerechnet wird.
Sonst rechnet der Compiler intern mit int32_t und kürzt nachher auf uint8_t.
Wenn man den binären Überlauf mit einkalkuliert ergibt es einen Rechenfehler.

Grüße Jan
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Das ist mir bisher nicht aufgefallen, weil ich sowieso IMMER cstdint nutze.
Was ich auch jedem hier nur empfehlen kann, dann passiert sowas erst garnicht. 8-)
virtexultra
Beiträge: 130
Registriert: So 9. Dez 2018, 11:30

Re: Der AVR-/ARDUINO-Faden

Beitrag von virtexultra »

Also meine Compiler machen das schon etwas länger so. Das sieht zumindest der erste C Standard (89) auch so vor - ich zitiere mal:

"int , signed , signed int , or no type specifiers [...] designates the same type, except that for bit-field declarations" aus http://port70.net/~nsz/c/c89/c89-draft.txt (3.5.2)

Dieser Thema im ESP8266 Forum resultiert für mich daraus das der Compiler zwischen den Variablen Padding einfügt um einen schnellen Datenzugriff zu ermöglichen.

Nur bei char gibt es keine eindeutige Definition - hierzu hat GCC die Flags -funsigned-char und -fsigned-char bereitgestellt um das Verhalten zu definieren.

Bei mir macht die Toolchain Xtensa in Version 4.8.2 aus der Negierung den neg asm Befehl. Für den ESP8266 gibt es nur Negierungsbefehle für 32 Bit und single prec. - weiterhin werden für das Codeschnipsel alles als l32i.n bzw s32i.n ausgeführt. Somit sollte ein Under- oder Overflow ausgeschlossen sein.

Der Compiler optimiert bei mir ohne das volatile aber etwas lustig. Er hält sowohl die 500 als auch die -500 im Flash vor und lädt diese mit dem movi Befehl als 12 bit signed constant in ein Arbeitsregister.

Also für mich ist das Problem nicht beim Compiler oder dem gezeigten Code zu suchen sondern irgendwo anders. Wenn du den Debug Build deines Programms aber mal rüber schickst kann man sich die Befehle ja anschauen. Vielleicht täusche ich mich mit meinen Gedankengängen ja auch :)

Die Datentypen intX_t und uintX_t sind auf jeden Fall immer eine gute Idee. Evtl. auch int_fastX_t bzw. uint_fastX_t falls es auf Geschwindigkeit ankommt.
Benutzeravatar
Hightech
Beiträge: 11451
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Wie mache ich das generell eigentlich korrekt, wenn ich mit dem AVR rechne mit den "Kommazahlen", besonders wenn ich Zahlen teile?
Zum Beispiel 10/3. Da hab ich ja 3.333333, das kann ich für spätere Berechnungen ja nicht einfach abschneiden. Oder alles in float?
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Fixkomma, du rechnest mit einer festen Anzahl an Nachkommastellen.
Oder statt in Ampere in mA/µA.
Um da Überläufe zu vermeiden braucht man aber ab und zu mal ne 64Bit Variable.
Das wird aufm AVR dann auch groß im Code und langsam.
(Vor allem bei Mul und Div).
float auf AVRs ist aber noch schlimmer.

Es empfiehlt sich eine modernere CPU Architektur wie ARM ;)
nero
Beiträge: 722
Registriert: Mo 12. Aug 2013, 11:58
Wohnort: Oberbayern

Re: Der AVR-/ARDUINO-Faden

Beitrag von nero »

Was sehr lange dauert ist die Umwandlung integer - float - double
Das an zeitkritischen Stellen vermeiden.
Dabei auch aufpassen: 1.23 ist double. Wenn man float will 1.23f schreiben.

Der Compiler wandelt (castet) automatisch immer alles in die "hochwertigste" Einheit. Das ist problemtisch vor allem da unsigned "höherwertig" als signed ist. Steht also eine unsigned int in der Berechung wird die Berechnung und das Ergebnis unsigned. (klassischer Fehler der schon zu vielen Sicherheitslücken geführt hat - unsigned index -> Indexberechung -> check auf kleiner 0 -> ist eh klar da Ergebnis unsigned war -> Index ist riesig und greift auf falschen speicher zu).
Steht ein float in der Berechnung wirds float. Bei einem Double wird alles double.
Worst case ist für die Berechnungsdauer und Speicherbedarf ist also sowas: y = 77 * x1 + 333 * x2 + 1.1;
Braucht vier mal Umwandlungen von int in double.
Besser so schreiben:
y = (770 * x1 + 3330 * x2 + 11) / 10;
oder mit verbessertem Rundungsfehler:
y = (770 * x1 + 3330 * x2 + 11) + 5 / 10;
oder wenns die Genauigkeit braucht:
y_10fach = 770 * x1 + 3330 * x2 + 11;

Bei ARM (Cortex) etc ist zwar eine (also Eine) float Operation immer noch recht langsam (verglichen mit int). Das Gleitkommarechenwerk hat aber eine Pipline. dh das Ergebnis der Gesamt Rechnung kommt 7 (glaub ich aus Stegreif) Takte verspätet. Egal ob dort steht y = 7.77f * x; oder y1 = 1.11 x1; y2 = 2.22f x2; y3 = 3.33f * x3; ...

Bei 8bit wie AVR dauert das einfach alles "ewig". Also an einer Stelle machen wo Zeit keine Rolle spielt ist die beste Lösung.
Zuletzt geändert von nero am Di 3. Nov 2020, 11:12, insgesamt 1-mal geändert.
nero
Beiträge: 722
Registriert: Mo 12. Aug 2013, 11:58
Wohnort: Oberbayern

Re: Der AVR-/ARDUINO-Faden

Beitrag von nero »

doppelt
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Auch das Rechnen dauert lange.
Eine Floatzahl wird bei jedem rechnen erstmal ausgepackt.
Dann wird gerechnet, am Ende wird gerundet und wieder eingepackt.
Bei einer Addition wird vorm Rechnen noch die Mantisse angefasst und auf 128Bit aufgeblasen!
Sonst wäre jede Addition ein Würfelspiel.

Einpacken und auspacken ist quasi ein:
nero hat geschrieben: Di 3. Nov 2020, 11:01 Was sehr lange dauert ist die Umwandlung integer - float [..]
Das Dauert, vor allem auf nem 8Bitter.
Daher hat der AVR GCC erst garkein double.
Auf einem ARM ist softfloat etwas schneller, aber auch lahm.
Zum Glück haben Cortex-M4 Aufwärts ne FPU 8-)

Es ist natürlich imemr vom Anwendungsfall abhängig obs sich lohnt, wer viel rechnet sollte was mit FPU nehmen.
Für meine E-Last war ein AVR schon zu lahm, der konnte keine 100Hz nach einem Gleichrichter mehr mit konstant 1A belasten.
nero hat geschrieben: Di 3. Nov 2020, 11:01 Das Gleitkommarechenwerk hat aber eine Pipline. dh das Ergebnis der Gesamt Rechnung kommt 7 (glaub ich aus Stegreif) Takte verspätet.
Japp, das weis der Compiler aber und versucht da andere Befehle reinzustreuen.
Ein zu früher Zugriff in Eigenbau ASM stallt dann einfach die CPU selbst bis die FPU fertig hat.
Benutzeravatar
Später Gast
Beiträge: 1697
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Hightech hat geschrieben: Di 3. Nov 2020, 07:36 Wie mache ich das generell eigentlich korrekt, wenn ich mit dem AVR rechne mit den "Kommazahlen", besonders wenn ich Zahlen teile?
Zum Beispiel 10/3. Da hab ich ja 3.333333, das kann ich für spätere Berechnungen ja nicht einfach abschneiden. Oder alles in float?
Ich mache das so, dass ich intern die Variable so weit aufmultipliziere, wie es die Größe der Variable halt zulässt und es nur für die Anzeige/Ausgabe durch den entsprechenden Faktor teile. Es muss dann nix mit Kommas gerechnet werden und Trunkierung führt zu vernachlässigbaren Ungenauigkeiten. In deinem Fall könnte man 30/3 rechnen und das Ergebnis der späteren Weiterverarbeitung nach der Weiterverarbeitung nochmal durch 3 teilen.Wenn man bei der Ausgabe Nachkommastellen braucht, halt vorher mit entsprechenden Zehnerpotenzen multiplizieren.
Benutzeravatar
Lukas_P
Beiträge: 1709
Registriert: Mo 12. Aug 2013, 21:21

Re: Der AVR-/ARDUINO-Faden

Beitrag von Lukas_P »

oke ich hab es rausgefunden :

ich hatte bei einem if in einem ganz anderen Teil meines Codes (der lange nachher abgearbeitet wird) das 2. = vergessen ... nur warum das so viel weiter vorn im Programm scheisse baut ist mir nicht klar...
IPv6
Beiträge: 2207
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Ich habe in eine Schaltung einen Arduino Nano (läuft klassisch mit 5 V) reingefrickelt.
In der Schaltung sitzt ein IC und ein Display, die über I²C mit dem Arduino sprechen sollen.
Das Display und das IC werden mit 3,3 V versorgt, zumindest das Display ist an seinen I²C Pins nicht 5 V tolerant.

Kann ich nun auf Levelshifter verzichten, indem ich die Pullups von I²C einfach auf 3,3 V lege, also mein ganzer I²C Bus einfach mit 3,3 V läuft?
Die ganzen Busteilnehmer ziehen die Leitungen ja bloß auf GND, der Arduino dürfte da keine 5 V drauf geben.
Auch wenn es etwas knapp ist aber in der Regel werden die 3,3 V ja noch als Highpegel erkannt.

Könnte gehen, oder?
Anse
Beiträge: 2304
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

IPv6 hat geschrieben: So 15. Nov 2020, 21:50 Könnte gehen, oder?
ja. Aber warum probierst Du es nicht einfach aus?
Das ist aber halt auch noch ein Nachteil des Arduino Ökosystems. Keine frei Wahl der Spannungsebene.
IPv6
Beiträge: 2207
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Weil ausprobieren sehr viel Fädeldrahtgefädel bedeutet, das würde ich gerne ein einziges Mal so machen, dass es dann möglichst auf Anhieb läuft :D
Benutzeravatar
Finger
Administrator
Beiträge: 7446
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Dat funzt, hab ich schon erfolgreich gemacht .
jodurino
Beiträge: 2104
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Hallo

so zum Programm debuggen ist der IDE Seriellemonitor nicht schlecht, habe mir noch Hterm herunter geladen weil manche Sachen ja nicht auf dem IDE Monitor gehen sollen.

Ich möchte gerne wen ich den Monitor oder das Terminalprogramm starte erst mal nix, maximal nur "." angezeigt bekommen.

Dann bei zB Taste "D" sollen Werte angezeigt werden:

Wert 1
Wert 2
Wert 3
.
.
.
Wert 7
mit Serial.prinln(wert)
klappt es auch gut, nur scrollt er dann natürlich nach oben

Hatte schon das her probiert als clearscreen:

Serial.print(27,BYTE); //Print "esc"
Serial.print("[2J");

funktioniert aber nicht da BYTE nicht mehr unterstützt wird.

Gibt es da eine Lösung für eine rudimentäre GUI?

cu
jodurino
Benutzeravatar
Finger
Administrator
Beiträge: 7446
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Benutze sprintf mit %c, so in etwa

char buf [20];
sprintf (buf, „%c“, 27);
Serial.print (buf);

Ist deutlich flexibler als der Arduino-Kram, braucht aber auch mehr Speicher.

Oder ne VT100-Lib benutzen...
Benutzeravatar
Weisskeinen
Beiträge: 3947
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Wie wär's mit "Serial.write(27)"?
jodurino
Beiträge: 2104
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Hallo
ok das mit dem VT100 klappt so einigermaßen, muss mich damit noch mehr befassen.

Jetzt wieder was völlig neues, bei dem einen ArduinoNano geht es bei dem anderen nicht.

An DigitalPin2 ist ein OptokopplerAusgang und 10kPullUp Widerstand an 5V. Lege ich 12V mit Vorwiderstand an de Optokopplereingang wird DigitalPin2 auf Low gezogen.

Code: Alles auswählen

#include <avr/sleep.h>

void INT_PINisr(void)
  /* ISR fuer Pin 2 */
  {
  /* detach Interrupt, damit er nur einmal auftritt */
  detachInterrupt(0);
  }

void enter_sleep(void)
  {
  attachInterrupt(digitalPinToInterrupt(2), INT_PINisr, LOW);
	
  //attachInterrupt(0, INT_PINisr, LOW);
  /* Arduino schlafen legen */
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sleep_mode();
  sleep_disable(); 
  }
Also bei dem einen Nano funktioniert es ich rufe in der loop irgendwann die enter_sleep auf und wecke ihn wieder mit dem Interrupt an pin 2

bei diesem geht es nicht, wenn ich 12V anlege und der pin 2 auf low ist hält das Programm einfach an.

Was ist den da nu wieder?

attachInterrupt(digitalPinToInterrupt(2) probiert ohne Erfolg
cu
jodurino
Benutzeravatar
Finger
Administrator
Beiträge: 7446
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Das
detachInterrupt(0);
in der ISR ist irgendwie nicht koscher (finde ich). Warum machst du das? Irgendwie riecht das nach "Ist eher Zufall das das mal geht", weniger nach Abhängigkeit von einer Hardware...
jodurino
Beiträge: 2104
Registriert: So 17. Nov 2013, 20:43

Re: Der AVR-/ARDUINO-Faden

Beitrag von jodurino »

Finger hat geschrieben: Sa 28. Nov 2020, 16:13 Das
detachInterrupt(0);
in der ISR ist irgendwie nicht koscher (finde ich). Warum machst du das? Irgendwie riecht das nach "Ist eher Zufall das das mal geht", weniger nach Abhängigkeit von einer Hardware...
Hallo

Code: Alles auswählen

#include <avr/sleep.h>

#define INT_PIN 2
#define LED_PIN 13

void INT_PINisr(void)
  /* ISR fuer Pin 2 */
  {
  /* detach Interrupt, damit er nur einmal auftritt */
  detachInterrupt(0);
  }

void enter_sleep(void)
  {
  attachInterrupt(0, INT_PINisr, LOW);
  /* Arduino schlafen legen */
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sleep_mode();
  sleep_disable(); 
  }

void setup()
  {
  Serial.begin(9600);
  Serial.println("Starte ...");
  /* Pin 2 als Interrupt-Pin, Pullup einschalten */
  pinMode(INT_PIN, INPUT);
  digitalWrite(INT_PIN, HIGH); 
  pinMode(LED_PIN, OUTPUT);
  Serial.println("Init erfolgt ...");
  delay(100);
  }

void loop()
  {
  /* warten, bis der Interrupt-Eingang wieder frei ist */
  while (digitalRead(INT_PIN) == LOW)
    {
    Serial.println("*** Taste loslassen ***");  
    delay(500);
    }
  Serial.println("Gehe schlafen ...");  
  delay(100);
  /* LED umschalten und wieder schlafen */
  digitalWrite(LED_PIN, ! digitalRead(LED_PIN));
  enter_sleep();
  Serial.println("Bin aufgewacht ...");  
  delay(100);
  }
ich habe es von hier, nur das ich keinen Taster sondern einen Optokoppler an den Eingang angeschlossen habe.
Der Beispielcode funktoniert nur mein Spahhhrgelgetti code nicht.

Habe noch mal neu angefangen und Stück für Stück Ergänzt mal sehen wo der Fehler ist.

cu
jodurino
Benutzeravatar
Hightech
Beiträge: 11451
Registriert: So 11. Aug 2013, 18:37

Stress mit dem Telegram-Bot bzw. UniversalTelegramBot

Beitrag von Hightech »

Ich hab hier einen ESP8266 als Telegram-Client, der Nachrichten von einem Telegram-Bot empfängt.
Das funktioniert schon mal ganz gut, jedoch wenn der Eingabetext zu lang ist, ca 300-500 Zeichen, kommt am Bot nichts mehr an und auch wenn ich den ESP neu Starte und den Bot neu starte kommen keine Nachrichten mehr am ESP an. Nur wenn ich einen neuen Bot generiere, klappt alles wieder.

Hat da jemand einen Plan von?
Ich vermute irgend ein Server-Puffer bekommt die Daten nicht in den ESP-Puffer und dann bleibt der Brocken da stecken, kann ich da irgendwo einen Timeout bei Telegram setzen oder im ESP einen Inputbuffer Zwischendengeln?

Hier der Code auf dem ESP8266

Code: Alles auswählen

/*******************************************************************
    A telegram bot for your ESP8266 that responds
    with whatever message you send it.

    Parts:
    D1 Mini ESP8266 * - http://s.click.aliexpress.com/e/uzFUnIe
    (or any ESP8266 board)

      = Affilate

    If you find what I do useful and would like to support me,
    please consider becoming a sponsor on Github
    https://github.com/sponsors/witnessmenow/


    Written by Brian Lough
    YouTube: https://www.youtube.com/brianlough
    Tindie: https://www.tindie.com/stores/brianlough/
    Twitter: https://twitter.com/witnessmenow
 *******************************************************************/

#include <ESP8266WiFi.h>
#include <WiFiClientSecure.h>
#include <UniversalTelegramBot.h>
#include <strings.h>

// Wifi network station credentials
#define WIFI_SSID "SSID"
#define WIFI_PASSWORD "PASSWD"
// Telegram BOT Token (Get from Botfather)
#define BOT_TOKEN "TELEGRAMTOKEN"

void nadel_convert(int a)
{

switch(a){
  case 150: //Ö
    a=92;
    break;    
    case 182: //ö
    a=124;
    break;    
    case 156: //Ü
    a=93;
    break;        
    case 188: //ü
    a=125;
    break;    
    case 132: //Ä
    a=91;
    break;
    case 164: //ä
    a=123;
    break;    
    case 159: //ß
    a=126;
    break;
    case 91: //[
    a=40;
    break;
    case 93: //]
    a=41;
    break;
    case 123: //{
    a=40;
    break;
    case 125: //}
    a=41;
    case 92: //\
    a=47;
    break;    
    default:
    break;    
    }
  if ((a>126)||(a<10)){
      ;;}
  else{
    if (isAscii(a)){  
      //Serial.println(int(a));
      Serial.write(a);}
      }          
}

const unsigned long BOT_MTBS = 1000; // mean time between scan messages
String texte;
int len;

X509List cert(TELEGRAM_CERTIFICATE_ROOT);
WiFiClientSecure secured_client;
UniversalTelegramBot bot(BOT_TOKEN, secured_client);
unsigned long bot_lasttime; // last time messages' scan has been done

void handleNewMessages(int numNewMessages)
{
  for (int i = 0; i < numNewMessages; i++)
  {
    texte=(bot.messages[i].text);
    len = texte.length();
    if (len>300){
      bot.sendMessage(bot.messages[i].chat_id,"Der Beitrag ist leider zu lang, >3000 Zeichen");
      }
    else{
        for (int a=0;a<len;a++){
         //Serial.write(texte[a]);
          nadel_convert(texte[a]);
            }
          Serial.write("\n");
          }
    bot.sendMessage(bot.messages[i].chat_id,"Danke für Deinen Beitrag");
    }
}

void setup()
{
  Serial.begin(9600);
//  Serial.println();

  // attempt to connect to Wifi network:
//  Serial.print("Connecting to Wifi SSID ");
// Serial.print(WIFI_SSID);
  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
  secured_client.setTrustAnchors(&cert); // Add root certificate for api.telegram.org
  
  while (WiFi.status() != WL_CONNECTED)
  {
//    Serial.print(".");
    delay(500);
  }
//  Serial.print("\nWiFi connected. IP address: ");
//  Serial.println(WiFi.localIP());

//  Serial.print("Retrieving time: ");
  configTime(0, 0, "pool.ntp.org"); // get UTC time via NTP
  time_t now = time(nullptr);
  while (now < 24 * 3600)
  {
//    Serial.print(".");
    delay(100);
    now = time(nullptr);
  }
//  Serial.println(now);
}

void loop()
{
  if (millis() - bot_lasttime > BOT_MTBS)
  {
    int numNewMessages = bot.getUpdates(bot.last_message_received + 1);

    while (numNewMessages)
    {
     // Serial.println("got response");
      handleNewMessages(numNewMessages);
      numNewMessages = bot.getUpdates(bot.last_message_received + 1);
    }
    bot_lasttime = millis();
  }
}
lüsterklemme2000
Beiträge: 259
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Hallo, ich bin mir nicht ganz sicher ob das hier hergehört, aber ich möchte keinen extra Faden aufmachen:

Langsam wird es bei mir mal Zeit für den Umstieg von der Atmega Serie Richtung STM32. Bisher habe ich im Programmers Notepad die Software editiert, und mit dem GNU Compiler kompiliert. Der Upload erfolgte dann mittels AVRDUDE und USBAsp.
Kein IDE-Krams, sondern simples Registergeschubse auf unterster Ebene.
Eigentlich würde ich auch bei den STM32 weiterhin auf HAL und co. verzichten wollen. Ich weiß halt gerne, was der Controller auf Registerebene tut. Ganz ohne wird es aber wohl aufgrund der gesteigerten Komplexizität nicht gehen.
Die meisten Tutorials wollen mir entweder die Arduino-IDE, oder die CUBE-IDE andrehen. Nun bin ich von der Arduino-IDE kein Freund, und die CUBE-IDE gefällt auch nicht wirklich (damit könnte ich mich aber anfreunden, wenn es keine Alternative gibt).

Daher wäre meine Frage:
Welche Entwicklungsumgebung/Programme/Toolchain verwendet Ihr und könnt Ihr empfehlen, um von der Idee bis zum fertig programmierten Controller zu kommen (muss auch keine IDE sein)?

Vielen Dank und einen schönen 4.Advent,
Lüsterklemme
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Du kannst immernoch beim Programmers Notepad und GCC bleiben.
Brauchst eben den ARM GCC: https://developer.arm.com/tools-and-sof ... /downloads
Das ist dann sogar der heißeste sch**ss, der AVR GCC ist ja ziemlich stehen geblieben in der Entwicklung.

Als "brenner" nimmste den stlinkv2, der hat auch ein Commandline Tool und ist damit vom makefile aus bedienbar.
Dieser ist auf den STM32 devboards von ST direkt drauf.
Meine Empfehlung geht aber eindeutig zu einem J-Link edu (66€), aber das erst wenn du gefallen an ARM gefunden hast.
Der kommt dann auch mit einem standalone debugger (Ozone).
lüsterklemme2000 hat geschrieben: So 20. Dez 2020, 01:04 Eigentlich würde ich auch bei den STM32 weiterhin auf HAL und co. verzichten wollen. Ich weiß halt gerne, was der Controller auf Registerebene tut. Ganz ohne wird es aber wohl aufgrund der gesteigerten Komplexizität nicht gehen.
So Komplex ist der nun auch wieder nicht.
Es muss ja nicht gleich DMA beim UART genutzt werden.
Beim STM32 gibts das "datasheet", dieses enthält welche Periph es gibt und an welcher Basisadresse diese schlummern.
Dann noch ein reference manual und da sind die Periph dann aufs Bit genau erklärt inkl. Init bzw Handling Sequenzen.

Die Bitdefines sind ARM Universum weit im sogenannten CMSIS vorgehalten.
Für die STM32 kommste da über CubeMX ran.
Das Teil ist übrigens recht brauchbar für Pinbelegungen ;)

Ansonsten Helfe ich hier gerne.

Im Anhang mal Beispielcode für ein startmakefile.
Einmal C und einmal CPP.
Dateianhänge
faults.zip
(498.11 KiB) 28-mal heruntergeladen
ModbusIO.zip
(305.85 KiB) 28-mal heruntergeladen
lüsterklemme2000
Beiträge: 259
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Der AVR-/ARDUINO-Faden

Beitrag von lüsterklemme2000 »

Vielen Dank. Das bringt mich denke ich schonmal deutlich weiter. Schön, dass es scheinbar doch unkompliziert geht.
Das Refernce Manual ist ja total geil, jedes Register bis aufs letzte Bit aufgeführt :D . Das war das was mir immer gefehlt hat. Ich kannte nur das Datasheet und dachte das sei alles, was man dazu bekommt (bei Atmel ist das zumindest bei den ATmega und SAM Serien so).

Dann werde ich mich da mal die Tage dran versuchen und bei Fragen wiederkommen.
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

lüsterklemme2000 hat geschrieben: So 20. Dez 2020, 01:04
Welche Entwicklungsumgebung/Programme/Toolchain verwendet Ihr und könnt Ihr empfehlen, um von der Idee bis zum fertig programmierten Controller zu kommen (muss auch keine IDE sein)?
Ich würde Dir auf jeden Fall eine Make-Umgebung empfehlen mit GCC.

Um Code auf das Zielsystem zu schaufeln (angeschlossen über RS-232/TTL) verwende ich seit 8051-Zeiten einen Bootmonitor (Bootloader und Monitor, damals RISM-51). Compiler war imho Keil.

In der 4ma hatten wir das mehr oder weniger genau so beibehalten. Das funktioniert sogar bei gemischten Systemen z.B. ARM und TMS320.

Ich weiß, das stinkt etwas nach Arduino, aber alles ist ja auch nicht schlecht an den Dingern. Und außerdem ist die Technik schon vieeeeel älter.
Genau genommen würde ich sogar den Arduino-Bootloader übernehmen - weil, er ist ja schon da, zumindest für AVR und ARM.

Für die Eingeweide tat's GDB ganz gut, rangetüddelt über JTAG.
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Die STM32 kommen schon mit Bootloader vom Hersteller.
Ansprechbar mit einem STM32 Commandline Tool.
Die USB Fähigen STM32 haben sogar einen USB Bootloader (DFU: Device Firmware Upgrade).
Damits brauchts dann garkein spezielles STM Tool mehr, das ist ein Standard.

Der mitgelieferte stlink auf den devboards ist aber erstmal besser für den Einstieg.
j.o.e
Beiträge: 550
Registriert: Fr 29. Nov 2019, 01:15

Re: Der AVR-/ARDUINO-Faden

Beitrag von j.o.e »

Fritzler hat geschrieben: So 20. Dez 2020, 14:38 Die STM32 kommen schon mit Bootloader vom Hersteller.
Ansprechbar mit einem STM32 Commandline Tool.
Commandline ist gut, könnte man im "make install" aufrufen.
ch_ris
Beiträge: 3039
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ich probiere grade mit Encodern rum.
https://koraykaraman.com/blog/3546/Ardu ... ed-Library
hab diese lib installiert, dort steht:
There are three options.

Best Performance: Both signals connect to interrupt pins.
Good Performance: First signal connects to an interrupt pin, second to a non-interrupt pin.
Low Performance: Both signals connect to non-interrupt pins, details below.

die dritte, also ohne interupt, geht, selbst bei einfach dran rum drehen, gar nicht.
mit einem interupt scheint's soweit zu funktionieren.
jetzt hat der nano ja nur 2.
meint ihr da geht was per software interupt?
IPv6
Beiträge: 2207
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Im Mikrokontrollerforum stehen da ein paar grundlegende Dinge sehr übersichtlich.
Also was man da für Lösungen wählen kann und wo die Vor- und Nachteile liegen.
Was genau davon deine Lib umgesetzt hat müsstest du nachsehen...

https://www.mikrocontroller.net/articles/Drehgeber

Der Link ist aber gerade nicht verfügbar, im Webarchiv aber einsehbar:
https://web.archive.org/web/20200806064 ... /Drehgeber
Anse
Beiträge: 2304
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

ch_ris hat geschrieben: Mo 28. Dez 2020, 15:36 meint ihr da geht was per software interupt?
So was wie ein Software Interrupt gibt es bei AVRs nicht.
Die Low Performance Variante nutzt wahrscheinlich einen Timer Interrupt um die Zustandsänderung zu erfassen. Ist der Timer vielleicht schon belegt?
Eigentlich sind so Encoder eine simple Sache, besonders, wenn sie nur als Input Device für den Benutzer dienen sollen. So was lässt sich recht einfach selber schreiben. Man muss eigentlich nur periodisch die Eingänge Abfragen, und vergleichen, ob sich was verändert hat. Wenn ja, dann entscheiden, ob es einen Schritt vorwärts oder rückwärts ging.
Die Interrupt Variante finde ich nicht so toll. Prellende Kontakte können da zu unschönen Effekten führen.
ch_ris
Beiträge: 3039
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ich meinte mittels pinchangeint interrupts zu emulieren.

nee das sind so highspeed encoder mit 2400s/U.
ich glaube da prellt nix.

Code: Alles auswählen

Output :AB 2phase output rectangular orthogonal pulse circuit, the output for the NPN open collector output type
Maximum mechanical speed: 5000 R / min
Response frequency: 0-20KHz
den Artikel +1 muss ich mal durchsehen.
was ich bis jetzt gelesen hab legt schon mal nahe das viel performance viel hilft und evtl. was anderes als nano hier besser wäre.
Benutzeravatar
Bastelbruder
Beiträge: 11539
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Es gibt nichts schlimmeres als die Haptik diverser Drehknöpfe In modernen Heilix Blechle.

In irgendeiner Amateurfunke hat man die Gefahr verlorener Flanken vor gut 30 Jahren etwas anders gelöst. Da schiebt der Encoder seine Impulse in einen Zähler (4029 ?) und das viel zu behäbige Kleinhirn holt bei Gelegenheit die 4 Bits ab.
Benutzeravatar
Fritzler
Beiträge: 12597
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Bastelbruder hat geschrieben: Mo 28. Dez 2020, 18:47 In irgendeiner Amateurfunke hat man die Gefahr verlorener Flanken vor gut 30 Jahren etwas anders gelöst. Da schiebt der Encoder seine Impulse in einen Zähler (4029 ?) und das viel zu behäbige Kleinhirn holt bei Gelegenheit die 4 Bits ab.
Ordentliche Controller haben inzwischen Hardwaretimer, die auch Encoderpulse zählen können.
Inkl Entprellfilter!

Der Softwerker muss nurnoch genug Ahnung haben das auch zu nutzen.
Aber genau da haperts dann leider meistens :?

PS:
Damit meine ich jetz nich irgendwelche Heimfrickler, sondern durchaus Leute, die fürs Coden bezahlt werden.
Benutzeravatar
Raja_Kentut
Beiträge: 1551
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

Moin, könnte bitte mal die Gemeinde über meinen Codeschnipsel schauen und sagen "löppt woll" oder "geit nich, wägn...".
Compilieren tut er, auf Hardware testen geht grade nicht weil der Chinamann noch auf sich warten lässt.
Ich hab da erstmalig in meiner Programmierkarriere eine IF innerhalb einer ELSE, darf das überhaupt?
Funktion : Zwischen zwei Öffnungsvorgängen soll mindestens 10 minuten gewartet werden (schließen immer sofort).
Das Hauptprogramm springt "fenster_oeffnen_auto" an, wenn dafür die Voraussetzungen gegeben sind. Geht bisher, die Sache mit den millis() hab ich nachgestrickt.

Code: Alles auswählen

// ******* öffnen Automatikbetrieb *******
void fenster_oeffnen_auto ()                     // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
  if(gradC_Ai < gradC_Ii)                        // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
    {
     fenster_schliessen();                       // Routine fenster_schliessen anspringen
    }
      else                                       // sonst prüfen ob Zeit "VerzAuf" vergangen ist und dann fenster öffnen
         {
         neuMillis = millis();                   // beim allerersten Programmdurchlauf ist altMillis = 0 wegen Deklaration
          if (neuMillis - altMillis >= VerzAuf)  // vor öffnen prüfen ob Verzögrungszeit "VerzAuf" in ms vergangen ist
            {                                    // wenn das der Fall ist...
            fenster_oeffnen();                   // Routine fenster_oeffnen anspringen
            }                                    // sonst zurück zum Hauptprogramm springen aber vorher noch
         altMillis = neuMillis;                  // altMillis auf neuMillis hochsetzen
         }
}
Anse
Beiträge: 2304
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Ist "altMillis" eine Globale Variable?

Ifs zu Schachteln ist kein Problem.
Aber hier muss eine Klammer rein:

Code: Alles auswählen

 if ((neuMillis - altMillis) >= VerzAuf)
Benutzeravatar
Raja_Kentut
Beiträge: 1551
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

altMillis kommt von ganz oben : (ist das dann global?)

Code: Alles auswählen

//  ************* Libraries **************************
#include <OneWire.h>            // für Dallas 18B20 Temp.-Chip
#include <DallasTemperature.h>  // für Dallas 18B20 Temp.-Chip 
#include "Wire.h"               // für SHT31 Temp./RH-Chip
#include "SHT31.h"              // für SHT31 Temp./RH-Chip

OneWire oneWire(4);                    // Data Pin von Sensor am Pin 4 angeschlossen (4)
DallasTemperature sensors(&oneWire);   // Library starten
SHT31 sht;                             // Library starten

//  ************* Variablen ******************************
  float gradC_I;   // Innentemperatur in Grad Celsius
  float gradC_A;   // Aussentemperatur in Grad C
  float humid_RH;  // Relative Luftfeuchtigkeit
  float tp;        // Taupunkt in Grad C

  unsigned long altMillis = 0;      // Speichert alten millis Wert
  unsigned long neuMillis = 0;      // Speichert aktuellen millis Wert
  const long VerzAuf = 600000;      // Verzögerungszeit für Fenster öffen in Automatikbetrieb im ms (600.000 = 10 minuten)

  int ZylAus_O = 5; // Output für Signal Zylinder ausfahren
  int ZylEin_O = 6; // Output für Signal Zylinder einfahren
..das mit der Klammer macht Sinn!
IPv6
Beiträge: 2207
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Die Funktion zum Fenster öffnen wird dann regelmäßig alle "VerzAuf" aufgerufen, solange es draußen wärmer ist als innen.
Die Fenster schließen Funktion entsprechend bei jedem Durchgang wenn die Bedingung erfüllt ist.
Je nach dem was da hintendran steht könnte das ein Problem sein, muss aber nicht.
Man könnt ein einer Variablen den Zustand des Fensters speichern und nur dann öffnen bzw. schließen, wenn der gewünschte Zustand noch nicht gegeben ist.

Um Pins einen Klarnamen zu geben ist "#define outputpin 1" die schönere Variante als "int outputpin = 1", funktioniert aber auch.
Anse
Beiträge: 2304
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

Raja_Kentut hat geschrieben: Sa 2. Jan 2021, 17:12 altMillis kommt von ganz oben : (ist das dann global?)
Ja, das nennt man global. Für diesen Fall solltest Du dir mal das Schlüsselwort static ansehen. Damit kann man lokalen Variablen kennzeichnen, die ihren Wert zwischen den Funktionsaufrufen behalten sollen. Sie verhalten sich wie globale aber man behält bessere Übersicht. Das ist sinnvoll, wenn man eine unbeabsichtigte Veränderung ausschließen möchte.

Code: Alles auswählen

// ******* öffnen Automatikbetrieb *******
void fenster_oeffnen_auto ()                     // Starten der Funktion Fenster öffnen NUR wenn Aussen wärmer als Innen (Zylinder Eingefahren = fenster auf)
{
static int  altMillis=millis();
static int FensterStatus=0;
  if(gradC_Ai < gradC_Ii && FensterStatus==1)                        // wenn Aussentemperatur kleiner Innentemperatur (Integerwerte) dann Fenster schließen
    {
    FensterStatus=0;
     fenster_schliessen();                       // Routine fenster_schliessen anspringen
    }
      else                                       // sonst prüfen ob Zeit "VerzAuf" vergangen ist und dann fenster öffnen
         {
         neuMillis = millis();                   // beim allerersten Programmdurchlauf ist altMillis = 0 wegen Deklaration
          if (neuMillis - altMillis >= VerzAuf && FensterStatus==0)  // vor öffnen prüfen ob Verzögrungszeit "VerzAuf" in ms vergangen ist
            {             
            FensterStatus=1;                       // wenn das der Fall ist...
            fenster_oeffnen();                   // Routine fenster_oeffnen anspringen
            }                                    // sonst zurück zum Hauptprogramm springen aber vorher noch
         altMillis = neuMillis;                  // altMillis auf neuMillis hochsetzen
         }
}
Und denk daran, millis() läuft nach X Tagen über. Den Wert hab ich nicht mehr im Kopf.
IPv6
Beiträge: 2207
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

Anse hat geschrieben: Sa 2. Jan 2021, 17:31 Und denk daran, millis() läuft nach X Tagen über. Den Wert hab ich nicht mehr im Kopf.
Das hatten wir etwas weiter oben im Thread schonmal, der Überlauf macht keine Probleme solange die Überprüfung "zeitNeu - zeitAlt > Intervall" lautet und solange die Variable "zeitAlt" von selben Typ ist wie das, was millis() zurückgibt (unsigned long).

Edit:
Das war in einem anderen Thread, nur wo genau nochmal...?
Antworten