Hallo,
ich habe 2 CUL 868 an meinem Pi und möchte einen für MAX und einen für FS20 und FHT Stellantriebe verwenden. Der für MAX ist neu, bisher hatte ich nur einen für FS20 und FHT.
Ich habe beide nun mit der aktuellen culfw 1.66 geflasht. Mit "ls -l /dev/serial/by-id" erscheint aber immer nur ein Eintrag, egal ob ich 1 oder 2 CULs angesteckt habe.
Definiert habe ich die beiden folgendermaßen:
define CUL_868_SlowRF CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 2234
attr CUL_868_SlowRF model CUL
attr CUL_868_SlowRF rfmode SlowRF
define CUL_868_MAX CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 0000
attr CUL_868_MAX model CUL
attr CUL_868_MAX rfmode MAX
Das funktioniert auch einigermaßen, ich kann z.B. Befehle senden, weiß aber nicht von welchem Stick sie aus gesendet werden. Wenn ich einen abstecke macht dies keinen Unterschied (es wird immer noch gesendet), aber ich habe einige Probleme mit dem Empfang die vermutlich daher kommen.
Wie sollte ich die beiden CUL Stick definieren um sie getrennt ansprechen und verwenden zu können?
Die Forum und Google Suche hat mit leider keine eindeutige Lösung geliefert.
By-path definieren oder mit dem ftdi-programm einen umbenennen.
Mobil=Kurz
Längere Fassung:
1. Wenn Du nur die beiden seriellen Devices hast, könntest Du in diesem speziellen Fall auf auf die Eindeutigkeit verzichten (über /dev/ttyACM0 bzw. /dev/ttyACM1 bzw. ...USBx definieren); beide Geräte sind ja wirklich identisch und müssen halt nur mit den richtigen Befehlen gefüttert werden.
2. Zu "by-path" hat Otto was geschrieben (http://heinz-otto.blogspot.de/2016/10/mein-erstes-arduino-projekt.html) (ziemlich unten)
3. Ich nehme stark an, dass die busware-CUL FTDI-USB-seriell-Chips verbaut haben. Daher sollte man die Hersteller- und Typenbezeichnung ändern können, die wiederum die Grundlage zur Vergabe der "by-id"-Adresse ist (z.B. von "CUL868" auf "CUL868_1" und "CUL868_2". Details hier, zwei Beiträge weiter gibt es auch den Link auf das entsprechende Linux-Tool.
Mir persönlich läge hier Lösung 3 am nächsten. Ist zwar im ersten Moment etwas aufwändiger, hat aber den Vorteil, dass später in der Regel keine Probleme mehr entstehen (Umstöpseln, weitere serielle/USB-Devices/anderer (Linux-)Rechner...).
Gruß und viel Erfolg,
Beta-User
Hallo,
Vielen Dank für die Antwort. Mir erscheint auch Lösung 3 am praktischsten. Hast du dazu einen Link? Ich kann in deinem Post leider nur den zum 2. Vorschlag finden.
Der Busware CUL benutzt keinen FTDI Chip. Die Hersteller und Typbezeichnung kann man nur im Sourcecode ändern.
Zitat von: Telekatz am 29 Dezember 2016, 16:27:10
Der Busware CUL benutzt keinen FTDI Chip. Die Hersteller und Typbezeichnung kann man nur im Sourcecode ändern.
Das ist interessant und scheint ja (z.B.) über den Parameter
#define BOARD_ID_STR433 "nanoCUL433" in der board.h gesteuert zu werden, unabhängig vom konkret verwendeten Wandler.
Ist die Schlußfolgerung richtig, dass man das das dann auf andere (Arduino-basierte) USB-Geräte übertragen kann, indem man das schlicht in board.h entsprechend angibt, und die Descriptors.c und.Descriptors.h mit einbindet???
(Nur Interessehalber...)
Gruß, Beta-User
Zitat von: Beta-User am 29 Dezember 2016, 17:57:40
Ist die Schlußfolgerung richtig, dass man das das dann auf andere (Arduino-basierte) USB-Geräte übertragen kann, indem man das schlicht in board.h entsprechend angibt, und die Descriptors.c und.Descriptors.h mit einbindet???
Nein, das kann man nur auf Geräte übertragen, die einen MEGA32U4 verwenden, wie der Arduino Leonardo oder Pro Micro oder auch bei den Busware CULs. Diese Geräte benötigen keinen USB Wandler, weil USB vom µC unterstützt wird. Den USB Descriptor kann man da in der Firmware anpassen.
Wird ein MEGA328 verwendet, wie z.B. beim Arduino nano, wird ein externer USB Wandler benötigt. Um den USB Descriptor kümmert sich da der Wandler und der kann dann nicht von der Firmware beeinflusst werden.
Vielen Dank für die ganzen Antworten.
Was genau bedeutet dass dann für mich? In der Datei board.h die entsprechende Zeile abändern, dann neu kompilieren (?) und dann diese culfw auf einen der Sticks flashen zur Unterscheidung?
Zitat von: kingmathers am 30 Dezember 2016, 11:25:39
Was genau bedeutet dass dann für mich? In der Datei board.h die entsprechende Zeile abändern, dann neu kompilieren (?) und dann diese culfw auf einen der Sticks flashen zur Unterscheidung?
Ja. Wobei für den USB Descriptor folgende Zeile in der board.h relevant ist:
#define BOARD_ID_USTR L"CUL868"
Zitat von: kingmathers am 30 Dezember 2016, 11:25:39
Was genau bedeutet dass dann für mich? In der Datei board.h die entsprechende Zeile abändern, dann neu kompilieren (?) und dann diese culfw auf einen der Sticks flashen zur Unterscheidung?
Da war jemand schneller, ergänzend noch:
Variante 2 wäre die "by-path"-Definition beider CULs (dann ist Umsetecken aber u.U. Quell weiterer Verwirrung)
Variante 3 (wenn und solange nichts anderes auf die ttyACMx-Pfade gemapped wird (siehe ls -l /dev/serial/by-id oder vermutlich auch .../by-path)) auch über eine "uneindeutige" Definition umer diese Art der Beschreibung der Schnittstellen.
Viel Erfolg und einen guten Rutsch!
OK mit der selbst kompilierten Firmware könnte ich die Stick dann über ls -l /dev/serial/by-id unterscheiden oder?
Ich müsste schon wissen welcher welcher ist, da der mit der größeren Reichweite für FS20 vorgesehen ist.
Ist die Anleitung aus dem Wiki (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software) bzgl. des kompilieren so richtig? Oder wäre jemand so nett mir das kurz zu kompilieren (mit "_2" am Ende oder so) und hier hochzuladen? :)
Zitat von: kingmathers am 30 Dezember 2016, 11:56:18
OK mit der selbst kompilierten Firmware könnte ich die Stick dann über ls -l /dev/serial/by-id unterscheiden oder?
...das war Sinn der Übung...
Zitat von: kingmathers am 30 Dezember 2016, 11:56:18
Ist die Anleitung aus dem Wiki (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software) bzgl. des kompilieren so richtig? Oder wäre jemand so nett mir das kurz zu kompilieren (mit "_2" am Ende oder so) und hier hochzuladen? :)
Nur Mut! Als ich das erste Mal diese Übung durch hatte, habe ich auch erst mal tief durchgeschnauft ;).
Aber wenn man mal ein Gefühl dafür bekommt, kann man richtig Lust auf mehr bekommen (=>SIGNALduino, MySensors, Selbstbau-CUL) ;D. Im schlimmsten Fall kannst Du einfach wieder die bisher verwendete hex auf den Stick bannen...
Hallo,
ich habe nun wieder Zeit gefunden mich dem Thema zu widmen.
Bei mir fängt die Datei folgendermaßen an:
#ifndef _BOARD_H
#define _BOARD_H
// Feature definitions
#define BOARD_ID_STR "CUL868"
#define BOARD_ID_USTR L"CUL868"
#define MULTI_FREQ_DEVICE // available in multiple versions: 433MHz,868MHz
#define BOARD_ID_STR433 "CUL433"
#define BOARD_ID_USTR433 L"CUL433"
Auch im weiteren Verlauf gibt es einige Male eine Zeile, die mit "#define BOARD_ID_USTR" anfängt.
Welche Zeile genau muss ich zu was ändern?
Muss ich das Rautezeichen am Anfang löschen?
Hi,
weitere "#define BOARD_ID_USTR" habe ich in https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/board.h nicht gefunden, auf welchen Quellcode beziehst Du Dich?
Das "#" ist korrekt so, in C ist das kein Kommentar-Zeichen (das wäre "//" bzw. "/* bis */" für ggf. mehrzeilige Abschnitte).
Das sollte also z.B. dann so aussehen:
#define BOARD_ID_STR433 "CUL433A"
#define BOARD_ID_USTR433 L"CUL433A"
Sowas testet man am besten einfach mal aus, in der Regel kann nichts wirklich wichtiges schiefgehen ;).
Gruß, Beta-User
Ich bezog mich auf die Abschnitts weiter unten unter "#ifdef CUL_V2_HM", aber da ich ein CUL V3 habe sollte das ja irrelevant sein.
Dann werde ich es so (nur für 868, nicht 433 MHz) mal versuchen.
Danke für die Hinweise.