Hi,
ich möchte ein “Bussystem” für meinen RC LKW bauen. Dazu Sollen mehrere ATiny85 für die Steuerung von LEDs und 2-4 Servo-PWM (max 1 pro ATtiny) Signalen benutzen.
Welche Kommunikationsart wurdet ihr wählen?
Aktuell bin ich bei “softseriel” wobei ich #01#010de# senden würde.
01: Adressierter ATtiny
010de: Jeweiliger wert der Pins 1-5 (3 Digitalwert / 2 Analoge 0 bzw. 1% als ASCII to USINT wert)
Gibt es eine Elegantere Methode?
Das ist schwierig zu parsen.
Kein eindeutiger Anfang, Zahlen die oktal sind nach C/C++ Standard. Dazwischen ein "de" Und kein eindeutiges Ende.
Es gibt so viele schöne I2C Bausteine.
Auch die Tinys können I2C.
Und wenn dir dann ein Pin fehlt, kannste ja den Reset umdefinieren.
ich würde mir einen Controller mit CAN suchen und einen CAN Bus bauen.
Wenns nur "simple" über Serial gehen soll würde ich ein Protokoll in dieser Form nehmen:
1 Byte: Version
1 Byte: Sender
1 Byte: Empfänger
1 Byte: Funktion
n Byte: Nutzdaten
LF: EndbyteFrüher hat man Übertragungen mit STX begonnen und mit ETX beendet. Und alle Nutzdaten < 0x1f wurden mit ESC + (Nutzdaten+0x1f) maskiert. Damit konnte man immer gut aufsynchronisieren. Dazu dann noch ein CRC.
Die Übertragung als ascii hat die Vorteile, dass es leicht mit anderen Testgeräten simulierbar ist, und -wenn man es geschickt macht- kein Zeichen falsch interpretiert werden kann.
Ein eindeutiges Startzeichen zur Synchronisation ist hilfreich.
Ob du --wie von @noiasca vorgeschlagen-- Version, Sender, Endbyte ( CRC? ) brauchst und unterschiedliche Nachrichtenlängen, kann ich aus deiner Beschreibung nicht erkennen.
Ich geh mal davon aus der RC-LKW ist ein "Spielzeug" und nichts tun bei Übertragungsproblemen ist ausreichende Fehlerbehandlung. 
Weiß ich nicht, aber im Thema Attiny85 will nicht aufwachen bin ich über die Bibliothek VirtualWire gestolpert, die offensichtlich auch auf dem ATtiny85 läuft. Mangels Funkmodul habe ich die Empfangsseite mit einem UNO simuliert. Das sollte auch umgekehrt funktionieren.
END OF LIFE NOTICE: This VirtualWire library has now been superceded by the RadioHead library RadioHead: RadioHead Packet Radio library for embedded microprocessors RadioHead and its RH_ASK driver provides all the features supported by VirtualWire, and much more besides, including Reliable Datagrams, Addressing, Routing and Meshes. All the platforms that VirtualWire supported are also supported by RadioHead.
Sollte die Bibliothek für Dich interessant sein, kann man nochmal näher hinschauen 
Ich vielleicht auch. Allerdings hängt es ein wenig vom Maßstab des Modells ab, ob das nicht am Ende over-sized ist.
Da braucht es dann auch kein wirkliches Protokoll. Information kann in unterschiedlichen Nachrichten-IDs versendet werden - es stehen ungefähr 2000 verschiedene (2^11 im Minimal-Standard CAN 2.0A) zur Verfügung; die Empfänger können auf die für sie jeweils passenden Nachrichten horchen.
Naja ich brauche (+) ,( -) und 5 DO/AO in einem DIP8 Gehäuse bleibt da noch 1 Pin. Naja zwischen dem Datenpuffer zweier Nachrichten stehen 2 “#”.
Aber Ich denke ich werde es eher Funktionsspiezifisch aufbauen, somit hätte ich an den ATtinys auch keine “Verzögerung”.
Also anstatt mit #01# den Tiny zu adressieren, schickt der ESP einfach ##BL#1# [heißt Blinker links 1]. Dass ganze dann doppelt verschickt und alle sollten es mitbekommen. Der tiny Vorne Links Muss dann nur noch wissen an pin3 hab ich einen Linken Blinker [BL] den mus ich jetzt einschalten.
Jetzt wäre natürlich interessant wie man so eine Definition, also BL = BlinkerLinks, Global für alle Tinys und dem ESP in der IDE verwaltet?
Vielen dank.
Vor 25 Jahren haben wir sowas mit einer gemeinsamen Header-Datei gemacht, die in allen beteiligten Projekten angezogen wurde. Das geht auch heute noch und wäre einfach gesprochen sowas wie eine Library ohne funktionalen Code.
Die typischen Probleme von damals (einer ändert, nicht alle bekommen es mit, ein anderer ändert zurück, Änderungen sind nicht rückwärtskompatibel) solltest Du nicht haben solange Du allein an dem Projekt arbeitest und alle Teile im Griff hast.
wie schon angesprochen, leg dir eine .h Datei in einer eigenen Library an und gib dort alles an globalen Variablen/Konstanten/Funktionen/Klassen die du in allen deinen LKW Sketches brauchst.
Und so Wertevoräte passen gut in eine gescopte Enumeration
enum class Function {
BlinklerLinks = 48,
BlinkerRechts,
Standlicht,
Ablendlicht,
Fernlicht,
Bremslicht,
};Würde ich lieber wie beim Auto (mit CAN-Bus) machen: Die Nachricht enthält das Ereignis, die angeschlossene Hardware sucht sich die für sie relevanten Informationen heraus.
Beispiel 1: Wenn das Ereignis "Bremsleuchte" kommt, können zwei ATtinys darauf reagieren, sowohl links wie auch rechts.
Beispiel 2: Beim Ereignis "Warnblinker" können alle vier Blinker reagieren.
Hi,
wie wäre denn die Dateistruktur? Oder hab ihr die Bib auf die einzelnen Projektordner kopiert? Danke.
jeder Sketch bekommt weiterhin sein eigenen Projekt Ordner und die gemeinsamen Sachen kommen als Library in ein Verzeichnis unter libraries. Dort wo die anderen libraries die du runterlädst auch hinkommen.
Kannst Du mal ein bisschen mehr über den RC-LKW schreiben? Wie groß/Maßstab? Was für Funktionen? Normalerweise sollte ein ESP32 doch ausreichen, um ein paar Servos und LED's auch direkt zu steuern. Ist ein Bussystem da nicht ziemlich oversized und macht das Ganze unnötig kompliziert?
Hi, wie gesagt habe ich jetzt meine Lösung.
Der LKW ist ein Kabolite 5801. Jetzt habe ich ein “PAAR” Zusatzleuchten gekauft. So 16 LEDs dazu noch Differentialsperre, Front- und Heckkraftheber, Zugmaul … und da zig Kabel quer durch den LKW zu legen oder 3 -Busleitungen- ist halt schon ein größerer Unterschied. Und der Spaß beim Programmieren ON-TOP 
vieleicht ist mein (LED) Toolkit für dich was:
Blinker, Warnleuchten wäre alles schon da:
I²C-Bus und ein paar enstprechende Bausteine wäre sicher auch eine Option gewesen. Da hätte man nur einen zentralen Sketch gehabt und nicht entsprechend viele ATtinys programmieren müssen. Aber schön, wenn Du eine für dich funktionierende Lösung gefunden hast 
.
Beeindruckendes Teil ... 