I’ve Come to a Reliable Conclusion upon working on CRC yesterday. Don’t try to understand what’s going on. Many walked this path before me, and yet I couldn’t look away at the promised cognitive pleasure of understanding it. In the end, I was denied this pleasure and here I am, left in frustration.
Well I might be a little bit exaggerating, but I’m sure that I’m miles away from having a grasp solid enough on CRCs to implement my own. For those who would want to do so though, this article from Barr’s group seems to stand as a reference, or at least a reliable entry point on the subject.… Read more
On Wednesday, I spent some times implementing task notify on the sensor task, until implementing it on the h-bridge task. Then, I realize that it creates many memory errors and was not really useful since the thread should not call the function that change the multiplexer until the I2C communication was finished.
I also find the way to put some values in the esp32 that I used for the test as an I2C slave, and realized that it works with only 7 bits adresses whitout a read/write bit at the beginning, so I changed its adress and it correctely acknowledge to my communication.… Read more
Lately I’ve been working on a way to make the communication between the STM and the ESP more reliable.
While searching on the subject, I came across two methods.
The first one made me reminisce some of the lessons we had in first year about information theory. The idea is to use a Hamming code for the messages of the protocol. This will make the communication more robust because of the properties of such a code. We plan to use a Hamming code (7,4) which means that the words will be 7 bits wide, with 4 bits of information (meaning we can go up to 16 different words, including the words with only bits at 0) and 3 bits of parity.… Read more
On Thursday and Friday, I spend some times coding the threads of the test PCB. I first debug and check if everything was ok for our thread that will read the state of all the box via the hall effect sensor. I used a logic analyser to check if everything was fine. I checked that the four pins that will be used for the multiplexer will not change until the end of the sending of an I2C message. Then I code a thread that initializes all the H-bridge by putting them at the 0 state.
I also realize that I have not seen a mistake in our scheme.… Read more
As I wrote in my previous posts, the ESP, the STM and the server were working together to receive images or animations depending of what the user wants. Now it’s time for the STM to become the sender.
We want the devices to be able to received images from the server but we also want to establish a connection between Touchs to send images from one to the other. On top of that at the end we want to have a communication between both devices in both ways. But as you may know chi va piano va sano. So first things firts, we implemented the emitting part for the first device.… Read more
So far, the ESP32 was able to receive images from the server through MQTT and transmit them to the STM32. It also could transmit animations but only if the animation was directly hardcoded. So what we wanted to do was to be able to transmit animations through MQTT just like images and also to find a way to chose if we want to receive an animation or an image.
First things first : the server side
The first step we did to go in this direction was to find a way to transmit animations.
We chose that, at least for now, the server will publish periodically on two topics.… Read more
After talking with Tarik, it seems our approach to FPGA/HPS communication was a bit off.
We wanted to use one data bus for writing on the LED band controllers and use GPIOs for the other signals coming from the HPS. It turns out that the GPIOs of the HPS cannot be directly connected to the FPGA, and according to Tarik the workaround are a bit sloppy.
So instead we decided to use the second data bus to write on registers in the FPGA, which will create the needed signals. The first bus will stay dedicated to the DMA module which transfers RAM data to the LED band controllers.… Read more
As I already wrote on previous post, we implemented a MQTT communication to send data from the server to the ESP, we also implemented an UART communication to pass data from the ESP to the STM. Now it is time to go all the way : sending data from the server all the way to the STM.
To do so we had to make a choice: at which point will we encode the data in regard of the communication protocol between ESP and STM.
As a remainder, to be able to differentiate data from commands, the bytes that will contain data will always start with a 1 and then code the state of 7 marbles.… Read more
As explained on my previous post, the communication between the ESP and STM will append through a protocol made to discriminate data and command bytes. We already had the code to send images from the ESP to the STM and this post will be about sending animations from the ESP to the STM.
Our first idea was to start like for the images with a byte to warn the STM about the kind of data that will be transmitted. TO do so we will start the communication with the byte “ANIM”. Then we wanted to send, after the ACK_BEGIN, the size and the animation itself in one time.… Read more
Since thursday I’ve looked into how to implement the wifi communication we need between our phyllos (see Ruling the colony of Phyllos ).
We need a way for multiple Phyllos next together to broadcast data between themselves, and a way to communicate with the Phyllos from a smartphone or computer (for instance), and we will be using a ESP32 dev kit C integrated in our Phyllos.
Data exchange between Phyllos
The rate at which the phyllo need to exchange data doesn’t have to be very high at all: we just want to exchange small messages such as “Here is my ID: xxxx” , or “Start animation X at time T”.… Read more