I Linux fungerar allt, enheten visas som /dev/ttyACM?
I Windows fungerar enumreringen, den visas i Device Manager men med ett utropstecken i en gul ring. Ingen drivrutin laddas.
Antar Windows vill ha någon liten fil som nu saknas så drivern för serieport över USB kan laddas. Kan det ordnas utan att skriva en hel driver eller ha tillgång till svindyr dokumentation o.dyl.? Eller en fulfix med lämplig VID:PID, men vad är i så fall lämpligt?
Här är vad lsusb -v viar för den:
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0xdead
idProduct 0xbeef
bcdDevice 0.01
iManufacturer 1 Upper Duckwater Group
iProduct 2 Quack State EFA-computer control unit
iSerial 3 1802
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 450mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Jaha, så då har din apparat någon form av kommunikationsprotokoll.
Du skriver seriellt, är den kompatibel med en befintlig enhet till exempel PL2303, FT232, CP2102 eller CH340G är det bara att "sno" deras ID, då kommer Windows automatiskt att välja en sådan drivrutin och om du följt protokollet korrekt så fungerar det.
Har du hittat på ett helt eget protokoll måste du skriva en egen drivrutin, men det skulle du ju behöva i Linux också då. Vilken drivrutin använder du i Linux?
Ingen aning om vad det är för driver Linux laddar utöver det dyker upp en /dev/ttyACM som öppnas som en fil och data kan srkrivas till eller läsas från enheten. Finns inget enklare får jag testa FT232, det kan ju funka. Enheten kan ta emot och kvittera baudrate o.dyl. som Linux skickar. Windows kanske är nöjd med det, eller så vill den ha CTS, DTR och allt vad det nu är för att vilja skicka något.
Om det ska fungera i Windows, och det ej är gjort för någon av de drivrutiner som finns inbyggt "generiskt" i Windows, tex. HID, så måste en drivrutin till.
Tror inte det finns någon generisk drivrutin för serieportsenheter.
Är det kompatibelt med någonting befintligt så kan en lösning vara att modifiera en INF-fil eller vad som är enklare (åtminstone om man har nyare 64bit Windows, vilket kräver signerade drivrutiner) om man nu har kontroll på mjukvaran i enheten, använda VID/PID ifrån denne enhet.
Du kan inte hitta vilken drivrutin Linux använder med lsmod?
Alla drivrutiner till Windows måste vara signerade och ha korrekt Vendor ID/ProdctID, annars fungerar dom inte.
Du har angett dessa parametrar:
idVendor 0xdead
idProduct 0xbeef
Dom kommer aldrig att fungera i Windows då de är fake (eller temporära)
Du hittar mycket info här: https://docs.microsoft.com/en-us/window ... rs/usbcon/
Det är mycket att ta in.
Har ändrat VID:PID nu. Det är en gammal W7 som körs i VB. När jag kryssar i VB's ruta så enemrerar den, men ingen drivrutin. Har ingen FT232, så valde Silicon Labs CP210. Linux identifierar den som sådan, allt fungerar, men Window låter sig inte luras. Får kanske kopiera samtliga descriptors om det skall funka.
Har provat att hitta den med lsmod, men det är omöjligt att avgöra vilken det är.
Ser nu att det skiljer, CP210 har bara EP1 för data. Skickar väl allt blaj på EP0. Jag tyckte det verkade rörigare när firmware skrevs, så min enhet har EP1 IN för att dumpa blaj och EP2 IN/OUT för data.
Tillägg: Här kom jag givetvis fel. Det är EP0 som används för det som här är skräpdata. Tyvärr är där annat som gör CP210 stökig att efterlikna.
Om enheten stödjer standard USB-CDC behövs inga egna drivrutiner och VID:PID-kombo spelar ingen roll. Välj den generiska CDC-drivern som följer med windows om den inte väljs automatiskt.
Anledningen att t.ex. FTDI och SL kräver egna drivrutiner är för att de inte har CDC-stöd utan egna protokoll för att kunna ha fler funktioner, t.ex. i FTDIs fall att kunna bricka kloner.
Testade att manuellt installera den som com-port. "This device can not start" blir resultatet.
Utan att veta vad det är Windows gnäller över är det lite svårt att komma vidare. Dessa användarvänliga felmeddelanden är ju helt programmerarfientliga, säger absolut noll och intet.
Som det är nu kvitterar enheten request# 20h och 22h på EP0. Linux är nöjd med det, men Windows vill tydligen ha något mer...
If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the Device Descriptor.
For more information, see USB communications device class (or USB CDC) Specification found on the USB DWG website.
I Windows 10 ska det gå att använda andra id än 02:02 så länge enheten är CDC-kompatibel men i tidigare versioner av Windows måste man göra en .INF-fil för att det ska fungera.
KTM: TmCommitTransaction for tx 846b83e8
KTM: Notifying RM of 1 for tx 846b83e8
KTM: TmPrepareTransaction for en 84d482c0
KTM: Notifying RM of 16 for tx 84d60030
KTM: Notifying RM of 2 for tx 846b83e8
KTM: TmPrepareTransaction for en 84d482c0
KTM: Notifying RM of 2 for tx 84d60030
KTM: Notifying RM of 32 for tx 84d60030
KTM: Notifying RM of 2 for tx 846b83e8
KTM: Notifying RM of 4 for tx 846b83e8
KTM: TmCommitTransaction for tx 84d60030
KTM: Notifying RM of 4 for tx 84d60030
KTM: Notifying RM of 64 for tx 84d60030
KTM: TmRollbackEnlistment for tx 84d60030
KTM: TmRollbackEnlistment for tx 846b83e8
KTM: TmRollbackTransaction for tx 84d60030
KTM: TmRollbackEnlistment for tx 84d60030
KTM: Notifying RM of 4 for tx 846b83e8
[Ännu mera i samma stil...]