1

hw : lpc1549 eval board with usb hid test firmware ...

endpoint size 64 bytes endpoint intr reads out-report buf and displays len and data in hex ... copies out_report into in_report buf and echoes back with write funct and len

host :

using qt5 , libusb-1.0.19 wingw32 dll and hidapi code

hid test code issues all your api calls (except write and read) sucessfully in linux, win7 and win8.1

test code issues hid_write followed by hid_read and get's data back properly in linux

i am not using the, by hidapi hid_write mandatory flagged Report ID, since the nxp firmware and keil software do not use it (as far as i could figure out) ... my linux sw sends and receives a defined 64 byte pattern or smaller len) correctly and byte [0] is part of this pattern ... out and in byte [0] data is intentionally different and correct received

running the keil hid client under windows succeeds to properly communicate with the lpc1549 firmware, even they only transfer and echo one byte ...

my firmware has the endpoint size changed to 64 bytes (i hope my changes are correct) and the keil hid client works with it in windows so my assumption is that my descriptors are correct ... hopefully

host sw kububtu 14.04 hid_write len = 17, device 17 bytes received, 17 bytes indicated as received ... all seems to work properly

host sw with hidapi in win 8.1 hid_write len = 17 bytes shows up on device with 16 bytes correct and the rest is 0, but the read indicates a received len of 64 ... i issued a write of 17, received 16 correctly, but was indicated as 64 received also win 8.1 throws a blank system32/cmd prompt window up ... why ???

the same hangs on win7 and only a hid_write len = 0 succeeds ... popping the same cmd prompt ... received len = 64, but no data transferred (as it would make sense with len = 0)

i can not single step or breakpoints since qt debugger get's segment fault upon app loading

also i link in my qt app to the hidapi "windows/hid.c" code and it is now part my code

sorry for my rather complicated description

why is a Report ID mandatory if it's not being used ... it would be a waste of one byte and if uint32_t alignment is required it would be a waste of about 7 % of the 64 bytes data

why does the keil hid client written in c++ msvs work correctly with my fw and hidapi not

would the functioning of the keil hid client indicate that my fw and my descriptors and report len are correct

What would cause an empty cmd prompt popping up?

What could i be doing wrong (a whole hidapi based app is correctly communicating with a complete usb based firmware pgm, not just the described test code)?

demonplus
  • 5,613
  • 12
  • 49
  • 68
Ein HexenMeister
  • 49
  • 1
  • 4

2 Answers2

1

after a couple of days a few things got clear

the ReportID seems to be something in windows and on the host side only ... the firmware is not effected on my setup

also what was not to clear initially is that the ReportID is in addition to the max of 64 report bytes

so i create a buffer with 1 + 64 bytes = 65 ... the 1st one is zero since i do not use the ReportID mechanism and the remaining 64 are normally used

the write call data size needs to be therefore 1 + whatever the reportsize is in the usb hid descriptor endpoint side

in linux there is no ReportID on hid what i could see

next : make sure the data length specified in the write call on the host as well on the device match exactly the endpoint size definitions, otherwise no data gets across either direction and your software might hang (wait forever) on the read on the other end

i hope this might help others to get a better pict of the windows end of the hidapi hid_write calls

Ein HexenMeister
  • 49
  • 1
  • 4
1

Alan Ott wrote me the following

http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html#gad14ea48e440cf5066df87cc6488493af

There is always a report ID. You must always send a report ID in HIDAPI, but it will not be sent to the device if the report ID is 0.

Ein HexenMeister
  • 49
  • 1
  • 4