Hallo, In meinem aktuellen Projekt möchte ich mehrere uC Boards von ST zwecks Datenaustausch verbinden. Eines der Boards ist der Bus-Controller, er holt sich Daten von den anderen Boards ab (Sensoren), oder sendet ihnen welche zu (Aktoren). Die Boards haben keinen LAN Anschluss, weil der uC STM32F4xx nicht genug Ressourcen hat. SPI, I2C, LIN, ModBus, und weitere, auch ältere Bussysteme sind mir bekannt, aber ich müsste einen recht umfangreichen Protokollstack schreiben, damit man die Teilnehmer z.B. via I2C reibungslos ein- und ausklinken kann. Der CAN Bus scheint mir bis jetzt die gängigste Lösung, und seine elektrischen Signale sind industrietauglich. Was mir nicht passt ist seine Busarbitrierung, die kleinen Datenpakete und die Tatsache, dass die Adresse eines Nodes vor dessen Anschliessen an den Bus programmiert werden muss. Was ich suche ist ein Bussystem (mit Protokollstack), das neue Teilnehmer automatisch erkennt, ihnen eine Adresse zuweist und sie einbindet. Es soll einen logischen Buscontroller geben, der die Arbitrierung vornimmt. Die Datenrate soll bis mindestens 500kbit/s hoch gehen, und der Bus soll mit einem UART (oder SPI) pro uC auskommen. Kennt jemand ein solches Bussystem, oder hat jemand mal was ähnliches programmiert? Grüsse, Andreas
Wenn ich deine Anforderungen sehe, wird es wohl auf Ethernet samt der dort üblichen Infrastruktur (Switche, DCHP Server, etc) hinaus laufen. Anbindung per SPI ist kein Problen, schau dir die Chips/Module von Wiznet an. Anbindung per UART kannst beim ESP32 haben (die gibt es wahlweise mit WLAN oder WLAN + Ethernet)
Andreas I. schrieb: > Was ich suche ist ein Bussystem (mit Protokollstack), das neue > Teilnehmer automatisch erkennt, ihnen eine Adresse zuweist und sie > einbindet. Das geht mit CAN sofern du einen Master bestimmst. Das Protokoll musst du halt selber machen das ist aber bei den meisten Bussen dieser Art so.
>weil der uC STM32F4xx nicht genug >Ressourcen hat.
So ein F407 zB braucht doch nur einen PHY fürs Ethernet.
RS485 gäbe es auch noch.
Johannes S. schrieb: > RS485 gäbe es auch noch. Daran dachte ich auch, aber er will ein fix und fertiges Protokoll "das neue Teilnehmer automatisch erkennt, ihnen eine Adresse zuweist und sie einbindet".
RS485 Halb-Duplex (zwei Adern) wenn du nur einen Master hast der sendet bzw. die Slaves nur auf Anfrage senden dürfen. Automatische Erkennung einfach zu lösen indem der Master ab und zu alle Adressen auf Antwort prüft. Bei CAN brauchst du dich nicht um verlorene Pakete/Kollisionen kümmern.
:
Bearbeitet durch User
Ja, in das enumerieren müsste man etwas Hirnschmalz stecken. Zum Adressieren kann man den Multidrop Mode nutzen. Die F4 können da allerdings nur nur 16 Adressen, die F7 haben 8 Adressbits. Damit bekommt man auch 10 Mbit hin.
Andreas I. schrieb: > die Adresse eines Nodes vor dessen Anschliessen an den Bus programmiert > werden muss. Eingestellt werden ja, aber nicht unbedingt per Programm. Banale DIP-Switches?
Wie weit sind den die Teilnehmer auseinander. Wieviel Teilnehmer willst du insgesamt miteinander verbinden. In welcher Umgebung wird den das ganze betrieben (Störungresistenz des Busses / automatische Fehlerkorrektur). Wenn externe Buscontroller eine Option sind: SPI <-> Ethernet ENC28J60 - https://www.microchip.com/en-us/product/ENC28J60 ENC624J600 - https://www.microchip.com/en-us/product/ENC624J600 https://www.wiznet.io/product/tcpip-chip/ UART <-> Ethernet W7100-S2E https://www.wiznet.io/product-item/w7100-s2e WIZnet hat einiger solche Ethernet IC https://www.wiznet.io/
Andreas I. schrieb: > Was ich suche ist ein Bussystem (mit Protokollstack), das neue > Teilnehmer automatisch erkennt, ihnen eine Adresse zuweist und sie > einbindet. Wozu? Warum so kompliziert? Jeder Teilnehmer bringt seine eigene, eindeutige ID mit, z.B. Seriennummer des Mikrocontrollers oder eben irgendein ID-Bauteil, wenn man die nicht einprogrammieren will. Naja, und sobald der Teilnehmer am Bus ist, sendet der einfach regelmäßig ein "Hallo, ich bin hier". Der Master empfängt es, und kann entsprechend reagieren. Kommt halt drauf an, wie lange es maximal dauern soll, bis ein neues Gerät vom Master entdeckt werden soll. Maximal eine Sekunde oder 10 Sekunden? Ist stark Anwendungsabhängig. Aber auch hier sind mit ein bisschen Cleverness, bessere Lösungen möglich.
CANopen und wenn DIP Schalter für die Adressen zu aufwändig sind, dann gerne CANopen mit LSS.
Besten Dank für eure Infos und Fragen. Ich möchte hier nicht alle einzeln zitieren, nur eine Zusammenfassung: Ich sehe, Ethernet über SPI könnte funktionieren. Hätte ich nicht gedacht. Danke für den Tipp 'Wiznet'. Wenn ich nun an die Dimensionen der Stecker und Kabel denke, passt Ethernet trotzdem nicht. Zu gross. CAN könnte mit Abstrichen (und Zustrichen) passen. Die automatische Fehlerkorrektur und Kollisionserkennung zum Beispiel sind natürlich super. RS-485 ist meine erste Wahl für Schicht 1, falls es nicht doch CAN ist am Schluss. WiFi passt nicht auf meine Anwendung (siehe unten). Wenn möglich möchte ich bei der STM32F4 Familie bleiben, allenfalls auf F7 aufrüsten. Die ESP Dinger sind super cool, leistungsfähiger als die F4, aber meine Zeit ist begrenzt, und die F4 kenne ich schon. Die Adressierung von 16 Busteilnehmern würde für meine Applikation reichen. Auf DIP-Switches möchte ich verzichten. Die Boards sind klein, die Switches auch, und in eingebautem Zustand lassen sie sich schlecht ablesen. Das zieht eine manuelle Tabelle nach sich, welches Board welche Adresse hat. Wenn möglich möchte ich das vermeiden. Besser wäre, ich könnte den Controller fragen, welche Teilnehmer am Bus sind. In allen euren Antworten fehlt der Hinweis auf einen existierenden Protokollstack, der meine Anforderungen abdeckt. Dem entnehme ich, dass es wohl keinen gibt. Vielen Dank auch für diesen versteckten Hinweis. Meine Anwendung, Hobbybereich: ich möchte uC Boards 'beliebig' vernetzen können. Zum Beispiel in Robotern (welcher Art auch immer), Modellflugzeugen (es muss ja nicht immer nur 1 uC Board mit Sensoren/Aktoren via I2C sein) oder LED-Streifen Controller. Häufig verwenden Produkte herstellerspezifische Protokolle, was ja gerechtfertigt ist. Nur lassen sie sich dann schlecht verbinden. Deshalb meine Idee, Übersetzer-Boards mit Busanschluss zu bauen, mit welchem sich 'beliebige' Produkte in ein Bussystem einbinden lassen. Nicht neu, ich weiss. Aber fromm.
Andreas I. schrieb: > Wenn ich nun an die Dimensionen > der Stecker und Kabel denke, passt Ethernet trotzdem nicht. ??? Es gibt für Ethernet extra dünne Kabel und niemand hindert dich daran, kleinere Stecker zu benutzen. Allerdings halte ich nicht viel von dem Miniaturisierungs-Wahn. Das kleine Zeug geht immer schneller kaputt. Andreas I. schrieb: > ich möchte uC Boards 'beliebig' vernetzen können. Kenne ich aus eigener Erfahrung. Anfänger wollen immer alles unnötig universell. Bis sie mit dem dazu nötigen Aufwand und den Problemen konfrontiert werden.
Andreas I. schrieb: > In allen euren Antworten fehlt der Hinweis auf einen existierenden > Protokollstack, der meine Anforderungen abdeckt. Dem entnehme ich, dass > es wohl keinen gibt. Gibts schon, ist aber sehr einsatzspezifisch. Bspw. MQTT ist wohl extra für verteilte Sensoren entworfen worden. Ist aber nicht echtzeitfähig. Also Robotersteuerungen mit Bewegungsabläufen kann man damit nicht machen. Anders ist es, wenn man nur einfache Befehle verschickt, und die tatsächliche Steuerung übernimmt dann nur ein Controller. Dann gäbs noch Protokolle aus der Automatisierungstechnik, sind echtzeitfähig mit Zykluszeiten um 1ms. Aber da braucht es normalerweise spezielle Hardware und hobbymäßig ist das wohl auch nichts. Dann gibts noch Protokolle aus dem Automobilbereich usw. Kommt halt immer darauf an, was man braucht.
Andreas I. schrieb: > In allen euren Antworten fehlt der Hinweis auf einen existierenden > Protokollstack Stimmt nicht. Ich habe dir Chips von Wiznet und Espressif (ESP32) empfohlen, da ist der Protokollstack integriert.
bei dem RS485 und Multidrop arbeitet man mit 9 Bit, ein Bit unterscheidet Adressen/Daten. Der Empfänger ignoriert alles bis er die passende Adresse bekommt. Mit einer Master - Zuhörer (Slave darf man ja nicht mehr sagen) Struktur geht jetzt die Kommunikation immer vom Master aus. Der schickt einem Zuhörer ein Kommando und der macht was. Das kann auch eine Antwort mit Daten sein, dann sollte er erstmal sagen wieviele Daten kommen. Damit brauche ich kein aufwändiges Protokoll, nur einen Watchdog falls nicht die erwartete Anzahl Daten kommt. Da kann man mit DMA die Daten effektiv schaufeln ohne mit IRQs zugeballert zu werden, es gibt nur einen wenn die Adresse angesprochen wurde.
Adressierung: Bei einem Bus gibt es erstmal keine "automatische" Adressierung. Sondern: a) Jeder hat eine unique ID (Mini-Chip, MAC, ...) b) jeder bekommt eine zufällige ID (der erste die 1, beim nächsten Aufstarten die 4) c) einprogrammiert (DIP-Schalter) d) eindeutige Telegramm-IDs (CAN) e) Daisy-Chain (z.B. Interbus) f) feste Steckplätze (16 Kabelstrippen) g) Codierstecker h) feste Typen (I2C) i) ... beliebige Mischformen (I2C z.B. mit Adressbits) Was möchtest/brauchst Du? Und das betrifft nur die Adressierung.
>Adresse eines Nodes
bei CAN wird da ehr die Nachricht adressiert, nicht wer sie sendet
dummschwaetzer schrieb: > bei CAN wird da ehr die Nachricht adressiert, nicht wer sie sendet es gibt auch Geräte die z.B. eine ID für TX und eine ID für RX haben und dann alle Nachrichten multiplexen.
Vielen Dank für eure Anregungen. Sie haben meinen Horizont erweitert und reichen für einen ersten Anlauf aus. Beste Grüsse, Andreas
Allenfalls sollte noch eingeworfen werden, dass ein Master-Slave System beliebig viel einfacher wie ein Multimaster System ist. Das waere dann der Master macht alles, die Anfragen, das Timing, die Slave antworten nur. Sinnvollerweise macht man's so, dass die slaves immer Antworten, wenn sie's verstanden haben. Jede verstandene Anfrage gibt eine Antwort, auch wenn sie leer ist. Und nicht, wenn sie's nicht betrifft, resp den Inhalt nicht verstanden haben. Bedeutet keine Antwort bedeutet, die Anfrage ging verloren. Der Master muss nochmals senden. Sinnvollerweise macht man die Kommunikation auf Applikationslevel zustandsfrei. Bedeutet die Antwort kann zweifelsfrei zugewiesen werden. ZB bei einem Download wird die Packetnummer oder Index mitgeliefert, der Download laeuft in Bloecken. Was bedeutet der Master kann bei einem Uebertragungsfehler den Download per Index/Blocknummer nochmals anfordern und muss nicht bei Null beginnen.
Moin, Eine frage hätte ich da noch, musst du deine Sensoren / aktoren eindeutig identifizieren können? oder ist es dir egal wenn Sensor A beim nächsten kaltstart zu Sensor B wird und Aktor Z beim nächstenmal Aktor Y? Auf was ich raus will, du wirst ggf um irgend eine art der ID / Address vergabe beider Sensor / Aktor knoten gar nicht herumkommen. Ob die jetzt auf Basis von dip switches Seriennummern lötbrücken / Spannungsteilern eeprom emulation im flash hardcoded in x FW Varianten / ... ist dann zweitrangig.
BLE schrieb: > ist es dir egal wenn Sensor A beim > nächsten kaltstart zu Sensor B Slaves automatisch eine Adresse zuzuweisen ist das geringste Problem, die Schwierigkeiten fangen eine Ebene höher an: ist das neu adressierte Gerät nun ein Temperatursensor, eine Anzeige oder ein Garagentor? Der Protokollstack sagt dazu nichts, das ist Sache der Anwendungssoftware, und vermutlich viel komplexer als das Übertragungs-Protokoll selbst. Bei sich ändernden Adressen muss der Slave mitteilen was er darstellt. Bei Master-Slave erhebt sich die Frage wie sich neue Slaves anmelden - ich habe z.B. den Master dazu programmiert, neben den Abfragen der bekannten Slaves immer eine von 64 möglichen sonstigen Adressen bzw. Slaves abzufragen, dann muss man das Masterprinzip nicht aufgeben, aber da in jedem Zyklus nur eine Adresse abgefragt wird und man ja warten muss ob jemand antwortet dauert es eine Weile bis ein neuer Slave erkannt und in die Liste aufgenommen wird - was in meinem Fall akzeptabel ist. Schnell geht es nur wenn der Slave von sich aus aktiv wird (und laufende Übertragungen unterbricht), aber dann ist das Masterprinzip durchbrochen. Georg
@Purzel: Meine Ideen gehen genau in die Richtung die du beschreibst. Nicht allzu viel Logik in die Kommunikationsschichten, aber doch genug, dass die Applikation merkt wenn etwas schief gelaufen ist. Dann kann sie entscheiden was sie macht. Und nur einen Bus-Controller. Es gibt so viele mögliche Fehlerquellen in einem verteilten System, von 'da hat jemand den Stecker gezogen' bis zu 'ein Adressbit wurde verdeichselt'. Das möchte ich nicht alles in den Comm Layer packen. Es gäbe sowieso keine allgemein gute Lösung. @BLE (Gast): Du hast natürlich völlig recht. Irgendwo muss so eine Tabelle existieren. Ich möchte sie im Bus-Controller haben und sie dort via Kommandozeile lesen und schreiben können. Als eindeutige Identifikation (UID) möchte ich die Seriennummer des uC nehmen. Auf Projekt-/Applikationsebene muss ich den Knoten ebenfalls eine ID zuweisen, z.B. Sensor1: Id=1, Sensor2: Id=2, Aktor1: Id=3. Der Bus-Controller muss diese IDs kennen (Konfiguration über C Code oder Kommandozeile, Speicherung im NV Memory), und er muss sie bei den Knoten abrufen können. Mit diesem Ansatz, so meine ich, sollte es möglich sein, die Busadresse eines Teilnehmers bei der Businitialisierung frei zu vergeben. Danke für euer Interesse und Mitdenken. Grüsse, Andreas
Ich wuerde die erste Methode verwenden, wo der Master mit einem Broadcast nicht numerierte Slaves sucht. Je nach System kann man das unter einer Sekunde machen. Passende Baudrate vorausgesetzt. Die Slaves muessen ja auch nicht zyklisch abgefragt werden. Der Master bestimmt wann was gesendet wird.
@Georg: Gute Idee mit dem Abfragen aller möglichen Adressen! Besten Dank und Gruss.
Andreas I. schrieb: > Gute Idee mit dem Abfragen aller möglichen Adressen! Besten Dank und > Gruss. Nein. Ein neuer Teilnehmer hat unzugeordnet immer die höchste Adresse, diese Adresse ist in dem System aber keine Adresse sondern nur ein Einstiegspunkt. Sie wird, wie alle existierenden, immer mit abgefragt. Wenn jemand da ist, bekommt er sofort eine "richtige" Adresse zugewiesen, und der Einstiegspunkt ist wieder frei für den nächsten Neuankömmling.... Gruß JJ
JensJens schrieb: > Wenn jemand da ist, bekommt er sofort eine "richtige" Adresse > zugewiesen, und der Einstiegspunkt ist wieder frei Ok, auch eine Möglichkeit zu vermeiden, dass sich ein neuer Slave "reindrängeln" muss, denn das würde zu einer ganzen Reihe von Komplikationen führen. Z.B. dass der Slave den laufenden Busverkehr mit roher Gewalt anhält. Vorteil: es geht schneller als mit meiner Methode, ist bloss ein wenig mehr zu programmieren (freie Adresse zuweisen). Georg
@ JensJens(Gast) Aeh, nein. Ein Slave darf nicht einfach eine Adresse, und wenn es die Hoechste ist, annehmen. Was geschieht beim Einschalten des Systems ? Dann nehmen alle Slaves diese Adresse ein, und koennen keine Antwort geben, weil sie sich in die Quere kommen. Der Standardansatz ist per Protokol eine Zuweisung per Random Aufloesung vorzunehmen. Jeder Slave muss sich natuerlich zu seinen Eigenschaften und Standort ausweisen koennen.
:
Bearbeitet durch User
Andreas I. schrieb: > Gute Idee mit dem Abfragen aller möglichen Adressen! Ich sage jetzt mal ganz bös, hast du auch schon mal etwas neben deiner Anforderungsliste hineingedacht?? Als Bastelprojekt scheiden natürlich die "Profilösungen" aus und da etwas Nachbaun ist keine Option. Stefan ⛄ F. schrieb: > Kenne ich aus eigener Erfahrung. Anfänger wollen immer alles unnötig > universell. Bis sie mit dem dazu nötigen Aufwand und den Problemen > konfrontiert werden. Zumindest der Hinweis auf dieses Wiznet scheint ja etwas für dich zu haben. Ansonsten heißt es Ärmel aufkrempeln und selbst schreiben! Gruß Rainer
Georg schrieb: > Slaves automatisch eine Adresse zuzuweisen ist das geringste Problem, > die Schwierigkeiten fangen eine Ebene höher an: ist das neu adressierte > Gerät nun ein Temperatursensor, eine Anzeige oder ein Garagentor? Eine automatische Adresse ist das größte Problem. Zusammen mit der Zuordnung von Sensor und Einbauposition, das ist äquivalent. Was es ist, fragt man dann den Sensor selber. Beispiel: Du hast 5 identische Sensoren S1..S5, die je eine Temperatur messen. Alle melden sich gleichzeitig am Bus. Woher weiß ein Sensor, welche Temperatur er genau misst. Diese Zuordnung (z.B. S1 = Warmwasser, S2 = Vorlauf, S3 = Rücklauf) ist äquivalent zur Adressierung. Wenn Du das Problem löst, ist das andere auch gelöst.
Aeh, nein. Ist es nicht. Der Sensor soll einen String speichern, zB "Warmwasser Vorlauf", der wird im EEPROM gespeichert, und den fragt man nachher ab.
Purzel H. schrieb: > Aeh, nein. Ist es nicht. Der Sensor soll einen String speichern, zB > "Warmwasser Vorlauf", der wird im EEPROM gespeichert, und den fragt man > nachher ab. Dann kann man auch gleich die Adresse mit im EEPROM speichern... Du begreifst ganz offensichtlich das Problem nicht.
c-hater schrieb: > Dann kann man auch gleich die Adresse mit im EEPROM speichern... Bzw einen Hash Code des Strings zur Adresse machen.
Andreas I. schrieb: > mehrere uC Boards von ST Andreas I. schrieb: > Als eindeutige Identifikation > (UID) möchte ich die Seriennummer des uC nehmen. Die hat aber 96 Bit, ein wenig sperrig für z.B. 24 Bit Nutzdaten, oder? Wenn man versucht, die 96 Bit zu komprimieren, ist es nicht mehr eindeutig. Die 1-Wire IDs mit 56 Bit sind auch kaum besser. Und vor allem löst das nicht das eigentliche Problem :) https://www.reichelt.de/dreh-codierschalter-16-polig-omr-a6r-161rf-p290112.html?&nbc=1
Stefan ⛄ F. schrieb: > Bzw einen Hash Code des Strings zur Adresse machen. Ja, kann man machen. Aber was bringt das? Die Zuordnung zwischen Adresse und Funktion muss der Master ohnehin beherrschen. Da ist es doch Schwachsinn, Master und Slave mit Hash-Funktionen zu belasten. Der Slave braucht doch garnicht wissen, was er eigentlich genau tut, also diesen String garnicht zu kennen. Alles was der wissen muß: die Adresse. Der Master hingegen muß natürlich beides wissen. Aber die Strings und die Zuordnung zu den Adressen braucht NUR er zu wissen. Ob man diese Zuordnung nun per Hashfunktion erzeugt oder durch eine simple Enumeration der Strings: spielt keine Geige. Enumeration ist viel einfacher, also nimmt man das.
Purzel H. schrieb: > Aeh, nein. Ist es nicht. Der Sensor soll einen String speichern, zB > "Warmwasser Vorlauf", der wird im EEPROM gespeichert, und den fragt man > nachher ab. Jetzt wird mir auch klar wozu du die 500kbit für Sensordaten brauchst. Kannst du dir nicht noch einen größeren Roman ausdenken? Wenn du CAN benutzt mit extended IDs, dann hat du 29bit. Wenn du nur z.B. 24bit für eine fortlaufende "Seriennummer" deiner Sensoren verwendest, wird das wohl reichen bis zum Ende deiner Tage. Die wird dann einmalig in den Flash an eine sichere Stelle geschrieben und nie mehr verändert. Beim F4 gibts da auch den OTP Bereich, den kann man dafür auch benutzen. Irgendwas eindeutiges wirst du brauchen. Oder sollen sich alle Sensoren neu anmelden nachdem einmal der Strom weg war? Was fertiges wirst du da nicht finden, wer opfert schon gern seine Lebenszeit für so einen Schwachsinn. Wenn es nicht CAN wird, dann nagle einfach einen DS18S20 o.ä. mit auf die Sensorboards und schon hast du eine eindeutige ID, die als CAN Message Nr allerdings zu groß ist.
Nachtrag: Wenn du Sensoren baust die du für Vorlauf, Rücklauf, Warmwasser o.ö. benutzt ist es doch absoluter Schwachsinn die jedesmal um zu konfiguriren wenn man sie tauschen will. Da macht man wohl für jeden Sensor noch einen Konfigurationsdialog über uart o.ä. nur um diesen dämlichen String da rein zu kriegen? Diese Zuordnung ist Sache des Masters, ausser man will gerade das eckige Rad erfinden.
Nein, sie können nicht einfach das Thermostat vom Bügelzimmer als Ersatz für das kaputte Thermostat im Wohnzimmer verwenden, weil sonst das Bügelzimmer erwärmt wird wenn es im Wohnzimmer zu kalt ist. Um die Namen zu ändern bestellen Sie unseren Kundenservice zu sich oder kaufen sie unser 500 Euro Teures Konfigurations-Terminal. Mich würde das sehr verärgern.
oszi schrieb: > Nachtrag: Wenn du Sensoren baust die du für Vorlauf, Rücklauf, > Warmwasser o.ö. benutzt ist es doch absoluter Schwachsinn die jedesmal > um zu konfiguriren wenn man sie tauschen will Will der TO das? Das Beispiel hat jemand anderes gebracht. Wenn eine lange Kennung auf dem RS485 Bus liegt, dann müssen alle ständig zuhören und ein Protokoll dekodieren um zu erkennen das sie angesprochen wurden. Mit der Multidrop Option können die anderen schwatzen wie sie wollen, die belasten die Zuhörer nicht. Erst wenn die passende Adresse gesendet wurde werden die hellhörig.
Hallo, Die Adressierung neuer Teilnehmer scheint ein heisses Thema zu sein. Möglicherweise gibt es dazu mehrere gute Lösungen. Ich wage einen Versuch mit RS-485 für Schicht 1. Im uC werde ich USARTS benutzen, diese können gleichzeitig senden und empfangen. Ein Sender kann somit immer mithören was auf dem Bus läuft. Wenn er nicht dasselbe empfängt was er sendet, ist eine Kollision aufgetreten. Damit hat jeder Teilnehmer die Möglichkeit, Kollisionen zu erkennen. Das ist für den Algorithmus der initialen Adressierung hilfreich. Wie ich das genau lösen werde, weiss ich noch nicht. Die maximale Nachrichtengrösse werde ich auf jeden Fall grösser wählen als bei 'standard' CAN, womit 96bit UID kein Problem darstellen werden. Wiederum danke für alle zusätzlichen Anregungen und Tipps. Herzlich, Andreas
Andreas I. schrieb: > Ich wage einen Versuch mit RS-485 für Schicht 1. Schlechte Wahl. Der Rest... Andreas I. schrieb: > Im uC werde ich USARTS > benutzen, diese können gleichzeitig senden und empfangen. Ein Sender > kann somit immer mithören was auf dem Bus läuft. Wenn er nicht dasselbe > empfängt was er sendet, ist eine Kollision aufgetreten. Damit hat jeder > Teilnehmer die Möglichkeit, Kollisionen zu erkennen. ...ist O.K. funktioniert aber mit dem RS485 nicht zuverlässig. Man kann prima die Transceiver für CAN in Verbindung mit USARTs verwenden. Dort funktioniert die Kollisionserkennung durch Verfälschungserkennung der Nachricht zuverlässig.
Andreas I. schrieb: > Das ist für den > Algorithmus der initialen Adressierung hilfreich. Wie ich das genau > lösen werde, weiss ich noch nicht. > Wenn ich mir vorstelle wie lange das dauert diese Initialisierungsgeschichte zu Implementieren würde ich nie auf die Idee kommen was andere als CAN zu nehmen. Da ist der ganze Quark schon abgefackelt. Das was du vorhast ist am Ende fast das gleiche. > Die maximale Nachrichtengrösse werde ich auf jeden Fall grösser wählen > als bei 'standard' CAN, womit 96bit UID kein Problem darstellen werden. Ich sehe die 8 Byte nicht als wirkliches Problem. Seit vielen Jahren kommt die Welt damit klar und macht sogar Firmewareupdates über CAN. Und dann jammerst du, dass das bei deinem Spielzeugprojekt nicht reicht. Wenn es mehr sein muss, wird es halt aufgeteilt in mehrere. Die CAN Id des Sensors (oben wurde mal von max. 16! gesprochen) kann ja die gleiche bleiben und das nächste Byte klassifiziert die Message. Oder nimm gleich CAN-FD dann geht es bis zu 64 Byte. Ich gehe jede Wette ein, dass dein neu erfundener Standard nicht besser wird als bestehende Lösungen. Nur halt mit dem Unterschied, dass ein etablierter Standard nicht nur von dir verstanden wird. Route_66 H. schrieb: > Man kann prima die Transceiver für CAN in Verbindung mit USARTs > verwenden. Ja, das ist wohl wahr, kann man machen. Vor vielleicht 25 Jahren habe ich mal ein Sensornetz aufgebaut mit ca. 20 Sensoren. Die haben einfach nur mit einem Open Collektor Ausgang und einem gemeinsamen Widerstand ihre kurzen Pakete gesendet wann sie wollten (mit genügend Random-Zeiten dazwischen). Alles in allem ca. 200m. Die Packete wurden doppelt mit CRCs gesichert und wenn mal eine Kollision auftrat, war das Paket eben weg. Bei Funk wird's ja in der Regel auch nicht anders gemacht. Der Aufwand ging gegen 0 und das ganze läuft heute noch.
Andreas I. schrieb: > Die maximale Nachrichtengrösse werde ich auf jeden Fall grösser wählen > als bei 'standard' CAN, womit 96bit UID kein Problem darstellen werden. Bei CAN gibts für größere Pakete ISO-TP. Ist millionenfach im Einsatz und funktioniert. https://www.embeddeers.com/knowledge-area/jro-can-isotp-einfach-erklaert/ fchk
Angehängte Dateien:
oszi schrieb: > Vor vielleicht 25 Jahren habe ich mal ein Sensornetz aufgebaut mit ca. > 20 Sensoren. Die haben einfach nur mit einem Open Collektor Ausgang und > einem gemeinsamen Widerstand ... Hat mich irgendwie and das mc-Netz erinnert, beschrieben in mc 4/1983 und 5/1983. Dieses wiederum basierte auf SP-Netz (Elektronik 8/1982). Als Hardware brauchte es einen UART und eine pipi-PHYs (Anlage). Klar, ist altes Geraffel. Aber ein paar gute Ideen gab es doch.
CAN ist schon gut als unterste Schicht. Aber Flusskontrolle fehlt noch. LG, Sebastian
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.