Hallo Zusammen, Welche Protokolle verwendet Ihr um zu kommunizieren zwischen PC und MCU für verschiedene Schnittstellen (RS232, USB, Ethernet, CAN)? Ist das Protokoll (PC-Seite) selbstgeschrieben oder gibt es eine gute Bibliothek dafür? Bitte, keine teoretische Grundlagen - einfach von eigene Erfahrung. Diese frage ist nur für meine Interesse. Es gibt keine konkrete Probleme/Aufgabe zu lösen. Um die Frage mehr praktisch zu machen, hier sind einpaar Anforderungen: - Soll Firmware Aktualisierung möglich sein (falls Protokol erlaubt dass) - 10 bit ADC 2-3 Kanelle abgetastest möglich soll - Ping beziehungsweise Hearbeat 10-15 Mal/sec. soll möglich sein Platformen mehr richtung Arduino Uno/MSP430. Danke
:
Bearbeitet durch User
Kommt drauf an, was "das Gerät" ist, und was seine Aufgabe ist. So ist Deine Frage viel zu allgemein gestellt und daher nicht sinnvoll zu beantworten.
In den meisten Fällen (excl. RS232) kann man am Protokoll nicht herumfummeln. USB Es sind jede Menge Geräte möglich bei USB-Verbindung, da dies aber sehr tief in das System eingreift, ist der Eigenentwurf eines eigenen Gerätes eine Siphos-Arbeit. Aber auch hier MUSST Du innerhalb der USB-Spezifikationen bleiben. CAN Soweit mir bekannt, lässt das CAN-Protokoll einige "Sonderwünsche" zu, die aber auch innerhalb der Spezifikationen bleiben MÜSSEN. Ethernet Das hier verwendete Protokoll ist ebenfalls genau spezifiziert. Vor allem im Bereich der Datenpaketgröße kann man einiges machen, aber nur, wenn das auch vorgesehen ist. Man sollte auch nicht vergessen, dass ein beträchtlicher Teil der Übertragungsarbeit schon in der Hardware abgewickelt wird und deshalb auch von ihr verstanden werden muss. Am meisten Spielraum lässt hier wohl das serielle Protokoll zu. Geschwindigkeit, Prüfungen (incl. Stoppbits), Anzahl an Datenbits (meist 5 bis 9) usw. Was aber in die Datenpakete hineingepackt wird, wie viele zusammengehören, ob irgendwelche als Adresse interpretiert werden, interessiert keinen. Der Spielraum ist aber insofern beschränkt, dass man manchmal an bestimmte "Schalter" nicht herankommt.
Als Entwickler von eigenen Geraeten : Ich verwendete bisher UART, als RS232 & RS422, resp UART ueber USB, weil das von der Geschwindigkeit her reichte. Das Protokoll hab ich selbst entwickelt. Ein zustandsloses Master-Slave-Protokoll, das mehrere Slaves gleichzeitig erlaubt. Fuer neue Geraete mit hoeheren Anspruechen an die Geschwindigkeit werde ich Ethernet verwenden, auch mit einem selbst entwickelten Protokoll. Web falls passend.
Einige Regeln die ich selber immer benutze -wenn moeglich- : * PC immer als master. Der Slave sendet also immer NUR wenn er gefragt wird. * Keine 0 karakters im protocol, am liebsten alles lesbar halten um die debugging einfacher du machen * Timing nicht abhangig von kommunikation machen um damit nicht abhangig zu sein von latencies. Also am besten ein start/stop command und ein command um den puffer auszulesen. * Wenn komplette binaire files hin- und her gesendet werden muessen (zB fuer bootloading) dann via ZMODEM protocol. Mittels TeraTerm (oder Hyperterm) kann man dann testen * RS-232 : Einfachsten * USB : Virtual comm-port benutzen * Via ethernet : Ein socket benutzen * Via xxx : Immer eine einfache seriele verbinding benutzen Also wenn die bandbreidte der daten es moeglich macht, zoviel moeglich standarisieren. Das macht das definieren, testen, programmieren usw viel einfacher. Wie meinst du PING 10~15x pro sekunde ? Das kann schnell problematisch werden zB bei USB virtual comm-port sind eine latency von ca 50ms schon schnell erreicht.
Es gibt in diesem Bereich SCPI. Das ist allerdings sehr ..ähm.. ausufernd: http://www.ivifoundation.org/docs/SCPI-99.PDF
Michael X. schrieb: > Es gibt in diesem Bereich SCPI Volltreffer! IEEE bzw. IEC-Bus ist so ziemlich die einzige Verbindung, nach der der TO NICHT gefragt hat (liegt sicher daran, dass er davon noch nichts gehört hat). Georg
Sapperlot W. schrieb: > Als Entwickler von eigenen Geraeten : > Ich verwendete bisher UART, als RS232 & RS422, resp UART ueber USB, weil > das von der Geschwindigkeit her reichte. Das Protokoll hab ich selbst > entwickelt. Ein zustandsloses Master-Slave-Protokoll, das mehrere Slaves > gleichzeitig erlaubt. > Fuer neue Geraete mit hoeheren Anspruechen an die Geschwindigkeit werde > ich Ethernet verwenden, auch mit einem selbst entwickelten Protokoll. > Web falls passend. Ist das möglich mit mehrere Slaves über UART kommunizieren? Oder meinst du protokoll-Kanele/virtuele Slaves?
Oleh P. schrieb: > Ist das möglich mit mehrere Slaves über UART kommunizieren? Mach ich seit Jahrzehnten, setzt allerdings busfähige Hardware (RS422/485) oder Multiplexer voraus, da die serielle Schnittstelle ohne Zusatz nur 2 Geräte verbinden kann. Und ein Master-Slave-Protokoll, damit immer nur 1 Slave antwortet. Georg
Georg schrieb: > IEEE bzw. IEC-Bus ist so ziemlich die einzige Verbindung, Meinst Du IEEE 488 aka general-purpose-bus? Insgesamt scheint aber hier vor dem Feiertag eher ein Freitagsprogramm zu laufen. Der "Schreibakzent" ist zu offensichtlich. ;)
Wie man das anstellt per UART mit mehreren Slaves zu kommunizieren. Meine bevorzugte Loesung, RS422. Diese Loesung hat zwei Leiter Paare, das eine vom Master weg, das andere zum Master hin. Das Paar vom Master weg ist immer aktiv, das Paar zum Master hin ist nur aktiv wenn ein Slave antworten muss, fuer exakt diese Meldung. Der betreffende Slave schaltet seinen Treiber zum Antworten ein. Das Protokoll besteht aus einer Meldung vom Master an einen adressierten Slave, welcher innerhalb einer Zeitspanne antworten muss. Die Kommunikations Zustaende der Geraete duerfen daher nicht blockierend sein. Die Antwort muss quasi sofort zurueck kommen. Man sollte die Kommunikation zusammen mit der Hardware aus einem Guss entwickeln und nicht nachher aufsetzen.
Detail : IEEE 488 war auch die bus die im seriele form fuer commodore 64 benutzt war. Fuer floppy/printer... Fast vergessen... Gutes beispiel !!! Patrick
Bonzillo schrieb: > Man sollte die Kommunikation zusammen mit der Hardware aus einem Guss > entwickeln Wobei das beschriebene Master-Slave-Protokoll (so mache ich es auch) für eine ganze Reihe verschiedene Hardware-Verbindungen geeignet ist von V24 bis Ethernet. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.