Led’s bare-metal

Today we all brainstormed about the software architecture. 

Since we are still waiting to receive the Hall and optical sensors for the speed feedback aspects, we turned our attention to the rest of the Phyllo.

While Marc and Vlaya worked on how to organise the software for the main board – which they will tell you all about in an upcoming post – Sibille and I looked into the LED-driving PCBs. Their role is simple :

  • Receive color configuration for each LED and control commands via SPI as discussed in this post
  • Configure and control the timers to generate the appropriate PWM signals to light the LEDs

Since these tasks are simple enough, we plan to forego using an OS and instead write bare-metal code.… Read more

The clearer, the better.

For the last two days, I mostly spent time making the code clearer. Some big functions got divided to make them easier to read and to modify once we will get the test PCB.

The second thing was to add semaphores to protect the variable shared between our threads on both the ESP and the STM. I also create a new thread that will be used to display the image or the animation we receive from the ESP. So far it only prints on the console the value of each bytes but having it already created allowed me to add the semaphores on the image so that when we will be trying to display images with the coils we will simply have to deal with the coils.… Read more

Let’s go all the way !

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

Because we want animations too

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

Can’t you hear my protocol byte so

In our design, we want to use a STM as our main processor bu also an ESP to deal with the network part of our device. This imply a communication between those two.

The low-level protocol

At first we wanted to use the UART protocol. Yet because we will have very strong magnetic fields, we migh need a more reliable protocol. We decided that we will implement both an UART and an SPI interface and test both on the device. As of today we have implemented the UART communication but as we don’t have on our development board (iot-node) any RTS/CTS pin that can be mapped to the arduino connectors we used delays to avoid the overrun we initially had.… Read more

I swear I could connect

Now that the Hall effect sensor is working and while the coils are still being tested with the marbles, we started working on our WiFi module. As explained in our project’s presentation, we want our devices to be able to communicate through MQTT with a backend and with other Touch.

The WiFi module :

To do our test we took an ESP32 Wroom-32 Dev kit C. The main purpose of this module will be to connect to the WiFi, receive through MQTT the images that the box will display and then transmit them to the STM32. In some cases, the STM32 will send to the ESP the state of the box and it will have to transfert those data through MQTT.… Read more

We keep feeling it

We previously tested a Hall effect sensor that, was working, but which gave us a voltage from which we could get the marble’s side. The issue with this is that in the final box, with all the marbles and the coils, we could have had strong pertubations that could alter the data. To avoid this issue we decided to use a sensor that would send the data through a communication protocol that could resist. We chose the TLE493DW2B6A0HTSA1 Infineon Technologies. This sensor sends its data through the I2C protocol so it should resist to our perturbations.

Let’s connect it !Read more

Can you feel it ? Yes we can !

In the components familly, it was time for the Hall effect sensors to be tested.

The sensor:

We used the SS39ET from HonneyWell. This sensor has 3 pins. One is GND, one is Vcc and the last is the output. The output is a voltage proportional to the magnetic field. We choose for Vcc a value of 3.3V.

First tests, let’s use a voltmeter.

To do the first tests we measure the output voltage with a voltmeter. To power the device we used a DC power supply. We also added an ampermeter to measure the current going to the Hall effect sensor.… Read more

How To Touch together ? MQTT is here.

One of the most critical part of the project will be the communication. Whether it is between the Touchs of with the backend we need our device to be able to communicate.

The communication challenge:

The first thing we had to do was to choose the protocol. As we wanted to allow both a communication with a backend and between devices, we chose the MQTT protocol. It has the advantages to be easy to use and to easily allow us to switch from listening to the server to listening an other device.

The first step: the broker:

In MQTT, all devices (may it be a server or an actual connected thing) are clients.… Read more