Arduino frage zu Serial.print

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

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.

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.

Dr. Sommer schrieb:
> also USBSerial

Hat der Arduino Uno das?

Nein. Ein Fdti an RX-TX:
https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf

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.

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.

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.

Mit BASCOM täte es auch ein ganz normaler ATMEGA8!

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

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...

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!

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.

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.

> 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.

> 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.

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.

> 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.

Bei meinem indischen Motorrad hat sich der Hersteller was interessantes 
ausgedacht:

1

Tx o---[===]---------o-+

2

                       |

3

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.

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?

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 :-)

> 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.