Selbstbau CUN (MapleCUN)

[Telekatz]

PS: Was sehr cool wäre: Der aktuelle Stand in nächster Zeit mal wieder fertig kompiliert. (Es gibt m.E. kein fertiges Binary für W5500 mit gleichzeitig der Erkennung "sonderbarer" Funkmodule...)

Gibt es seit heute wieder.

[blueicechip]

Hallo,

Wie wäre es denn, wenn man bei der Version, bei der der Maple nach unten kommt, einfach zwei Microtaster auf der Platine vorsieht. Die beiden Tasten vom Maple sind doch rausgeführt, wenn ich das richtig gesehen habe.

[Ranseyer]

Gibt es seit heute wieder.

Danke ! (Gleich geflasht und läuft bis jetzt)

Wie wäre es denn, wenn man bei der Version, bei der der Maple nach unten kommt, einfach zwei Microtaster auf der Platine vorsieht.

Kritik an meiner Umsetzung ist immer sehr gerne willkommen. In dem Fall werde ich das jedoch nicht umsetzen weil:
Wenn der Maple-USB-Bootloader einmal getauscht ist sollte man daran nichts mehr machen.
Wenn doch, und dabei auch noch Probleme auftreten, sollte das ganze durch Anlöten eines einzigen Drahtes zu machen sein (der auf den passendes Potential gelegt wird und der MAPLE währenddessen angeschlossen wird).
Wenn dann noch ein Loch die Sache erleichtert per Button, sollte das mehr als genug sein...

[gloob]

Hat jemand von euch einen Link für CC1101 Briefmarken Module mit 433MHz. Leider konnte ich dazu bisher nichts finden.

[pejonp]

@gloob

hier gibt es CC1101 (868 & 434MHz) in verschieden Sorten.
http://www.tme.eu/de/details/rc-cc1101-spi-434/rf-kommunikationsmodule/radiocontrolli/#
http://www.tme.eu/de/details/rc-cc1101-smt-434/rf-kommunikationsmodule/radiocontrolli/rc-cc1101-spi-smt-434/#

pejonp

[gloob]

Ich auch aber welche mit dem passenden Pin-Layout

[Ranseyer]

Die von Pejonp sind für das Projekt nicht sinnvoll.

Wer minimal blättern kann findet hier Links von Telekatz: https://forum.fhem.de/index.php/topic,60458.msg607387.html#msg607387
Der war bei mir original und OK: https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html


Solche hier sollten es auch tun, und werden neuerdings seit letzter Firmwareanpassung auch korrekt initialisiert. (Allerdings bei mir nicht immer-immer: Selten muss ich den MAPLE auch nochmals reseten)
https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html

PS: Mir ist es das Wert für den Transceiver ein paar Euro mehr zu bezahlen. Aber dafür fest verlötet, also auch ohne jedes wackeln. Wer lieber Steckmodule nimmt hat mehr Auswahl zu besseren Preisen für 433MHz. Allerdings sieht es für 8866 MHz recht schlecht aus bei Steckmodulen. (Dafür habe ich Adapterplatinen um aus Stamps ein Steckmodul zu machen)

[A.Harrenberg]

Hallo Telekatz,

Ich versuche gerade mit der a-culfw und der 4xMapleCUL von Ranseyer Platine 3 ZWave-Empfänger gleichzeitig (mit verschiedenen Funk-Datenraten) in Betrieb zu nehmen. Hierbei haben Rudi und ich festgestellt das die Kommunikation mit dem Empfänger der nur mit 9600 Baud sendet mehr oder weniger i.O ist. Die beiden anderen Empfänger mit 40k und 100k Übertragungsrate empfangen im Schnitt aber nur 1/3 der Pakete. Vor allem scheinen alle "ACK" Nachrichten vom Maple nicht erkannt bzw. verschluckt zu werden.
Siehe auch diese Diskussion hier, bzw. meine erste Anfrage an Björn hier. Der Text hier entspricht mehr oder weniger der Anfrage an Björn.

Ich habe nun angefangen mir einige Debug-Zeilen mit TRACE_INFO_WP auf die serielle Debug-Schnittstelle zu schicken. Über ein kleines FHEM-Modul kann ich nun die serielle Schnitstelle öffnen und die Ausgabe per "Log3" mit in das fhem.log schreiben um es einfacher mit den Logzeilen des normalen ZWave-Dongels bzw. des ebenfalls mitlauschendem CUL vergleichen zu können.

Dabei fällt auf das hier das Zeilenende "\n" sehr oft fehlt und dadurch teilweise mehrere Zeilen als eine Zeile ausgegeben werden, da dann natürlich das splitten in FHEM nicht mehr funktioniert. Das sieht dann bespielsweise so aus:

Code Auswählen Erweitern

2017.04.14 14:53:21.290 5: slog: 40k:  reading bytes from CC1100: done40k:  e015dfed0113050a4065 ,CS ok40k:  msg received with len:020

Das sind eigentlich drei Ausgaben, die jeweils mit "40k:" anfangen...

Ich habe mir das auch schon mal ohne den "Umfweg" über das Log, also direkt mit einem Terminal angesehen, dort ist es ebenfalls so, d.h. das newline geht nicht innerhalb von FHEM verloren.

Hast Du eine Idee was hier schief läuft? Die modifizierte rf_zwave.c mit den eingefügten TRACE_INFO_WP Zeilen habe ich mal angefügt.

Die Platine ist im übrigen voll bestückt, d.h. ein 433er Modul auf CC0, drei 868er Module auf den anderen Plätzen und ein W5100. Momentan habe ich sogar die serielle DBG auf den ersten UART Anschluss gelegt damit ich das alles über einen USB-Port auslesen kann...

Gruß,
Andreas.

[Telekatz]

Hast du es auch schon mit "\n\r" probiert?

[A.Harrenberg]

Hi,

nein habe ich nicht, aber im logging Modul wird nach /n getrennt und dann per Log3 ausgegeben, da würde mir ein /r ja auch den Output kaputt machen.

Die Frage ist aber warum das meist (aber eben nicht immer) verschluckt wird...

Gruß,
Andreas.

[Telekatz]

Passiert das auch, wenn du über einen anderen USB-Seriell Wandler direkt am DBG Anschluss loggst?

[A.Harrenberg]

Hallo Telekatz,

ja, momentan habe ich die DBG Leitung über Kreuz auf eine der UART Schnitsstellen von der Platine verbunden und nutze die gleiche USB-Schnittstelle wie für die CULs. Ich habe aber auch mit einem USB-Seriell Wandler direkt am DBG Anschluss das gleiche Problem. Einige Zeilen werden einfach nicht getrennt.

Ich werde aber jetzt noch mal mit /n/r testen und schauen wie es dann aussieht, ich erwarte dann aber unerwünschte Zeilenumbrüche...

Gruß,
Andreas.

[A.Harrenberg]

Hi,

also mit /n/r werden die Zeilen teilweise "überschrieben", das bringt also auch nichts.

Gruß,
Andreas.

[A.Harrenberg]

Hi Telekatz,

ich habe jetzt mal alle \n durch \nblub\n ersetzt, d.h. eigentlich würde ich nach jeder normale Logzeile noch mal ein Zeile mit "blub" erwarten.

Wie Du siehst erscheint das "blub" manchmal richtig in einer einzelnen Zeile, andere Zeilen haben das "blub" aber vorne angesstellt, d.h. das letzte \n am Schluss wird irgendwie unterschlagen.

Code Auswählen Erweitern


2017.04.14 16:47:46.640 5: slog: blub100k: msg received with len:043
2017.04.14 16:47:46.640 5: slog: blub
2017.04.14 16:47:46.640 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:46.898 5: slog: blub100k: fd95f8de67f9f12b966feedcdbc2afeff5cfbfffc7e7fd2f6bb7beadf3f4f7fcfefb9ef21f7fdff5fff9af, CS **not** ok!
2017.04.14 16:47:46.898 5: slog: blub100k: msg received with len:091
2017.04.14 16:47:46.898 5: slog: blub
2017.04.14 16:47:46.898 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:47.940 5: slog: blub100k: Discarding msg, bb437f6d9e134bcf ,len:207
2017.04.14 16:47:47.940 5: slog: blub
2017.04.14 16:47:48.413 5: slog: 100k: Discarding msg, d7fa3ec755b1efb5 ,len:181
2017.04.14 16:47:48.413 5: slog: blub
2017.04.14 16:47:48.578 5: slog: 100k: Discarding msg, 3f64df5e9efefbfc ,len:252
2017.04.14 16:47:48.578 5: slog: blub
2017.04.14 16:47:50.130 5: slog: 100k: msg received with len:155
2017.04.14 16:47:50.130 5: slog: blub
2017.04.14 16:47:50.130 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:50.253 5: slog: blub100k: Discarding msg, cd3beaff73f6e1e3 ,len:227
2017.04.14 16:47:50.253 5: slog: blub
2017.04.14 16:47:55.132 5: slog: 100k: Discarding msg, d97bfe62c2eb9beb ,len:235
2017.04.14 16:47:55.132 5: slog: blub
2017.04.14 16:47:56.864 5: slog: 100k: msg received with len:103
2017.04.14 16:47:56.864 5: slog: blub
2017.04.14 16:47:56.864 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:57.194 5: slog: blub100k: msg received with len:135
2017.04.14 16:47:57.195 5: slog: blub
2017.04.14 16:47:57.195 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:58.175 5: slog: blub100k: Discarding msg, fa1f7dcbfb61ffff ,len:255
2017.04.14 16:47:58.175 5: slog: blub
2017.04.14 16:48:01.357 5: slog: 100k: msg received with len:105
2017.04.14 16:48:01.357 5: slog: blub
2017.04.14 16:48:01.357 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:01.550 5: slog: blub100k: msg received with len:017
2017.04.14 16:48:01.550 5: slog: blub
2017.04.14 16:48:01.550 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:01.550 5: slog: blub100k: bfe7916a760831117f6f3319fa586fdbf9, CS **not** ok!
2017.04.14 16:48:03.104 5: slog: blub100k: msg received with len:123
2017.04.14 16:48:03.104 5: slog: blub
2017.04.14 16:48:03.104 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:04.252 5: slog: blub100k: msg received with len:039
2017.04.14 16:48:04.252 5: slog: blub
2017.04.14 16:48:04.252 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:04.253 5: slog: blub100k: 36f17fdbaff5d727c9f73168bdeeefee3ffff7da3d0797fff977b7fc83bb9ef97dbfdbff178c6f, CS **not** ok!
2017.04.14 16:48:04.734 5: slog: blub100k: msg received with len:015
2017.04.14 16:48:04.734 5: slog: blub
2017.04.14 16:48:04.734 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:04.734 5: slog: blub100k: 9bfed7dcfbdcc80f5feebdfd9affff, CS **not** ok!


Im übrigen bekomme ich einen Compilererror wenn ich nur ein \n ohne irgendetwas anderes ausgeben will:

Code Auswählen Erweitern

TRACE_INFO_WP("\n");

Code Auswählen Erweitern

/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/sbrkr.c:58: undefined reference to `_sbrk'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-writer.o): In function `_write_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/writer.c:58: undefined reference to `_write'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-closer.o): In function `_close_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/closer.c:53: undefined reference to `_close'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-fstatr.o): In function `_fstat_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/fstatr.c:62: undefined reference to `_fstat'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-isattyr.o): In function `_isatty_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/isattyr.c:58: undefined reference to `_isatty'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-lseekr.o): In function `_lseek_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/lseekr.c:58: undefined reference to `_lseek'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-readr.o): In function `_read_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/readr.c:58: undefined reference to `_read'
collect2: error: ld returned 1 exit status

Keine Ahnung ob das in einem Zusammenhang steht, da dort ja im Prinzip aber nur ein printf aufgerufen wird wundert mich das schon.

Gruß,
Andreas.

[Telekatz]

Da fängt GCC an printf zu optimieren und das verträgt sich dann nicht mit der größenoptimierten printf Implementierung in STM32/stdio.c.

Benenne in stdio.c die Funktion "printf" in "_printf" um und ersetze in trace.h alle "printf" durch "_printf", dann sollte es funktionieren.