Does anyone know of any available drivers that implement HID Over I2C which would be appropriate for use on an MCU, with permissive licensing (i.e. non-GPL). I have a display with a touch controller that is well supported in operating system, but has a fairly complex driver. (The Linux reference driver is > 3k lines). The controllers appear to implement HID over I2C (developed by Microsoft) to allow for driver standardization for MS Windows 8 and up.
The touch controllers are Atmel mXT640U and mtx1066t2.
I'd also be perfectly happy with a simple driver for the controllers that output touch coordinates - I'm mainly hoping to avoid duplicating something if it already exists, but based on some initial searches, I'm not terribly hopeful.
A hack approach would be to look at the Teensy HID driver. This is intended to make the Teensy be an HID driver over USB look like a normal HID device - it supports Microsoft, Linux, and (if memory serves) MAC.
The original source is on pjrc.com - they make the Teensy.
I'm looking for the host side (I believe the teensy behaves as a HID device). Now that you mention it, I could probably re-purpose some HAL code from the USB HID Host in STM Cube if it came to that, but I'm not immediately familiar with the differences between standard HID and HID over I2C.
I was just wondering if anybody had any knowledge of a ready-to-go "HID over I2C" specific driver for MCU's. The controllers I'm working with appear to have some touch reports that might be fairly easy to get to, so I might just short-cut things and read those.
Teensy HID has the host side source code for all three OS's, with build sequences (makefiles).
Don't get confused by form vs content. In your case, the I2C (vs USB) is a form issue - the form of the input data channel. The content is mutable into whatever information you want for your HID.
What OS? I am assuming Windows or Linux.
The host will be the MCU, with the device being the touchscreen (there is no operating system).
So bare-iron.
I'm not sure how to answer your question. I have written dozens of bare-iron and RTOS device drivers. I would start with polled to understand the peripheral hardware, then an interrupt driver.
A good model is the Unix/Linux: open/close/read/write/ioctl. the simplest is open/read for a read-only device, or open/write for write-only. The next is open/read/write where write does a setup/config on boot and is never called again.
I'm not sure how to answer anything else. What are your specific issues/questions? it seems obvious you want to get (x,y) points from a touchscreen over I2C. Write an I2C driver using the MPU I2C hardware, configure the touchscreen to return the (x,y) coordinates, then start reading the coordinates.
You will need to pay attention to the jitter of the coordinates - print out the coordinates in a series of tests. This will also give you an idea about the sample rate.
Please ponder the above, then come back with some specific questions. you need to read the datasheets for the MPU and touchscreens.
One hint: look at what I2C breakout boards are available from Adafruit and Sparkfun. They allow you to have devices that are easier to understand how the MPU I2C peripherals work. Form vs content.
I assume you have an oscilloscope. If not, get the rigol DS1054Z 50MHz for $350. 4 channels (trust me - get 4 channels). I will not tell you there is a hack to make it into 100 Mhz.... or to just google for the SW tool...
As some other poster has already asked, what OS are you targeting ? Clearly it's not Windows or Linux, so this raises the question, in your target OS do you have a HID abstraction layer ? HID messages are not a big deal, they have a very low complexity, especially for a pointing device. The real big deal is to get reliable data from the touchscreen.
A driver developed for Windows will be fully useless and the one from Linux will be partially useless, as you don't have the same paradigms. If I remember correctly the ATMEL controllers were under a strict NDA for the firmware, usually this is delivered as a BLOB and needs to be loaded, but afterwards getting the X/Y coordinates were not a big deal and one of these controllers had even an interrupt line for events, to make life a bit easier.
But as long as we don't know the OS there is no way of getting really usefull information.
It looks looks bare-iron control loop.
