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
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.
