2018-11-10 01:06 PM
using the second endpoint address looked pretty simple. I open the endpoint, changed my descriptor to use 0x82 instead of 0x81, changed the code so that I send two different reports, one for 0x81 and the other for 0x82 and everything looks simple. But nothing transmits to the PC, I see nothing in the trace.
This goes back to my encoder. For some reason, when I code the endpoints to both use 0x81, the keyboard and encoder don't work. If I put one at 0x81 and the other at 0x82, the one at 0x81 works but not 0x82. If I try just 0x82 standalone, that doesn't work either.
This is pretty basic and I'm hoping someone can point me at my failing. I don't think I have to change the HID report descriptor with an endpoint address change, do I?
I seem to be pretty close now, my encoder works when its address 0x81 and the keyboard works when it is 0x81. If I can get 0x82 endpoint address to work, I'll be dancing in the street.
Thanks,
Jerry
2018-11-10 02:10 PM
Two endpoints mean you've moved to the composite device variant, correct?
Then check the low level code for initializing the 2nd EP: assign buffer memory to it and so on.
Otherwise you want only one endpoint, with report IDs as the 1st byte of each report.
No, the report descriptor does not depend on EP address. But, if you still use multiple collections, you must use report IDs and fix the report descriptor accordingly.
-- pa
2018-11-10 02:21 PM
Pavel, yes, composite device. And I have it working, sort of. I put the reportID in the first byte. I think both the keyboard (reportID 0x01) and encoder(reportID 0x02) are going to the same driver - the encoderdriver. I can see both my keyboard and encoder are enumerated. I can see the encoder being sent and working in the encoder software. I see the keyboard characters being sent to the PC but not typing into any application.
The last thing I was going to try was to use two in endpoints, 0x82 for the keyboard and 0x81 for the encoder. I initialize both endpoints as you suggest and whatever gets sent to 0x82 just doesn't go; nothing in the trace, etc. I looked closely at the init code and it all looks fine. I traced all the transmissions through and they all look fine. Some secret here that eludes me.
But even if I start with bare code from CubeMX and just change the endpoint address to 0x82, a simple change, I have the same issue.
God, this is difficult!
Jerry
2018-11-10 03:39 PM
very difficult... befuddled by twaddle... is my middle name.
There are so many aspects that have to be 100% and 99.9999999999999999999% doesn't cut it.
Some of the complexity is Bill's fault, but now, after 25/30 years, Windows is a fantastic clean fast stable and robust platform, and unix still looks like crap.
Lets not mention Apple, a beautiful pile...
2018-11-11 05:18 PM
I found where the endpoint buffers are allocated, I think, in USBD_LL_Init and I added:
HAL_PCDEx_SetTxFifo(&hpcd_USB_OTG_FS, 2, 0x80) // for the second EP of 0x82.
I then try to send data to the 0x82 end point and the DataIn stage is never called for it. So I am wondering if I have to add something to the class structure???
Any help would be appreciated.
And by the way, I was on the IBM architecture team in the early 80's that gave the DOS operating system to Bill and his company. Admittedly I was a small cog in a very big wheel, a co-op engineer on temporary assignment, but was in some of the meetings. I wish I had moved over there. I still have the little going away present we were given for working on what we called "the little guy" vs the "big guy" which was the IBM DataMaster. Too bad Phil Estridge died in that plane crash and never saw his baby grow up.
Jerry