- Details
- Geschrieben von: Super User
- Kategorie: STM32 Projekte
- Zugriffe: 18315
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 Quarz

Die 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.
- Details
- Geschrieben von: Super User
- Kategorie: STM32 Projekte
- Zugriffe: 8540
EA DOXL240-7 Display Ansteuerung mit STM32F103xx
Einleitung
Dies ist mein erstes Projekt mit einem Grafik-Display. Bis jetzt hatte ich immer nur LCD Text Displays verwendet.
EA DOGXL-240-7 - Grafik-Display
- 240x128 Dots - entspricht 16 Zeilen a 40 Zeichen bei kleinen Zeichen
- 3,3 V Single Supply
- 3 serielle Schnittstellen für die Ansteuerung einstellbar:
- 3-Wire SPI
- 4-Wire SPI <== wird hier von mir verwendet
- I2C - Kontroller UC1611S mit integrierten Grafik-Ram
- LED Hintergrund Beleuchtung (niemlas die Vorwiderstände für die LEDs vergessen)
Anforderungen
Das Display soll im "4 WIRE, 8-BIT SPI-MODE" (s. Datenblatt) betrieben werden. Somit ist nur ein Schreiben der Daten mit max 8 MHz möglich.
Realisierung
..... in Arbeit, in Kürze mehr...
Schaltplan
Abb.1.3 - Schaltplan - Seite 1 - Prozessor
Abb. 1.4 Schaltplan - Seite 2 - Displayansteuerung
Links
- Datenblatt - EA DOGXL240-7
- Datenblatt - LCD Controller ( UC1611S )
- Initialisierungsbeispiel für- EA DOGXL240-7 vom Hersteller
(C Code / R8C25 - Zip-File - DOGM240_UC1611S.zip)
Projekt Funkwaage - EA DOXL240-7 Display
In einem anderen Projekt habe ich diese Anzeige ebenfalls verwendet, allerdings wurde hier die Displayanzeige um 90° gedreht um eine vertikale Darstellung zu ermöglichen.
Dies hatte zur Folge, dass ich nicht auf die Standardfunktionen die man im "Netz" findet zurückgreifen konnte. Dafür wurde die Anzeige des "Balkens" vereinfacht. Hier mal ein paar Bilder von der Anzeige:
![]() |
![]() |
|
![]() |
![]() Test mit vertikaler Textdarstellung und einer Fontgröße 6x8 Pixel |
- Details
- Geschrieben von: Super User
- Kategorie: STM32 Projekte
- Zugriffe: 12517
ST-Link - Multiflashing Tool für STM32
Um mehrere STM32 Prozessoren gleichzeitig flashen zu können habe ich probeweise mal 5 ST-LINKS angeschlossen und ein kleines C#-Sharp Programm geschrieben welches jetzt die ST-LINKs verwendet um die Prozessoren gleichzeitig zu programmieren.
Abb.1.1 Anzeige der angeschlossene ST-Link Interfaces
Abb.1.2 Statusanzeige nach dem Flashen
Getestet habe ich das ganze jetzt mit bis zu 5-ST-Links und eine Erweiterung auf weitere ST-Links ist problemlos möglich.
Funktions Prinzip:
Als Basis und Inspiration für mein Tool diente mir folgender Beitrag:
aus dem Mikrocontroller Forum. Ich verwende das gleiche Prinzip und habe es für meine Bedürfnisse optimiert :-)
Multiflasher in Aktion :-)
Hier mal ein kurzes Beispiel Video von meinem Tool wie es bei mir auf der Arbeit eingesetzt wird.
Video: https://youtu.be/AhopRF9cBd4
Update - 10/2022
Für Testzwecke wurde die Software mal auf 10 ST-Links erweitert.
Wer es will kann es ja mal selbst ausprobieren:
Download: STM32-Multiflasher - Installation
Hinweise:
- Die Hex-Files müssen unter "c:\stm32-hexfiles" abgelegt werden
- Es werden folgende Prozessoren verwendet:
- STM32F103 - 64k => (CR-5000)
- STM32F103 - 128k => (CR-4000)
- STM32F105 - 128K => (STM32-CAN)
- Details
- Geschrieben von: Super User
- Kategorie: STM32 Projekte
- Zugriffe: 38963
STM32CubeMX Testprojekt für die STM32-CAN Hardware
Dies ist mein erster Versuch um mich mit dem CubeMx vertraut zu machen.
Hinweise, was man besser machen kann sind willkommen!
Das Projekt ist auf Github hinterlegt: Github: STM32-CAN - CubeMX Testprojekt
Ziel ist es erst mal nur die LEDs anzusteuern zu können und über CAN1 (Hight-Speed Treiber) CAN-Botschaften zu senden und empfangen zu können.
Dazu sind im Cube-Mx erst mal folgende Schritte erforderlich:
- Konfiguration der Prozessor Pins im Reiter "Pinout"
Abb. 1.1 - Pin Konfiguration
Hier werden die Pins für :
- externer Quarz
- CAN1/2 Tx/Rx Pins
- CAN_RS - Steuerleitung für den High-Speed CAN-Treiber (low=aktiv, high bzw. Input Float =standby Mode)
- nCAN2_STB - Steureleitung für den Low-Speed CAN-Treiber
- Inputs (PullUp) für den Jumper S2 (PA2,PC2)
- LED Ausgänge (Push Pull) - Clock Konfiguration:
Der STM wird auf die maximale mögliche Clocks die mit einem externen 8 MHz Quarz möglich sind konfiguriert (Systemtak 72Mhz mittels PLL)
Abb 1.2 Clock-Konfiguration - Konfiguration der einzelnen Hardwaremodule
Abb. 1.3 Konfigurations übersicht
Abb.1.4 CAN1-Parameter
CAN1 Settings:
- Baudrate 500 kBit
- normal Mode
Abb. 1.5 ISR-Settings
Abb. 1.6 CAN1-GPIO-Settings
CAN2 wird auf gleicherweise konfiguriert, wird hier aber nicht weiter betrachtet, das hier erst mal nur CAN1 verwendet wird.
Abb. 1.7 GPIO-Pin Konfiguration
Die restlichen Einstellungen bleiben auf Default und jetzt kann mit "Generate Code" kein Keil V5 Projekt erzeugt werden.
Dies Keil-Project hat dann folgenden Aufbau:
Achtung ist veraltet und gilt nur für die HAL-Version < 1.7
Anpassungen im erzeugten Keil-Projekt
Bei Anpassungen im Code sollte man darauf Achten, dass man seinen Code nur in den "USER CODE" Bereichen:
/* USER CODE BEGIN 2 */
/* USER CODE END 2 */
ändert, damit die Anpassungen nicht beim erneuten Generieren vom Keil Projekt überschrieben werden.
Die genaue Anpassungen im Code könnnen dem fertigen Projekt (s.o) entnommen werden.
Hier möchte ich nur auf ein paar grundsätzliche Dinge eingehen:
- Ansteuerung der LEDs und sonstige Pins:
Die Pins können direkt mit der Funktion HAL_GPIO_WritePin(...); angesteuert werden. Und zwar unter Verwendung der Namen die bei der Pinkonfiguration für die Pins eingetragen wurden.
/* USER CODE BEGIN 2 */ HAL_GPIO_WritePin(LED_RED_GPIO_Port,LED_RED_Pin,GPIO_PIN_SET); HAL_GPIO_WritePin(LED_BLUE_GPIO_Port,LED_BLUE_Pin,GPIO_PIN_RESET); HAL_GPIO_WritePin(CAN_RS_GPIO_Port,CAN_RS_Pin,GPIO_PIN_RESET); // enable 82C250 HS
Obiges Beispiel schaltet die rote LED ein und setzt die Ausgänge für die blaue LED und den CAN_RS Pin auf 0. - CAN Messages senden/empfangen
Für das CAN-Handling sind ein paar Schritte mehr nötig:
1.) Variablen für die CAN-Daten anlegen:
/* USER CODE BEGIN PV */ static CanTxMsgTypeDef myTxMessage; static CanRxMsgTypeDef myRxMessage; static CAN_FilterConfTypeDef myFilter; /* USER CODE END PV */
2.) Prototypen für den CallbackHandler für Rx-Botschaften anlegen
/* USER CODE BEGIN PFP */ /* Private function prototypes -----------------------*/ void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef* hcan);
Diese Funktion wird jedesmal beim Empfang einer CAN-Botschaft aufgerufen
3) Senden einer CAN Botschaft (std Format):
hcan1.pTxMsg = &myTxMessage; myTxMessage.DLC = 4; myTxMessage.StdId = 0x234; myTxMessage.IDE = CAN_ID_STD; HAL_CAN_Transmit_IT(&hcan1);
Wichtig hierbei ist nur, dass man nicht vergisst als erstes den Pointer auf die TxMessage zu setzen, da man sonst irgendeinen Speicherbereich überschreibt, was meistens in einen Hardfault endet.
Im obigen Besipiel wird folgende CAN-Botschaft:
0x234 4 00 00 00 00
gesendet.
Und hier noch ein Beispiel für eine Extende CAN-Botschaft:
myTxMessage.DLC = 3; myTxMessage.ExtId = 0x14F00500; myTxMessage.IDE = CAN_ID_EXT; myTxMessage.Data[0] = 0xAA; HAL_CAN_Transmit_IT(&hcan1);
4) Empfang einer CAN-Botschaft
Jetzt wird als erstes der CallBackHandler für die Rx-Botschaften definiert:
Die blaue LED wird beim Empfang einer CAN-Botschaft getoggelt./* USER CODE BEGIN 4 */ void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef* hcan) { HAL_GPIO_TogglePin(LED_BLUE_GPIO_Port,LED_BLUE_Pin); // todo ... CAN-Daten verarbeiten __HAL_CAN_ENABLE_IT(hcan, CAN_IT_FMP0); // hier mal fest FMPIE0 wieder freigeben, damit weitere CAN-Botschaften (CAN RX ISR ausgelöst werden) }
Die Rx-Botschaften sollen im nicht blockiert Modus (ISR) abgearbeitet werden. Dazu sind folgende Schritte erforderlich:
1) Empfangs Filter einrichten (alle IDs mittels Filtermaske erlauben)
2) Pointer auf die Empfangs Struktur setzen.
3) ISR empfangsroutinge Aufrufen ( auf eine Fehlerbehandlung wird erst mal verzichtet)myFilter.FilterNumber = 0; myFilter.FilterMode = CAN_FILTERMODE_IDMASK; myFilter.FilterScale = CAN_FILTERSCALE_32BIT; myFilter.FilterIdHigh = 0x0000; myFilter.FilterIdLow = 0x0000; myFilter.FilterMaskIdHigh = 0x0000; myFilter.FilterMaskIdLow = 0x0000; myFilter.FilterFIFOAssignment = 0; myFilter.FilterActivation = ENABLE; HAL_CAN_ConfigFilter(&hcan1,&myFilter); hcan1.pRxMsg= &myRxMessage; ...... // und in der main Hauptschleife erfolgt dann der Aufruf: /* USER CODE BEGIN 3 */ // Korrektur, dieser Aufruf in der Hauptschleife war eine Fehlinterpetation von mir // HAL_CAN_Receive_IT(&hcan1,CAN_FIFO0); /* Das Problem ist das die Funktion "HAL_CAN_Receive_IT" vom IRQ-Handler: - HAL_CAN_IRQHandler() aufgerufen wird. Und in dieser Funktion wird das FMPIE-Bit zurückgesetzt // Disable FIFO 0 message pending Interrupt __HAL_CAN_DISABLE_IT(hcan, CAN_IT_FMP0); Und dieser Handler wird wieder vom CAN-RX ISR aufgerufen. - CAN1_RX0_IRQHandler() // CAN-ISR Handler Dies hat nun zur Folge das keine weiteren Empfangs ISR ausgelöst werden. Lösung: In der Call-Back Funktion "CAN_RxCpltCallback()" muss der Fifo0 Interupt wieder freigegeben werden __HAL_CAN_ENABLE_IT(hcan, CAN_IT_FMP0); // hier mal fest FMPIE0 freigeben Deshalb wird nun in USER CODE BEGIN 3 nichts eingetragen. */ */
Zur Erinnerung, hier ist das komplette Projekt abgelegt:
Github: STM32-CAN - CubeMX Testprojekt
Dort ist auch noch ein eigener SysTickCallBack Handler implementiert um eigene Delay-Varriablen zu Verwalten, um z.B. Botschaften zyklisch senden zu können.
20.02.2016: Das Projekt auf Github wurde jetzt um die USB-Funktionalität und um das Grundgerüst für die Verarbeitung von Lawicel - Befehle erweitert.
Mit dem Makro PING_PONG werden alle empfangenen Zeilen auf als Echo zurückgesendet, dies dient nur zum Testen im Terminal um zu sehen, ob die USB-Kommunikation auch funktioniert.
Das Lawicel Grundgerüst besteht erst mal aus den Befehlen:
- V - Software Versionsnummer
- v - Hardware Versionsnummer
- unbekannte Befehle werden mit dem Error-Status (0x07) quittiert.
17.07.2016: Das Projekt auf Github wurde jetzt um weitere Lawicel - Befehle erweitert, so dass der CAN-Hacker die empfangene CAN-Botschaften in der RX/Trace Liste anzeigt.
Folgende Lawicel Befehle werden jetzt in der Version V0.3 unterstüzt:
- Sn[CR] - Auswahl diverser Standardbaudraten
- sxxyy[CR] - Auswahl diverser benutzerdeifinierten Baudraten (s. Dokumentation zu STM32-CAN§)
- O[CR] - CAN Kanal im "normalen Modus" öffnen
- L[CR] - CAN Kanal im "Listen only Modus" öffnen
- C[CR] - CAN Kanal schließen
- Zn[CR] - Zeitstempel für die empfangene CAN-Botschaften "EIN"/"AUS"
- Das Senden von Extend/Standard Botschaften vorbereitet (sende immer die gleiche Testmessage
- Empfang von Standard und Extended CAN-Botschaften (RX: tiiildd...[CR] und Tiiiiiiiildd...[CR])
Somit werden die Botschaften im CAN-Hacker angezeigt
Das Senden der Testbotschaft beim Anschließen an USB wurde entfernt. Die Testbotschaft wird jetzt nur noch beim Sendewunsch gesendet (Std oder Extend ID).
- Details
- Geschrieben von: Super User
- Kategorie: STM32 Projekte
- Zugriffe: 60723
STM32-CAN – Hardware V1.2
Abb. 1.1 STM32-CAN V1.2 Hardware
Hardware 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-Schalter |
3 | GND (optional) |
4 | CAN2 - LOW vom CAN LOW-Speed Bus Treiber |
5 | nicht verwendet |
6 | GND |
7 | CAN-HIGH Signal Auswahl LOW/HIGH Speed CAN Bus erfolgt mittels DIP-Schalter |
8 | nicht verwendet |
9 | CAN2 - High vom CAN Low Speed Bus Treiber |
Software:
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