The firmware
Let’s deal now with the description of the program that will be loaded on the ATmega32U4. The sketch will have to deal with the management of the USB, serial and I²C communication, by understanding the commands read and by putting them into practice, by adequately commanding the driver’s inputs. The sketch considers then a listening routine on the three communication ports, while waiting for the data to arrive; luckily the small ATmega32U4 has two UART modules and a I²C hardware port, and they are perfect for our project. The main serial (Serial) port depends on the USB module and from the software point of view it behaves exactly like Arduino Uno’s serial port, thus the data reception of the on this port may be obtained by means of the Serial.available() instruction, that refers the number of characters found on the reading buffer. In this mode, OMC21 can be controlled via a PC or any other peripheral having a USB host. This serial communication’s usage declaration is made by means of the Serial.begin(9600) code line, with 9600 being the communication speed (which can be modified, depending on your needs). We used 9600 as a default setting since it is the most used speed; if you want to reduce the commands’ reading time, you may increase this value up to a maximum of 115.200 bps. If there are characters in the UART module’s buffer, they are read by means of the Serial.readBytes(inByte, maxinByte) instruction, that enables the reading of a predetermined amount of bytes in a prearranged time interval. The communication protocol we thought to use takes into account that four bytes will be used, the first one being the ‘$’ character only, which is needed to recognize the beginning of the sequence. Along with the number of characters sent, it represents the accuracy control when reading the command. Once the reading of the four bytes has ended, there is a check to verify if there are more; in any case the buffer is emptied. It may happen that by sending commands some unnecessary characters are added, such as an end of line or a return; in our application those are ignored and deleted from the buffer. The three remaining bytes (after the ‘$’ character) represent the controller’s commands: the second byte contains information concerning the operating mode (brake or standby) and on the motors’ direction of travel, while the third and fourth bytes contain information concerning speed, for the motors 1 and 2 respectively. In this way, by sending a four bytes sequence, both motors can be commanded at the same time.
Byte2 contains information concerning both the operating mode and the direction of travel. Byte2’s fifth bit, if set at one, enables the request of the power supply reading; this is the only case in which the bidirectional serial communication is needed, otherwise just the line concerning the data sent to the controller is enough.
In Listing 1 you will find the sketch’s code lines that develop the described functions. If you want to command the controller by means of the microcontroller’s serial port, you will have to use the second serial port (Serial1) of the ATmega32U4 microcontroller, whose TX and RX pins are available in the CN1 connector.
