und das mit 1MBit -- aber zum Ausgleich mit nur 3 uC auf einer Europakarte. Im Prinzip wird der "Bus" aus einem AND-Gatter wohl funktionieren. Aber das wäre ja zu einfach, also sollen die drei uC den internen 16MHz-RC-Oszillator benutzen und den per Software trimmen. Das führt zu Frequenzsprüngen von 0.2 bis 0.4%, aber das sollte kein Problem sein, wenn sonst alles optimal passt. Wie könnte unter den Umständen das Bit-Timing aussehen? Der Bus ist ja ziemlich kurz, ein 74AUP ist mit 2 bis 7ns ein wenig schneller als ein echter Treiber plus Kabel, aber irgendwie hilft das nichts? Nach Bosch geht eigentlich nur: Sync=1, Prop=1 Phase1=3, Phase2=3; aber dann ist der Sample Point bei 62.5%, was angeblich viel zu früh ist? Hätte ich gleich sagen sollen, dass ich keinen Plan hab? Es kommt noch schlimmer. Von den drei uC sammeln zwei Messwerte und schicken die an den dritten. Die beiden Sammler sind absolut gleich, nur die Nummern der Messstellen unterscheiden sich. Jetzt wäre es naheliegend, diese Nummern in die CAN-ID einzubauen. Dann kann es passieren, dass der eine Sammler mangels Priorität total ausgebremst wird. Mit festen CAN-ID geht es auch nicht. Wie schafft man es, dass beide halbwegs abwechselnd ihre Messages los werden? Muss ich wirklich nach jeder Message eine Pause einbauen? Das wäre doch wider die Natur... Mit je einer eigenen UART-Verbindung würde alles wie von selbst funktionieren und es wäre auch noch echtes Vollduplex. Gibt es vielleicht noch andere serielle, also außer I2C und SPI? Könnte man I2S missbrauchen? Außerdem scheint CAN bei STM ziemlich unbeliebt zu sein, das Kapitel im Reference Manual finde ich ziemlich dürftig. Kennt jemand etwas ausführlicheres?
Angehängte Dateien:
-
AND-Bus.png
3,3 KB
Bauform B. schrieb: > Jetzt wäre es naheliegend, diese Nummern > in die CAN-ID einzubauen. Dann kann es passieren, dass der eine Sammler > mangels Priorität total ausgebremst wird. Aber nur wenn der andere den Bus dicht macht. Welche Buslast erwartest denn, bzw. mit welchen Zykluszeiten werden die Botschaften gesendet? > Muss ich wirklich nach jeder Message eine Pause einbauen? Das wäre doch > wider die Natur... Nein, das ist eigentlich der Normalfall. Botschaften werden entweder regelmäßig, z.B. alle 20 ms gesendet, oder wenn bestimmte Ereignisse eintreten, aber niemals einfach "volle Lote, was die Leitung hergibt", denn dann käme ja grundsätzlich immer nur die höchste ID und absolut nix anderes mehr durch. > Mit je einer eigenen UART-Verbindung würde alles wie von selbst > funktionieren und es wäre auch noch echtes Vollduplex. Warum hast du dann stattdessen CAN verwendet? Deine Anwendung scheint dafür eher unorthodox zu sein. > Gibt es vielleicht noch andere serielle, also außer I2C und SPI? Warum "außer"? Das wären für mich die offensichtlichsten Kandidaten für sowas. > Könnte man I2S missbrauchen? Warum muss man denn unbedingt etwas missbrauchen?
Eine UART-Verbindung würde nach dem gleichen Schema funktionieren.
Rolf M. schrieb: > Botschaften werden entweder regelmäßig, z.B. alle 20 ms gesendet, > oder wenn bestimmte Ereignisse eintreten, aber niemals einfach > "volle Lote, was die Leitung hergibt", denn dann käme ja > grundsätzlich immer nur die höchste ID und absolut nix > anderes mehr durch. Genau so ist es geplant, die Daten sind auch sowieso in CAN-kompatible Päckchen verpackt. Ich bin aber noch unschlüssig, wie viel ich periodisch senden muss. Das allermeiste sollte nur bei Bedarf Daten produzieren. Aber es gibt "globale" Ereignisse zu denen jeder etwas zu sagen hat, z.B. wenn das zweite Netzteil nachträglich eingeschaltet wird. Wenn ich dann wegen den miesen 16MHz von 1MBit auf 250kBit runter gehen muss, würde es eng werden. Wobei mir auch nicht klar ist, wo da bei CAN die Grenze ist. Böse Zungen meinen, ab 50% wird's kritisch, aber meinen die 50% Brutto oder Netto? Dann ist mir aufgefallen, dass die Reihenfolge der Messages durcheinander kommt, während sie bei Punkt-zu-Punkt Verbindungen zwangsläufig stimmt. Ich müsste erforschen, wie sehr das stören könnte oder Zeitstempel einbauen... > Warum hast du dann stattdessen CAN verwendet? Das ist bis jetzt nur eine Idee, weil mal wieder die Pins knapp werden. Mit diesem mini-Bus würde die Schaltung deutlich aufgeräumter. Und nachdem CAN angeblich ganz toll ist, hab' ich das gestern Morgen auch noch geglaubt. >> Gibt es vielleicht noch andere serielle, also außer I2C und SPI? > > Warum "außer"? Das wären für mich die offensichtlichsten Kandidaten > für sowas. I2C und SPI brauchen einen externen Takt, bei SPI müsste ich den auch noch dauernd laufen lassen. SPI brauche ich für serielle Speicher. SPI braucht viele Pins. I2C-Hardware im STM32 ist buggy. Zu CAN warte ich heimlich auf eine Ansage wie "CAN mit STM32? Vergiss es!". Allerdings brauche ich ja nur 11-Bit-ID, keine Filter, kein Open Drain und keinen Schickschnack.
:
Bearbeitet durch User
Bauform B. schrieb: > und das mit 1MBit -- aber zum Ausgleich mit nur 3 uC auf einer > Europakarte. Im Prinzip wird der "Bus" aus einem AND-Gatter wohl > funktionieren. Aber das wäre ja zu einfach, also sollen die drei uC den > internen 16MHz-RC-Oszillator benutzen und den per Software trimmen. Das > führt zu Frequenzsprüngen von 0.2 bis 0.4%, aber das sollte kein Problem > sein, wenn sonst alles optimal passt. Es geht noch schlanker, mit drei Dioden und einem 1 kOhm-Widerstand. Als praxiserprobte Anwendung fällt mir der MidiBox-SID-Synthesizer ein. Da laufen die Controller mit Quarz, aber bei ausreichendem Gleichlauf sollte das auch mit anderen Taktquellen funktionieren.
Bauform B. schrieb: > "CAN mit STM32? Vergiss es!". Da du offensichtlich nicht verstanden hast was an CAN Vorteile bietet und wie es funktioniert tu ich dir den Gefallen. In deinem Fall, CAN mit irgendeinem Controller, vergiss es!!!!! Wenn deine Pins knapp sind nimm halt einen größeren Controller.... Wenn du das nicht willst leb mit den Einschränkungen. Bauform B. schrieb: > I2C-Hardware im STM32 ist buggy. I2C ist generell Buggy egal wo, weil der Standard seine schwächen hat deshalb gibt es ja auch I3C Bauform B. schrieb: > Dann ist mir aufgefallen, dass die Reihenfolge der Messages > durcheinander kommt, während sie bei Punkt-zu-Punkt Verbindungen > zwangsläufig stimmt. TTCAN ist ein Begriff? PS: die Buslast sollte nicht mehr als 75% sein, was bei 1Mbit wohl schwer wird wenn du nur ein paar Messwerte sendest. Alternativ gäbe es noch FDCAN, das fällt dann bei dir aber wohl ganz raus.
Bauform B. schrieb: > Hätte ich gleich sagen sollen, dass ich keinen Plan hab? Es kommt noch > schlimmer. Von den drei uC sammeln zwei Messwerte und schicken die an > den dritten. Die beiden Sammler sind absolut gleich, nur die Nummern der > Messstellen unterscheiden sich. Jetzt wäre es naheliegend, diese Nummern > in die CAN-ID einzubauen. Dann kann es passieren, dass der eine Sammler > mangels Priorität total ausgebremst wird. Mit festen CAN-ID geht es auch > nicht. Wie schafft man es, dass beide halbwegs abwechselnd ihre Messages > los werden? Nimm die unteren 3 Bits. Der eine hat LSB=0, der andere LSB=1. Der erste toggelt immer Bit 1 nach jeder Nachrichtm der andere Toggelt immer Bit 2 nach jeder gesendeten Nachricht. Damit sollten beide ihre Nachrichten loswerden, weil sich die Prioritäten nach jeder Nachricht ändern. Probiere es mal aus. fchk
Soul E. schrieb: > Es geht noch schlanker, mit drei Dioden und einem 1 kOhm-Widerstand. Wenn das Timing sowieso schon kritisch ist, riskiere ich das nicht. Außerdem sind das 4 Bauteile, davon 2 verschiedene und Dioden kommen sonst nirgends vor -- gegenüber einem Bauteil, das ich auch noch anderweitig gebrauchen kann. Also, schlank ist relativ. > Als praxiserprobte Anwendung fällt mir der MidiBox-SID-Synthesizer ein. > Da laufen die Controller mit Quarz, aber bei ausreichendem Gleichlauf > sollte das auch mit anderen Taktquellen funktionieren. Wenn ich 12.3456MHz oder so zentral erzeugen würde, würde es ja von selbst funktionieren ;)
Guest schrieb: > Bauform B. schrieb: >> "CAN mit STM32? Vergiss es!". > > Da du offensichtlich nicht verstanden hast was an CAN Vorteile bietet > und wie es funktioniert tu ich dir den Gefallen. > > In deinem Fall, CAN mit irgendeinem Controller, vergiss es!!!!! > PS: die Buslast sollte nicht mehr als 75% sein > TTCAN ist ein Begriff? Jetzt verrate doch nicht alle Geheimnisse, CAN ist doch nicht für's Bodenpersonal gedacht ;) Zu TTCAN sagen die Errata von mehreren STM32:
1 | 2.19.1 bxCAN |
2 | time-triggered communication mode not supported |
3 | Description |
4 | The time-triggered communication mode described in the reference |
5 | manual is not supported. As a result, timestamp values are not |
6 | available. The TTCM bit of the CAN_MCR register must be kept cleared |
7 | (time-triggered communication mode disabled). |
8 | Workaround None. |
Frank K. schrieb: > Bauform B. schrieb: >> Wie schafft man es, dass beide halbwegs abwechselnd ihre Messages >> los werden? > > Nimm die unteren 3 Bits. Der eine hat LSB=0, der andere LSB=1. Der erste > toggelt immer Bit 1 nach jeder Nachrichtm der andere Toggelt immer Bit 2 > nach jeder gesendeten Nachricht. Damit sollten beide ihre Nachrichten > loswerden, weil sich die Prioritäten nach jeder Nachricht ändern. Das könnte funktionieren, danke.
Bauform B. schrieb: > Zu TTCAN sagen die Errata von mehreren STM32: Der bxCAN kann das nicht der FD bei den neuen uC aber schon. Außerdem lässt sich das relativ leicht selbst in Software Implementieren.
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.