Author Topic: TerSer Library von Didel (Arduino Serial Replacement)  (Read 11905 times)

boxtec-support

  • Moderator
  • Hero Member
  • *****
  • Posts: 787
  • Karma: +15/-0
    • Boxtec Web
TerSer Library von Didel (Arduino Serial Replacement)
« on: March 27, 2019, 06:19:09 PM »
Hallo zusammen,

JDN von Didel hat im Rahmen einer seiner Projekte eine viel schlankere und etwas schnellere Alternative zu Arduinos Serial Library entwickelt. Die Möglichkeit diese recht einfach als drop-in replacement für Arduino Serial einsetzen zu können hat mich beeindruckt und ich habe vorgeschlagen daraus eine einfach zu installierende Library für die Arduino IDE zu erstellen.
Das haben wir getan und möchten diese auch beim Arduino Library Manager hinzufügen.

Bevor wir das aber beantragen würden wir gerne etwas Feedback dazu erhalten. Wenn also jemand grad was mit Arduino Serial macht, gebt doch bitte der TerSer Library eine Chance und lasst mich wissen was Ihr davon haltet.

Zum semi-automatischen Installieren in Arduino IDE >=1.6:
  • Zip aus git heruinterladen: Link
  • Heruntergeladenes ZIP in der Arduino IDE unter Sketch | Include Library | Add .ZIP Library importieren

Danke im voraus für jegliches Feedback.

Grüsse - Christoph

pylon

  • freakyfriday
  • Full Member
  • *
  • Posts: 158
  • Karma: +16/-0
Re: TerSer Library von Didel (Arduino Serial Replacement)
« Reply #1 on: March 28, 2019, 09:47:07 AM »
Ich habe mir das Teil kurz angeschaut. Es dürfte sicher seine Einsatzgebiete haben, aber den Begriff "Drop-in Replacement" finde ich etwas gar gewagt dafür. Das Interface erweckt nicht einmal den Anschein, kompatibel zu sein. Ich sehe die Library als eine Minimal-Variante für die Ansteuerung der (ersten) Hardware-Serial-Schnittstelle der meisten AVR-Boards (alle anderen Arduinos können sie nicht verwenden). Sie hat keine Pufferung, praktisch keine Komfort-Funktionen und vor allem: sie blockiert, man wartet also bis das gewünschte Zeichen gesendet oder empfangen wurde. Dies dürfte für den durchschnittlichen Benutzer der wichtigste Unterschied sein, denn ein Get()-Aufruf wartet notfalls für immer, wenn von der Gegenseite keine Übertragung kommt.

Für die Anbindung eines seriellen Geräts mit festem Protokoll kann die Bibliothek als Platz und Arbeitsspeicher sparende Minimalvariante genutzt werden, als Ersatz der HardwareSerial-Klasse der Arduino-IDE taugt sie nicht ansatzweise.

Vorausgesetzt, man ist gewillt, ein komplett anderes API zu verwenden und das Blockieren ist in der Anwendung akzeptabel, bleibt meiner Meinung nach ein grosses Problem: man muss genau wissen, wann ein Zeichen zu erwarten ist. Es gibt keinen Interrupt, der ein empfangenes Zeichen erst mal speichert, es gibt auch keine Funktion, um zu schauen, ob ein Zeichen empfangen wurde (ohne zu blockieren bis das Zeichen wirklich empfangen wurde). Klar, der technikversierte Anwender kann das selbst mit Registerchecks machen, das kann dieser aber grundsätzlich mit der ganzen seriellen Funktionalität machen.

Die Möglichkeiten der Ausgabe von Zahlenwerten sind interessant, aber eine Ergänzung bzw. ein Ersatz der Print-Klasse wäre für viele Anwender sinnvoller gewesen, da sie eher Nutzen daraus hätten ziehen können.

boxtec-support

  • Moderator
  • Hero Member
  • *****
  • Posts: 787
  • Karma: +15/-0
    • Boxtec Web
Re: TerSer Library von Didel (Arduino Serial Replacement)
« Reply #2 on: March 28, 2019, 01:42:38 PM »
Vielen Dank für Dein Feedback!

Speziell den Fingerzeig auf das Blocking von Get() finde ich sehr hilfreich und werde das mit JD ansprechen. Ich muss zur Motiviation der Library vielleicht noch sagen woher das kommt.
Didel entwickelt zurzeit eine Art Nachfolger des Xbotmicro, den Witty einen balancierenden Mini 2WD Bot (mit eingebauter Disco-Stossstange  ;D):



Da der Code recht umfangreich wird um alle Peripherie auf dem Bot zu kontrollieren ist jedes gesparte Byte wertvoll wenn man plötzlich debugging über seriell einschalten möchte. Von daher kommt auch die Vielzahl von Möglichkeiten Werte tabularisch, formattiert etc. auszugeben. Die Get() Funktion ist in diesem Zusammenhang wohl eher nachträglich meiner Idee geschuldet das ganze als Library zu erweitern. Persönlich denke ich, dass Get() entweder (optional) nicht-blockierend werden sollte. In jedem Fall ist der Punkt nun vorerst mal unter den Limitations aufgeführt.