Anyone here knows proper working of a Keyboard. What I know is that there are make and break code for every key. However where does the scan code is : D+ or D- PIN of USB ?
I want to understand this in terms of interfacing it to some MCU not MPU.
> Anyone here knows proper working of a Keyboard. What I know is that > there are make and break code for every key. However where does the scan > code is : D+ or D- PIN of USB ?
> I want to understand this in terms of interfacing it to some MCU not MPU.
You are mixing up two things (or rather several things).
The original keyboard i/f was a simple 2 wire i2c like interface. It later aquired bidirectional capabilities.
The usb device is a phy layer with a software stack (USB HID, storage, bulk etc). Keboard scan codes have to be picked up by he software stack (USB HID) and sent over the phy layer. D+ and D- act as balanced differential lines and carry data.
On Wed, Apr 4, 2012 at 1:24 PM, Surendra Kumar <p.surendraku...@gmail.com>wrote:
> helped me in interfacing a At Keyboard to the 8051 a decade ago
> Regards, > Surendrakumar
> On 4 April 2012 11:21, chetan patil <chtpa...@gmail.com> wrote:
>> Hi,
>> Anyone here knows proper working of a Keyboard. What I know is that >> there are make and break code for every key. However where does the scan >> code is : D+ or D- PIN of USB ?
>> I want to understand this in terms of interfacing it to some MCU not MPU.
On Wed, Apr 4, 2012 at 3:06 PM, J T Dsouza <jtd1...@gmail.com> wrote:
> You are mixing up two things (or rather several things). > The original keyboard i/f was a simple 2 wire i2c like interface. It later > aquired bidirectional capabilities. > The usb device is a phy layer with a software stack (USB HID, storage, > bulk etc). Keboard scan codes have to be picked up by he software stack > (USB HID) and sent over the phy layer. D+ and D- act as balanced > differential lines and carry data.
So you mean to say standalone MCU can't capture USB Keyboard scan codes and store or display it ?
> On Wed, Apr 4, 2012 at 1:24 PM, Surendra Kumar <p.surendraku...@gmail.com>wrote:
The web link referred by Surendra Kumar is excellent link to understand how PC AT keyboards used to work with PS/2 interface. PS/2 keyboards have normally 80C51 compatible CPU inside which communicates with PC CPU. This CPU generates scan codes and sends them to BIOS of PC which interprets the keys correctly. With USB keyboard, same legacy scan codes are used, but physical layer is USB. Keyboard gets enumerated as HID class device to PC. So to interface PC USB keyboard to your MCU, your MCU needs to do whatever PC does with its USB host stack for HID class. You will need to select a MCU already having a USB host with HID class device driver. Microchip has one demo board with similar application and quite a few devices to select from. Visit www.microchip.com/usb for further info.
> On Wed, Apr 4, 2012 at 3:06 PM, J T Dsouza <jtd1...@gmail.com > <mailto:jtd1...@gmail.com>> wrote:
> You are mixing up two things (or rather several things). > The original keyboard i/f was a simple 2 wire i2c like interface. > It later aquired bidirectional capabilities. > The usb device is a phy layer with a software stack (USB HID, > storage, bulk etc). Keboard scan codes have to be picked up by he > software stack (USB HID) and sent over the phy layer. D+ and D- > act as balanced differential lines and carry data.
> So you mean to say standalone MCU can't capture USB Keyboard scan > codes and store or display it ?
> On Wed, Apr 4, 2012 at 1:24 PM, Surendra Kumar > <p.surendraku...@gmail.com <mailto:p.surendraku...@gmail.com>> wrote:
On Wed, Apr 4, 2012 at 3:11 PM, chetan patil <chtpa...@gmail.com> wrote: > Hi,
> On Wed, Apr 4, 2012 at 3:06 PM, J T Dsouza <jtd1...@gmail.com> wrote:
>> You are mixing up two things (or rather several things). >> The original keyboard i/f was a simple 2 wire i2c like interface. It >> later aquired bidirectional capabilities. >> The usb device is a phy layer with a software stack (USB HID, storage, >> bulk etc). Keboard scan codes have to be picked up by he software stack >> (USB HID) and sent over the phy layer. D+ and D- act as balanced >> differential lines and carry data.
> So you mean to say standalone MCU can't capture USB Keyboard scan codes > and store or display it ?
Not without usb hid software and usb hardware OR bitbanged io pretending to be usb hardware. search for avr usb bit banging.
>> On Wed, Apr 4, 2012 at 1:24 PM, Surendra Kumar <p.surendraku...@gmail.com >> > wrote:
1) USB female port is connected to MCU via Rx & Tx at D+ & D- 2) Keyboards USB Male port gets attached to above USB Female connector.
Now if I press a key on Keyboard then a make and brake code will be formed and can't the MCU just use a loop to scan the code and gather the make brake code and with a look up table send that to lets say a LCD display ?
After all its a serial communication.
On Wed, Apr 4, 2012 at 5:09 PM, J T Dsouza <jtd1...@gmail.com> wrote:
> On Wed, Apr 4, 2012 at 3:11 PM, chetan patil <chtpa...@gmail.com> wrote:
>> Hi,
>> On Wed, Apr 4, 2012 at 3:06 PM, J T Dsouza <jtd1...@gmail.com> wrote:
>>> You are mixing up two things (or rather several things). >>> The original keyboard i/f was a simple 2 wire i2c like interface. It >>> later aquired bidirectional capabilities. >>> The usb device is a phy layer with a software stack (USB HID, storage, >>> bulk etc). Keboard scan codes have to be picked up by he software stack >>> (USB HID) and sent over the phy layer. D+ and D- act as balanced >>> differential lines and carry data.
>> So you mean to say standalone MCU can't capture USB Keyboard scan codes >> and store or display it ?
> Not without usb hid software and usb hardware OR bitbanged io pretending > to be usb hardware. search for avr usb bit banging.
>>> On Wed, Apr 4, 2012 at 1:24 PM, Surendra Kumar < >>> p.surendraku...@gmail.com> wrote:
USB world is not so easy as you think. Because USB offers plug and play features, companies have agreed on protocol stack and device drivers long time back and all manufacturers are adhering to that. So unless you implement a USB host driver, you will not get from third party keypad, which faithfully adheres to HID class implementation which works seamlessly with any make PC motherboard.
> 1) USB female port is connected to MCU via Rx & Tx at D+ & D- > 2) Keyboards USB Male port gets attached to above USB Female connector.
> Now if I press a key on Keyboard then a make and brake code will be > formed and can't the > MCU just use a loop to scan the code and gather the make brake code > and with a look up table > send that to lets say a LCD display ?
> After all its a serial communication.
> On Wed, Apr 4, 2012 at 5:09 PM, J T Dsouza <jtd1...@gmail.com > <mailto:jtd1...@gmail.com>> wrote:
> On Wed, Apr 4, 2012 at 3:11 PM, chetan patil <chtpa...@gmail.com > <mailto:chtpa...@gmail.com>> wrote:
> Hi,
> On Wed, Apr 4, 2012 at 3:06 PM, J T Dsouza <jtd1...@gmail.com > <mailto:jtd1...@gmail.com>> wrote:
> You are mixing up two things (or rather several things). > The original keyboard i/f was a simple 2 wire i2c like > interface. It later aquired bidirectional capabilities. > The usb device is a phy layer with a software stack (USB > HID, storage, bulk etc). Keboard scan codes have to be > picked up by he software stack (USB HID) and sent over the > phy layer. D+ and D- act as balanced differential lines > and carry data.
> So you mean to say standalone MCU can't capture USB Keyboard > scan codes and store or display it ?
> Not without usb hid software and usb hardware OR bitbanged io > pretending to be usb hardware. search for avr usb bit banging.
> On Wed, Apr 4, 2012 at 1:24 PM, Surendra Kumar > <p.surendraku...@gmail.com > <mailto:p.surendraku...@gmail.com>> wrote:
On Wed, Apr 4, 2012 at 6:27 PM, chetan patil <chtpa...@gmail.com> wrote: > Hi,
> Considering the scenario :
> 1) USB female port is connected to MCU via Rx & Tx at D+ & D- > 2) Keyboards USB Male port gets attached to above USB Female connector.
> Now if I press a key on Keyboard then a make and brake code will be formed > and can't the > MCU just use a loop to scan the code and gather the make brake code and > with a look up table > send that to lets say a LCD display ?
> After all its a serial communication.
Why dont you try out and tell us the results. As I said in my previous mail, all you need is a little bit banging on the D+D- to simulate a USB HID endpoint.
Also trim the irrelevant portions of your mail and do not top or bottom post.
