CAN-BUS

  • CAN-Modul

    CAN-Modul

    Universelles CAN-Modul basierend auf den MCP2515 CAN-Controller und dem ATA6660 CAN-Treiber.

    Kurzbeschreibung

    Hiebei handelt es sich um eine kleine Adapterplatine die über ein 10poliges Flachbandkabel mit dem Host-Controller-Board verbunden werden kann. Für die Ansteuerung des CAN-Controlles  wird die SPI-Schnittstelle vom Host-Prozessor verwendet. Der CAN-Controller wird mit einem externen 20 MHz Quarz betrieben.

    Die CAN-BUS Datenleitungen werden auf einen 9 poligen SUB-D Stecker geführt und die Pin-Belegegung richtet sich nach dem CIA-Standard.

    Mittels Jumper JP1 kann eine 120 ohm Terminierung für die Signalleitungen CAN-H und CAN-L aktiviert werden.
    Mit den  optionalen  Widerstände R2 (Pullup für CAN-H nach +5V) und R10 (Pulldown nach GND) kann das Modul an hersteller spezifischen Bussysteme angepasst werden.

    Mit dem Jumper JP4 kann der StandBy Modus vom CAN-Bustreiber verhindert werden (bei gesetzen Jumper ist der Treiber immer aktiviert) ansonsten hängt der StandBy-Mode vom Eingangssignal "CTR_ATA" (Pin 7) ab.

    Schnittstellen Beschreibung:

    • 2x5 poliger Pin Header

      Pin Funktionsbeschreibung
      1 MOSI - SPI-Schnittstelle Dateneingangssignal
      2 SS - Chip Select Signal für den CAN-Controller (low aktiv)
      3 MISO - SPI Schnittstelle Datenausgangssignal
      4 INt1_MCP - Interrupt Ausgangssignal vom CAN-Controller (10 k Pull-Up nach +5V)
      5 SCK - SPI Schnittstelle Taktsignal (Eingang)
      6 RXCAN - RX-Signal vom CAN-Transceiver. Bietet die Möglichkeit den Host-Controller mittels Interrupt aus dem Sleepmoudus zu wecken. Bei Bedarf kann der Widerstand R1 (10 kohm) als PullUp nach +5V bestückt werden.
      7 CTR_ATA - Eingangssignal um den CAN-Transceiver in den StandBy Mode zu versetzen:
      - High: CAN-Transceiver ist aktiviert
      - Low: CAN-Transceiver im StandBy Mode
      8 OSC1_MCP2515 - Bei Bedarf kann bei gesetzen Jumper JP3 das Taktsignal vom 20 MHz Quarz abgegriffen werden, bzw. wenn der Quarz nicht bestückt ist ein externes Taktsignal von den CAN-Controller eingespeisst werden.
      9 +5 V Versorgungsspannungs Eingang
      10 GND- Masse

      Hinweis: Mit den Widerstände R5-R6 (1k)  erfolgt die Entkopplung von der SPI-Programmierschnittstelle, werden mehrere CAN-Module an der SPI-Schnittstelle betrieben so müssen diese Widerstände gebrückt werden und und auf dem Host-Controller müssen die Signalleitungen für die ISP-Programmierschnittstelle entkoppelt werden.
    • SUB-D9 Stecker X1 (männlich)

      Pin Beschreibung
      1 nicht belegt
      2 CAN-Low
      3 Masse
      4 nicht belegt
      5 nicht belegt
      6 nicht belegt
      7 CAN-High
      8 nicht belegt
      9 nicht belegt

     

    Schaltplan

    Schaltplan MCP 2515 - Adapter
    Abb. 1.1 - MCP 2515 Adapter Schaltplan

    Download als PDF:  Schaltplan.pdf

    3D-Ansichten (Eagle3D)

    CAN MCP2515 Adapter

    Abb. 1.2   MCP 2515 Adapter - Eagle 3D Ansicht von der Bestückungsseite

    MCP 2515 Adapter - Eagle3D Ansicht von der Leiterbahnseite

    Abb. 1.3 MCP 2515 Adapter - Eagle3D Ansicht von der Leiterbahnseite

    Layout (Google Sketchup)

    Bestückungsseite incl. Bestückungsdruck   Leiterbahnseite
    Abb.1.4-Bestückungsseite   Abb.1.5 - Leiterbahnseite

    Und so siehts in echt aus

     

    Leiterplatte von oben   Leiterplatte von Unten
    Abb.1.6 - Foto von der Bestückunsseite   Abb. 1.7 Foto von der Leiterbahnseite

     

    Betrieb des Moduls an einem Raspberry Pi 3 

    Um das Modul mit dem Raspberry Pi 3 zu verwenden, muss die Hardware leicht modifiziert werden, da der Pi keine +5V an seine Eingänge verträgt. Dadurch wird nun der MCP2515 und die Pull-Up Widerstände von den SPI-Leitungen (und IRQ) mit +3,3V vom Raspberriy versorgt. Und der Rest der Schaltung hängt weiterhin an den +5V die auch vom Raspberry zur Verfügung gestellt werden. Mein Testaufbau mit dem modifzierten Modul und Raspberry Pi 3 hat prima funktioniert.

    Hier folgt nun eine Beschreibung der Modifikationen für den Betrieb mit einem Raspberry Pi 3

    • Widerstand R4 um 90° drehen so das er Kontakt mit dem unteren Ende von R3 hat.Raspi PI3 - Modifikation Bestückungsseite
      Abb.1.8 - Foto von der Modifikation auf der Bestückunsseite und Anschlussbelegung
    • Leiterbahn am oberen Pad von R4 unterbrechen (+5V werden abgetrennt).
    • JP6 oberer Pin  wird als Anschluss für die +3,3V vom Raspberry verwendet.
    • JP6: die Leiterbahn am oberen Pin auf der Leiterbahnseite auftrennen.Raspberry Pi 3 - Modifikation Leiterbahnseite
      Abb.1.9 - Foto von der Modifikation auf der Leiterbahnseite

    • Anderer Seite von der aufgetrennten Leiterbahn nun mit +5V (oben am Elko) verbinden.
    • Jumper "JP4" setzen, keine Standby Kontroller über den Anschlussstecker. Der MCP ist immer aktiviert.

    Hier nochmal die Übersicht der Verbindungen, es wird die SPI0 - Schnittstelle vom Raspi verwendet:

    Raspi
    40 Pin Header
    Modul 
    10 Pin Header
    Beschreibung
    1  - 

    +3,3V - direkt auf LP
    Lötauge für Pin 19 MCP

    2 9 +5V
    6 10 GND
    19 1 MOSI
    21 3 MISO
    22 4 MCP_INT0
    23 5 SCLK
    24 2 CE0

     

    Raspberry Pi3 konfigurieren für den SPI-Support (wirklich nur eine Kurzanleitung, bzw. Gedankestüzte):

    https://geier99.de/wiki/doku.php?id=pi3_tipps

     

  • Pi-CAN FD - Duo - HAT-Modul

    PI-CAN FD Duo - HAT-Modul

     

    Hardware  (Version 0.1)

     Schaltplan

    Die Schaltung besteht im Wesentlichen aus:

    • 2 x MCP2517-FD -  CAN-Controller
    • 2 x MCP2562-FD -  3,3V CAN-Bus Treibern
    • 1 x EEPROM - HAT ID Eeprom 
    • optionale Terminierung der CAN-Bus Leitungen mittels Jumper
    • JP6 - Header : UART-Schnittstellen (console), so dass man den Raspi auch ohne Netzwerk über eine serielle Konsole konfigurieren kann.

    Die CAN-Controller sind über den SPI-BUS an den Raspberry Pi angebunden und die SPI-Taktfrequenz beträgt 40MHz.

    Hinweis: In dem Schaltplan sind für die Quarze jeweils zwei Bestückungsvarianten vorgesehen, so daß man die Bauform verwenden kann, die man gerade zur Hand hat, bzw. bei Handbestückung einfacher zu löten sind.

     

    Schaltplan - PI-CAN-FD Duo
    Abb. 1.1  Schaltplan - PI-CAN-FD Duo

    Schaltplan V0.1 PDF-Version

     Layout

    Toplayer
    Abb. 1.2 Bestückungsseite PI-CAN FD - Duo

     

    Bottomlayer PI-CAN FD-Duo
    Abb.1.3 Leiterbahnseite PI-CAN FD - Duo

     Aufbau

     PI-CAN FD - DUO eingebaut
    Abb.1.4  PI-CAN FD - Duo eingebaut

    PI-CAN FD-Duo bestückte Leiterplatte
    Abb.1.5  PI-CAN FD - Duo bestückte LP

     

     

     

    ..... in kürze mehr!

     

    Die ersten Tests sahen schon sehr vielversprechend aus, d.h. das Senden und Empfangen von CAN-FD-Frames (auch mit Baudrate Switch) haben funktioniert.

     

    Testsetup mit STM32 NUCLEO-G474-RE Board

    CubeMX Pin Konfiguration für NUCLEO CANFD Test
    Abb 1.6 CubeMX Pin Konfiguration

    Das Modul wurde mit dem Nucleo Board und diversen Baudraten getestet. Das verlinkte Video lief mit 1MHz Baudrate und 2 MHz Datenrate.

    Meine CubeMx-Konfiguration:
    images/pi_projekte/picanfd_duo/FD_Test.ioc

    Es wird der FDCAN1 verwendet welcher dann direkt mit dem  CAN-FD Treiber MCP2561FD direkt verbunden ist ( mit flying wires). Dafür wird eine kleine Lochrasterkarte verwendet.

    Ebenso wird der USART2 für die Debug-Ausgaben verwendet, da dieser hier im Nucleo Board über die USB-Buchse als VirtualComPort zur Verfügung gestellt wird, somit wird nur ein USB Anschluss und eine 5-6 V Versorgung benötigt.

    Achtung: Dazu den Jumper auf +5V_VIN setzen (somit wird nur der intenre ST-Link mit Spannung versorgt). Und die Versorgungsspannung über Vin einspeisen

    Eventuell ist dies  nicht notwendig und man kann alles über USB betreiben, aber dann wird der CAN-Treiber außerhalb seine Spezifikation von der Versorgungsspannung betrieben. (+5V für den CAN-Treiber).

    CAN-FD Testaufbau mit dem STM32G474 Nucleo Board
    Abb. 1.7 CAN-FD Testaufbau mit NUCLEO Board

     

    Und hier ein kurzes Video welches die Funktion des Tests zeigt:

    https://youtu.be/W887qp6XLx4

    CAN0 wurde folgendermaßen konfiguriert:

    pi@raspberrypi:~ $ sudo ip link set can0 up type can bitrate 1000000   dbitrate 2000000 restart-ms 1000 berr-reporting on fd on
    pi@raspberrypi:~ $ 
    pi@raspberrypi:~ $ ip -det link show can0
    3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
        link/can  promiscuity 0
        can <BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000
              bitrate 1000000 sample-point 0.750
              tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
              mcp25xxfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
              dbitrate 2000000 dsample-point 0.750
              dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1
              mcp25xxfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
              clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
    

     

  • 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:

    STM32-CAN-FD  Bestückungsplan
    Abb.1.3 - 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:

    STM32-CAN-FD 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

    CubeMX Pin Konfiguration 3x CAN-FD
    Abb.1.5 CubeMX-Konfiguration Pins für 3x CAN-FD ohne USB und externen Quarz

     

    Die geplante Konfiguration für alle 3 CAN-FDs, USB und Quarz sollte dann so aussehen:

    CubeMX Pins für 3xCAN-FD
    Abb.1.6 CubeMX Pins für 3x CAN-FD, USB und Quarz

    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:

     

    CubeMX - CAN-FD Baudraten Konfiguration
    Abb. 1.7 CubeMX CAN FD1 Baudraten Konfiguration

    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 - Hardware V1.2

    STM32-CAN – Hardware V1.2

     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.

    Schaltplan:
    Schaltplan STM32-CAN  - Version 1.2

    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