Objective Development Forums

Hi,

I am planning to use the HIDKeys project as a data acquisition system. My system will have a MCU to gather data from various data sources and will signal it by pulling the input lines low. After data has been fed, one key configured as "enter" will be pulled low to signal break between two different data points.

Since the external MCU can toggle the switches used much faster than a human being, I wish to know the minimum amount of time for which input pins of the HIDKeys must be pulled low to guarantee that the "keystroke" has been captured and sent back to the PC.

rpg.314 wrote:Hi,

I am planning to use the HIDKeys project as a data acquisition system. My system will have a MCU to gather data from various data sources and will signal it by pulling the input lines low. After data has been fed, one key configured as "enter" will be pulled low to signal break between two different data points.

Since the external MCU can toggle the switches used much faster than a human being, I wish to know the minimum amount of time for which input pins of the HIDKeys must be pulled low to guarantee that the "keystroke" has been captured and sent back to the PC.

If you do two MCUs anyway, why not use some other form of interface between the two (such as SPI, TWI, UART or similar). This should be fairly simple. I have implemented a function to send a string of key-codes with my C64 USB keyboard. This was used for an easter egg, but also intended for doing keyboard macros. Basically, I had a buffer of the next character to be sent, and if the USB stack was ready for an interrupt I would create a report with the next key-code in it.

Also, be aware that the report descriptor for the HIDkeys example only allows a single key-press at the time (if you need more simultaneous keys, you will need to make a different report descriptor).

Your solution is definitely more elegant as it uses existing MCU resources instead of "hacking" the putative keyboard. Modifying the given sources seems nigh-impossible for me.

I don't want to offend anybody, but I seriously think that the code of usbtiny

http://www.xs4all.nl/~dicks/avr/usbtiny/index.html

is quite more readable.

I chose HIDKeys for my initial idea because it seemed to be ideal for one way transfer.One key press at a time is good enough. I suppose the polling interval period of the keyPressed function would be the time required to hold the key down.

Yes, the poll interval time should be long enough.

Regarding code readability: Yes, usbtiny is more readable since it has much less #ifdefs and other optional stuff. But all those features make AVR-USB more powerful. You can implement applications with up to 4 endpoints, such as AVR-CDC. AVR-CDC is for production, not for studying the algorithms.