CUL mit serial für eindeutige Zuordnung per udev?

Begonnen von kpwg, 03 August 2014, 12:13:24

Vorheriges Thema - Nächstes Thema

no_Legend

Es sollte auch möglich sein, mit einem Windows Tool nur die Seriennummer zu setzten.
Schaut euch noch mal den Link hier an:
http://askubuntu.com/questions/49910/how-to-distinguish-between-identical-usb-to-serial-adapters

Bis nach unten Scrollen, ist der letzte Beitrag.
Habe es noch nicht getestet, also auf eigene Gefahr.

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

noansi

Hallo Peter,

Zitatkennst Du diese application note von Atmel http://www.atmel.com/Images/doc8201.pdf? Könnte man das in die Descriptors.c einbauen und per board.h verfügbar machen?

Geht wohl nach Vergleich von aktuellem LUFA und der in CUL genutzten Version.

In lufa -> StdDescriptors.h, DevChapter9.h und DevChapter9.c muss

#if !defined(NO_INTERNAL_SERIAL) && (defined(USB_SERIES_6_AVR) || defined(USB_SERIES_7_AVR))

durch

#if !defined(NO_INTERNAL_SERIAL) && (defined(USB_SERIES_2_AVR) || defined(USB_SERIES_4_AVR) || defined(USB_SERIES_6_AVR) || defined(USB_SERIES_7_AVR))

ersetzt werden.

Dann wird der Code für die interne Atmel Seriennummer mit compiliert und es wird eine 20-stellige USB-Seriennummer geliefert. Benötigt allerdings 94 Bytes Flash Speicher zusätzlich, da die Nummer intern gelesen, zu einem Descriptor geformt und dann geliefert werden muss.

Meine Custom Seriennummervariante benötigt auf CUL 54 Bytes zusätzlich für die 868xxx und 433xxx Seriennummer.

Gruß, Ansgar.

cotecmania

Hi,

wenn ich obige Aenderungen einfuege kommt beim compilieren :

Compiling C: ../../lufa/Drivers/USB/LowLevel/DevChapter9.c
../../lufa/Drivers/USB/LowLevel/DevChapter9.c:227:13: warning: 'USB_Device_GetInternalSerialDescriptor' defined but not used [-Wunused-function]
../../lufa/Drivers/USB/LowLevel/DevChapter9.c:221:13: warning: always_inline function might not be inlinable [-Wattributes]


Mache ich was falsch ?

Gruss
Joe
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

niceday

Zitat von: noansi am 09 Februar 2016, 22:50:23
Hallo Peter,

Geht wohl nach Vergleich von aktuellem LUFA und der in CUL genutzten Version.

In lufa -> StdDescriptors.h, DevChapter9.h und DevChapter9.c muss

#if !defined(NO_INTERNAL_SERIAL) && (defined(USB_SERIES_6_AVR) || defined(USB_SERIES_7_AVR))

durch

#if !defined(NO_INTERNAL_SERIAL) && (defined(USB_SERIES_2_AVR) || defined(USB_SERIES_4_AVR) || defined(USB_SERIES_6_AVR) || defined(USB_SERIES_7_AVR))

ersetzt werden.

Dann wird der Code für die interne Atmel Seriennummer mit compiliert und es wird eine 20-stellige USB-Seriennummer geliefert. Benötigt allerdings 94 Bytes Flash Speicher zusätzlich, da die Nummer intern gelesen, zu einem Descriptor geformt und dann geliefert werden muss.

Meine Custom Seriennummervariante benötigt auf CUL 54 Bytes zusätzlich für die 868xxx und 433xxx Seriennummer.

Gruß, Ansgar.
Das hat bei mir nix gebracht. Nach einem erneuten aus- und wieder einstecken (nach erfolgreichem flashen) des CUL bleibt es bei der selben ID: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0.

noansi

#19
Hallo niceday,

hast Du auch alle Vorkommen ersetzt und nicht nur einmal pro Datei?
In DevChapter9.c kommt es 2 mal vor.
Such am besten nach NO_INTERNAL_SERIAL .

Und natürlich müssen die header Dateien der avr Libs oder der compiler auch auch den __AVR_ATmega32U4__ define setzen, der in USBMode.h wiederum den passenden USB_SERIES_ define setzt.

Gruß, Ansgar.

Harst

Ich hätte da noch eine Idee.

Der CUL kann Daten im EPROM ablegen und Abfragen. Und der Speicher für die MAC-Adresse ist beim CUL irrelevant. Daran kann man den CUL wiedererkennen.

Horst

no_Legend

Es gibt auch noch eine andere Variante.
Damit benötigt man keinen Udev regel definieren.
Bei Ubuntu habe ich das gesehen und auch im Einsatz.

Voraussetzung:
Ubuntu (geteste 16.04 LTS)
USB Device bleibt immer am gleichen Port angeschlossen.
Kann auch für andere Distribution benutzt werden.

Funktion:
Sobald das gerät angesteckt wurde und die Treiber vorhanden sind, werden die Geräte eingebunden.
Somit kann unter /dev/serial mit zwei methoden arbeiten.
1. mit by-path
2. mit by-serial

2. fällt bei CULs raus, da diese zum jetztigen Zeitpunkt (soweit mir bekannt ist) keine eindeutige Seriennummer mitteilen.
1. sollte bei fast allem funktionieren, da hier auf den Geräte pfad verwiesen wird, den es nur einmal geben kann
Nachteil ist allerdings, sobald das Device umsteckt wird, ändert sich auch der Device Path.
Somit muss das Define dann auch angepasst werden

Anleitung für 1:
cd /dev/serial/by-id
ls -al
ausgabe zeigt usb-HUAWEI_Technology
Bsp Define: define name GSMSMS /dev/serial/by-id/usb-HUAWEI_Technology@19200

Anleitung für 2:
cd /dev/serial/by-path
ls -al
ausgabe zeigt pci-0000:000:14.0-usb-0:3.2:1.0-port0
Bsp Define: define name GSMSMS pci-0000:000:14.0-usb-0:3.2:1.0-port0@19200

Fazit:
Version 1 habe ich mometan für einen Huwaei stick im satz.
Mehre Neustarts überlebt.

Version 2 ist von mir noch nicht getestet worden.
Ich bin mir nicht sicher, ob die FHEM das define so aktzeptiert.


Viel Spaß und Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

niceday

Zitat von: noansi am 22 Januar 2017, 19:54:33
Hallo niceday,

hast Du auch alle Vorkommen ersetzt und nicht nur einmal pro Datei?
In DevChapter9.c kommt es 2 mal vor.
Such am besten nach NO_INTERNAL_SERIAL .

Und natürlich müssen die header Dateien der avr Libs oder der compiler auch auch den __AVR_ATmega32U4__ define setzen, der in USBMode.h wiederum den passenden USB_SERIES_ define setzt.

Gruß, Ansgar.
Danke für die Anmerkung, ich denke eher das Problem liegt ganz woanders in meinem Fall. Unzwar habe ich keinen FTDI-Chip verbaut auf dem Arduino sondern es ist eine billig China-Kopie mit nem Winchiphead-Chip (https://blog.sengotta.net/arduino-nano-wird-nicht-erkannt-was-tun/). In so einem Fall kann man keine (neue) Seriennummer setzen und somit steht der Chip immer auf 0000.
Ich habe das jetzt aktuell erstmal so gelöst indem ich statt /dev/ttyUSBxxx den hier verwende: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0 bzw. /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0. Das ist der direkte Linux-Pfad zu dem jwlg. USB-Port und da ich nicht daurend die CUL's umstecke bleiben sie immer am selben Ort und der Pfad ändert sich nicht, fertig :-)

noansi

Hallo niceday,

ZitatUnzwar habe ich keinen FTDI-Chip verbaut auf dem Arduino
In der Tat, nanoCUL ist eigentlich nur ein serielles Gerät. Da kann die Firmware nichts an der USB Seriennummer ändern.
Das geht nur mit Tools für den USB-seriell Chip, sofern verfügbar, wie Du schon richtig festgestellt hast.

Gruß, Ansgar.