3.7 KiB
USB Keyboard over RS-485
The project is to have a device that appears to a computer as a USB keyboard, but it receives it’s key presses from another computer via an RS-485 multidrop bus. It will use the Syote library for communications, and as there can be multiple devices on the bus, a single gateway controller can service multiple such keyboards, making it a nice option for an IPMI like solution. It is also expected that GPIOs of the device can be used to control the power switches, along with observing various LEDs. As most microcontrollers have an ADC, it could theoretically support beeps from the PC speaker.
Devices
These are the device that are under conideration for the project:
STM32F103C8
64KB flash, but the devices I have seem to have 128KB flash. They appear to be BluePill clones. Green LED is GPIOC Pin 13.
Currently looking at USART3, B0 for DE, B1 for RE.
TIM2_CH4 can be mapped to PB11 (UART3 RX). This is to do break detection. Table 45 says TIM2_REMAP, either full or partial (value 1x).
Table 5 pin definitions of stm32f103c8.pdf (all can be remapped)
USART has idle line detction
USART1_TX PA9 5v tollerant USART1_RX PA10 5v tollerant USART2_TX PA2 NOT 5v tollerant USART2_RX PA3 NOT 5v tollerant USART3_TX PB10 5v tollerant USART3_RX PB11 5v tollerant
flash: 0/x boot loader (an2606) pattern 1: 1/0 embedded sram: 1/1 top jumper BOOT0/44 bottom jumper BOOT1/PB2/20
MAX485
This requires a 5V VCC. There is a 3.3V part called the MAX3485, but as often micros can be 5V tollerant, and the MAX485 is fine w/ logic levels down to 2V, this should be fine.
D - Driver DE Driver enable (high enable) DI Driver input R - Receiver RO Receiver output /RE Receiver enable (low enable)
Note: Some pre-assembled devices have pull up resistors on the DE/RE lines. This is a BAD design as it means that it will be driving the bus by default. This can often be fixed by removing the pull-up resistors.
Programming
Command to program the HID device:
sudo openocd -f interface/ftdi/digilent-hs1.cfg -f interface/ftdi/swd-resistor-hack.cfg -f target/stm32f1x.cfg -c "init" -c "reset init" -c "program build/rs485hid.elf verify reset exit"
Keying
There are two keys involved, the initiator key, which is made w/ the Makefile, by issuing the command:
bmake hid_priv_key
Which creates the private key in the file .hid_priv_key. This is
needed for the build process.
The other key is the device key, which is generated by the USB HID
device at first start. The device will “type” the hex encoded public
key when the A7 pin is grounded. This public key should be saved to
a file, which can then be passed to the lora.py initiator program
via the -p argument.
Low level info
Definitions: Mark: logic 1, B > A Space: logic 0, B < A
Idle state: Mark
Async comms: Space | 8 bits LSB, 0 through 7 | Mark
As the start of the sequence begins w/ a space, it requires that the line be “idle” (aka mark) before things start, so any non-mark state before TX starts should consider the line as busy, and not be ready to transmit. Additional info on this is in the Wiring section.
Wiring
For long runs, it is recommend to have terminating resistors w/ a value of 120 Ω, the impedence of twisted pair, to prevent reflections.
Wikipedia recommends to add biasing resistors to help w/ noise immunity, BUT, care must be done when using them. When the bus is idle, make sure that the receivers are outputing a hi value (aka mark), that is 5V if you’re using a MAX485 converter. If it is 0V, then the receiver will not work. I have seen in some cases where grounding A w/ a 2.2k Ω resistor makes things work.