Hallo,
ich versuche gerade CAN Bus beim STM32 zum laufen zu bekommen.
Dazu bin ich nach dieser Anleitung vorgegangen:
https://www.youtube.com/watch?v=gu1Uz2K3zh4
Wie im Video tritt auch bei mir der Bug auf, dass Reset gedrückt werden
muss um die nächste Nachricht zu empfangen. Ab 40:18 wird ein Workaround
für den CAN Bus Bug erklärt, der jedoch bei mir nicht funktioniert:
1
void RxIntEnable(CAN_HandleTypeDef *CanHandle) {
2
3
if(CanHandle->State == HAL_CAN_STATE_BUSY_TX)
4
CanHandle->State = HAL_CAN_STATE_BUSY_TX_RX;
5
else {
6
7
CanHandle->State = HAL_CAN_STATE_BUSY_RX;
8
9
// Set CAN error code to none
10
CanHandle->ErrorCode = HAL_CAN_ERROR_NONE;
11
12
// Enable Error warning Interrupt
13
__HAL_CAN_ENABLE_IT(CanHandle, CAN_IT_EWG);
14
15
// Enable Error passive Interrupt
16
__HAL_CAN_ENABLE_IT(CanHandle, CAN_IT_EPV);
17
18
// Enable Bus-off Interrupt
19
__HAL_CAN_ENABLE_IT(CanHandle, CAN_IT_BOF);
20
21
// Enable Last error code Interrupt
22
__HAL_CAN_ENABLE_IT(CanHandle, CAN_IT_LEC);
23
24
// Enable Error Interrupt
25
__HAL_CAN_ENABLE_IT(CanHandle, CAN_IT_ERR);
26
}
27
28
// Enable FIFO 0 message pending Interrupt
29
__HAL_CAN_ENABLE_IT(CanHandle, CAN_IT_FMP0);
30
}
Als Fehler wird angezeigt:
1
Symbol 'HAL_CAN_STATE_BUSY_TX_RX' could not be resolved
und
1
Symbol 'HAL_CAN_STATE_BUSY_RX' could not be resolved
Die Abfrage ob TX beschäftigt ist funktioniert jedoch.
Im Internet konnte ich leider nichts hilfreiches finden.
STM32F072RBT6 und STM32F042F6P6 tritt bei beiden auf.
CubeMX 5.0.1 und Eclipse mit GCC
Danke, hab beides ausprobiert. Er zeigt zwar jetzt keinen Fehler mehr
geht aber trotzdem nicht.
Er springt nicht in die if Schleife.
Warum gibt es hier RX0 und RX1? Es gibt zwar 2 mögliche Pinbelegungen,
aber nur einen CAN Bus Controller.
Ja entschuldigung, dass ich mich vertippt habe.
Selbst wenn ich die if Bedingung änder, dass er immer reinspringt
funktioniert es nicht.
Gibt es noch einen anderen Workaround dafür?
Habs noch mal mit einem Schritt rückwärts probiert.
Im Loopback Modus funktioniert es genau so wie es sein soll (mit beiden
µC und jeweils mit dem Code oben). Aber sobald ich in den normalen Modus
wechsel muss ich Reset am Empfänger drücken für die nächste Nachricht.
Zwischendrin hatte ich den Fall, dass ich beim Slave Reset gedrückt habe
und dann lief es so wie es eigentlich soll.
Kann es sein, dass der Bus belegt ist oder so?
Frag die HAL_CAN_ErrorCallback Funktion.
Dazu musst du dann natürlich HAL_CAN_Transmit_IT verwenden.
Für den Empfang gibt es auch eine Funktion mit _IT und eine ohne die
wartet.
Wenn du die ST Beispiele meinst, die habe ich mir angesehen. Auf den Bug
gehen die überhaupt nicht ein.
Man findet halt leider zu CAN keine einzige Anleitung die mal wirklich
zu 100% funktioniert.
Heinz M. schrieb:> Man findet halt leider zu CAN keine einzige Anleitung die mal wirklich> zu 100% funktioniert.
Also eigentlich ist das auch nicht so schwierig. Erst auf Wikipedia den
Artikel zu CAN genau lesen, dann exakt nach Datenblatt auf die Register
zugreifen. Dabei die HAL gekonnt ignorieren. Dabei bin ich noch auf
keine Hardware Bugs gestoßen, und HAL Bugs erübrigen sich so auch.
@pegel: Danke bis hierhin
@Dr. Sommer: Bitte mal daran denken dass es anderen nicht so leicht
fällt. Nach deiner Vorgehensweise würde ich 10 Jahre brauchen. Wenn der
Bug noch behoben ist hat es ca. ein halbes Jahr gedauert. Für meine
bescheidenen Hobbyprojekte mehr als ausreichend.
Hab das Problem beseitigt. Obs gelöst ist, dazu kenne ich mich zu wenig
aus.
Ich habe µC1(Sender) dauerhaft ADC Werte senden lassen, weil man bei
schwankenden Werten schön sieht, dass es dauerhaft läuft. Ist eine Art
Standardtest von mir.
Wenn ich µC2(Empfänger) programmiert oder resetet habe, konnte der eine
gewisse Zeit nicht empfangen, wodurch die in der Zeit gesendeten aber
nicht empfangenen Pakete zu Problemen führten (so meine Vermutung). Da
der Empfänger auch das Display initialisieren muss braucht der natürlich
wesentlich länger, als der Sender der nur den ADC hat.
Meine Lösung sieht jetzt so aus, dass der Sender erst anfängt zu senden,
wenn man auf dem Empfänger eine Taste drückt und dies per CAN Bus dem
Sender mitteilt. Funktioniert bis jetzt ohne Probleme.
Überall da wo ich per CAN Bus dauerhaft viele Werte senden möchte, werde
ich beim Empfänger einbauen, dass dieser ab und zu ein Lebenszeichen
sendet. Fällt das aus, dann hören die Sender auf zu senden.
Vielen Dank an pegel. Ohne die Hilfe hätte ich es nicht geschafft.
Heinz M. schrieb:> Meine Lösung sieht jetzt so aus, dass der Sender erst anfängt zu senden,> wenn man auf dem Empfänger eine Taste drückt und dies per CAN Bus dem> Sender mitteilt
Das ist aber eigentlich unnötig. Die STM32 kommen definitiv damit klar
wenn beim Hochfahren ständig Nachrichten ankommen.
Wie ich vermutet hatte ist das Problem nicht beseitigt. Ich habe mal
versucht das Problem einzugrenzen und bin jetzt an dem Punkt, dass das
Problem nur auftritt, wenn versucht wird auf einen Bus zu schreiben wo
kein Empfänger dran ist.
Wenn die Kommunikation beendet wird, das Kabel abgezogen und wieder ran
gesteckt wird und danach die nächste Nachricht gesendet wird ist alles
ok.
Wird eine Nachricht geschickt, wenn das Kabel abgezogen ist, hängt sich
der Canbus des Senders auf. Alles andere funktioniert weiter.
Seltsam ist, dass sich die Kommunikation Slave -> Master jedes mal
aufhängt und die Kommunikation Master -> Slave nur manchmal (ich vermute
je nach dem wer gerade gesendet oder empfangen hat). Beide sind als
Master im Canbus. Master ist bei mir der mit dem Display und Slave der
mit dem ADC zum Werte erfassen.
Reset beim Slave löst nur das Problem Master -> Slave. Reset beim Master
geht alles wieder.
Ich denke es hat mit dem Problem hier zu tun, aber leider keine Antwort:
https://community.st.com/s/question/0D50X00009XkgdwSAB/can-bus-error-management
Hier wird ebenfalls mein Problem gestriffen.
https://electronics.stackexchange.com/questions/280882/problem-with-can-on-stm32
Wie baue ich einen error handler ein, welcher das senden unterbindet und
evtl. sogar den Fifo löscht, wenn kein ACK kommt?
Wenn ich nach dem zweiten Link gehe, müssten immer 2 Nodes an einem
Busabschnitt hängen und dürften nie getrennt werden, sonst gibt es
Fehler. Aber das kann ich doch gar nicht ausschließen.
No-Automatic Retransmission habe ich bereits auf enable gesetzt. Keine
Veränderung.
Heinz M. schrieb:>> Wird eine Nachricht geschickt, wenn das Kabel abgezogen ist, hängt sich> der Canbus des Senders auf. Alles andere funktioniert weiter.>
Das ist ja auch kein Wunder, denn da gibt es auf dem CAN-Layer
Protokolle, die nur funktionieren, wenn mindestens 2 Teilnehmer am Bus
sind. Ansonsten laufen dir die Errorcounter hoch und dann gibt es einen
BusOff, weil das ACK fehlt. Das hängt sich nicht auf, das ist per Design
so gewollt.
Heinz M. schrieb:> Seltsam ist, dass sich die Kommunikation Slave -> Master jedes mal> aufhängt und die Kommunikation Master -> Slave nur manchmal
CAN kennt keine Master und Slaves.
Heinz M. schrieb:> No-Automatic Retransmission habe ich bereits auf enable gesetzt. Keine> Veränderung.
Mal das CAN_MCR_ABOM Bit gesetzt? Den CAN-Controller zu resetten ist wie
gesagt nicht nötig. Im Gegensatz zu gewissen anderen
Peripherie-Modulen ist der CAN-Controller der STM32 ziemlich robust. Der
hat sich bei mir noch nie aufgehängt und verkraftet trennen/verbinden,
verzögertes Starten der Teilnehmer, 100% Buslast, Störungen problemlos.
Eventuelle Probleme sind hier in der Firmware zu suchen. Als Erstes
würde ich unbedingt alle Warteschleifen entfernen und vollständig
asynchron/ereignisbasiert programmieren. Im Empfangs-Interrupt
eingehende Nachrichten verarbeiten und Mailbox leeren. Im
Sende-Interrupt Nachrichten senden, falls welche vorliegen. Niemals
blockierend auf das Freiwerden von Mailboxen bzw. das Ankommen von
Nachrichten warten.
@Sven S.: Ja das habe ich jetzt auch gelesen.
Hätte eigentlich gedacht, dass wenn ich den Automatic Bus-off
ausschalte, er so lang sendet, bis der Empfänger ein ACK sendet.
Deswegen versuch ich gerade die Can Error Codes auszulesen.
1
CanFehler=CAN_GetLastErrorCode(CAN_TypeDef*CAN);
Bringt den Fehler "expected expression before 'CAN_TypeDef'"
1
CanFehler=CAN_GetLastErrorCode(CAN);
Bringt den Fehler "undefined reference to `CAN_GetLastErrorCode'"
Leider finde ich (bis auf eine russische Seite keine Beispiele zur
Verwendung der Funktion).
Heinz M. schrieb:> n.> CanFehler=CAN_GetLastErrorCode(CAN_TypeDef*CAN);
CAN_TypeDef ist der Typ des Parameters. Du musst "CAN1" oder "CAN2"
übergeben. Genau wie bei CAN_Init & Co.
Heinz M. schrieb:> Bringt den Fehler "undefined reference to `CAN_GetLastErrorCode'"
Dann linkst du die HAL nicht richtig.
Heinz M. schrieb:> Leider finde ich (bis auf eine russische Seite keine Beispiele zur> Verwendung der Funktion).
Schreib doch einfach "CAN1->ESR" um das Statusregister abzufragen.
Dessen Bits sind genau im Reference Manual dokumentiert.
Also bei mir hat der CAN auch nicht funktioniert, als ich ihn
initialisiert und die Transmit oder die Receive Funktion genutzt habe.
Aber drauf geschissen. Ich habe dann die Transmit und die Receive
Funktion selbst geschrieben, indem ich die Handvoll bits selber gesetzt
bzw. geschoben habe.
Ist ja nicht allzu kompliziert das Ganze.
Markus schrieb:> Also bei mir hat der CAN auch nicht funktioniert, als ich ihn> initialisiert und die Transmit oder die Receive Funktion genutzt habe.>> Aber drauf geschissen. Ich habe dann die Transmit und die Receive> Funktion selbst geschrieben, indem ich die Handvoll bits selber gesetzt> bzw. geschoben habe.
Du bist nicht nur ein ganz toller Bursche, sondern hast zudem noch eine
gewählte Ausdrucksweise.
ESR habe ich ausgelsen bekommen, aber wieder mit sehr viel suchen.
Richtig heißt es CAN_ESR und für STM32F072RBT6 heißt der Befehl
"CanFehler=CAN->ESR;".
Angezeigt wird 51, also wie schon vermutet der Acknowledge Fehler.
Ist das ABOM Bit setzen so richtig?
1
CAN->MCR |= 1<<6;
Bei Registern will ich nicht rumprobieren, wer weiß was man da alles
zerstören kann. Reference Manual Seite 833.
Theoretisch müsste es doch reichen das bei der Initialisierung zu setzen
oder?
Heinz M. schrieb:> ESR habe ich ausgelsen bekommen, aber wieder mit sehr viel suchen.
Wo hast du denn gesucht?! Das steht im Reference Manual auf S. 841. Da
der Controller nur einen CAN-Controller hat ist es halt "CAN" statt
"CAN1".
Heinz M. schrieb:> Angezeigt wird 51, also wie schon vermutet der Acknowledge Fehler.
Dezimal? Dann ist er aber noch nicht im Bus-Off-Mode.
Heinz M. schrieb:> Ist das ABOM Bit setzen so richtig?CAN->MCR |= 1<<6;
Wie wärs mit CAN->MCR |= CAN_MCR_ABOM? Gleich viel besser lesbar.
Heinz M. schrieb:> Bei Registern will ich nicht rumprobieren
Dann such dir ein anderes Hobby. Ohne Register gibt das nichts.
Heinz M. schrieb:> wer weiß was man da alles> zerstören kann.
Nichts.
Heinz M. schrieb:> Theoretisch müsste es doch reichen das bei der Initialisierung zu setzen> oder?
Am Besten während man noch im Initialisierungs-Modus ist.
Nach Reset: 0
Nach Rausziehen: 51
Nach wieder reinstecken: 51
Knopf drücken zum Nachricht senden: 11
Nachricht kommt auch beim Slave an, aber keine Werte beim Master.
Also nichts anders als Vorher.
Ja Werte sind dezimal.
Belgacom schrieb:> Markus schrieb:>> Also bei mir hat der CAN auch nicht funktioniert, als ich ihn> initialisiert und die Transmit oder die Receive Funktion genutzt habe.> Aber drauf geschissen. Ich habe dann die Transmit und die Receive> Funktion selbst geschrieben, indem ich die Handvoll bits selber gesetzt> bzw. geschoben habe.>> Du bist nicht nur ein ganz toller Bursche, sondern hast zudem noch eine> gewählte Ausdrucksweise.Belgacom schrieb:> Markus schrieb:>> Also bei mir hat der CAN auch nicht funktioniert, als ich ihn> initialisiert und die Transmit oder die Receive Funktion genutzt habe.> Aber drauf geschissen. Ich habe dann die Transmit und die Receive> Funktion selbst geschrieben, indem ich die Handvoll bits selber gesetzt> bzw. geschoben habe.>> Du bist nicht nur ein ganz toller Bursche, sondern hast zudem noch eine> gewählte Ausdrucksweise.
Solange ich keinen damit beleidige ist es ja ok. Ausserdem ist das ein
Zeichen dafür, dass der CAN von ST wirklich so beschissen ist. Der
Fehler besteht ja schon seit 2016 oder noch länger.
Das ist eine Tatsache und hat nichts mit den Leuten hier zu tun.
Markus schrieb:> Ausserdem ist das ein> Zeichen dafür, dass der CAN von ST wirklich so beschissen ist. Der> Fehler besteht ja schon seit 2016 oder noch länger.
Es ist nur ein Fehler in der Bibliothek. Die ist bekanntermaßen mies.
Der CAN-Controller selbst ist ok und vermutlich überhaupt nicht von ST
selbst sondern von Bosch oder so zugekauft.
Junge Junge
CAN verstehen bevor man von BUGs redet ...
Wenn ein CAN-Teilnehmer eine Nachricht sendet (es gibt wie schon erwähnt
kein Master oder Slave) und niemand diese Quittiert (ACK) macht der CAN
Controller je nach einstellung lustiges Zeug auf dem BUS (alles nach
Standart ...) zB. Präambel schicken und Retransmisions usw ...
Also schön Brav die HAL Callbacks verwenden (auch die des Errors !!!!)
und den CAN Controller richtig (so wie gewollt) einstellen.
Dann funzt das wunderbar...
und nochmals: die haben keinen BUG !!!
Markus schrieb:> Ausserdem ist das ein> Zeichen dafür, dass der CAN von ST wirklich so beschissen ist. Der> Fehler besteht ja schon seit 2016 oder noch länger.
Nein du bzw. dein Programm ist kaputt. Meinetwegen zusätzlich auch die
HAL. Alles was es zu wissen gibt steht im Ref. Manual und im Errata.
Wenn man sich daran hält geht es auch. Ich erdreiste mich sogar zu der
Aussage: Wenn du nicht in der Lage bist die paar Register nach Manual zu
verstehen und richtig zu bedienen solltest du entweder dazulernen oder
dir ein anderes Hobby suchen.
Man kann sich die HAL Problematik auch mal anders vorstellen. Was ich
von ST kaufe ist der Controller und weiter nichts. Dazu gibt es eine
Dokumentation in der alles steht was ich wissen muss. Wenn ST
zusätzliche Libs oder Democode oder was auch immer auf seinen Web-Seiten
anbietet, ist das eine freiwillige Leistung die du nicht gekauft hast.
Damit gibt es auch kein Recht auf Vollständigkeit oder Fehlerfreiheit.
Noch weniger auf Langzeitverfügbarkeit und Updates oder Kompatibilität
mit zukünftigen Controllern. Deshalb ist an dieser Stelle wirklich
weniger mehr.
Alternativ kannst du deine Fragen in den Arduino-Foren stellen, da
triffst du Gleichgesinnte.
temp schrieb:> Markus schrieb:> Ausserdem ist das ein> Zeichen dafür, dass der CAN von ST wirklich so> oder Fehlerfreiheit. Noch weniger auf Langzeitverfügbarkeit und Updates> oder Kompatibilität mit zukünftigen Controllern. Deshalb ist an dieser> Stelle wirklich weniger mehr.>> Alternativ kannst du deine Fragen in den Arduino-Foren stellen, da> triffst du Gleichgesinnte.
Da fühlt sich aber einer angegriffen. Arbeitest du bei ST :)
Sven S. schrieb:> Heinz M. schrieb:>>>>> Wird eine Nachricht geschickt, wenn das Kabel abgezogen ist, hängt sich>> der Canbus des Senders auf. Alles andere funktioniert weiter.>>>> Das ist ja auch kein Wunder, denn da gibt es auf dem CAN-Layer> Protokolle, die nur funktionieren, wenn mindestens 2 Teilnehmer am Bus> sind. Ansonsten laufen dir die Errorcounter hoch und dann gibt es einen> BusOff, weil das ACK fehlt. Das hängt sich nicht auf, das ist per Design> so gewollt.
Sofern der Knoten seine eigene Nachricht korrekt zurücklesen kann
(Abschlusswiderstand) geht der Knoten nur in Error Passive
(Sonderregel).
Dies erkennt man an der dauerhaften Sendewiederholung.
Diese hört auf, sobald ein zweiter Knoten die Nachricht bestätigt.
Oben die Erwähnungd es Abschlusswiderstandes, da sich das
Hochlaufverhalten von dem des Trennen des Netzes unterscheidet.
Markus schrieb:> Da fühlt sich aber einer angegriffen. Arbeitest du bei ST :)
Ne, wie kommst du auf diesen Zusammenhang? Ich hasse sie eigentlich ehr
dafür, dass ST jedem Anfänger die HAL förmlich aufzwingen. Und wenn sie
das so richtig verinnerlicht haben fällt der Umstieg auf einen anderen
Controller doppelt schwer, was natürlich beabsichtigt ist.
Ich jammere eigentlich nur über das ständige Jammern bei Problemen mit
der HAL. Was zum großen Teil aber daran liegt, dass viele das Ref-Manual
nicht mal ansatzweise lesen sondern nur die Beispiele kopieren. Und dann
kommen Threads wie dieser dabei raus.
temp schrieb:> Markus schrieb:> Da fühlt sich aber einer angegriffen. Arbeitest du bei ST :)>> Was zum großen Teil aber daran liegt, dass viele das Ref-Manual> nicht mal ansatzweise lesen sondern nur die Beispiele kopieren. Und dann> kommen Threads wie dieser dabei raus.
Das stimmt, da gebe ich dir Recht, aber vielmals tut es aber auch nicht,
auch wenn man das Reference Manual liest. Zum Beispiel ist mir
aufgefallen, dass ich anfangs trotz des Lesens vieles übersehen oder
vergessen habe die richtigen Bits zu setzen. Zb bei den Timern das MOE
Bit welches bei advanced irgendwie gesetzt werden muss, bei anderen
wiederum nicht etc. Da blickt man anfangs nicht so durch und es fehlt
einem einfach an Erfahrung herauszufinden, woran es liegen könnte, auch
wenn es dem einen oder anderen damit vertrauten leicht erscheint. Nach
einer gewissen Zeit wird man aber doch vertrauter mit der Materie und
kann etwa einschätzen, was es sein könnte und kann viele Probleme schon
messen oder debuggen.
Aber einfach wie der TO zu sagen, dass er an den Registern nicht herum
hanzieren möchte, finde ich dann doch ein wenig bequem. Darum geht es ja
letztendlich auch.
Ich habe den CAN zB anders zum Laufen gebracht, als wie weiter oben
erwähnt mittels der Callback Funktionen. Nur weil ich es anders gemacht
habe und nicht die Callback Funktionen genutzt habe, heisst es ja nicht,
dass ich das Manual nicht verstanden habe. Deshalb möchte ich dir nur zu
Herzen legen, dass du beim nächsten Mal vielleicht deine Vorschläge ein
wenig diskreter anzubringen versucht. Ich bin offen für Vorschläge aber
deinen letzten Satz habe ich nicht so als freundlich empfunden.
Nur so als Hinweis: Markus ist nicht der Threadsteller.
Weiterhin, damit hier keiner aneinander vorbei redet:
Master Slave bezieht sich wie bereits erwähnt auf meine Anwendung und
nicht auf den Bus. Der Master hat ein Display und Bedienelemente. Die
Slaves Sensoren oder Aktoren.
Mir ist völlig bewusst, dass mein Programm verbuggt ist. Habe auch nie
das Gegenteil behauptet.
Cube MX, HAL oder was auch immer hat Bugs, das ist bekannt. Trotzdem
muss ich sagen, dass UART, I2C und einige andere Sachen super schnell
funktioniert haben. Canbus und USB leider nicht. Deswegen programmiere
ich aber nicht sämtliche ST Bibliotheken neu.
Zurück zum Problem.
Wenn beide so konfiguriert sind, dass der Master zyklisch ein Signal
sendet, woraufhin der Slave einen Wert zurücksendet, dann kann ich nach
der Leitungsunterbrechung zwar an den Slave eine Nachricht schicken,
aber beim Master kommt nichts an. Master hat Fehlercode 51, Slave 0.
Wenn der Slave dauerhaft sendet und der Master ab und zu, dann geht der
Fehlercode auf beiden hoch. Beide versuchen zu senden, was man der
niedrigeren Bildwiederholrate der Displays merkt. Sobald ich das Kabel
wieder einstecke geht der Fehlercode bei beiden auf 0, die
Bildwiederholrate ist wieder flott, aber trotzdem werden keine
Nachrichten gesendet oder empfangen (kann ich ohne Oszi nicht sagen).
Oder brauche ich einen dritten CAN Knoten, der die beiden wieder auf die
Beine bringt?
Wenn ja, würde das bedeuten es müssen mindestens 2 Knoten an einem
Teilabschnitt des Busses ohne Fehler aktiv bleiben, damit der Bus wieder
"hochgefahren" werden kann. Oder verstehe ich da was falsch?
Nachtrag zu Markus:
Ich habe kein Problem mit Registern. Nur wenn ST mir ein Tool liefert um
diese schier endlosen Register zu umgehen, dann möchte ich das auch
nutzen. Einfache Peripherie (z.B. I2C Temperatursensoren) habe ich kein
Problem mit den Registern.
Was ich sehr ungern mache und beim STM32 nicht machen werde, ist auf
Verdacht in Registern rumzuspielen. Entweder man weiß genau was man da
tut oder man weiß es nicht. Und ich weiß es nicht. Wie du schon
geschrieben hast ist das Reference Manual ein harter Brocken, wenn man
kaum Erfahrung mit der Materie hat.
Heinz M. schrieb:> Oder brauche ich einen dritten CAN Knoten, der die beiden wieder auf die> Beine bringt?
Nein.
Heinz M. schrieb:> kann ich ohne Oszi nicht sagen).
Dann besorg dir eins von den billigen LA's.
Heinz M. schrieb:> dass UART, I2C und einige andere Sachen super schnell funktioniert> haben.
I2C ist deutlich lästiger als CAN bei den STM32. Bei CAN macht die
Hardware alles automatisch, bei I2C muss man jedes Schrittchen steuern.
Und im Gegensatz zur CAN-Hardware ist die I2C-Hardware verbuggt und
hängt sich ständig auf.
Heinz M. schrieb:> diese schier endlosen Register zu umgehen
Bei CAN sind das nur eine Hand voll. Die Filter-und Mailbox Register
sind einfach nur viele mit der gleichen Funktion, die muss man nur 1x
verstehen.
Heinz M. schrieb:> Wie du schon geschrieben hast ist das Reference Manual ein harter> Brocken, wenn man kaum Erfahrung mit der Materie hat.
Versuch's doch einfach mal... die Zeit die du hier mit Schreiben
verbracht hast hätte locker gereicht für das CAN-Kapitel.
Bei Gelegenheit werde ich mich mal ransetzen. 2 aktuelle Projekte die
ich damit vorhabe, ist es nicht so schlimm, wenn man Reset drücken muss.
Bevor ich ein Projekt mache, wo es drauf ankommt, werde ich es mit den
Registern versuchen. Edit: Und bis dahin mehr Erfahrung mit den STM32
Registern habe.
Danke bis hierhin.
