mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Arduino frage zu Serial.print


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Bert S. (kautschuck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Was passiert eigentlich, wenn ich einen Arduino Uno extern versorge und 
trotzdem Serial.print() verwende, ohne angeschlossenes Serial Interface? 
Der Arduino verwendet ja den Interrupt zum senden und somit werden die 
Daten alle in einen Buffer geschrieben. Ist dies überhaupt ein Ring 
Buffer, oder was passiert wenn dieser voll ist? Ich habe nämlich ein 
Problem mit einem Arduino Uno, der sich nach etwa 3 Wochen aufhängt, 
wobei ich festgestellt habe, dass ich ein Serial.print("...") vergessen 
habe, wo aber nur ein paar mal am Tag aufgerufen wird.

: Bearbeitet durch User
Beitrag #5415357 wurde von einem Moderator gelöscht.
Autor: yesitsme (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Serielle Schnittstelle hat keine Empfangsquitierung. Dein 
Serial.print() sollte ungehört verhallen und sich nichts irgendwo 
ansammeln.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yesitsme schrieb:
> Die Serielle Schnittstelle hat keine Empfangsquitierung. Dein
> Serial.print() sollte ungehört verhallen und sich nichts irgendwo
> ansammeln.

Gilt aber nur wenn das keine USB-Serielle ist, also USBSerial oder wie 
das hieß. Die wartet sehr wohl auf Bestätigung/Abholung...

P.Loetmichel schrieb im Beitrag #5415357:
> Ich würde ja BASCOM nehmen.
Schön für dich; es gibt Leute die können nicht nur solche Baby-Sprachen.

> Da funktioniert die serielle immer!
Das hat nichts mit der Programmiersprache zu tun.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bert S. schrieb:

> Was passiert eigentlich, wenn ich einen Arduino Uno extern versorge und
> trotzdem Serial.print() verwende, ohne angeschlossenes Serial Interface?

Vermutlich nix besonderes, die Daten werden einfach in's Nirvana 
gesendet, erscheinen also ganz normal am Ausgangspin, nur halt ohne, 
dass sich irgendwer dafür interessiert...

Irgendwas anderes käme überhaupt nur im Falle eines aktiven 
Handshake-Mechanismus in Frage.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der TX-Buffer voll ist, dann blockt HardwareSerial::write() (und 
damit auch Serial.print() ) so lange, bis genug Platz ist um die Daten 
in den Buffer zu schreiben. Für Details siehe auch 
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp#L213


P.Loetmichel schrieb im Beitrag #5415357:
> Ich würde ja BASCOM nehmen.
>
> Da funktioniert die serielle immer!

Deine ständige Schleichwerbung für BASCOM ist mittlerweile einfach nur 
noch lächerlich.

Autor: Bert S. (kautschuck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Wenn der TX-Buffer voll ist, dann blockt HardwareSerial::write() (und
> damit auch Serial.print() ) so lange, bis genug Platz ist um die Daten
> in den Buffer zu schreiben. Für Details siehe auch
> 
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp#L213

Dr. Sommer schrieb:
> Gilt aber nur wenn das keine USB-Serielle ist, also USBSerial oder wie
> das hieß. Die wartet sehr wohl auf Bestätigung/Abholung...

Ok, danke, dann liegt das in der Tat daran, dass ich auf die USB-Serial 
schreibe.

: Bearbeitet durch User
Autor: yesitsme (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> also USBSerial

Hat der Arduino Uno das?

Autor: DAVID B. (bastler-david)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
meine Erfahrungen sind so das es egal ist ob was angeschlossen ist oder 
nicht.
Da es keinen warte befehl gibt.
Der arduino sendet es einfach egal ob die gegen stelle bereit ist oder 
nicht.
ich frage zb mit einen 2560 alle 40 ms eine Spannung ab und sende sie an 
einen PC.
Und das auch mal 10 stunden lang.
Es spielt dabei aber keine rolle ob der PC läuft oder nicht die Daten 
werden gesendet und fertig.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Gilt aber nur wenn das keine USB-Serielle ist, also USBSerial oder wie
> das hieß. Die wartet sehr wohl auf Bestätigung/Abholung...
Nicht soweit mir bekannt....

Oder anders gesagt:
Meine tun das nicht.
Und ich werde ihnen auch nicht sagen, dass sie es tun sollen.

Die gesendeten Daten landen im Nirvana!
So wie beim 328P, als auch beim 32U4

Wenn man sie nicht im Nirvana haben möchte, sollte man (beim 32U4) eine 
Blockade einführen.

while(!Serial);
Blockiert den 32U4 solange, bis vom PC ein Port geöffnet wird.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Nein. Ein Fdti an RX-TX:
> https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf

Nöö..
Ein ATMega16U2. (oder ganz alt, ein 8U2)
Es gibt einige UNO kompatible mit anderen Serial Wandlern.
Aber mit FTDI ist mir keiner bekannt.

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

es ist egal was man da sendet, der AVR schiebt es ben zum TX raus und 
damit ist das Thema für ihn erledigt. Hier laufen auch Sachen, wo ich 
einfach vergessen habe, meine Debug-Ausgaben abzuschalten und da wird 
dann noch einges mehr an Daten ins Nichts geschickt. Die Ausgaben 
bremsen natürlich den Programmablauf etwas, wenn sie erfolgen. Da ich 
allerdings die Serielle ohnehin immer auf 115200 setze ist auch die 
Wartezeit auf Platz im seriellen Buffer gering falls es mal mehr als die 
64 Byte Buffer sind.

Solche Aufhänger sehen immer nach knapp werdendem Ram aus oder falscher 
Arraygröße, wo nur selten über die Grenze geschrieben wird, oder...

Gruß aus Berlin
Michael

: Bearbeitet durch User
Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert S. schrieb:
> Was passiert eigentlich, wenn ich einen Arduino Uno extern versorge und
> trotzdem Serial.print() verwende, ohne angeschlossenes Serial Interface?

Man sieht die Tx-LED flackern, weiter nichts, es läuft einfach.

Gedanken habe ich mir gemacht, einen ProMini möglichst schnell wieder 
schlafen zu legen, da frage ich einen Pin ab (Brückenstecker) und sende 
nur, wenn dieser auf "Debugmode" gesteckt ist.

Arduino F. schrieb:
> Ein ATMega16U2. (oder ganz alt, ein 8U2)
> Es gibt einige UNO kompatible mit anderen Serial Wandlern.
> Aber mit FTDI ist mir keiner bekannt.

Natürlich nicht, weil FTDI unverschämte Preise nimmt und sich damit der 
ChinUNO preislich verdreifachen würde. Mit FTDI ist mir nur der 
Gravitech-Nano bekannt, den ich nicht bereit bin, zu bezahlen.

Autor: P.Loetmichel (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
Mit BASCOM täte es auch ein ganz normaler ATMEGA8!

Autor: Joschua K. (cimera)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hast du vielleicht irgendwas im Code wie:

//mach alle paar Millisekunden irgendwas
if (millis() > last + x){
   //mach irgendwas
   last = millis();
}

Das kann beim Überlauf von millis() (etwa nach 50 Tagen) dazu führen das 
der Code im if-Statement nicht mehr ausgeführt wird. Falls du dann noch 
für dein millis in einem long statt unsigned long zwischenspeicherst 
o.Ä. würde das sogar mit deinen drei Wochen etwa hinkommen.

Das Problem wird auch hier beschrieben: 
https://forum.arduino.cc/index.php?topic=285280.0

Lösung:
if (millis() - last > x)

: Bearbeitet durch User
Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bert S. schrieb:
> Ist dies überhaupt ein Ring Buffer, oder was passiert
> wenn dieser voll ist? Ich habe nämlich ein Problem mit
> einem Arduino Uno, der sich nach etwa 3 Wochen aufhängt,
> wobei ich festgestellt habe, dass ich ein Serial.print("...")
> vergessen habe, wo aber nur ein paar mal am Tag aufgerufen wird.

Warum sollte ein Buffer voll laufen. Solange die 
Schnittstellengeschwindigkeit höher als deine mittlere Datenrate ist, 
klötern die Bits schneller am TX raus, als du sie rein schreibst. Der 
ATmega328 des Arduino Uno weiss nicht, was hinter seinem TX Ausgang 
kommt und ob sich jemand für die gesendeten Inhalte interessiert. Guck 
mal mit einem Oszi/LA auf TX (DIO1). Da kommen die Bits rausgepurzelt, 
egal wie du den Uno versorgst.
https://www.arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Nicht soweit mir bekannt....

Kann sein dass sich meine Erinnerung hier auf die STM32 Arduino 
Implementation bezieht... Es ist natürlich schon so dass ein Controller 
der direkt an die "echte" USB Schnittstelle angeschlossen ist merkt wenn 
Daten vom USB aus abgefragt werden. Ob er bei Nicht-Abfragen blockiert 
oder Daten löscht ist eine Implementations Frage...

Autor: Bert S. (kautschuck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joschua K. schrieb:
> Hast du vielleicht irgendwas im Code wie:
>
> //mach alle paar Millisekunden irgendwas
> if (millis() > last + x){
>    //mach irgendwas
>    last = millis();
> }
>
> Das kann beim Überlauf von millis() (etwa nach 50 Tagen) dazu führen das
> der Code im if-Statement nicht mehr ausgeführt wird. Falls du dann noch
> für dein millis in einem long statt unsigned long zwischenspeicherst
> o.Ä. würde das sogar mit deinen drei Wochen etwa hinkommen.
>
> Das Problem wird auch hier beschrieben:
> https://forum.arduino.cc/index.php?topic=285280.0
>
> Lösung:
> if (millis() - last > x)

Sehr gut das du das erwähnst. Ich verwende eine Timer library namens 
"TimerObject.h".

https://playground.arduino.cc/Code/ArduinoTimerObject

Im Code ist da sehr viel mit millis():
#include "TimerObject.h"

TimerObject::TimerObject(unsigned long int ms){
  Create(ms, NULL, false);
}

TimerObject::TimerObject(unsigned long int ms, CallBackType callback){
  Create(ms, callback, false);
}

TimerObject::TimerObject(unsigned long int ms, CallBackType callback, bool isSingle){
  Create(ms, callback, isSingle);
}

void TimerObject::Create(unsigned long int ms, CallBackType callback, bool isSingle){
  setInterval(ms);
  setEnabled(false);
  setSingleShot(isSingle);
  setOnTimer(callback);
  LastTime = 0;
}

void TimerObject::setInterval(unsigned long int ms){
  msInterval = (ms > 0) ? ms : 0;
}

void TimerObject::setEnabled(bool Enabled){
  blEnabled = Enabled;
}

void TimerObject::setSingleShot(bool isSingle){
  blSingleShot = isSingle;
}

void TimerObject::setOnTimer(CallBackType callback){
  onRun = callback;
}

void TimerObject::Start(){
  LastTime = millis();
  setEnabled(true);
}

void TimerObject::Resume(){
  LastTime = millis() - DiffTime;
  setEnabled(true);
}

void TimerObject::Stop(){
  setEnabled(false);

}

void TimerObject::Pause(){
  DiffTime = millis() - LastTime;
  setEnabled(false);

}

void TimerObject::Update(){
  if(Tick())
    onRun();
}

bool TimerObject::Tick(){
  if(!blEnabled)
    return false;
  if(LastTime > millis()*2)//millis restarted
    LastTime = 0;
  if ((unsigned long int)(millis() - LastTime) >= msInterval) {
    LastTime = millis();
    if(isSingleShot())
      setEnabled(false);
      return true;
  }
  return false;
}


unsigned long int TimerObject::getInterval(){
  return msInterval;
}

unsigned long int TimerObject::getCurrentTime(){
  return (unsigned long int)(millis() - LastTime);
}
CallBackType TimerObject::getOnTimerCallback(){
  return onRun;
}

bool TimerObject::isEnabled(){
  return blEnabled;
}

bool TimerObject::isSingleShot(){
  return blSingleShot;
}


Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich das auf die schnelle überblicken kann, sollte die Timer 
Klasse funktionieren.
Du verwendest eine veraltetete Version.
Aber auch das ist kein Drama.

Mir gefallen die "unsigned long" da nicht.
Das ist für AVR, angemessen, aber auf 32 Bit Modellen dürfte das dann 
unnötiger Weise 64 Bit nutzen.


Schlussendlich, dürfte die Klasse ok sein.
Und nicht deinen Fehler verursachen.

Die Serielle Ausgabe ist nicht dein Problem.

---------
Auch wenn du es nicht hören möchtest:
Aus meiner Sicht hast du ein anderes Problem im Code!

: Bearbeitet durch User
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Auch wenn du es nicht hören möchtest:
> Aus meiner Sicht hast du ein anderes Problem im Code!

Sehe ich genauso. Drei Wochen sind auch deutlich weniger als 49 Tage. Da 
ist was anderes Faul.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Mir gefallen die "unsigned long" da nicht.
> Das ist für AVR, angemessen, aber auf 32 Bit Modellen dürfte das dann
> unnötiger Weise 64 Bit nutzen.

long ist auf den meisten Plattformen 32 bit... So ein Ratespiel 
vermeidet man durch Nutzung von uint32_t & Konsorten.

Autor: Bratarrat (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hatte mir die tage das zurecht Geklöppelt.

Zwar nicht schön, aber erfüllt seinen Zweck. Wenn D2 nicht mit GND 
gebrückt, gibt es keine/kaum Serielle Ausgabe.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mir gefallen die "unsigned long" da nicht.
> Das ist für AVR, angemessen, aber auf 32 Bit Modellen dürfte das
> dann unnötiger Weise 64 Bit nutzen.

Zumindest beim ARM ist unsigned long ebenfalls 32bit.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Wenn D2 nicht mit GND gebrückt, gibt es keine/kaum Serielle Ausgabe.

Für solche Zwecke benutze ich manchmal einen Jumper, den ich mitten auf 
den 6 Poligen ISP Anschluss stecke.

Autor: Manfred (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
>> Wenn D2 nicht mit GND gebrückt, gibt es keine/kaum Serielle Ausgabe.
>
> Für solche Zwecke benutze ich manchmal einen Jumper, den ich mitten auf
> den 6 Poligen ISP Anschluss stecke.

Und wozu? Ich habe mindestens drei Anwendungen, wo serial.print aktiv, 
aber nichts angeschlossen ist, es passiert genau garnichts!

Ich teile diese Ansicht:
yesitsme schrieb:
> sollte ungehört verhallen

Ich habe eine Anwendung mit dem ProMini, wo ich Strom sparen will, da 
gibt es einen Brückenstecker (aka Jumper) "debug". Diesen frage ich ab 
und gebe nur serielle Daten aus, wenn er gesetzt ist, damit ich im 
Regelbetrieb schnell wieder in den Schlaf komme.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und wozu?

Um die Zeit zu sparen, die Debug Ausgaben kosten. Wenn das für die 
Anwendung irrelevant ist, dann braucht man natürlich auch keinen Jumper.

> Ich habe eine Anwendung mit dem ProMini, wo ich Strom sparen will, da
> gibt es einen Brückenstecker (aka Jumper) "debug". Diesen frage ich ab
> und gebe nur serielle Daten aus, wenn er gesetzt ist, damit ich im
> Regelbetrieb schnell wieder in den Schlaf komme.

Das wäre mein Grund Nr 2 gewesen. Ich bin verwirrt, das du nach einem 
Grund gefragt hast und direkt danach selbst einen geliefert hast. Irgend 
etwas muss ich da missverstanden haben.

: Bearbeitet durch User
Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei meinem indischen Motorrad hat sich der Hersteller was interessantes 
ausgedacht:
Tx o---[===]---------o-+
                       |
Gnd o----------------o-+

Und zwar hat es einen seriellen Ausgang, wo man eine LED anschließen 
kann. Diese gibt dann allerlei Diagnose-Infos als eine Art Morsecode 
aus. Fahren kann man in diesem Zustand nicht.

Im Fahrbetrieb zieht man die LED ab und steckt einen Brückenstecker auf. 
Dadurch wird die Ausgabe der Diagnosemeldungen deaktiviert.

: Bearbeitet durch User
Autor: npn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Bei meinem indischen Motorrad hat sich der Hersteller was
> interessantes
> ausgedacht:Tx o---[===]---------o-+
>                        |
> Gnd o----------------o-+
>
> Und zwar hat es einen seriellen Ausgang, wo man eine LED anschließen
> kann. Diese gibt dann allerlei Diagnose-Infos als eine Art Morsecode
> aus. Fahren kann man in diesem Zustand nicht.
>
> Im Fahrbetrieb zieht man die LED ab und steckt einen Brückenstecker auf.
> Dadurch wird die Ausgabe der Diagnosemeldungen deaktiviert.

Und der Kurzschluss von TX nach GND stört nicht?

Autor: npn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
npn schrieb:
> Und der Kurzschluss von TX nach GND stört nicht?

Ich seh gerade, das ist wohl ein Widerstand in der TX-Leitung?
Dann hat sich meine Frage erledigt. Sorry :-)

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
>> Und wozu?
>
> Um die Zeit zu sparen, die Debug Ausgaben kosten.

Wozu? Für gesparte Clockticks gibt's kein Geld zurück ;-)

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wozu? Für gesparte Clockticks gibt's kein Geld zurück

Wie gesagt, der Motor meines Motorrades kann zum Beispiel nicht laufen, 
wenn diese Debug Meldungen des Steuermoduls aktiviert sind.

Wenn die Ausgaben in der konkreten Anwendung nicht stören, würde ich 
auch auf eine Deaktivierung verzichten.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.