1

Topic: HIDSharp HIDStream Write throws exception

Hello,

I've trying to communicate with a FTDI FT260 Chip with the HIDSharp Library 2.1.

I can search / select the device, open it and get / set feature reports.

Also I get a HIDstream object back from the Open method. It is of type WinHidStream derived from HIDSharp.Platform.SysHidStream

Reading fails with the timeout as expected, as there is nothing to read yet,

But I'm unable to write a Byte array to the device with HIDStream.Write. I always get "Operation failed early: falscher Parameter" the german part meaning "wrong Parameter".

The following topic is related but the thread starter never answered back, so in my case. "Yes, I'm putting the report ID in the first byte." -->forum.zer7.com/topic/10086/

Here is the code up to this point (PowerShell on Windows 10 Version 1809 x64):

Add-Type -Path .\HidSharp.dll

[HidSharp.HidDevice[]]$devs = [HIDSharp.DeviceList]::Local.GetHidDevices(0x0403,0x6030)

[HIDSharp.HIDStream]$devstream = $devs[0].Open()
$buffer = New-Object Byte[] $devs[0].GetMaxFeatureReportLength()
$buffer[0] = 0xA1
$buffer.Count
$devstream.GetFeature($buffer)

$buffer[0] = 0xA1
$buffer[1] = 0x08
$buffer[2] = 0x04
$devstream.SetFeature($buffer)

$buffer = New-Object Byte[] $devs[0].GetMaxOutputReportLength()
$buffer[0] = 0xD0
$buffer[1] = 0x48
$buffer[2] = 0x06
$buffer[3] = 0x01
$buffer[4] = 0x00
$devstream.Write($buffer)

Has anyone an idea what to look for ?

To verify the device being working at all, I tried the same thing with the HidLibrary dll project, where it works. But I'd like to stay with HIDSharp because here the timeouts are working.

2

Re: HIDSharp HIDStream Write throws exception

What does the report descriptor look like for the device?

3

Re: HIDSharp HIDStream Write throws exception

Hello, the following Reports are supported according to GetReportDescriptor

ReportID (Reports)
--------
     177
     240
     241
     242
     243
     244
     245
     246
     247
     248
     249
     250
     251
     252
     253
     254
     240
     241
     242
     243
     244
     245
     246
     247
     248
     249
     250
     251
     252
     253
     254
     160
     161
     163
     162
     164
     176
     224
     225
     226
     
ReportID (InputReports)
--------
     177
     240
     241
     242
     243
     244
     245
     246
     247
     248
     249
     250
     251
     252
     253
     254
     
ReportID (OutputReports)
--------
     240
     241
     242
     243
     244
     245
     246
     247
     248
     249
     250
     251
     252
     253
     254
     
ReportID (FeatureReports)
--------
     160
     161
     163
     162
     164
     176
     224
     225
     226

0xC2 (194) is missing and the dll is working as expected I guess. But I'm not sure what to make of it as it works with the other dll.

If I can help with more information please tell me.

4

Re: HIDSharp HIDStream Write throws exception

Wow, that's a ton of Report IDs. What an unusual chip! Out of curiosity, what does GetRawReportDescriptor() return?

Based on the documentation of the FT260, that list appears to lack quite a few of the Report IDs that should exist. It's possible it is not reconstructing the report descriptor correctly (on Mac and Linux, it is able to retrieve it, but on Windows, it must reconstruct it as there is no API to get it directly). That said, the report descriptor should not affect your ability to write.

Are you using HidLibrary on the same PC? If not, is it possible to configure the FTDI chip to support I2C or UART? I wonder if Windows is caching an old HID descriptor.

5

Re: HIDSharp HIDStream Write throws exception

Ok, lets start with the good news: it is working now, the solution being the almost simplest. The device actually creates two HID devices (at least when both UART and I²C are activated I guess) and Hidlibrary sorts them so that the I²C is index 0 and yours sorts them differently, so that the index 0 is for the UART part.

Both (Sub)devices only implement the reports needed for them and not for the other. To tell them apart is possible by the path, the I²C one containing MI_01 instead of MI_00 for the UART part. Also I could check if the correct report is supported, this might be the more robust approach.

It was for searching which class implements GetRawReportDescriptor that I happened to find the second device in my $devs variable wink

But for completeness the answers to your questions: The result of GetRawReportDescriptor:

GetRawReportDescriptor
6
0
255
9
1
161
2
133
208
9
1
21
0
37
255
53
0
69
0
101
0
85
0
117
8
149
7
129
2
37
1
69
1
117
1
150
192
1
129
3
133
209
9
1
37
255
69
0
117
8
149
11
129
2
37
1
69
1
117
1
150
160
1
129
3
133
210
9
1
37
255
69
0
117
8
149
15
129
2
37
1
69
1
117
1
150
128
1
129
3
133
211
9
1
37
255
69
0
117
8
149
19
129
2
37
1
69
1
117
1
150
96
1
129
3
133
212
9
1
37
255
69
0
117
8
149
23
129
2
37
1
69
1
117
1
150
64
1
129
3
133
213
9
1
37
255
69
0
117
8
149
27
129
2
37
1
69
1
117
1
150
32
1
129
3
133
214
9
1
37
255
69
0
117
8
149
31
129
2
37
1
69
1
117
1
150
0
1
129
3
133
215
9
1
37
255
69
0
117
8
149
35
129
2
37
1
69
1
117
1
149
224
129
3
133
216
9
1
37
255
69
0
117
8
149
39
129
2
37
1
69
1
117
1
149
192
129
3
133
217
9
1
37
255
69
0
117
8
149
43
129
2
37
1
69
1
117
1
149
160
129
3
133
218
9
1
37
255
69
0
117
8
149
47
129
2
37
1
69
1
117
1
149
128
129
3
133
219
9
1
37
255
69
0
117
8
149
51
129
2
37
1
69
1
117
1
149
96
129
3
133
220
9
1
37
255
69
0
117
8
149
55
129
2
37
1
69
1
117
1
149
64
129
3
133
221
9
1
37
255
69
0
117
8
149
59
129
2
37
1
69
1
117
1
149
32
129
3
133
222
9
1
37
255
69
0
117
8
149
63
129
2
133
194
9
58
149
4
145
2
37
1
69
1
117
1
150
216
1
145
3
133
195
9
1
37
255
69
0
117
8
149
63
145
2
133
208
9
1
149
7
145
2
37
1
69
1
117
1
150
192
1
145
3
133
209
9
1
37
255
69
0
117
8
149
11
145
2
37
1
69
1
117
1
150
160
1
145
3
133
210
9
1
37
255
69
0
117
8
149
15
145
2
37
1
69
1
117
1
150
128
1
145
3
133
211
9
1
37
255
69
0
117
8
149
19
145
2
37
1
69
1
117
1
150
96
1
145
3
133
212
9
1
37
255
69
0
117
8
149
23
145
2
37
1
69
1
117
1
150
64
1
145
3
133
213
9
1
37
255
69
0
117
8
149
27
145
2
37
1
69
1
117
1
150
32
1
145
3
133
214
9
1
37
255
69
0
117
8
149
31
145
2
37
1
69
1
117
1
150
0
1
145
3
133
215
9
1
37
255
69
0
117
8
149
35
145
2
37
1
69
1
117
1
149
224
145
3
133
216
9
1
37
255
69
0
117
8
149
39
145
2
37
1
69
1
117
1
149
192
145
3
133
217
9
1
37
255
69
0
117
8
149
43
145
2
37
1
69
1
117
1
149
160
145
3
133
218
9
1
37
255
69
0
117
8
149
47
145
2
37
1
69
1
117
1
149
128
145
3
133
219
9
1
37
255
69
0
117
8
149
51
145
2
37
1
69
1
117
1
149
96
145
3
133
220
9
1
37
255
69
0
117
8
149
55
145
2
37
1
69
1
117
1
149
64
145
3
133
221
9
1
37
255
69
0
117
8
149
59
145
2
37
1
69
1
117
1
149
32
145
3
133
222
9
1
37
255
69
0
117
8
149
63
145
2
133
160
9
1
149
1
177
2
9
58
149
62
177
2
133
161
9
58
149
63
177
2
133
163
9
58
177
2
133
162
9
58
177
2
133
164
9
58
177
2
133
176
9
58
149
60
177
2
37
1
69
1
117
1
149
24
177
3
133
192
9
58
37
255
69
0
117
8
149
60
177
2
37
1
69
1
117
1
149
24
177
3
133
193
9
58
37
255
69
0
117
8
149
60
177
2
37
1
69
1
117
1
149
24
177
3
193
0

On the PCB I'm using you can choose between UART and / or I²C but I never changed from the original setting with both devices active.

And yes I'm using hidlibrary on the same PC.

As a first result I now have a function to list all present I²C devices which works perfectly.

In summary the problem was in front of the PC, not in it's parts. wink Thanks for the help and the fast response(es).