Close

Working with USART and keyboard input

A project log for RC AVR Car with 433MHz Modules

Designing a system where multiple cars can be controlled by keyboard via 433 MHz modules and AVR microcontrollers

Alvi AhmedAlvi Ahmed 11/15/2020 at 19:130 Comments

Results 

   As can be seen by the video, when one of the command keys is pressed the  corresponding led lights up and the TX packet sequence changes to the new command. This is the same with changing receivers where only the receiver number in the sequence changes.

   The sequence output is usually much faster, but for the sake of the  demo it was slowed down.

** Explanation Below **

USART

   USART by itself would not be enough to send
   reliable data transmissions via 433 MHz modules. Especially to 2
   different receivers. 

   The solution is  to send multiple bytes via USART. One byte for syncing, one
   for the receiver serial number (in this case 1 or 2) and the
   command (front, back, left or right).   

   The TX and RX AVRs both have data buffers that are used to
   store the multiple bytes. When a command is chosen on the TX side,
   the buffer is filled with the sync byte, serial byte and command
   byte. Then sent incrementally via TX interrupt. 

   This is the same with the RX AVR, with the RX data buffer being
   filled up incrementally with received bytes. 

   Initially I did have some trouble using this method, especially with
   making sure the AVR on the RX would read the data in the proper
   sequence.  

  To ensure that the data received would be put in the data
   buffer in the right sequence (sync, RX serial number, command), I
   made it so that the RX will only fill up the data buffer if the
   first thing it receives is a sync byte, else reset the RX data
   buffer index to 0 and keep on waiting for the right sequence. 

   While debugging the RX via serial terminal, I have noticed that the
   bytes being received appear in the wrong indexes. This is due to the
   fact that sometimes bytes are sometimes received out of order
   (i.e. command byte read first then stored or serial byte).  

   However, I noticed that whenever a sync byte is the first byte to be received,
   every other byte is in the correct sequence. Therefore that is the
   condition to ensuring a proper data transmission. 

   This may not be the best practice especially if I am planning on
   sending more and more bytes as a packet. Receiving the sync byte
   first may not guarantee that everything else will fall into sequence
   however it is the best solution I have for now. Will develop it more
   later on.

   Also, I am planning on changing the data type sent from char to
   bytes. Char was used purely for debugging purposes. 

   For a char data packet, s represents sync, 1 or 2 represents the
   receiver number and n,f,b,l,r represents neutral, front, back,
   left, and right respectively. This can be seen in the video of the initial test.
  

Pyserial 

   For interfacing the AVR with serial, an FTDI232 board module was used.

   To manage sending commands to TX AVR via keyboard I initially tried
   to use the serial terminal directly by inputting characters
   in it. However,  I have trouble with continuous input, when I hold
   down the button, this does not register in the serial term and treats it
   as 1 press, instead of a continuous press.  

   Therefore I decided to use python and the pyserial and pynput
   modules. This allows me to not only send multiple bytes to serial
   while holding a down button, but also it allows me to input keys
   without having to be in the serial term window due to pynput.  

   Using python also allowed me to later change the input keys from f,
   b, l, r (corresponding to front, back, left, right), to w, a, s and
   d keys.  

Discussions