Hallo, ich bin dabei, eine kompakte Platine von ca. 70x70mm zu entwerfen, auf der sich mehrere MCUs (bis zu vier STM32F1xx) befinden. Jede von ihnen soll Zugriff auf einen gemeinsamen CAN-Bus haben, welcher die Verbindung zur Außenwelt herstellt. Nun gibt es zwar interessante Quad-CAN-Transceiver, aber offenbar wurden diese für einen anderen Anwendungszweck entworfen (1 bis 4 UARTs -> 4 CAN-Busse). Auf CAN-Bus-Seite hingegen gibt es Minimallängen zwischen den einzelnen Nodes, welche auf meiner kleinen Platine garantiert nicht eingehalten werden können. Wilde "Freileitungen" und mehrfache Klemmen sind ebenfalls keine Option. Eine alternative Idee wäre eine art lokaler CAN-Bus (evtl. auch ohne Transceiver) auf der Platine und ein Repeater nach draußen. Hat hier jemand Erfahrungen mit ähnlichen Anwendungsfällen? Grüße, Hans
Mir würde spontan einfallen nur einen Stm an den Bus zu hängen und die anderen per SPI mit den daten zu versorgen. Alternativ wirklich 4 Nodes aufbauen und Leitungsnachbildungen dazwischen hängen.
Nimm doch statt 4x STM32F1 einfach 1x STM32F4. Wozu braucht man mehrere Mikrocontroller direkt nebeneinander, wenn es doch bei der Controller-Leistung noch viel Luft nach oben gibt?
Dr. Sommer schrieb: > Nimm doch statt 4x STM32F1 einfach 1x STM32F4. Kann schon Sinn machen, das zu verteilen. Nur mal so ne Idee: Alle CAN-TX auf ein AND-Gatter, das treibt dann die Tx-Leitung des Transceivers. Rx des Transceivers auf alle Rx der Controller. Müsste eigentlich funktionieren.
Ein Umstieg auf eine (große) MCU ist aufgrund von Ressourcenmangel (in erster Linie Timer), aufgrund von harten Realtime-Anforderungen und aus der daraus entstehenden Softwarekomplexität nicht möglich bzw. nicht wirtschaftlich umsetzbar. Ein Relaying ist ebenfalls nicht wirklich wünschenswert, da es vermutlich zu (marginalen) Timing-Unterschieden zwischen CAN-Node und SPI-Nodes führen würde. Hans
Die Gatter-Idee ist im Grunde schon interessant und ich hatte sowas auch schon im Sinn - ich bin nur noch nicht sicher ob es nicht Fälle offen lässt, in denen sich das System doch anders verhält, als mit vier einzelnen Transceivern (z.B. bei Buskollisionen). Hans
Hm, ich sehe in keinem Fall einen logischen Unterschied. Der einzige Unterschied wäre die zus. Gatterlaufzeit, die kann man aber vernachlässigen.
mit Can Synchronisieren geht aus Erfahrung nur so bis 500µs da wir es schon recht kompliziert. Mit SPI kann man auch 50 mal genauer. Viele Prozessoren bieten spezielle Verbindungen zu ihresgleichen. Mir fällt auch kein Problem ein zu dem die vorgeschlagene Lösung passt. Es erscheint eher so das man sich bei der Notlösung zur Notlösung, Balkon an Balkon im Wald verrannt hat. Da sollte man zurück zu Anforderungen und Systemdesign . Die Anzahl der µC geht als Potenz in den Aufwand und Komplexität ein. Ich habe schon Systeme mit 10 µC in Serie gebracht. War sehr lehrreich.
Hans M. schrieb: > Ein Umstieg auf eine (große) MCU ist aufgrund von Ressourcenmangel (in > erster Linie Timer), aufgrund von harten Realtime-Anforderungen und aus > der daraus entstehenden Softwarekomplexität nicht möglich bzw. nicht > wirtschaftlich umsetzbar. Das würde mich interessieren. Wenn du harte Realtime-Anforderungen hast, dann wirst du vermutlich auf irgendein OS setzen? Klärst du uns darüber auf? FreeRTOS? Oder ein OSEK? Alle die ich kenne brauchen für das OS 1 Timer, aus dem kann man dann das meiste ableiten. Die anderen Timer nutzt man dann für Encoder bzw. PWMs oder so. Meine Meinung: Du hast Anforderungen, bei denen dir als einzige Lösung mehrere µC einfallen. Wahrscheinlich gehts auch anders, aber da du uns keine weiteren Details sagen willst, kann man dir bei deinen geplanten Systemfehlern nicht weiterhelfen. Zum Topic: Kann man nicht so leicht beantworten. Sollen dann alle µC verschiedene Nachrichten (IDs = Prioritäten) verschicken? Wie sind deine Nachrichten aufgebaut(d.h. wie viele verschiedene IDs soll denn das System bedienen?) Lässt sich die Kommunikation evtl. auf z.B. zwei Controller reduzieren? Wie ein anderer Vorschlag schon war, kann man evtl. per SPI alle auf der Platine verbinden und dann mit einem Controller nach außen gehen (der übliche Weg)? Ich hab grad nicht im Kopf ob deine Controller DMAs haben, dann sollte sowas doch relativ schick gehen.
Die µC erfüllen völlig eigenständige Aufgaben (BL-Motorsteuerung), müssen nicht synchron laufen und kommunizieren nicht untereinander. Alle werden jedoch aus der gleichen Quelle angesteuert (der externe CAN-Bus) und senden Statusdaten dorthin. In jedem µC ist das (interne) Timing eher knapp. Bei >200k rpm Felddrehzahl führen 2µs Delay dazu, die FETs den magische Rauch ablassen (oder auch durch die Werkstatt fliegen). Auf jeder MCU eine identische Software zu haben und nur eine debuggen zu müssen, würde die Entwicklung ungemein vereinfachen. Ein bischen Hardwarekosten sind da vernachlässigbar, Platinenfläche sollte ebenfalls ausreichen.
Hans M. schrieb: > Auf jeder MCU eine identische Software zu haben und nur eine debuggen zu > müssen, würde die Entwicklung ungemein vereinfachen. Ein bischen > Hardwarekosten sind da vernachlässigbar, Platinenfläche sollte ebenfalls > ausreichen. Ok, also unterm Strich nur eine vervierfachung einer Funktion. Ich würde versuchen noch einen kleinen µC zur Kommunikation mit dem CAN-Bus zu spendieren. Dann hast du einen festen "Router" zum CAN-Bus und brauchst dir in der SW zur Ansteuerung deiner Motoren keine Gedanken über den CAN an sich machen. In dem Router baust du dir ne Tabelle auf (welche ID geht an welchen Motor, von welchem Motor kommen Statusnachrichten, mit welcher ID werden die auf den CAN Bus gelegt) und arbeitest so. Hat auch den Vorteil, dass du Kommunikationsprobleme nur an einem Controller lösen musst. Vor allem wenn alle 4 Motoren-µC gleichzeitig was senden wollen hast du IMHO Vorteile.
Hans M. schrieb: > Auf jeder MCU eine identische Software zu haben und nur eine debuggen zu > müssen, würde die Entwicklung ungemein vereinfachen. Dann hättest du kein Problem. Und gerade die angebliche Vereinfachung macht dir Probleme.
> Dann hättest du kein Problem. > Und gerade die angebliche Vereinfachung macht dir Probleme. Ja, im Prinzip ist das natürlich ein Tausch von "mehrkanalige, komplexe Software vs. simple einkanalige" gegen "überrede den CAN-Bus, ohne Mindestabstand zwischen den Nodes zu funktionieren". Bisherige Erfahrungen mit der Motoransteuerung bewegen mich dazu, den Problemtausch für einen ausgesprochen lohnenswertes Geschäft zu halten. BTW, auch die Idee mit der Leitungssimulation hat was, genau auch wie der Kommunikations-Controller. Bei letzterem dürfte das Problem wie so meistens wieder in den 0.5% der Funktionaltät liegen, die überhaupt nicht zur Kernaufgabe zählen (Firmwareupdates via CAN, Parametrierung, zukünftige Protokolländerungen).
Hans M. schrieb: > Bei letzterem dürfte das Problem wie so > meistens wieder in den 0.5% der Funktionaltät liegen, die überhaupt > nicht zur Kernaufgabe zählen (Firmwareupdates via CAN, Parametrierung, > zukünftige Protokolländerungen). Das dürftest du so oder so haben. Firmwareupdates wirst du auch bei deinen Motorcontroller brauchen. Und Protokolländerungen - kommt auf die Branche an, in der du tätig bist.
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.