Implementation of 2.4G wireless game remote control based on MSP430 and STM32

It took 7 days, a span of more than two weeks, to debug the remote control of the micro quadcopter. Apart from preparing for two exams, I spent the rest of my time in the dormitory using the Internet to kill time. I have to say that I was not in a good state, and in fact, I felt extremely empty inside.

I had already made the body of the micro quadcopter, and I couldn't wait to test it. I naively thought that the aircraft could be operated without a remote control. In fact, I imagined that I could simply use the development board at hand to simply accelerate and decelerate it. For this purpose, I specially wrote a touch control interface for it. There are only three touch points, one for acceleration, one for deceleration, and one for stop. It is very boring.

Later I found that it was really inconvenient not to have a remote control. I went to the second-hand market on Saturday and bought an airplane remote control for only 5 yuan. The battery inside was not used up and the quality was excellent. This remote control is infrared remote control. I checked the infrared tube with my mobile phone and it can emit light normally. In fact, of course, I hope to directly modify the existing circuit to achieve the most convenient. Things are often not so smooth.

I carefully examined the board. There were a lot of components, and the only chip in the upper right corner had its model number removed. As a young man with little experience in circuits, I naturally had no idea where to start, so I decided to develop a new one. However, in order to match the original case, the appearance and size of the circuit were completely planned based on the original board measured with a ruler.

The remote control board uses the low-power MSP430G2553 main control, and NRF24L01 transmits the remote control signal. For the joystick, to put it bluntly, it is a two-way and a four-way potentiometer. The control command can be obtained through the internal AD sampling of 430, and the circuit is very simple. In fact, the program of the remote control is also quite simple, judging from the functions I need to implement at present. It is only necessary to judge the direction of "up, down, left, right" according to the AD threshold value, and then send it directly to the receiver. The power supply voltage is ASM1117-3.3V, and its voltage drop is measured to be 1V, so it must be powered by 4.3V. In fact, when I bought this broken thing, there were 6 dry batteries left in it. I measured the voltage and it was still 6V, which was enough for me to debug and squander. The implementation code is as follows:

The pin header on the upper left corner of the remote control board is the port I reserved for program debugging and burning. For the sake of convenience, I don't need to make a downloader. I can directly use the LaunchPad of TI's university program to perfectly realize program debugging and burning. The most valuable part of this LaunchPad is its emulator, which is officially sold for only US$8, while the market price of a 430 emulator is 200. Last semester, the school gave me one for the competition, and the Electronic Engineer's Home website gave me another one. The G2553 was the one I cut out from it.

Of course, the most important part is the receiving end. How can the received data be used to control computer games? Because I have made a wired gravity-sensing game remote control before, I tried to use this method, that is, to receive the command through STM32, and then transmit it to my VC host computer through the serial port, and use the host computer program to implement the keyboard tapping command.

         On the VC host computer, I also use the keybd_event event to implement the pressing and releasing of the keys.

That night I tested all the program windows and several small games on the computer and found that there were no problems and they could be controlled. The next day when I wanted to officially test it on Need for Speed, the problem was finally exposed. It didn't work at all! Yes, this VC code can't be controlled in the game. Why can other programs be controlled, but this large game can't be controlled? Later, I checked Baidu and finally found some clues. It seems that the control method used in this kind of game is to directly read the port of the computer keyboard to receive commands. The code I wrote with VC actually just simulated the system keys. There was no solution on the Internet. Later, I asked a program development engineer who I met through the shadow system before. He told me to use Winio to write commands to the keyboard port to reach the driver level command.

Later I found that the effect was the same, and because I had little experience in VC++ programming, I directly operated the port, which brought bad consequences to the computer and caused disorder of the keyboard keys on my laptop. Of course, all this was not a problem for my computer. Thanks to the protection of Powershadow, many problems were solved after restarting.

    I don't believe that it can't be achieved with VC, but this involves the computer's ports and other low-level things. It's too difficult for me to study it, after all, I lack professional knowledge and experience. After consideration, I finally decided to adopt a simpler solution, directly emulating the keyboard's PS/2 protocol through the microcontroller, so that the computer thinks it is a keyboard. In this way, all operations must be valid for any program on the computer. The PS/2 protocol is relatively simple, and is somewhat similar to the serial port. One clock pulse sends one bit of data. As long as you know the keyboard code, you can send it to the computer.

The implementation code for this timing is as follows

The scan code of the keyboard can be obtained by looking up the table, which is divided into make code and break code. For the keyboard, when the key is pressed, the make code is sent to the computer, and when it is released, the break code is sent to the computer. I have also used an oscilloscope to look at the waveform of the keyboard. For this, my junior brother Fa Bo specially brought me a digital oscilloscope. I am very grateful.

         The keyboard protocol has some interesting parts. For example, if you hold down the "up" key and then press the "left" key, only the "left" key is valid. If you release the "left" key, the "up" key is still pressed, but it is invalid. Why can I press the "up" and "right" keys at the same time in the game and they are both valid? Because in the game, as long as the key is received after the "make code" is received without the "break code", the command is executed. This protocol can be implemented by the following code.

I used a development board and a multi-purpose board to build a simple 3.3V to 5V circuit to realize the entire receiving circuit. It looks a bit messy, but it is not lacking in beauty. In order to be able to implement it on my Acer with an I5 processor, of course, a PS/2 to USB interface is required.

Finally, a practical test of Need for Speed

Actually, I seldom play games, but I do know a little bit that in "Need for Speed" in addition to the control keys, you can also press the ALT key to accelerate with liquid nitrogen. Of course, I also took this into consideration. In fact, I have reserved two dedicated ports for buttons on the remote control board to make it possible.