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 Mode8 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
Abb. 1.1 - MCP 2515 Adapter Schaltplan
Download als PDF: Schaltplan.pdf3D-Ansichten (Eagle3D)
Abb. 1.2 MCP 2515 Adapter - Eagle 3D Ansicht von der Bestückungsseite
Abb. 1.3 MCP 2515 Adapter - Eagle3D Ansicht von der Leiterbahnseite
Layout (Google Sketchup)
Abb.1.4-Bestückungsseite Abb.1.5 - Leiterbahnseite Und so siehts in echt aus
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.
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.
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 HeaderModul
10 Pin HeaderBeschreibung 1 - +3,3V - direkt auf LP
Lötauge für Pin 19 MCP2 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
- 2x5 poliger Pin Header
-
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.
Layout
Aufbau
Abb.1.4 PI-CAN FD - Duo eingebaut
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
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).
Und hier ein kurzes Video welches die Funktion des Tests zeigt:
https://youtu.be/W887qp6XLx4CAN0 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:
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 - 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