The PiAnywhere module communicates between a RaspberryPi and a SIMCOM chip in order to execute commands such as texting, GPS location and calling a device. Currently, the devices communicate via USB connection. For the sake of flexibility, we were tasked with creating an alternative method for allowing the devices to communicate – via UART.
To begin our task, we were given 2 discovery boards – simple boards with a few features such as output LEDs, input buttons, and most importantly – UART ports. We started by simply reading and writing to pins – toggling LEDs with button presses through simple functions, pre-scripted by CubeMX. Once we had a basic understanding of PIN manipulation on the boards, we began to test UART. To test UART, two devices had to be connected to the PC and to eachother via the PINs used for UART connection. We instantly ran into an issue when attempting to compile any code at all – the debugger was confused by the presence of two programmable devices. We realised that only one can be connected to the PC at a time – making it a much more tedious process to run a debug test. Through simple commands, we were able to turn on the blue LED on one device when the button on the other was pressed – something. We then relayed it and sent it back to the Pi from the discovery board.
Our next task was more complicated, and involved sending a string between the devices.We began by preparing an array of characters and simply sending it as we did with the button pin. However, after sending it to the other board and having a string comparison ran, the string received did not match what we had sent. We came to the (incorrect) conclusion that the buffer was only 1 character long, and so the string must be sent one character at a time. We wrote a heavily convoluted system:
1) the “receiver” would send an integer representing the location in the string of the character it wanted
2) the “sender” would receive this character, look in the string array and send the relevant character back over the buffer
3) the “receiver” would wait until it receives this character, slots it into an array, then increments the integer it requests and starts the cycle again.
Whilst overcomplicated, and leaving a lot of space for data to be lost in communication, our fun and convoluted system worked. The two discovery boards could finally greet eachother with a kind “hello”.
Next, we will be tackling talking between a discovery board and a Raspberry Pi.