PIC USB keypad troubles with Qseven boards ONLY

[cafut]

Basing upon the CCS compiler's kbd/mouse(2) examples, I've built a firmware for a customized 32-keys keyboard with a PIC18F13K50 .

After some modification (removing the mouse code, making it bootable), I got it working under almost all circumstances: it works perfect with windows XP/7, DOS, the BIOS setup on all PCs and boards we found, with one exception: the Qseven platform it is meant for (ATOM Z5xx with US15W chip set). No keys with DOS, nor with the BIOS setup. With WinCE (the target platform) IT WORKS - but ONLY unless it is the ONLY USB device plugged in (standard keyboards DO work)!

I successfully* removed some 'incompatibilites' to 'standard' USB keyboards (which ALL work with the Qseven!): I dropped the status-LED OUT-endpoint and made it a low-speed USB device - both with no effect (* 'successfully': still all works fine with XP/7/DOS/Setup on other platforms!)

The one HUGE remaining difference I can see now, is the two-interface structure of 'standard' keyboards, one bootable and the second one non-bootable. I would try to copy this structure if only I knew how to handle them / what to do with the two interfaces.

I know this is VERY special and I am trying to work it out with the board manufacturer, but my hopes are getting lower and lower.

Now, is there ANYONE around who experienced similar problems OR has a clue, some hints? ANY idea would be greatly appreciated!

[temtronic]

I have run into this problem before in making custom keyboards and know the frustrations you're going through.
Though I don't have any first hand knowledege of the Qseven stuff here's what I'd do.
Take a known good keyboard hooked up to the Qseven. Attach a 'sniffer' or data recoder in between,it MUST be bidirectional ! Bootup and verify it works, especially the 32 keys of interest. Save the sniffed data.
Repeat for another known good keyboard.
Repeat the proceedure for your '32 key' keyboard PIC.
Be sure to use the exact same sequence of keypresses !

Now view or printout the data, good vs. bad and see what is different. Perhaps during the POST, the Qseven ,when it sees the keyboard records something 'special'.Since it's only your 'keyboard' that fails it should be evident why once you look at the data.

It should only take a day to figure it all out as you only have 1 'problem' keyboard.

[temtronic]

Had a quick, brief look at those Qseven boards..it appears they've cut their own BIOS code so I'm NOT surprised you're having a problem especially with WinCE.
I'd ask them if ANY version of WinCE will properly work or if it has to be 'their' version. Several manufacturers force 'custom' versions of the OS for their motherboards one reason why 'clones' are better in most cases unless you have direct access to the sourcecode.

[cafut]

Thank you so much temtronic!

Maybe we could figure this out (maybe including some 'sniffing' sessions) together with the board manufacturer. They do have BIOS programmers (persons rather than devices I hope!) and seem to be willing to co-operate.

I know that I am desperately lacking some in-depth USB knowledge, but considering the USB/HID boot interface descriptor specs I have no idea about the nature of "issuing a change protocol", nor whether/how this will be handled by the CCS PIC-USB framework.

I have tried to copy that double-interface structure although I do not know what to do with it. No matter what I do with that 2nd endpoint: just define it (a second non-boot interface with a second endpoint, without actually doing anything with it) - OR simply copying the key packets onto that second endpoint: nothing changes. XP/7/DOS/BIOS - they all work fine with our keypad, 'ALMOST everywhere' (probably just ignoring the non-boot interface).

Yet NO keys on the Qseven.

One thing I have noticed is that after switching to the double-interface version, USBVIEW.EXE no longer displays the endpoint directions ("IN"), although the bEndpointAddress value (eg. 0x81) makes it very clear that this must be an IN endpoint (yet it still works fine with XP/7, DOS, Bios on all other platforms I tried!) Strange.

Those USBVIEW IN-tags could be seen with the single-interface version as well as on any "standard" USB keyboard.

I have noticed that the HID Descriptor wDescriptorLength of the 2nd (non-boot) interface varies widely on different 'known good' keyboards I have tried (0x32..0x98). Strange II.

Maybe I am missing some important points about that USB/HID boot interface descriptor specs OR there is some silent agreement among keyboard and BIOS programmers not aware to the public (or both)? I fear I am getting paranoid.

AFAIK my boot interface report descriptor fully complies to Appendix B.1 of http://www.usb.org/developers/devclass_docs/HID1_11.pdf

[Darren Rook]

Sorry if I missed the answer to this question, above, but:

Do off-the-shelf USB keyboards work with Qseven?
_________________
I came, I saw, I compiled.

[cafut]

Hi Darren: Yes, consumer keyboards DO work with the Qseven bored, without any restrictions. In fact THAT'S what causing me headache. (Tried about ten different USB keyboards.)

BTW, the "IN"-tag issue is resolved. Nasty Chucklehead was using different versions of USBview.exe

Qseven still troublesome. Now waiting for support (from board manufacturer - any other still welcome!)

Thank you anyway!

[temtronic]

Since you already have good working keyboards, just mimic or copy the datastream that they are producing.You'll have to use some form of datalogger/capture unit to do so, but that will show you exactly the format,sequence,etc. that is required.
Either use an 'inline' logging device, or cut PC code to 'listen' to the data goint to and from the USB port the keyboard is attached to.
It might take an hour or two, but by getting the data from say 2 or 3 'good' keyboards and comparing it to the same keypresses your 32 key device makes will quickly show WHAT is different.This simple, side by side comparison is easy and quick.
As for the 'details' of Useless Serial Bus devices, I leave that to others. I have no time to waste on nondeterministic protocols that can not be used in realtime control applications.