With two discovery boards communicating via huart, we were ready to complicate things and talk between two different kinds of board – a discovery and a Raspberry Pi. With two discovery boards communicating via huart, we were ready to complicate things and talk between two different kinds of board – a discovery and a Raspberry Pi. This task seemed simple, and involved – once again – sending “hello” between two boards. The difference now was that we must send from a discovery board to a Raspberry Pi. We modularized our current approach – writing a “sendChar” function for sending a character, and a “sendStr” function which executed “sendChar” for every character in a string. We set up our pi to read our “hellos”, told our discovery board to send “hello” and ran.
Unfortunately, it didn’t act as expected. To debug, we stepped through our “sending” code one line at a time and to our surprise, “hello” was sent completely fine to the board. The issue was not in our approach, but rather the fact we had no delay in the sending of characters. We created “artificial delays” – incredibly pointless, inefficient chunks of code that would halt the program for a period of time, and were annoying to write. We did this using a large for loop. Even with this delay, however, we were still reading nonsense from our discovery board. We swapped out our “custom” delay for the on-board HAL_Delay function, and suddenly everything worked fine.
Next, we had to swap – receive a string from the Raspberry Pi and check it on the discovery board. This led to a discovery that rendered all of our work for the past few days completely redundant. Due to the fact we had to write our code for the Pi in python, we decided to try send a string over the huart port, read it and see what happens. It turned out we were completely wrong – the huart port would happily send and receive entire strings. We then rewrote our SendStr function and removed our SendChar function – and everything worked perfectly fine with no risk of characters being sent out of order at all. A problem arised when writing the C code to read from the huart port that the python sent. The python code would dynamically read any number of characters from the port without issue, but in C we had to define the number of bytes to read from the port. Our solution was to append our sent string from the Pi with enough null characters to make the string 100 characters long. Then, upon receiving the string, we would look for 100 bytes of data (each char being 1 byte large). Then we would loop through the data received, store it in a new string and cut off once we received the first null character. To confirm that the string sent from the Pi was not corrupted in any way, we then relayed it and sent it back to the Pi from the discovery board. Our feed began filling with “hello”s – the two boards could communicate back and forth despite having completely different hardware architecture.
We had one final task before we could begin integration with the PiAnywhere and SIMCOM chip, and that was to send a string from a discovery board to another discovery board, and then send that string to the Raspberry Pi. The process was simple and just involved reusing code we had already wrote – Sender1 would constantly send “hello” using sendStr over UART1, sender2 would wait until it received a signal on UART1 and send over UART2, and the Pi would read whatever was sent from its UART feed. All that was involved was the configuration of the UART2 port, which was done automatically by CubeMX. Now it was time to swap out our discovery board for the PiAnywhere. Upon doing so, we ran into an endless series of issues – mostly due to hardware config. The buad rate was configured incorrectly between the two devices and so random characters were being received over HUART. Compiling to the PiAnywhere often caused issues, often being undetected by our debugger. The HUART feed was unreliable, the contents of it changing every time between separate compilations. Our project file started getting confused – our main.c file went missing and was replaced by a phantom file that was sending “hello” whilst we were trying to send “123”. After so many issues, we decided our best course of action was to start from scratch. After rebuilding a new cubeMX project and rewriting our sendStr functions, we finally had our PiAnywhere receiving a string from the Pi and sending it back. We can now send commands from the Pi to the PiAnywhere, and send responses back. Everything is prepped for our SIMCOM communication – all that is left is to send the command to the SIMCOM chip and have a response sent back to the IOT BIT.