While looking at the HID device descriptor problem with the K8055 in the other thread, I actually resurrected the original PIC16C745, that came with my K8055 (kind of … picture is below).
I immediately noticed that the changes, I am currently making to the HID protocol in the K8055 Open Source Project, make our client library no longer talk to an original K8055. Not being able to talk to an original K8055 is not good, so I am looking for a way to clearly distinguish a modified board, talking the new protocol, from an original one, talking the old HID protocol.
Velleman used product IDs 0x5500 to 0x5503 for the four possible board addresses of the K8055. Am I guessing right that the 0x55… is somehow connected to it being a K8055? And am I further guessing right that there are no Velleman products using IDs 0x5504 to 0x55FF?
If those guesses are right, I think the best way to do this would be to use product IDs 0x55F0 and higher (or some other range within 0x55…) for user modified boards. The client DLL would then when asked for board 1 try to open the original ID 0x5500 first. If that fails, it would try to open 0x55F0. Depending on which ID can be opened, it would know which protocol version to talk.
OK, here’s the picture of the PIC16C745 on life support:
It works, for some definition of “works”. It connects like a real K8055 and the original K8055_Demo can control the LED.
It is a badly butchered setup. It only has LD8, the USB connection and SK5,SK6. The values for C4, C5 and C6 are off. However, it flashes properly on successful start and can communicate with my laptop. All inputs (except for RA2, RA3) are floating … I know, don’t do that … I just wanted to check some HID protocol stuff, so I didn’t care. If I decide to convert this into a more permanent setup for protocol compatibility testing, I promise to give it more and better peripheral circuitry.