Fullscreen HTML5Med Res (??MB)HTML4

USB Keyboard and Mouse Adaptor for Micros by Tim Blythman How can you connect a keyboard, or a mouse, to a microcontroller, especially now that most keyboards and mouses have a USB plug? This Adaptor is the answer. It makes it simple to connect a USB keyboard or mouse to any micro! It’s small, easy to build and it won’t break the bank! A keyboard or mouse would be a great addition to your Micromite or Arduino project, especially given how cheap a USB keyboard or mouse is these days. But there hasn’t been an easy way to do it – until now! One of the most challenging parts of designing a project around a microcontroller is providing a way for the user to control it. Touchscreens are great, but let’s face it: an on-screen keyboard is not particularly easy to use, and usually takes up most of the screen. A touchscreen plus a physical keyboard is a superior user-interface solution. And if you can add a mouse cursor, so much the better! Plus, there’s the added bonus that many USB keyboards and mouses are wireless these days. How convenient is that, an input method for your microcontroller project that doesn’t even need to be tethered to it via a cable? And this is a far easier way to achieve that than a home-brew wireless communication system. It’s just ‘plug and play’. We’re using the term ‘mouses’ as the plural for a computer mouse, as opposed to ‘mice’, which usually refers to the mammalian kind, or even ‘meeces’ as you’d find in a comic! The compact unit presented here bridges the gap between a USB keyboard or mouse and a simple microcontroller. The keyboard or mouse plugs into one side (or its tiny dongle, if it’s wireless) and a serial data stream is produced from the other side that any micro would find dead easy to read. There are various settings to adapt the serial data stream to your particular requirements, including a mode which allows detection of practically all keys on a keyboard with just a single byte transmitted for each keypress. Similarly, for a mouse, there are multiple modes to choose from, including one which supports three movement axes and up to five buttons. With USB hardware being cheap and plentiful, it’s now possible to easily and cheaply add these peripherals to your latest project. By the way, we know that you can also do this with a USB host shield or an Arduino Due. But our solution has two big advantages: first, it is cheaper and second, it’s definitely easier for you, and smaller too. How it works The Adaptor has a USB Type-A socket at one end, for plugging in a keyboard or mouse, and a four-way pin header at the other end which has a standard TTL serial port interface and is also used to supply 5V DC power to the board (and keyboard/mouse). Any device that can supply 5V and communicate via serial can therefore Connecting the Adaptor to your computer via a CP2102 USB/ serial module is a simple way to test and configure it. You can see here how compact the unit is when connected to a wireless keyboard or mouse dongle. Practical Electronics | February | 2020 31 make use of a USB keyboard or mouse – wired or wireless! When a keyboard is connected, the keystrokes are converted into data that is sent down the serial transmit line to whatever device is attached. Similarly, when a mouse is plugged in, data is generated on the serial port when you move it or click the buttons. This data is designed to be easy for a microcontroller to interpret and act upon. The USB Keyboard and Mouse Adaptor also has three LEDs to indicate its status. The red LED lights up when 5V power is applied. When a compatible keyboard or mouse is connected, the red LED extinguishes and the green LED illuminates instead. The yellow LED flashes each time keyboard or mouse activity is detected, and it lights up continuously while the unit is being configured. There are also four jumpers on the board. JP1 can be used to enter setup mode (you can also do this via the serial console). JP2 temporarily resets the configuration to default, while JP3 permanently resets it to default upon power-up (ie, writes default settings to Flash). When JP4 is inserted, configuration mode is not available, so the configuration can’t be accidentally changed. Circuit description The circuit, shown in Fig.1, is based on a PIC32MX270 microcontroller (IC1) which is closely related to the chip used for the 28-pin Micromite we have used in so many projects. The only difference between the PIC32MX270 used here and the PIC32MX170 used for the Micromite is that the -270 version has USB support, with pins 21 and 22 able to be used either as general-purpose I/Os (GPIOs) as RB10/RB11 or for USB communication (D+/D–). These are wired directly to the USB Type-A socket (CON2) which is also fed the board’s 5V power supply, to power the keyboard or mouse. The USB version of this chip has two fewer I/O pins than the non-USB version, which are instead used to supply power to the internal USB controller (USB3V3) and for USB bus voltage sensing (VBUS). IC1’s clock source is 16MHz crystal X1, connected between its clock input and output pins (pins 9 and 10), along with 22pF load capacitors. This is required to ensure that the USB communication timings meet the specifications. IC1’s internal PLL (phase-locked loop) multiplies this 16MHz source up to 48MHz for its instruction clock and that is then 32 Features and specifications Simple and low cost Accepts either a USB keyboard or mouse (two different firmware images) Translates key presses or mouse movement/clicks into serial data Just one pin on a micro required to receive either keyboard or mouse data Build two to connect both a keyboard and a mouse up to the same micro Configurable baud rate from 1200 to 115,200 ASCII translation for keyboards with optional codes for special keys VT100 emulation option for keyboards Supports mouses with up to three axes and five buttons Configurable mouse update rate and scaling factor Onboard status LEDs Powered from 5V DC divided by four to get the required 12MHz USB clock. Indicator LEDs LED1-LED3 are driven by GPIO pins RA0, RB15 and RB13 respectively (pins 2, 26 and 24), via 1kΩ current-limiting resistors. Jumper headers JP1-JP4 connect between GPIO pins RB9, 8, 7 and 5 (pins 18-16 and 14) and ground. Internal pull-ups on those pins keep them high when the headers are not shorted, allowing IC1 to detect the presence or absence of the four jumpers. Power supply IC1 requires a low-ESR capacitor between pin 20 (VCAP) and ground, of at least 10µF, to filter its internal 1.8V core supply. To meet the lowESR requirement, we are specifying a 47µF tantalum capacitor, only because we have previously found that lower-value tantalum capacitors do not always meet the ESR requirement of less than 1Ω. That is why we have often used SMD ceramics in this role in the past, as they can be relied upon to have a low ESR, even at 10µF. We have also found ceramics to be more reliable in the long-term. However, in this case, we’ve decided to stick with a through-hole component, hence the use of a tantalum capacitor. Power is fed into the board via the 5V and GND connections of CON3, which also carries the serial data. The supply has to be very close to 5V: ±5% is required by the USB specification, ie, 4.75-5.25V. This supply is used to power the USB keyboard or mouse directly. Fortunately, most keyboards and mouses have modest power requirements, so as long as your supply can provide a couple of hundred milliamps, that should be plenty. The 5V supply is bypassed by a 10µF capacitor, then fed via schottky diode D1 to another 10µF capacitor and regulated to 3.3V by REG1, an MCP1700 low-dropout (LDO) regulator. This has a 10µF output filter capacitor. We’ve tested several such capacitors to ensure that they have an ESR of less than 2Ω as specified in the MCP1700 data sheet. The 3.3V output of REG1 powers IC1 and is fed to its three supply pins: VDD (pin 13), analog VDD (AVDD, pin 28) and USB3V3 (pin 23), which powers the internal USB transceiver. Diode D1 ensures that any high current pulses drawn from the 5V rail do not come from REG1’s input filter capacitor and assists with the stability of the 3.3V rail when transients occur on the 5V rail. The 10kΩ pull-up resistor connected between pin 1 (MCLR), and the 3.3V rail prevents spurious resets of the micro which may occur due to EMI or power-supply transients. MCLR is connected to CON1, the in-circuit serial programming (ICSP) header, along with the 3.3V supply for IC1 and its PGED1 and PGEC1 programming pins. The pinout of IC1 suits a PICkit 3 or 4. Microcontroller IC1 has two internal hardware UARTs (serial ports). These can be mapped to various combinations of pins. In this case, we have set up U1TX on pin 11 (RPB4) and U1RX on pin 12 (RPA4). These go to CON3, the serial/power header, via 1kΩ series resistors. These allow the serial port to work safely with either 5V or 3.3V devices, as well as providing some extra ESD (static electricity) protection. Operating modes There are several different settings which can be changed to suit your requirements, but the most important one for keyboards is the translation mode. It can be set to translate either to 7-bit ASCII, 8-bit ASCII or VT100. Practical Electronics | February | 2020 REG1 MCP1700-3.3 D1 1N5819 +5V A K CON1 ICSP 10k 1 +3.3V 1 GND 3 4 5 6 7 CON3 UART +5V 15 2x 1k 11 12 GND 9 X1 16MHz 22pF IN GND 10 F 10 F 10 10 F OUT 28 13 AVDD VDD RA1/AN1/VREF– VREF+/AN0/RA0 RB 0/AN 2/PGED1 AN9/RB15 RB1/AN3/PGEC1 AN 10/RB 14 AN 11/RB 13 RB2/AN4 A LED1  K A LED2  K A LED3  K 23 1k 2 26 25 1k 24 CON2 USB TYPE A IC1 PIC32MX270F256B 22 -50I/SP PGEC 2/RB 11/D– VBUS/PGEC 3/RB 6 PGED2/RB 10/D+ SOSCI/RB4 TD0/RB 9 SOSCO /RA4 TCK/RB 8 CLK1/RA2 TDI/RB 7 PGED3/RB5 VCAP CLKO/RA3 22pF K A GND 1k VUSB3V3 MCLR RB3/AN5 LEDS MC P1700 +3.3V OUT IN AVSS 27 VSS 19 VSS 8 D– 21 +5V D+ 18 GND 17 16 14 20 47 F TANT SC Keyboard USB and & Mouse Adaptor USB KEYBOARD MOUSE ADAPTOR 20 1 9 JP4 JP3 JP2 JP1 1N5819 A K Fig.1: the circuit for the USB Keyboard and Mouse Adaptor is based around PIC32 microcontroller IC1. It communicates directly with the USB keyboard or mouse plugged into CON2, which is powered from the external 5V supply. The micro translates keystrokes or mouse movements received and sends them to the serial port on pins 2 and 3 of pin header CON3. In 7-bit ASCII mode, key presses will produce standard characters such as lower case or upper case letters, numbers, punctuation, space, Enter, tab, backspace and so on. Other key presses, such as arrow keys, page up/down, print screen and so on are simply ignored. If you have a number pad, numeric codes are produced in this mode, but only when Num Lock is active. Ctrl-letter key combinations also work in 7-bit ASCII mode. For example, Ctrl-C maps to ASCII code 3, which is used by the Micromite and many other systems to stop the currently running program. Control plus the letters A-Z map to ASCII codes 1-26. In 8-bit ASCII mode, all the same 7-bit ASCII characters are still sent but extended characters are also produced from other keypresses. This mode is useful if you need to be able to process presses of the arrow keys, home/end, delete, F-keys, modifier keypresses (eg, Shift, Ctrl, Alt), nonnumeric number pad keys and so on. Rather than invent a new scheme, we’ve implemented the standard Arduino ‘Keyboard Modifiers’ scheme, which you can view on the following web page: http://bit.ly/pe-feb20-mod However, that scheme is far from complete. For example, it does not Practical Electronics | February | 2020 provide any way of knowing when a modifier key such as Shift, Ctrl or Alt is released. So there’s no way to know for sure whether a key was pressed while one of these modifier keys were held down. And some keys on the keyboard, such as print screen and pause/break, are missing from the Arduino modifiers list. So we’ve added to that list – see Table 1. Since the Arduino keyboard modifiers are a subset of ours, they are compatible; your software can merely ignore any codes it doesn’t understand. But the new scheme gives you a much better idea of what keys the user is actually pressing. Note that all the added key up events have the same code as the key down events, plus 16 (hexadecimal 10). VT100 emulation mode goes a step further and translates certain keypresses into commands or ‘escape sequences’ which are compatible with the old-fashioned (1978!) VT100 video terminal. Those commands are still in use today in Unix-based operating systems. They allow for things like moving the cursor around the screen, erasing characters and so on. The Adaptor doesn’t produce all of VT100 escape sequences – just those which can be generated from a keyboard. Another mode setting determines what happens when you press Enter on the keyboard. The unit can either generate a single code: either carriage return (CR, ASCII 13) or line feed (LF, ASCII 10). Or it can generate two codes: CR, then LF. A carriage return typically moves the cursor to the left-hand side of the screen while line feed moves it down one line (and possibly scrolls the display if it’s already at the bottom). If you’re programming the receiving micro yourself, a single CR (the default) or LF code would probably be easier to handle. But you may need to set the unit to produce the CR/LF pair when using it with pre-existing software that expects that combination, such as a ‘dumb terminal’, where this code pair moves the cursor to the start of the next line. Mouse modes There are three options for the serial data format produced when using the Adaptor with a mouse. In all modes, mouse movements are relative, so the receiving device must accumulate the movements to track the mouse cursor position. The default mode is the Microsoft Serial Mouse format. This consists of three bytes of 7-bit data for each 33 update, containing the current mouse button states and the horizontal and vertical movement in pixels since the last update. In this mode, we set the eighth bit of each byte to 1. The data can therefore be decoded as either 8-bit data with one stop bit or 7-bit data with two stop bits, but it is also compatible with systems that expect 7-bit data with one stop bit, as the extra bit simply appears as extra idle time between bytes. The Microsoft Serial Mouse format only supports two buttons and eight bits of movement resolution in each axis, so we developed an eight-bit version that supports three buttons and nine bits of movement resolution. That is the second mouse mode that you can select. The third mode produces humanreadable CSV data, with four fields. The first field is a bitmap of the button states and it supports up to five buttons. The next three fields are three-axis delta values, corresponding to the x, y and z axes. Although not many mouses support a third (z) axis, this data is sent over USB, so we have included it in this mode. Note that most of the mouses that we tried which had mouse wheels did not report mouse wheel rotation using the basic HID protocol, so it’s unlikely that you will be able to detect rotation of the mouse wheel using this Adaptor. The software The software running on microcontroller IC1 is programmed to communicate using the USB ‘Human Input Device’ or HID protocol, the standard used by keyboards and mouses (and also some other devices). This requires the USB interface to run in ‘host mode’, which is different from the ‘device mode’ that you would use for communicating with a computer via its USB port. The HID driver is from Microchip, which comes with several other different USB drivers in their ‘Harmony’ library. This is integrated with their MPLAB X IDE (Integrated Development Environment). The Harmony utility automatically generates the code for low-level USB interfacing, such as detecting and enumerating connected USB devices. We had to add code to activate the USB interface, query it and respond to events that occur. So that allows us to get keystroke data from keyboards and mouse movement/click data from mouses. But there are further difficulties in converting the keystroke codes from 34 a USB keyboard into a useful form of serial data. For the keyboard version of the firmware, the Microchip USB library calls our user function every time a keyboard event occurs. Mostly, these are to report that a key has been pressed or released, but there are also events indicating when a compatible keyboard is attached or detached. We use these events to change the status of the red and green LEDs. Each report from the keyboard contains a list of which keys are currently depressed (up to six) and which combining keys are pressed (shift, Ctrl, Alt). The report needs to be filtered so that keys that are still down in subsequent reports are not detected as pressed again. These events are then decoded. The keystroke events from the keyboard do not neatly map to the ASCII codes, so we need to perform some table lookups based on the mode and shift keys to determine what ASCII code to produce. The basic 7-bit ASCII codes such as letters, numbers and punctuation are handled first. If the software can’t find a match to a 7-bit ASCII code for a keystroke, then it checks whether Enter has been pressed, and if so, it generates either CR, LF or CR/LF, depending on the mode setting as explained above. If the keystroke didn’t correspond to a 7-bit ASCII code or Enter, and if 8-bit extended ASCII mode or VT100 mode are enabled, it then checks to see whether the keystroke should produce one or more codes to suit those schemes. Finally, Num Lock, Caps Lock and Scroll Lock key presses are detected and internal flags set so that their states can be taken into account when decoding subsequent keys. A message is also sent back to the keyboard to update the respective status LEDs. The mouse version of the firmware is somewhat simpler but works similarly. A function is called each time the mouse is moved or a button is clicked (or released) and it then formats and sends the corresponding serial data to the microcontroller. Every time data is sent to the serial port, the yellow LED is switched on and a timer is started. The yellow LED is switched off after it has been on for 50ms, thus giving the effect of flashing briefly for each keystroke or mouse movement/clips. Construction The USB Keyboard and Mouse Adaptor is built on a compact PCB measuring 64mm x 44mm, which is coded 24311181 and is available from the PE Table 1: 8-bit keyboard modifier codes Key Hex code KEY_LEFT_CTRL 0x80 KEY_LEFT_SHIFT 0x81 KEY_LEFT_ALT 0x82 KEY_LEFT_GUI 0x83 KEY_RIGHT_CTRL 0x84 KEY_RIGHT_SHIFT 0x85 KEY_RIGHT_ALT 0x86 KEY_RIGHT_GUI 0x87 KEY_LEFT_CTRL_UP 0x90 * KEY_LEFT_SHIFT_UP 0x91 * KEY_LEFT_ALT_UP 0x92 * KEY_LEFT_GUI_UP 0x93 * KEY_RIGHT_CTRL_UP 0x94 * KEY_RIGHT_SHIFT_UP 0x95 * KEY_RIGHT_ALT_UP 0x96 * KEY_RIGHT_GUI_UP 0x97 * KEY_RETURN 0xB0 KEY_ESC 0xB1 KEY_BACKSPACE 0xB2 KEY_TAB 0xB3 KEY_F1 0xC2 KEY_F2 0xC3 KEY_F3 0xC4 KEY_F4 0xC5 KEY_F5 0xC6 KEY_F6 0xC7 KEY_F7 0xC8 KEY_F8 0xC9 KEY_F9 0xCA KEY_F10 0xCB KEY_F11 0xCC KEY_F12 0xCD KEY_INSERT 0xD1 KEY_HOME 0xD2 KEY_PAGE_UP 0xD3 KEY_DELETE 0xD4 KEY_END 0xD5 KEY_PAGE_DOWN 0xD6 KEY_RIGHT_ARROW 0xD7 KEY_LEFT_ARROW 0xD8 KEY_DOWN_ARROW 0xD9 KEY_UP_ARROW 0xDA KEY_CAPS_LOCK_ON 0xE0 * KEY_CAPS_LOCK_OFF 0xE1 * KEY_SCROLL_LOCK_ON 0xE2 * KEY_SCROLL_LOCK_OFF 0xE3 * KEY_NUM_LOCK_ON 0xE4 * KEY_NUM_LOCK_OFF 0xE5 * KEY_PRINTSCREEN 0xE6 * KEY_PAUSE_BREAK 0xE7 * * added by us Practical Electronics | February | 2020 + 24311181 + X1 5819 +5V 1k 22pF 16MHz CON3 CON1 8111342 124311181 22pF D1 1k GND 1k 1k 10 F + C USB Keyboard & Mouse Interface 1k CON2 ICSP REG1 SILICON CHIP 10k 10 F 10 F IC1 PIC32MX270F250B MCP1700-3.3 1 LED1 K LED2 K LED3 K 4 3 2 1 JP4 47 F TANT + JP3 JP2 JP1 PCB Service. Use the PCB overlay diagram, Fig.2, as a construction guide. The following instructions assume you have the board oriented with the USB socket on the right and the single-row header pins on the left, as shown in Fig.2. There aren’t many options that need to be considered when building this board. If you have a pre-programmed microcontroller, you can omit CON1, the ICSP programming header. It can always be installed later if necessary. Start by fitting the resistors where shown. One is a 10kΩ type, so don’t get it mixed up with the others. If you have any doubt about the markings (they look similar), check the resistances with a multimeter. D1 is the only diode, and it must be installed with its cathode band facing to the right. If you have a low-profile HC49US crystal for X1, install it next, as it will probably sit lower than its accompanying capacitors. Next on the list is the microcontroller, IC1. You can either solder it directly to the board or solder a socket and plug it in. The socket makes it easier to swap the chip but sockets can fail over time due to oxidisation, so it’s up to you whether to use one. Regardless, make sure you solder the part in with the correct orientation, ie, the pin 1 dot/notch towards the top of the board. The tantalum capacitor is next. It is polarised and will have a ‘+’ marked on its body to indicate the positive lead, which should also be longer than the other. Make sure this lead goes into the pad marked with a ‘+’ sign on the PCB. The ceramic capacitors can be fitted next. They are not polarised and can be installed either way. Follow with the three regular electrolytic capacitors. Their longer lead is positive and the stripe on the can indicates the negative lead. The positive lead must be soldered to the pad marked with a ‘+’ sign on the PCB. Note that one of the electrolytic capacitors is oriented differently than the others (the one with the more widely spaced pads). Practical Electronics | February | 2020 A Fig.2: use this PCB overlay diagram and photo as a guide when building the Keyboard and Mouse Adaptor. IC1, D1, LEDs1-3 and the tantalum and aluminium electrolytic capacitors are all polarised, so must be fitted with the orientations shown. You can use a vertical or horizontal pin header for CON1 and CON3 to suit your application; note that CON1 is only required to program IC1 in-circuit. Fit REG1 next. Its legs will need to be cranked outwards and then down to match the PCB footprint. Take care to mount it with the orientation shown in Fig.2. The LEDs can now be installed. You can push them all the way down onto the board as we did, or bend their leads so that they face to the side, depending on how you are planning to use the board. Regardless, make sure that the anode (longer) lead goes to the pad on the left, away from the nearest edge of the board. The various connectors and jumper headers can be mounted next. CON2 will only fit one way, with the socket opening projecting out over the edge of the PCB. Ensure it is flush before soldering its pins. As mentioned earlier, CON1 is only needed if your PIC is not yet programmed. You can use a vertical or right-angle header for both CON1 and CON3. If your crystal is a fullheight type, now would be a good time to solder it in place. If you fitted a socket for IC1 earlier, straighten the IC pins before plugging it into the socket, ensuring that none of the legs fold up under it and that its pin 1 dot/notch lines up with the notch on the socket, as shown in Fig.2. Programming IC1 If you have a pre-programmed PIC, you don’t need to worry about programming it, and you can now proceed to the next section for testing. Note that if you’re using a PICkit 4 to program the chip (which is a bit wider than a PICkit 3), when you plug it into CON1, it may touch the pins of CON3. You should still be able to get a good enough connection to program IC1 despite this. One potential solution would be to install a vertical header for CON1 and a horizontal header for CON3, or leave CON3 off the board until you’ve programmed IC1. Microchip’s free MPLAB X IDE or IPE software can be used with a PICkit 3 or PICkit 4 to load the firmware into the microcontroller. Alternatively, you could build the Microbridge Programmer, described in our May 2018 issue. If you don’t have a USB/Serial converter (or something similar) to use for testing, then you can use a Microbridge, as this can act as a USB/Serial converter as well as a PIC32 programmer. Connect your programmer of choice to CON1, ensuring that the arrowed pin (pin 1) on the programmer aligns with the arrowed pin on the PCB. If using the MPLAB X IPE, choose the PIC32MX270F256B micro from the list, and ensure that the ‘Power target circuit from tool’ option is selected. Open the HEX file (available for download from the February 2020 page of the PE website) and then press the Program button. Make sure you are using the appropriate HEX file depending on whether you are programming the device to operate with a keyboard or mouse; they have a different file name suffix. Check the progress display at the bottom of the window to ensure that the firmware upload is successful. The red LED should then illuminate, indicating that the USB Keyboard and Mouse Adaptor is waiting for a keyboard or mouse to be connected. Testing For initial testing and familiarisation with how the USB Keyboard and Mouse Adaptor works, we recommend that you connect it to a PC using a USB/serial converter; eg, one based on the CP2102 chip. Four wires need to be connected to CON3: 5V, GND and the two serial data lines. We have used arrows to indicate the data flow of the two serial data lines, as TX and RX markings are often ambiguous. Connect the RX line on the USB/ serial adaptor to the pin with the arrow that’s pointing towards the edge of the PCB, and the TX line to the pin with the arrow that’s pointing into the middle of the PCB. Then plug the USB/serial adapter module into a computer. The red LED on the board should light up. 35 Now plug a USB keyboard or mouse (or wireless keyboard/mouse dongle) into the socket on the PCB. After around a second, the red LED should go out and the green LED should turn on. If you do not get the green LED lighting up, then check the construction and component values. Also, make sure that you have loaded the keyboard firmware if you are using a keyboard, and the mouse firmware if you are using a mouse. If all is well, open up the serial terminal program of choice (PuTTY, TeraTerm Pro and the Arduino Serial Monitor all are suitable) and set the baud rate to 9600 (for the keyboard version) or 1200 (for the mouse version). Now type on the keyboard or move the mouse. You should see data appear in the serial console. For the keyboard version, if you press letter keys, you should see the corresponding letter. In the default mouse mode, the data which appears will probably look like gibberish. You may wish to change it to CSV mode, at least temporarily, to get more legible data (the procedure is described below). Note that if you are using the Arduino Serial monitor and the keyboard firmware then you may not get the usual effect of the Backspace key; we found that on our system it produced a black rectangle rather than deleting the previous character. Changing the settings On your computer, use the serial terminal program to send a ‘~’ character to the device. On the Arduino Serial Monitor, you may need to press Enter after typing this, to send the data. The settings menu (Fig.3 for keyboards or Fig.4 for mouses) should appear in the terminal, and the yellow LED on the unit will light up solid to indicate that you are in settings mode. You can change most of the settings with single keystrokes. The action is confirmed on the terminal and the menu is re-displayed with the new settings shown. These settings are not active until the ‘X’ key is pressed to activate them. They can be saved to Flash with the ‘S’ command, in which case they will become active the next time the device restarts and the settings are loaded from Flash. The purpose of most of the settings should be intuitive. If you change the baud rate, you will need to also change your terminal program’s baud rate after pressing ‘X’. The baud rate can be set to pratically any value between 100 and 1,000,000, with a few common values such as 9600, 38,400 and 115,200 available directly from the menu. Serial data is always sent in the standard 8N1 (8 data bits, no parity, 1 stop bit) format. As mentioned earlier, the default baud rate in keyboard mode is 9600, Fig.3: (below left) this is the settings screen of the USB Keyboard and Mouse Adaptor when programmed with the firmware suitable for interfacing with keyboards. If you have set a very low baud rate, it may take a few seconds for this to be displayed. The currently selected parameters are shown below the menu. becuase this can easily be handled by a software serial port and it is more than fast enough for normal typing. The default baud rate in mouse mode is 1200 because that is what is used by default in the Microsoft Serial Mouse protocol, and again, it’s fast enough in most cases. But you could bump it up to 9600 baud or higher, if required for your application. If you change the keyboard mode to VT100 emulation and set your terminal emulator to VT100 mode, you should be able to use the arrow keys on the keyboard to move the cursor around the terminal and type text in various locations. That will confirm that the VT100 mode is operating correctly. Note that instead of sending a ‘~’ character, you can also get into the settings menu by inserting JP1. And if you change the settings and manage to get the device into a weird mode (eg, an unknown baud rate), you can temporarily switch it back to the default settings by inserting JP2. Removing JP2 and power cycling the unit will revert it back to whatever configuration you last saved. To permanently revert the settings back to the default (you can change them again later), place a shorting block on the JP3 header and cycle power to the unit. You can then remove the shorting block. The default configuration values will have been written to Flash. And once you have set up the unit the way you need it, you can place a shorting block on JP4 to prevent accidental configuration changes. Fig.4: (above right) similarly, the settings screen shown when using the Adaptor in mouse mode. The default baud rate in this mode is lower (1200) for compatibility with the Microsoft Serial Mouse protocol, but you can change it if necessary. Options 4, 5 and 6 allow you to select between the three different data formats, with each mode having different capabilities – see Tables 2-4 for details. Mouse-specific settings Besides the three possible modes described above, there are two additional mouse-specific settings: the DPI Divisor (movement scaling factor) and Update Interval. The internal mouse movement pixel count is divided by the DPI Divisor before being sent to the serial port. Some mouses report movement values which overflow some of the data formats, so this setting provides a way of scaling the movement values down to a suitable range. You may also find that specific scaling values make it simpler to handle mouse movements in your micro firmware. The Update Interval is specified in milliseconds. It is the minimum interval between movement updates; button press or release events are reported immediately. The USB interface can operate at up to 125Hz – ie, 8ms between updates. If your application does not need such a high update rate or just can’t 36 Practical Electronics | February | 2020 Table 2: Microsoft Serial Mouse data format Byte 0 Bit 7 1 Bit 6 1 1 2 1 1 0 0 Bit 5 Left button X5 Y5 Bit 4 Right button X4 Y4 Bit 3 Y7 Bit 2 Y6 Bit 1 X7 Bit 0 X6 X3 Y3 X2 Y2 X1 Y1 X0 Y Table 3: 8-bit Mouse data format Byte 0 Bit 7 1 1 2 0 0 Bit 6 Left button X6 Y6 Bit 5 Right button X5 Y5 Bit 4 Middle button X4 Y4 Bit 3 Y8 Bit 2 Y7 Bit 1 X8 Bit 0 X7 X3 Y3 X2 Y2 X1 Y1 X0 Y0 Bit 1 0 Bit 0 0 Table 4: CSV Mouse data format Each entry has the form: Buttons,delta x,delta y,delta z<CR><LF> Where Buttons is an 8-bit value: Bit 7 Left Button Bit 6 Right Button Bit 5 Middle Button Bit 4 Button 4 Bit 3 Button 5 Bit 2 0 These tables show the three data formats available when using the mouse version of the firmware. The Microsoft Serial Mouse data format is identical to that used on the Microsoft Mouse 2.0 (from 1985). How’s that for backward compatibility! handle it, you can use the update rate setting to increase the interval. We found that 100ms (giving 10Hz updates) was adequate for most of our micro-based applications. Connecting it to your target micro When connecting the USB Keyboard and Mouse Adaptor to a micro, you usually only need to run three wires. The serial receive line (next to GND on CON3) does not normally need to be connected. If you’re using an Arduino Uno or similar device, with only one hardware serial port that’s already used for debugging/programming, we suggest that you configure a receive-only software serial port to connect to each Keyboard/Mouse Adaptor. These are usually limited in baud rate because they use too many CPU cycles at higher baud rates. But 9600 baud is fast enough for this application and it will typically only take up a single digital I/O pin. Ensure that the device you are connecting to has a stable 5V supply which can provide enough power to run the connected keyboard or mouse. If your micro was already set up to receive data via a serial terminal, you can use the Keyboard Adaptor in 7-bit ASCII mode and simply wire it up to that terminal. You should not need to make any changes to enter commands. Note that you may not be able to feed data directly into the serial console of a micro board if that serial port is Practical Electronics | February | 2020 permanently wired to a USB/Serial converter chip. That chip may override any data coming from the Adaptor. In that case, you will need to use a separate serial port (hardware-based or software-based) to handle the data. Linux terminal consoles can work in VT100 compatible mode. In the case of small single-board computers such as the Raspberry Pi, the console is often broken out to a physical UART on the GPIO header. So the USB Keyboard and Mouse Adaptor can be directly connected there and set up in VT100 mode, to drive the console directly. Similarly, if you are using the Keyboard Adaptor with a Micromite, you may need to do nothing more than connect it up to the serial console and configure the Adaptor for the correct baud rate and terminal mode. If you are using the Micromite Plus Explore 100 with an SSD1963-based 5-inch (or larger) LCD panel, you will have a complete stand-alone system, with console text displayed on the LCD and updated via the USB keyboard. We suggest you use VT100 mode in this case. The Explore 100 does already have a keyboard connector, but it’s the ancient PS/2 type; suitable keyboards are getting hard to find. Handling mouse and keyboard data in your software In many cases, we expect that you will want to write specific software to interpret key presses, and this will almost certainly be the case if you are using a mouse. You will therefore need to set up one or more serial ports with the correct baud rate, wire up the board(s) to their receive pins, and then periodically check to see whether data has been received on those ports. When data is received, your program will need to decide what action to take. For example, it could compare the received key codes to a list of expected codes and execute a different function depending on which key is pressed. Since the mouse data is more tricky to interpret than keyboard data, we have written a sample Arduino sketch to read and decode the mouse data. You can download it from the PE website, in the same download package as the firmware. If you plan to decode the mouse data yourself, the three data format are explained in Tables 2-4. Parts list – USB Micro Keyboard and Mouse Interface 1 double-sided PCB, 64mm x 44mm, coded 24311181, available from the PE PCB Service 1 5-pin vertical or right-angle header (CON1) 1 USB Type-A socket (CON2) 1 4-pin vertical or right-angle header (CON3) 1 2x4 pin header (JP1-JP4) 1 jumper shunt (JP1 or JP2 or JP3 or JP4) 1 16MHz HC-49/U or HC-49/US crystal (X1) Semiconductors 1 PIC32MX270F256B-50I/SP (IC1), programmed with 2431118K.HEX (for use with a keyboard) or 2431118M.HEX (for use with a mouse) 1 1N5819 schottky diode (D1) 1 3mm red LED (LED1) 1 3mm yellow LED (LED2) 1 3mm green LED (LED3) 1 MCP1700-3.3 3.3V linear regulator, TO-92 package (REG1) Capacitors 3 10µF 16V electrolytic 1 47µF 6V tantalum 2 22pF ceramic Resistors (1/4W or 1/2W 1% metal film) 1 10kΩ 5 1kΩ Reproduced by arrangement with SILICON CHIP magazine 2020. www.siliconchip.com.au 37