[Gelöst] Zweite SoftwareSerial - Nur senden?

International Deutsch
#1

Hallo zusammen,

ich habe eine Platine mit At328P, die ich gerne um einen Logger auf eine SD-Karte erweitern möchte.
Die Platine ist aber schon fertig und verfügt nur noch über herausgeführte Pins der ISP-Schnittstelle.
Deshalb habe ich mir einen Nano geschnappt, das SD Modul per SPI angeschlossen und einen Sketch geschrieben, der alles vom HardwareSerial entgegen nimmt und in eine Datei schreibt.
Funktioniert auch im Testaufbau!

Nun zum eigentlichen Problem:
Sowohl Hardware- & Software-Serial sind bereits in Gebrauch. Zwei Software-Serial funktionieren nicht parallel.
Dafür gibt es die AltSoftSerial-Library, die das durchaus ermöglicht.
Allerdings möchte ich ja ausschließlich senden und daher den Timer nicht unnötig damit belasten, auf eingehende Daten zu lauschen, die nie ankommen werden.
Die andere, bereits genutzte SoftwareSerial-Schnittstelle ist zwingend bidirektional.

Mir geht es dabei nur um ein erweitertes Debuggen. Nicht um den Einsatz im Dauerbetrieb o.ä.

Prinzipiell arbeiten alle Schnittstellen nacheinander:
SWSerial empfängt einen Befehl, HWSerial sendet ihn raus, wartet auf die Antwort und schickt diese per SWSerial zurück. Dazwischen möchte ich die Ein- und Ausgehenden Befehle und Antworten "wegschreiben". Vielleicht auch noch ein paar Status-Meldungen zur Konvertierung der Daten.

Oder wäre die Alternative SWSerial ständig zu stoppen, auf die anderen Pins zu starten, Loggen und wieder zurück zu setzen? Stelle ich mich sehr langsam vor :confused:

#2

So richtig verstehe ich dein Vorhaben nicht.

In vielen meiner Projekte funktioniert SoftwareSerial problemlos an 2 Schnittstellen, allerdings wie du schon schreibst, funktioniert das nur nacheinander. Aber auch das geht mit SoftwareSerial.

#3

Okay, also wäre die simpelste Lösung etwas wie:

void LogData(String str){
  Bluetooth.end();
  Logger.begin(57600);
  Logger.println(str);
  Logger.end();
  Bluetooth.begin(57600);
}

Hätte nur irgendwie erwartet, dass das nicht sonderlich performant ist. Aber das kann ich ja selbst messen, wie lange die Initialisierung dauert.

Dann kann ich zumindest auf eine weitere Library verzichten! Das ist schon mal gut zu wissen.

#4

TriB:
Okay, also wäre die simpelste Lösung etwas wie:

void LogData(String str){

Bluetooth.end();
 Logger.begin(57600);
 Logger.println(str);
 Logger.end();
 Bluetooth.begin(57600);
}



Hätte nur irgendwie erwartet, dass das nicht sonderlich performant ist. Aber das kann ich ja selbst messen, wie lange die Initialisierung dauert.

Dann kann ich zumindest auf eine weitere Library verzichten! Das ist schon mal gut zu wissen.

Das sollte so funktionieren.

In meinem Sketch habe ich beide Instanzen (für Nextion und MP3-DFPlayer) im Setup gestartet und das funktioniert auch.

Zu der Performance kann ich nichts sagen, da ich nur beides manuell bediene.

#5

HotSystems:
In meinem Sketch habe ich beide Instanzen (für Nextion und MP3-DFPlayer) im Setup gestartet und das funktioniert auch.

Genau das hatte ich bereits versucht und es ist nichts auf meine SD-Karte angekommen.
Habe ich einen neuen Sketch erstellt, ohne 2. serielle Schnittstelle, wurde freudig auf die Karte geschrieben.

Aber dann werde ich es mal mit der o.g. Herangehensweise versuchen und berichten.

Dank Dir bis hier hin :slight_smile:

#6

So geht es natürlich sofort!
Den anderen Port explizit beenden und schon kommen die Daten sauber an.
Habe jetzt noch nicht gemessen wie lange der "Wechsel" dauert, scheint meinen Programmfluss aber nicht zu stören.

#7

TriB:
So geht es natürlich sofort!
Den anderen Port explizit beenden und schon kommen die Daten sauber an.
Habe jetzt noch nicht gemessen wie lange der "Wechsel" dauert, scheint meinen Programmfluss aber nicht zu stören.

Ok, scheint dann ja eine sichere Sache zu sein.
Vielen Dank für deine Rückmeldung.

#8

Auch auf die Gefahr hin, einen gelösten Thread wieder nach oben zu bringen, wollte ich noch kurz die Dauer des Ganzen bekannt geben.

Arduino Nano (AtMega328P) 16mHz

void Log(String text){
  uint32_t start = millis();
  Bluetooth.end();
  Logger.begin(9600); //57600
  Logger.println(text);
  Logger.end();
  Bluetooth.begin(57600);
  uint32_t ende = millis();
  Bluetooth.print("Log: ");
  Bluetooth.println(ende-start);
}

Ergebnisse:

Text 9600 57600
Log("TST") 17 5
Log("TST1234567890") 29 6
Log("TST123456") 27 4
Log("TST") 17 3

Die Zeiten sind mehrfach reproduzierbar und man kann gut nachvollziehen, dass gerade bei der niedrigen Baudrate, die Länge der Übertragung linear steigt.
Bei erhöhter Baudrate fällt das kaum noch ins Gewicht.

Mir reicht das absolut aus und die Verzögerung ist zum debuggen/loggen absolut zu verschmerzen.

#9

Hallo,

eine andere Erkenntnis hätte auch verwundert. Wenn du das “gerade bei” streichst haut es hin. Denn es gibt ganz konkret einen linearen Zusammenhang zwischen Baudrate und Zeit der Übertragung. Denn die Baudrate sagt nichts weiter aus wieviel Bits pro Sekunde übertragen werden.

#10