Detecting all keyboard events via the EDBG serial port?

Log in or register to post comments
Go To Last Post
5 posts / 0 new
Author
Message
rdpoor
rdpoor's picture
Level: New Member
Joined: Wed. Jun 9, 2021
Posts: 19 View posts
#1
Posted by rdpoor: Fri. Jul 2, 2021 - 02:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Not sure which forum is best for this question, but this seems as good as any...)

 

I have an XMEGA Xplained Pro (and a SAME54 Xplained Pro, and SAMD21 Xplained Pro, and ...).  I can write a simple demo program that receives characters from a terminal emulator and the external keyboard via getchar(), etc.  Works great.

 

Now: what if I want to start receiving all changes to the keyboard keys (press and release)?

 

If the keyboard was plugged directly into the XMEGA (or SAME54, or SAMD21, etc) via a USB port, I imagine I could capture the USB HID events.  But the USB interface connects to the EDBG processor, not the main processor.  Is there any way to configure the system to receive all key change events?

 

Tags:

Tools, Evaluation and Development Kits (AVR-related)
Top
meolsen
meolsen's picture
Level: Site Admin
Joined: Wed. Jul 27, 2011
Posts: 4052 View posts
Location: Microchip, Arizona
Posted by meolsen: Fri. Jul 2, 2021 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To capture this, you need a part that can be a USB host (or USB-OTG) that you connect the keyboard to. You then need a USB host stack on the device, and a USB HID stack... Not a small order :) 

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Top
rdpoor
rdpoor's picture
Level: New Member
Joined: Wed. Jun 9, 2021
Posts: 19 View posts
Posted by rdpoor: Fri. Jul 2, 2021 - 02:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Addendum: I realize that I'm not thinking this through very clearly.  The processor has a USART that expects to receive a byte when a key is pressed and nothing more.

 

To accomplish what I'm asking for means that the terminal emulator (or whatever is listening to the keyboard) needs to be put into raw mode and send all change events to the processor.  So one key change event must result in a sequence of bytes being sent to the USART, and there needs to be code in the processor that knows what that sequence of bytes means.

 

But even if my original question was poorly constructed, the question remains: in the world of Xplained Pro / ASF / EDBG interfaces, how might one detect all keyboard events?

 

[Ah - morten - thanks for your response.  It crossed paths while I was writing this...]

Last Edited: Fri. Jul 2, 2021 - 02:26 PM
Top
meolsen
meolsen's picture
Level: Site Admin
Joined: Wed. Jul 27, 2011
Posts: 4052 View posts
Location: Microchip, Arizona
Posted by meolsen: Fri. Jul 2, 2021 - 03:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A CDC/UART is character basert, not scancode basert. So, you either must use an interface or protocol that provides scancodes,  like HID, or do it yourself ( i.e write an application on your pc that fetches the codes, wraps them in some sort of protocol, and sends them to the micro over some sort of interface)

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 22954 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Fri. Jul 2, 2021 - 04:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As Morton outlined, UART is NOT the tool for this. It only manages fully formed characters. Those come from a keyboard only after processing. A UART never knows about key state (up or down). 

 

USB >>MIGHT<< be a different matter, depending on where the keyboard is interpreted and what it transmitted over the USB channel. If keycodes are transmitted, then you can tell more and there MIGHT even be information about when the key is released since this information is needed for the repeating function when a key is held down. IF that repeat is generated in the keyboard, then you are "outta' luck" as they say. If the USB host generates the repeat, then you are "in". It will take a review of keyboard standards to tell what you have to work with.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top