STM32 Projekte Bootloader CAN-Logger
-
J-1850 CRC Berechnung
Beispiel CRC-8 Prüfsumme nach J-1850
-
STM32 Projekte
Diverse STM32 Projekte:
- CAN-Analyzer ( STM32-CAN Hardware mit FT und HS CAN-Treiber )
- Tripple CAN-FD
- CubeMX Demoprojekt für meine STM32-CAN Hardware
- ....
-
STM32-3x-CAN-FD
Tripple CAN-FD USB Dongle
Realsierung mit dem STM32G474-RB Prozessor.
.... in kürze ist hier mehr zu finden Sobald die Prototypen überprüft wurden.Vorschau:
Bestückungsplan:
Prototyp V1.0
Dieser Prototyp funktioniert auch ohne bestückten Quarz, d.h. der interne DFU-USB Bootloader und CAN-FD1 hatten auf Anhieb funktioniert. Ein kompletter Funktionstest, bei dem alle Hardware Module getestet werden, steht noch aus. Ebenso ist ja der Einsatz eines 24 MHz Quarz geplant. Für diesen Kurztest wurde der interne HSI verwendet und mittels PLL der System-Takt auf 160 MHz eingestellt. Die 160 MHz wurden gewählt, da dieser günstiger ist, um die üblichen CAN-Bus Baudraten einzustellen.
Hinweis: Der interne USB-Bootloader aktiviert den Ausgang PA6 (blaue LED). Dies hängt wohl damit zusammen, dass der interne SPI-Bootloader den PA6 als Ausgang konfiguriert. Mich wundert es etwas, dass diese Konfiguration nicht rückgängig gemacht wird, wenn der USB-Bootoader erkannt wird. Ist aber praktisch, da man jetzt automatisch eine Statusanzeige für den internen USB-Bootloader hat :-). Und hier noch das Foto von meinem ersten Prototyp:
Abb.1.4 - Prototyp V1.0
Funktionstests
Die Tests wurden mit einer Testsoftware, die mit dem STM32CubeMX für den MDK-Keil erstellt wurde, durchgeführt.
Als 2. CAN-Device kam ein Raspberry Pi mit meinem Pi-CAN FD - Duo - HAT-Modul zum Einsatz bei dem der CAN0 mit:sudo ip link set can0 up type can bitrate 1000000 dbitrate 2000000 restart-ms 1000 berr-reporting on fd on
konfiguriert wurde.
Hier sind meine Testergebnisse:
- SWD Debug-Schnittstelle funktioniert.
- USART2 Debug Schnittstelle inkl. (Retargeting) funktioniert
- USB-DFU Bootloader funktioniert
- Die Logik PB8-Boot0 und Jumper J1 muss nochmal überdacht, bzw. überarbeitet werden. Macht diese hier überhaupt Sinn wegen dem CAN-FD1 Treiber?
- CAN-FD1, CAN-FD2 und CAF-FD3 Rx und Tx mit den Baudraten:
- nominal 1 MBit/s
- Datenrate 2 MBit/s
getestet
- Ansteuerung der LEDs in Ordnung (Vorwiderstände wurden angepasst, s. V1.1)
Hinweis: PA6 (blaue LED) wird vom interne DFU-USB Bootloader ebenfalls angesteuert. - to dos:
- weitere CAN-FD Baudraten testen
- last, but not least, die Firmware schreiben :-)
Für den ersten Test bei der alle 3 FDCANs verwendet werden, habe ich über die Debug-USART Schnittstelle die empfangenen Botschaften ausgegeben. Dabei wird von FDCAN2 die 0x111 Botschaft gesendet, die von FDCAN3 empfangen wird. Und der FDCAN1 empfängt die Botschaften die mein Raspberry Pi sendet:##################################### # Startup: # HW: STM32-CANFD # SW: SW 1.0.0 (23:23:28 - Feb 19 2021) ####################### # STM32G4: # STM32 Device-ID: 0469 Revision: 2001 # Flash-Size: 128 kBytes # Package = 00 (LQFP64) # SN: 4500264752501820393855 ####################### [FDCAN3] 111 (BRS) 16 50 34 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN1] 7AF (___) 64 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 60 1A 24 39 91 2B 11 77 [FDCAN1] C (___) 5 BA E0 7C 56 10 [FDCAN1] 6FC (___) 8 AA 11 79 04 85 B7 7F 2B [FDCAN1] 6AD (BRS) 2 A3 9B [FDCAN3] 111 (BRS) 16 38 38 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN1] 47B (___) 0 [FDCAN1] x12F2D3A3 (___) 20 61 C8 9F 53 40 C3 33 77 61 C8 9F 53 40 C3 33 77 61 C8 9F 53 [FDCAN1] x1192058C (___) 0 [FDCAN1] x0057A18E (___) 8 06 FD BF 1F 48 82 D4 36 [FDCAN1] 4E2 (___) 4 B8 7B F1 4A [FDCAN3] 111 (BRS) 16 20 3C 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN1] 26 (___) 1 86 [FDCAN1] 4DF (___) 4 40 52 B6 7A [FDCAN1] x19FFBCB3 (___) 8 D1 7F 14 0E 15 85 9F 4D [FDCAN1] 3DE (___) 1 2A [FDCAN1] x084209AB (___) 8 85 1A 5A 45 B1 06 02 68 [FDCAN3] 111 (BRS) 16 08 40 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN1] 28E (___) 3 E5 05 05 [FDCAN1] x06F173B9 (BRS) 24 88 87 01 21 40 01 BD 27 88 87 01 21 40 01 BD 27 88 87 01 21 40 01 BD 27 [FDCAN1] x16C7A3C8 (___) 8 79 82 29 7A 09 F6 7D 31 [FDCAN1] x118C8C6E (___) 8 6F AC E0 2D 3F 0C A1 3F [FDCAN1] x010E04AA (___) 8 72 C2 4E 38 D4 1F 3D 53 [FDCAN3] 111 (BRS) 16 F0 43 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN1] x02366CFF (BRS) 0 [FDCAN3] 111 (BRS) 16 D8 47 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN3] 111 (BRS) 16 C0 4B 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61 [FDCAN3] 111 (BRS) 16 A8 4F 03 00 45 46 47 48 6E 65 77 4D 65 73 73 61
Das ganze schaut mal sehr gut aus, somit müsste das mit dem CAN fürs Senden / Empfangen in Ordnung sein.
Zumal keine Botschaften verloren gehen.Und hier noch ein kurzes Video von einem weiteren Test:
(https://youtu.be/Ao3T23NJt5g )
Hier noch das CubeMX Konfigurationsfile für den Protoypen. Das Keil-Projekt wurde noch nicht auf Github veröffentlicht (to do).
- FD_Test.ioc - Variante ohne USB und externen 24 MHz QuarzDie geplante Konfiguration für alle 3 CAN-FDs, USB und Quarz sollte dann so aussehen:
Software
Wie oben schon erwähnt, wurde die Testsoftware mithilfe von STM32CubeMX konfiguriert und als Keil-Projekt exportiert (s. o. FD_Test.ioc )
CAN-FD Baudraten
Um günstige Werte für die CAN-Baudraten Berechnungen zu erhalten wurde der Systemtakt des Prozessors auf 160 MHz festgelegt (168 MHz wären auch gut :-) ).
Die Konfiguration im CubeMX erfolgt dann hier:
Obiges stellt die Baudrate auf 1 MBit/s (nominal) und 8 MBit/s Datenbaudrate ein. Der jeweilige Sampling-Point liegt bei 75%
Mithilfe meines Excels-Sheets ( fdcanBitrateCalculatorSTM32G4 - Wiki )habe ich mal folgende Einstellungen für die diversen Baudraten ermittelt und mit einem PCAN-FD Interface getestet. Diese Werte gelten für einen Systemtakt von 160 MHz
Ebenso wurden die Werte für einen Sampling-Point von 75% festgelegt:-
250 kBit/s - Normale Baudrate (Es kommt zu Errors in Pcan-View)
-
Init.NominalPrescaler = 8;
-
Init.NominalSyncJumpWidth = 1;
-
Init.NominalTimeSeg1 = 59;
-
Init.NominalTimeSeg2 = 20;
-
-
500 kBit/s - Normale Baudrate
-
Init.NominalPrescaler = 4;
-
Init.NominalSyncJumpWidth = 1;
-
Init.NominalTimeSeg1 = 59;
-
Init.NominalTimeSeg2 = 20;
-
-
1 MBit - Normale Baudrate
-
Init.NominalPrescaler = 4;
-
Init.NominalSyncJumpWidth = 1;
-
Init.NominalTimeSeg1 = 29;
-
Init.NominalTimeSeg2 = 10;
-
-
2 MBit/s - Datenrate
-
Init.DataPrescaler = 4;
-
Init.DataSyncJumpWidth = 1;
-
Init.DataTimeSeg1 = 14;
-
Init.DataTimeSeg2 = 5;
-
-
4 MBit/s
-
Init.DataPrescaler = 1;
-
Init.DataSyncJumpWidth = 1;
-
Init.DataTimeSeg1 = 29;
-
Init.DataTimeSeg2 = 10;
-
-
8 MBit/s - (vereinzelte Stuffbit Fehler in PCAN-View)
-
Init.DataPrescaler = 1;
-
Init.DataSyncJumpWidth = 1;
-
Init.DataTimeSeg1 = 14;
-
Init.DataTimeSeg2 = 5;
-
Da es jeweils nur ein kurzer Test war, sind diese Werte erstmal unter Vorbehalt zu sehen. Weitere Tests werden noch folgen.
-
STM32-CAN
STM32-CAN-Busadapter
Einleitung
Da ich mich in letzter Zeit vermehrt mit den Cortex-Arm-Prozessoren von ST befasse, musste nun wieder mein Lieblingsprojekt – ein CAN-Bus Interface - herhalten.
Als Ziel habe ich mir ein CAN-Bus Interface vorgenommen, welches sich vor kommerzielle Interfaces nicht verstecken muss, und mit der CANHacker Software von der Seite: http://www.canhack.net laufen soll.
Und das ist es nun, mein aktuelles Projekt: STM32-CANAnforderungen:
- High-Speed und Low-Speed CAN-Bussystem sollen unterstützt werden. Konfiguration mittels DIP-Schalter oder Jumper auf dem Interface.
- Abschlusswiderstand über DIP-Schalter zu schaltbar
- CAN-Anschlussstecker erfolgt über ein 9-poliger SUB-D-Stecker (CIA Belegung)
- USB-Schnittstelle incl. USB-Bootloader
- Lawicel-Protokoll damit es mit der CANHacker Software läuft.
- Status LED für die Anzeige von Tx und Rx auf dem CAN-Bus
- STM32F105-RB Prozessor
- STM-JTAG - Schnittstelle (ST-Link und U-Link kompatible mit eigenen Programmierstecker)
- Spannungsversorgung über den USB-Anschlussstecker
Realisierung:
Für die CAN-Schnittstelle werden folgende CAN-Treiber verwendet:
- LOW-Speed CAN-Treiber: TJA1055
Unterstützte Baudraten: 10 kBaud - 125 kBaud
Eindrahtbetrieb ist im Fehlerfall möglich - HIGH-Speed CAN-Treiber: PC82C250
Unterstützte Baudraten: 10 kBaud- 1 MBaud
Abb. 1.1 Schaltplan STM32-CAN Version V1.1
CAN-Anschlussstecker Belegung (SUB-D 9polig männlich):
Pin-Nr. Beschreibung 1 nicht verwendet 2 CAN-LOW -Signal 3 GND (optional) 4 nicht verwendet 5 nicht verwendet 6 GND 7 CAN-HIGH Signal 8 nicht verwendet 9 nicht verwendet Die Anbindung an den PC erfolgt mittels einer USB-Mini Buchse über die Hardware auch mit Spannung versorgt wird (+5 V).
Für die Umsetzung des Virtuellen Com Ports (VCP) werden die ST-Firmwaretreibern (OTG-Device-Host Firmware für STM32F105/F107) verwendet. Dies Paket beinhalte auch die Standard Peripherie Library in einer etwas aktuellern Version als die V3.5.0.modifiziertes CANHacker Protokoll (basierend auf dem Lawicel-Protokoll)
- Verarbeitung von 11-Bit Standard/29-Bit Extend-ID CAN-Botschaften (t/T)
-
feste Baudrate wird mit dem Sx-Befehl gesetzt (Befehl wird nur verarbeitet wenn der CAN-Kanal geschlossen ist:
- S0: 10 kBit
- S1: 20 kBit
- S2: 50 kBit
- S3: 100 kBit
- S4: 125 kBit
- S5: 250 kBit
- S6: 500 kBit
- S7: 33 kBit ==> CANHACKER verwendet hier: 800 kBit (Im CANHacker 800 kBit auswählen)
- S8: 95 kBit ==> CANHACKER verwendet hier: 1 MBit ( Im CANHacker 1 MBit auswähle)
- S9: 83 kBit ==> wird von CANHacker nicht unterstützt
- User Def.: Zur Zeit wird nur eine Benutzerdefinierte Einstellung unterstützt:
- 3333: 33,33 kBit/s
- 8333: 83,33 kBit/s -
Listen-Only Modus wird unterstützt.
- Timestamps werden unterstützt (über CANHacker konfigurierbar). Die Timetamps werden bei jedem neuen Verbindungsaufbau zurückgesetzt und laufen von 0-99s. Die Auflösung beträgt 1ms
Gehäuse
Das Gehäuse stammt vom Dennis T. - Vielen Dank dafür!
Abb. 1.2 Gehäuse für das STM32-CAN Board3D Daten
Abb. 1.3 Gehäuse Entwurf für das STM32-CAN BoardEntwurfsdaten:
- Deckel: deckel.stl
- Boden: gehäuse.stl
obige Daten sind wohl zu klein (nur 7 mm) Hier sind die korrigierten Versionen (Danke Marco P.): - Deckel: AI3M_Deckel new.stl
- Boden: AI3M_gehaeuse new.stl
Projekt-Status:März 2013:
- Protoypen Software wie oben beschrieben
- Prototypen Leiterplatten sind beim PCB-Pool bestellt
August 2014:
- modifizierte Firmware um das Interface als Gateway zwischen dem Low-Speed und Hight-Speed CAN in BMW-Fahrzeugen zu benutzen. Dazu wird einfach ein 2.Sub-D9 auf die LP gelötet und der Low-Speed-CAN dann direkt am DIP-Switch abgegriffen. Ausserdem werden die Botschaften die vom CAN-Hacker gesendet werden, auf beiden CAN-Schnittstellen ausgegeben. Ansonsten werden alle Nachrichten von der einen Seite zur anderen geroutet.
Abb.1.4 STM32-CAN modifziert für BMW-CAN-Gateway High-Low-Speed
April 2015:
- STM32-Bootloader - Prototyp vom STM32 Online-Flasher auf die Supportseite gestellt (JavaApplet mit dem das Interface über USB geflasht werden kann)
November 2015:
- 2, Protoypen Version, neue Hardware V1.2:
- Bugfix VUSB, somit
- grüne LED hinzugefügt für den RX-Stauts ( blau ist dann der Tx-Status)
- Low-Speed CAN-Bus jetzt fest auf den SUB-D9 Stecker gelegt (somit entfällt obiger Umbau für ein Gateway) - Hier gehts zur Beschreibung der neuen Version: STM32-CAN neue Hardware Version V1.2
Dezember 2015:
- STM32-CAN Flasher Tool überarbeitet und Online gestellt (s. Support)
- CanAnalayer V24 - Online gestellt
- Button zum Abspeichern der Trace-Liste hinzugefügt. Speichert die Traceliste im CANHacker Trace-Format ab.
April 2016:
- CanAnalyzer V26 - Online gestellt
- In der Trace-Liste kann jetzt im Kommentar Bereich eine ASCII-Darstellung der Datenbytes aktiviert werden.
(Der Dank für die Anregung geht an: surfjenser )
- Beim Abspeichern der RX-Liste / Trace Liste nun eine Warnung ausgeben, wenn die Datei schon existiert.
- Aktuell verwendete Baudrate wird nun in den RX-Liste und Trace-Liste mit abgespeichert.
- kleinere Bugfixes
- neuer Start-Trace Button - CanAnalayzer V27 in Vorbereitung (in Kürze im Support Bereich verfügbar)
- aktuelle Settings beim Verlassen merken und beim Erneuten Start verwenden (Ini-File)
März 2019:
- 2 weitere modifizierte Firmwares um das Interface mit dem CAN-Hacker als Gateway zwischen dem Low-Speed und Hight-Speed CAN zu nutzen erstellt (s. Supportbereich). Diesmal für Mercedes Benz Low-Speed (83,3kBit/s und 125 kBit/s). Mit dem CAN-Hacker wird die Baudrate für die High-Speedseite eingestellt und die Low-Speed seite ist entsprechend der verwendete Baudratre fest eingestellt.
Abb.1.5 STM32-CAN modifziert für MERCEDES CAN-Gateway High-Low-Speed (Lowspeed:83,3kBit/s oder 125kBit/s
Januar 2020:
- Gehäuseentwurf von Dennis T. hinzugefügt.
Support
Die Support-Seite steht nur den angemeldeten Benutzern zur Verfügung. Dort finden sich die Downloads der aktuellen Firmware und eine Installations-Anleitung für das Interface.
Link zur STM32-CAN - Download PageCAN-Analyzer
Zur Zeit ist ein eigener CAN-Logger in Arbeit. Das besondere wird die RX-Liste sein, bei der dann die aktuellsten Datenbytes grafisch hervorgehoben werden, und ältere Daten werden dann langsam unsichtbar. Dies vereinfacht dann ungemein das lokalisieren von bestimmten Datenbits wenn man im Auto die CAN-Botschaften analysiert.
Besondern Dank geht an Robert G. für die zur Verfügungstellung des Lazarus-Grundgerüst von dem Projekt, somit konnte ich mich voll auf die grafische Hervorhebung der aktuellen Daten in der RX-Liste konzentrieren.
Hier mal ein Vorschaubild von der RX-Liste:
Abb.1.4 Vorschau von der RX-Liste mit grafischer Hervorhebung von aktuellen Datenbytes
Funktionsumfang:
- Es werden alle Interfaces unterstützt, die das Lawicel-Protokoll verwenden (und die gleiche Hardware ID gesendet wird,
siehe Support-Page).
(unter Beachtung, dass ich ein leicht modifiziertes Protokoll für die Baudraten verwendet habe s.o. )
- RX-Liste
- RX-Trace
- Export der Listen/Traces
- Empfangsfilter (todo)
- eigene Botschaften senden (todo)
Es wird aber noch einige Zeit dauern, bis alles umgesetzt ist.
Die aktuellen Versionen stehen auf der STM32-Supportseite (s.o.) zum Download bereit.Video: https://www.youtube.com/embed/uIO9P0yFNek
Vorab schon mal die Eagle-3D Bilder von der Leiterplatte:
Abb. 1.5 EAGLE-3D Ansicht von STM-CAN - Inteface Version 1.0 - Prototype
Abb.1.6 - Bestückseite STM-32-CAN Interface Version 1.0 - PrototypeAbb.1.7 Darstellung ca. original Größe Fertige Leiterplatte:
Beim Layout hat sich ein kleiner Fehler eingeschlichen, der in der neuen Leiterplattenvariante behoben wird, bzw. in den Protoypenleiterplatten mit etwas Fädeldraht behoben wurde :-)
Abb.1.8 CAN-STM32 - Protoypenversion - V1.0 (manueller Umbau auf V1.1)
Aktuell habe ich wieder ein paar Prototoypen in obiger Ausführung vorrätig, die Ihr für inkl. Versand nach:
- Deutschland: 25,- EUR inkl. Versand (Brief)
- Europa: 30,- EUR inkl. Versand (DHL-Päckchen)
erwerben könnt. Wer kein PayPal verwenden will, kann mich auch über das Kontaktformular kontaktieren.
Der Lieferumfang entspricht in etwa obiger Abbildung Abb.1.8Hinweise:
- Unversicherter Postversand
- Versand nur innerhalb der EU - Außerhalb der EU nur auf Anfrage
- Es handelt sich hierbei um einen Privatverkauf!
- Die gesetzliche Gewährleistung wird hiermit ausgeschlossen. Der Käufer akzeptiert dies mit Klick auf den "Jetzt kaufen" Button
- Das Interface wird vor dem Versand nochmal auf Funktion geprüft.
todos für die Zukunft:
- Protokoll für die Benutzerdefinierten Baudrate erweitern
- eigenenr CAN-Analyzer Software , quasi ein CAN-HACKER II :-)
- Hardware Filter setzen (Mxxxxxxxx Akzeptanz-Code für STM32 setzen)
- Hardeware Mask-Filter setzen (mxxxxxxxx Akzeptanz-Mask für STM32 setzen)
- Manuelle Baudraten Auswahl (sxxyyzz) verallgemeinern , zur Zeit werden nur die Baudraten:
- 3333 = 33,33 kBaud
- 8333 = 83,33 kBaud
unterstüzt. - Remote Frames senden (rxxxl/Rxxxxxxxxl)
- Listen Only Modus ( L[CR] )
- Get Serialnumber auf CAN-Bus Interface ( N[CR])
- Read Statusflags, dazu müsste aber erst mal ein komplettes Fehlerhandling implementiert werden ( F[CR])
- virtuellen COM-Port durch ein HID-Device ersetzen, so das keine speziellen Treiber benötigt werden
- Schnittstelle schreiben damit das Interface mit dem BUSMASTER läuft:
- die prinzipielle Einbindung in den Busmaster klappt schon mal
- jetzt muss noch eine STM32-CAN-Treiber DLL erstellt werden. Da ich kein Windows-Programmierer bin, kann das etwas dauern, bzw. ich könnte hier Unterstützung gebrauchen.
Links:
TJA1055 - Datenblatt
PCA82C250 - DatenblattSTM32-Resourcen:
UM1021 - User manual "USB On The Go host und device library für STM32F105/107"
STSW-STM32046 - Version 2.1.0 : stm32_f105-07_f2_f4_usb-host-device_lib.zip
STSW-STM32054 - Version 3.5.0: STM32F10x standard peripheral libraryEntwicklungsumgebung: Keil Compiler - MDK-Lite Version V4.70a
www.canhack.net: - CANHacker V2.00.02 Download (direkter Link auf die Zip-Datei: CANHackerV2.00.02.zip)
BUSMASTER (BUSMASTER is an Open Source Software tool to simulate, analyze and test data bus systems such as CAN)
Produktionschritte vom PCB-Pool:Die Protoypen LP wurden beim PCB-Pool gefertigt. Hier sind dann die einzelne Arbeitsschritte von der Leiterplattenfertigung dargestellt:
- Auftragsvorschau
- Leiterplatte bohren
- Leiterplatte belichten
- geätzte Leiterplatte
....
-
STM32-CAN - Hardware V1.2
STM32-CAN – Hardware V1.2
Abb. 1.1 STM32-CAN V1.2 HardwareHardware Modifikationen (L10009.02):
- Bugfix V-Bus Signal
- LED 3 (grün) hinzugefügt, dient jetzt als Rx-Status LED
- Low-Speed CAN-Bus jetzt fest auf SUB-D9. (Pin 4 - CAN-LOW, Pin 9 - CAN-High)
Somit kann das Interface mit einer speziellen Firmware als Gateway zwischen dem Low-Speed und High-Speed CAN-Bus eingesetzt werden.
Abb. 1.2 Schaltplan STM32-CAN Version V1.2
SUB-D9 Steckerbelegung (männlich):
Pin-Nr. Beschreibung 1 nicht verwendet 2 CAN-LOW -Signal
Auswahl LOW/HIGH Speed CAN Bus erfolgt mittels DIP-Schalter3 GND (optional) 4 CAN2 - LOW
vom CAN LOW-Speed Bus Treiber5 nicht verwendet 6 GND 7 CAN-HIGH Signal
Auswahl LOW/HIGH Speed CAN Bus erfolgt mittels DIP-Schalter8 nicht verwendet 9 CAN2 - High
vom CAN Low Speed Bus TreiberSoftware:
Die neue Hardware wird ab den Softwareversionen V2.0.x unterstützt. Wobei grundsätzlich auch die alte Version verwendet werden kann, allerdings wird dann die grüne LED nicht unterstützt.
Software V2.0.5 / V3.0.5:
- Senden und Empfangen von Remote Frames (RTR) hinzugefügt.
(Die CANHacker Software macht aber kleine Anzeigefehler bei DLC > 0, getestet auch mit slcand)
Software V2.0.3 / V3.0.3:
- Benutzerdefinierte Baudrate für 47,619 kBaud (Saab-Fahrzeuge) hinzugefügt.
( Benutzerdefinierte Baudrate = 4762 )
Software V2.0.2 / V3.0.2:
- Benutzerdefinierte Baudrate von 95,234 kBaud hinzugefügt.
(Benutzerdefinierte Baudrate = 9500)) - Versionsnummer ab V3.x.x (ab V3.0.2) ist die CAN-Hacker kompatible Variante die die Baudraten von:
- 800 kBit
- 1 Mit
unterstützt.
Software V2.0.1:
- Lawicel Protokoll um den Befehl F[CR] - Read Error Status erweitert
- CAN-Error Status abfragen (Vorerst wird nur das 'Bus Error (BEI)' Bit unterstützt! )
- Anzeige von CAN-Buss Error mittels synchronem Blinke aller LEDs.
Ebenso wird beim Buserror die Read Error Status Meldung ohne Anforderung gesendet (maximal 1 mal pro Sekunde)
Software V2.0.0:
- Rx-Status, LED 3 (grün) toggeln wenn CAN-Botschaften empfangen werden
- Watchdog abgeschaltet
- CAN-Error Handling verbessert (ABOM auf enabled gesetzt)
Die neune Software Versionen sind auf der STM32-CAN - Download Page zu finden! (nur registrierte Benutzer)STM32CubeMX - Testprojekt für STM32-CAN
In Kürze werde ich hier eine kleine Anleitung für STM32CubeMX veröffentlichen, die beschreibt wie man meine Hardware mit dem CubeMX programmieren kann. Zur Kurzbeschreibung gehts hier:
STM32-CAN CubeMX - Projekt
Das CubeMX-Projekt ist hier: Github: STM32-CAN - CubeMX Testprojekt veröffentlicht.Status (V0.3):
- LED ansteuern
- Lawcel Protokoll teilweise implementiert, so das der CAN-Hacker als CAN-Logger verwendet werden kann
- CAN TX-Message Testbotschaft senden, beim Empfang (Lawicel) zum Senden einer CAN-Botschaft
- Rx-Message empfangen (blaue LED wird getoggelt) und die Daten über Lawicel an den PC senden (CAN-Hacker zeigt
die Botschaft im Monitor oer Trace-Fenster an)
- Normal Mode oder Listen Only Mode werden unterstützt
- Auswahl der Baudrate vom CAN-Hacker übernehmen
Status (V0.1):
- LED ansteuern
- CAN1 initialisiere 500 kBaud
- TX-Message senden
- Rx-Message empfangen (blaue LED wird getoggelt)Wichtiger Hinweis für die Leute, die mein Protoypen-Board von mir erhalten haben:
Bitte nicht flashen, da sonst mein Bootloader überschrieben wird, und somit kein Firmware update mehr möglich ist.Important not for the people who got my protoype interface from me:
Do not flash the interface, becaus my integrated bootloader will be erased, and so no further firmware upodates are possible.
Zur Zeit sind alle Prototypen V1.2 verkauft. Eventuell, wenn sich noch ein paar Interessenten finden, werde ich wieder welche fertigen lassen. Da ich aus Versehen die alte Version erneut gefertigt hatte, wird es die neue Version vorerst nicht geben. Allerdings muss zu erst der Restbestand von V1.1 aufgebraucht sein.
für:
- Deutschand: 25,-EUR inkl. Versand (Brief)
-- Europa: 30,- EUR inkl. Versand (DHL Päckchen)
erwerben könnt. Wer kein PayPal verwenden will, kann mich auch über das Kontaktformular kontaktieren.Der Lieferumfang entspricht obiger Abbildung Abb.1.1
Hinweise:
- Unversicherter Postversand
- Versand nur innerhalb der EU - Außerhalb der EU nur auf Anfrage
- Es handelt sich hierbei um einen Privatverkauf!
- Die gesetzliche Gewährleistung wird hiermit ausgeschlossen. Der Käufer akzeptiert dies mit Klick auf den "Jetzt kaufen" Button
- Das Interface wird vor dem Versand nochmal auf Funktion geprüft.Achtung: Prototypen von der 1. Version können weiterhin bezogen werden. Außer das in der ersten Version eine LED weniger bestückt ist und ein Bug-Fix von Hand korrigiert wurde haben beide Versionen den gleichen Funktionsumfang und funktionieren gleich gut.
Hier gehts zur Vorgänger Version:
"1.Prototypen Version V1.1" PayPal Link: 1.Protoypen Version V1.1 jetzt kaufen