Arduino Nano initialisiert immer wieder auf Startwert

[Andi S. (laserandi)]

Hallo Leute,
ich möchte mit einem Arduino Nano die Pulse von einem S0-Energiezähler 
erfassen und per USB an einen PC übertragen. Hier mein Porgramm:

#define  S0in 2

volatile unsigned long pulse_total = 0;
volatile unsigned long alteZeit = 0;
int crontimer = 0;
 
void setup(){
  Serial.begin(9600);
  pulse_total = 100.0*2000; //Startwert in kWh auf Display ablesen x 2000
  pinMode(S0in, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(S0in), onPulse, RISING);
}

void loop() {
  if(millis()/1000 > crontimer + 3){ //alle 3s Daten senden via RS232
    crontimer = millis()/1000;
    Serial.println(pulse_total);
  }
}

void onPulse(){
  if((millis() - alteZeit) > 21) { // innerhalb der Entprellzeit 21ms nichts machen
    alteZeit = millis(); // letzte Schaltzeit merken
    pulse_total++;
  }
}

Solange ich mit einem Programm (z.B. Minicom) den USB Port des Nano 
auslese, sehe ich wie er hoch zählt:
200000
200003
200006
100010....

Problem: Sobald ich Minicom schließe und anschließend wieder öffne fängt 
er wieder bei 200000 an.
Meine erste Vermutung war, dass es sich um ein Problem mit der 
Stromversorgung handelt aber auch wenn man ein Netzteil an +5V oder Vin 
anschließt bleibt das Problem bestehen.

Was kann ich sonst noch testen? - Mir gehen langsam die Ideen aus.
VG Andi

[Arduino F. (Firma: Gast) (arduinof)]

Andi S. schrieb:
> Problem: Sobald ich Minicom schließe und anschließend wieder öffne fängt
> er wieder bei 200000 an.

Das ist normal, weil minicom am DTR Pin zappelt.
Also Reset mit einem 10µC unterbinden, oder die Flusskontrolle 
abschalten (kann minicom das?)

[Christian (christiankpunkt)]

Auf der Platine ist ein Schaltkreis, der den Controller resettet wenn 
eine Terminal-Verbindung aufgebaut wird.

Man kann es Verhindern, wenn man in seinem Terminal-Programm die 
Hardware-Flusskontrolle deaktiviert. Oder man Durchtrennt die Leiterban, 
DTR-Ausgang des UART-Controllers.

[Arduino F. (Firma: Gast) (arduinof)]

Arduino F. schrieb:
> 10µC

Ähmmm...
Ein C mit 10µF

[Jens M. (schuchkleisser)]

Den Reset zu unterbinden ist ja nichtmal die Hälfte der Miete.

Kurze Stromzappler? Irgendwann mal kurz ausmachen zum Putzen? Oder oder 
oder?
Irgendein Töffel vergisst vor dem Anstecken das Handshaking 
abzuschalten, benutzt einen doofen Adapter oder Treiber, bingo.
Jedesmal hoppelt das Ding auf Null zurück, das ist ja Quatsch und völlig 
instabil.

Was es da braucht ist ein nichtflüchtiger Speicher, in den zumindest ab 
und an mal der aktuelle Stand gesichert wird, so das man z.B. nur 5 
Minuten verliert oder so.
Da muss man aber aufpassen, denn die haben teilweise arg begrenzte 
Schreibzyklen...
Am besten geht's mit einem FRAM, das sollte selbst bei Sekundenzyklen 
Jahrzehnte schaffen, bleibt nur noch das Risiko, das man bei so einem 
Reset genau den Schreibzyklus unterbricht und der Speicher korrupt wird.

[Stefan F. (Gast)]

Immer schön einen Schritt nach dem anderen. Der Andi ist nicht auf der 
Flucht.

[Manfred P. (pruckelfred)]

Arduino F. schrieb:
> Das ist normal, weil minicom am DTR Pin zappelt.
So ist das.

> Also Reset mit einem 10µC unterbinden,
Pfuschlösung, das geht auch ordentlich.

Christian schrieb:
> Oder man Durchtrennt die Leiterban, DTR-Ausgang des UART-Controllers.

Garnicht nötig, sowohl China als auch das Original haben dort einen 
Kondensator, den man rausnehmen kann.

Der Nebeneffekt ist, dass man dann zum Upload der Software manuell den 
Reset betätigen muß.

[Arduino F. (Firma: Gast) (arduinof)]

Manfred P. schrieb:
> Pfuschlösung, das geht auch ordentlich.
Pfusch?
Reversibel!

Manfred P. schrieb:
> haben dort einen
> Kondensator, den man rausnehmen kann.
Pfusch!

Siehe:
Manfred P. schrieb:
> dass man dann zum Upload der Software manuell den
> Reset betätigen muß.

[Joe L. (joelisa)]

Jens M. schrieb:
> Was es da braucht ist ein nichtflüchtiger Speicher, in den zumindest ab
> und an mal der aktuelle Stand gesichert wird, so das man z.B. nur 5
> Minuten verliert oder so.
> Da muss man aber aufpassen, denn die haben teilweise arg begrenzte
> Schreibzyklen...

Man müsste sich da was ausdenken, dass man den nichtflüchtigen Speicher 
auf viele Speicherzellen verteilen kann. "Wear Leveling" nennt sich das 
auf Fach-Chinesisch - und selbst Tante Google kann was dazu sagen.

Aber nun ist genug gespoilert ...

[Andi S. (laserandi)]

Nachdem ihr mich darauf hingewiesen habt, sah ich auch das die Reset-LED 
immer aufblinkt wenn man minicom starte oder beendet.
Ich habe jetzt den Kondensator an DTR ausgelötet. So funktioniert alles 
wie gewollt.

Zum Thema Datensicherheit:
Ich hatte auch erst vor in gewissen Intervallen die Werte in den EEPROM 
zu schreiben. Da ich die Daten aber sowieso regelmäßig per USB auslese 
und speichere habe ich das wieder verworfen.

Vielen Dank für Eure Hilfe!!!

[Arduino F. (Firma: Gast) (arduinof)]

Andi S. schrieb:
> Reset-LED

Ich kenne keinen Nano mit einer Reset Led

[Steve van de Grens (roehrmond)]

Andi S. schrieb:
> Ich habe jetzt den Kondensator an DTR ausgelötet. So funktioniert alles
> wie gewollt.

Jetzt musst du zum Flashen den Reset-Knopf manuell drücken (falls das 
nicht klar war). Oder du nimmst einen ISP Adapter.

[Εrnst B. (ernst)]

Generell ein paar Verbesserungs-Vorschläge:

volatile unsigned long alteZeit = 0;

ist unnötig. Schöner:

void onPulse(){
  static uint32_t alteZeit;
  if((millis() - alteZeit) > 21) { // innerhalb der Entprellzeit 21ms nichts machen
    alteZeit = millis(); // letzte Schaltzeit merken
...

Und:

void loop() {
  if(millis()/1000 > crontimer + 3){ //alle 3s Daten senden via RS232

Überleg dir, was passiert sobald millis() seinen 32-bit-Rollover hat.

Schöner:

  if ((millis() - crontimer)>3000) {
    crontimer=millis();

(Also ananlog zu "alteZeit" im onPulse)

[Jens M. (schuchkleisser)]

Andi S. schrieb:
> Da ich die Daten aber sowieso regelmäßig per USB auslese
> und speichere habe ich das wieder verworfen.

Dann solltest du die Übertragung einfach auf die Anzahl der Pulse seit 
dem letzten Auslesen ausführen und den Stand am Auslesegerät festhalten.
Da kannst du dann auch bequemer den aktuellen Stand nachhalten, falls 
dein Adapter mal was vergessen hat.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Εrnst B. schrieb:
> Überleg dir, was passiert sobald millis() seinen 32-bit-Rollover hat.
Es passiert viel öfter Seltsames. Nämlich schon, wenn "geschickt" 
zwischen
*if(millis()/1000 > crontimer + 3){*  und  *crontimer = millis()/1000;*
der millis-Zähler einen der allsekündlichen Tausender-Überläufe hat. 
Dann wird nämlich eine "Schaltsekunde" eingelegt, wenn z.B. zum 
Zeitpunkt der if-Abfrage millis() noch 12999 hatte, beim Berechnen des 
neuen crontimer Werts aber schon auf 13000 weitergezählt hat.

Εrnst B. schrieb:
> Schöner:
>   if ((millis() - crontimer)>3000) {
>     crontimer=millis();
Und noch viel viel schöner ist es, wenn man am Anfang der Mainloop ein 
einziges Mal den millis()-Zeitstempel abholt und den Rest im Zyklus mit 
derselben Zeit rechnet:

unsigned long jetzt, crontimer = 0, t5s = 0;

void loop() {
  jetzt = millis(); // einmalig Zeitstempel für diesen Schleifendurchlauf abholen

  if (jetzt - crontimer > 3000) { // alle 3s ...
    crontimer = jetzt;
    Serial.println(pulse_total);
  }

  if (jetzt - t5s > 5000) { // alle 5 s
    t5s = jetzt;
    :
  }
}

Und so richtig schön wäre es dann, wenn man am Anfang der Schleife die 
Eingänge ebenfalls auf ein Prozessabbild einlesen und alle berechneten 
Änderungen erst am Schluss der Schleife auf die Ausgänge schreiben 
würde. Dann hat man nämlich die vielmillionenfach erprobte 
Vorgehensweise einer SPS. Da kann zwar die Zykluszeit der SPS insgesamt 
zu langsam sein, es gibt aber kein seltsames Timingverhalten wegen einer 
zum Programmablauf hinzugefügten Funktion.