Autor Thema: Selbstbau CUN (MapleCUN)  (Gelesen 35118 mal)

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Selbstbau CUN (MapleCUN)
« am: 09 November 2016, 20:29:52 »
Hallo zusammen,

Ich möchte euch ein neues CUL Interface vorstellen. Einen CUN zum selberbauen.
Benötigt werden dazu folgende Teile:

Maple Mini Board:
https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html

W5100 Ethernet Modul:
https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html

CC1101 Funkmodul
https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html


Die Module werden gemäß Schaltplan miteinander verbunden. Da alle Module mit 3,3V laufen sind keine Bauteile für eine Pegelanpassung notwendig.

Zum flashen des Maple Bootloaders wird noch ein USB/TTL Wandler benötigt. Da der UART1 Anschluss des Controllers 5V tolerant ist kann auch ein Wandler mit 5V Ausgang verwendet werden. Angeschlossen wird der Wandler an X4 (DBG).

Die Firmware ist in der a-culfw enthalten. Es gib zwei Versionen, einmal für ein W5100 und einmal für ein W5500 Ethernet Modul. Falls kein Ethernet Modul vorhanden ist (MapleCUL), ist es egal welche der beiden Versionen verwendet wird.
Die Binarys gibt es hier zu herunterladen.

Flashanleitung: https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md

Wiki Artikel: MapleCUN


Update 17.12.2016:
Schaltplan geändert

Update 05.02.2017:
Schaltplan geändert
Wiki hinzu

Update 06.03.2017:
Flashanleitung verlinkt
« Letzte Änderung: 06 März 2017, 19:23:04 von Telekatz »

Offline locutus

  • Sr. Member
  • ****
  • Beiträge: 797
  • No support over PM! Please use the thread ...
Antw:Selbstbau CUN
« Antwort #1 am: 10 November 2016, 23:17:39 »
Würdest du bitte den Quellcode veröffentlichen bzw. verlinken? Danke im Voraus!
Produktivsystem: Raspberry Pi 3, Add-On Board mit 1.8" TFT LCD, FHEM V5.7, CULFW V1.66, FS20, ESA2000, JeeLink Clone RFM69CW, LaCrosse, EMT7110, 1-Wire, WiFi LED Controller, Yamaha AVR
Testumgebung: NanoPi Neo, FHEM trunk, FHEM Tablet UI, ESP8266, miniCUL-WLAN mit a-culfw, LaCrosseGateway

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Antw:Selbstbau CUN
« Antwort #2 am: 11 November 2016, 08:01:13 »
Der Quellcode ist im Branch STM32 der a-culfw verfügbar:
https://github.com/heliflieger/a-culfw/tree/STM32

Offline locutus

  • Sr. Member
  • ****
  • Beiträge: 797
  • No support over PM! Please use the thread ...
Antw:Selbstbau CUN
« Antwort #3 am: 26 November 2016, 12:55:17 »
12 € für ein CUL mit 128 kB Speicher und Netzwerkanbindung! Das Preis-/Leistungsverhältnis ist unschlagbar.
Ich habe noch einige Fragen zum selbstbau CUN.

CUL Kommando "L" ...
#define HAS_MAICOWas für ein Funkprotokoll ist das?

Stellt
#define HAS_UART 1CUL RAW Messages transparent auf USART1 bereit?

Zusätzliche CC1101 Transceiver ...
//additional CC1101 Transceiver
//#define CC1100_ASKSIN 1
//#define CC1100_MORITZ 2
//#define CC1100_MAICO 3
Ist das nur graue Theorie oder bereits in der Praxis anwendbar?

Ist WIZnet W5100 durch W5500 ersetzbar?
#define HAS_W5500W5500 ist im Quellcode vorhanden, aber wird die Hardware tatsächlich unterstütz?

Die Konfiguration und Anbindung an FHEM klappt, aber der Router und die Netzwerkscanner App zeigen die IP-Adresse des mapleCUN nicht an. Ist das so gewollt oder liegt es möglicherweise an der FritzBox?

« Letzte Änderung: 06 März 2017, 12:07:59 von locutus »
Produktivsystem: Raspberry Pi 3, Add-On Board mit 1.8" TFT LCD, FHEM V5.7, CULFW V1.66, FS20, ESA2000, JeeLink Clone RFM69CW, LaCrosse, EMT7110, 1-Wire, WiFi LED Controller, Yamaha AVR
Testumgebung: NanoPi Neo, FHEM trunk, FHEM Tablet UI, ESP8266, miniCUL-WLAN mit a-culfw, LaCrosseGateway

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Antw:Selbstbau CUN
« Antwort #4 am: 26 November 2016, 23:50:06 »
CUL Kommando "L" ...
#define HAS_MAICOWas für ein Funkprotokoll ist das?
Das ist für meinen Maico Lüfter http://www.maico-ventilatoren.com/produkte/produkte-maico/katalog/detail///p37601/.

Stellt
#define HAS_UART 1CUL RAW Messages transparent auf USART1 bereit?
Das ist noch ein Überbleibsel aus der Cube Vorlage. Hat momentan keine Funktion. Angedacht hab ich aber eine Funktion wie beim CUNx mit dem Pigator. USART 2 und 3 des STM32 sollen über zusätzliche USB Ports und/oder Netzwerkports direkt angesprochen werden können. Einen HM-MOD-RPI-PCB könnte man dadurch Netzwerkfähig machen.

Zusätzliche CC1101 Transceiver ...
//additional CC1101 Transceiver
//#define CC1100_ASKSIN 1
//#define CC1100_MORITZ 2
//#define CC1100_MAICO 3
Ist das nur graue Theorie oder bereits in der Praxis anwendbar?
Es funktioniert auf meinem Cube. Die Kombination SlowRF/Homematic funktioniert dort ohne Probleme. Für den STM32 muss ich das erst noch anpassen.

Ist WIZnet W5100 durch W5500 ersetzbar?
#define HAS_W5500W5500 ist im Quellcode vorhanden, aber wird die Hardware tatsächlich unterstütz?
Die Basis für den Netzwerkzugriff habe ich vom CUNx übernommen. Dort habe ich den W5500 durch den W5100 ersetzt. Sollte also mit Anpassungen auch wieder mit dem W5500 funktionieren. Zum Testen habe ich aber nur den W5100.

Die Konfiguration und Anbindung an FHEM klappt, aber der Router und die Netzwerkscanner App zeigen die IP-Adresse des mapleCUN nicht an. Ist das so gewollt oder liegt es möglicherweise an der FritzBox?
Gewollt ist das nicht. Liegt dann aber wohl eher an der Implementierung in der Wiznet Lib oder im W5100.

Der Quellcode wurde jetzt übrigens auch in den Master Branch der a-culfw übernommen.

Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline locutus

  • Sr. Member
  • ****
  • Beiträge: 797
  • No support over PM! Please use the thread ...
Antw:Selbstbau CUN
« Antwort #5 am: 27 November 2016, 11:00:42 »
Mir fällt auf, dass MAICO
#ifdef HAS_MAICO
{ 'L', maico_func },
#endif
mit BELFOX kollidiert …
#ifdef HAS_BELFOX
{ 'L', send_belfox },
#endif

Das Kommando "L" ist bis heute in Commandref nicht dokumentiert.
Auch das willkürliche Flackern bzw. Aufleuchten der CUL-LED ist vermutlich darauf zurückzuführen.
Produktivsystem: Raspberry Pi 3, Add-On Board mit 1.8" TFT LCD, FHEM V5.7, CULFW V1.66, FS20, ESA2000, JeeLink Clone RFM69CW, LaCrosse, EMT7110, 1-Wire, WiFi LED Controller, Yamaha AVR
Testumgebung: NanoPi Neo, FHEM trunk, FHEM Tablet UI, ESP8266, miniCUL-WLAN mit a-culfw, LaCrosseGateway

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Antw:Selbstbau CUN
« Antwort #6 am: 27 November 2016, 14:02:40 »
Das Flackern der LED kann damit nichts zu tun haben.

Es wir zwar bei beiden Protokollen "L" verwendet, aber
#ifdef HAS_BELFOX
{ 'L', send_belfox },
#endif
ist in der fntab[] der ARM Devices nicht vorhanden. Und nur diese Devices haben Maico. Desweiteren hätte das auch nur Auswirkungen beim Senden.

Das flackern liegt an der Empfindlichkeit des CC1101, der Rauschen im slowRF Mode empfängt. In rf_receive.c wird dann versucht das zu decodieren. Das löst dann das toggeln der LED aus.
Abhilfe schafft da, die Empfindlichkeit des CC1101 herunterzusetzen.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline stefanru

  • Full Member
  • ***
  • Beiträge: 289
Antw:Selbstbau CUN
« Antwort #7 am: 06 Dezember 2016, 11:03:08 »
Hi Telekatz,

nochmals danke für den Tip mit dem Maple Mini.
Hab mich jetzt schonmal soweit eingelesen.
Will den Maple als CUL verwenden.

Wei ich gesehen habe muss der Maple mit USB TTL adapter geflasht werden.
Da ich bisher nur die arduinos per USB geflasht habe und den Bootloader der Arduinos per zweitem Arduino im ISP mode habe ich eine kurze Frage.
Ist dieser USB to TTL ok?
http://www.ebay.de/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-Arduino-Mini-Port-/222099549821?hash=item33b62a2e7d:g:ipAAAOSwd0BVxNxc

Danke und Gruß,
Stefan

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Antw:Selbstbau CUN
« Antwort #8 am: 06 Dezember 2016, 11:43:28 »
Wei ich gesehen habe muss der Maple mit USB TTL adapter geflasht werden.
Da ich bisher nur die arduinos per USB geflasht habe und den Bootloader der Arduinos per zweitem Arduino im ISP mode habe ich eine kurze Frage.
Ist dieser USB to TTL ok?
http://www.ebay.de/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-Arduino-Mini-Port-/222099549821?hash=item33b62a2e7d:g:ipAAAOSwd0BVxNxc
Ja, mit dem sollte es funktionieren.

Online Ranseyer

  • Sr. Member
  • ****
  • Beiträge: 579
    • Homepage
Antw:Selbstbau CUN
« Antwort #9 am: 17 Dezember 2016, 17:15:14 »
Danke für das geniale Projekt !
Die Teile sind vorher gekommen, also kanns nun losgehen !


Bin am überlegen ob ich dazu eine Platine pinseln soll... (Das wäre schlauer gewesen mit der Teilebestellung zusammen)


Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Antw:Selbstbau CUN
« Antwort #10 am: 17 Dezember 2016, 20:19:37 »
Mittlerweile funktioniert auch der Zugriff auf die beiden freien seriellen Schnittstellen. Über USB werden dabei zwei weitere Schnittstellen angelegt, der Netzwerkzugriff erfolgt über die Ports 2324 und 2325.

Zur Einstellung der Baudrate über Netzwerk gibt es folgende Befehle:

UART0 Baudrate einstellen
pb0@115200
UART1 Baudrate einstellen
pb1@9600
Baudrate im EEPROM speichern
ps
Baudrate anzeigen
pi

Ein am UART0 angeschlossener HM-MOD-UART kann z.B. mit folgender Definition in FHEM eingebunden werden:
define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2324

Online Ranseyer

  • Sr. Member
  • ****
  • Beiträge: 579
    • Homepage
Antw:Selbstbau CUN
« Antwort #11 am: 18 Dezember 2016, 11:10:15 »
Ich hätte noch 1-2 Fragen zum Thema:

Der CC1101 braucht Platz von ca 8 Pinreihen des Maple. Wenn man also eine Platine machen möchte die nicht größer als der Maple ist, und keine genutzen Pins unter dem CC1101 sein sollen (wäre notfalls auch möglich), dann sind Pins im Weg.
Könnte 11+10 (Nummer laut Aufdruck) weiter nach unten auf andere Pins (weg von der USB Buchse) verlagert werden ?

Mein favorisierter Weg:
Flashen sollte doch auch per USB über den Bootloader möglich sein, dann wäre 21+22 unnötig, und man könnte einfach eine Platine machen die etwas breiter ist und ca. Nr. 15-24 überdeckt (10 Pins sind mehr als genug!) ?
Frage dazu: wäre es möglich das Makefile so anzupassen dass auch ein Binary passend für Bootloader-Einsatz erzeugt werden kann ?

Offline locutus

  • Sr. Member
  • ****
  • Beiträge: 797
  • No support over PM! Please use the thread ...
Antw:Selbstbau CUN
« Antwort #12 am: 18 Dezember 2016, 13:45:37 »
Nimm bitte Rücksicht auf diejenigen, die den MapleCUL/MalpeCUN schon im Einsatz haben. Ich halte nachträgliche Änderungen an der GPIO-Belegung im Quellcode und somit Änderungen an der Referenzschaltung für problematisch. Denn nicht jeder ist dazu in der Lage, den Code zu deuten und verstehen zu können.
Produktivsystem: Raspberry Pi 3, Add-On Board mit 1.8" TFT LCD, FHEM V5.7, CULFW V1.66, FS20, ESA2000, JeeLink Clone RFM69CW, LaCrosse, EMT7110, 1-Wire, WiFi LED Controller, Yamaha AVR
Testumgebung: NanoPi Neo, FHEM trunk, FHEM Tablet UI, ESP8266, miniCUL-WLAN mit a-culfw, LaCrosseGateway

Online Ranseyer

  • Sr. Member
  • ****
  • Beiträge: 579
    • Homepage
Antw:Selbstbau CUN
« Antwort #13 am: 18 Dezember 2016, 15:33:09 »
Zitat
Nimm bitte Rücksicht auf diejenigen, die den MapleCUL/MalpeCUN schon im Einsatz haben

Das passt eh zu meiner favorisierten Methode:
Zitat
könnte einfach eine Platine machen die etwas breiter ist und ca. Nr. 15-24 überdeckt

Ich hab nochmals nachgelesen:
Zitat
RX1/TX1 am Maple Mini mit einem USB/TTL Adapter mit dem PC verbinden.
Beim STM32F105 kann man direkt per USB Flashen. Habe gehofft das würde hier auch gehen.
Weisst Du ob ich hier falsch liege ? (Das würde zwei zusätzliche PINs bedeuten, was kein Beinbruch sein sollte weil ich eh 10 Pins für Enternet, aber es hat nicht jeden nen USB2Seriell Wandler)


Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 606
Antw:Selbstbau CUN
« Antwort #14 am: 18 Dezember 2016, 15:45:54 »
Könnte 11+10 (Nummer laut Aufdruck) weiter nach unten auf andere Pins (weg von der USB Buchse) verlagert werden ?
Möglich ist das, aber wie locutus schon bemerkt hat, möchte ich das jetzt nicht mehr an der Referenzschaltung ändern. Du müsstest das dann für dich selber kompilieren.
Wenn du die Belegung änderst, sollte CC_IN0 auf 3 (PB0) umgelegt werden. Ansonsten müsste auch noch der EXTI IRQ Handler angepasst werden.

Mein favorisierter Weg:
Flashen sollte doch auch per USB über den Bootloader möglich sein, dann wäre 21+22 unnötig, und man könnte einfach eine Platine machen die etwas breiter ist und ca. Nr. 15-24 überdeckt (10 Pins sind mehr als genug!) ?
Frage dazu: wäre es möglich das Makefile so anzupassen dass auch ein Binary passend für Bootloader-Einsatz erzeugt werden kann ?
Der integrierte Bootloader kann nicht über USB flashen. Für USB bräuchstest du also einen extra Bootloader, den du ja auch irgendwie flashen können musst. Allerdings ist 21+22 dazu gar nicht nötig. Das ist nur die optionale SWD Schnittstelle. Der Bootloader benutzt 25+26.