Driving me crazy

Romain and I spent the last few days trying to get the WiFi dongle to work with the SOM.

The little fella

However, several issues had to be overcome in order to succeed in doing this.

Overcurrent detection

Overcurrent detection had to be disabled for USB devices to be detected by the SOM.

WEXT and cfg80211

For the driver to work, wext and cfg80211 drivers have to be enabled in the configuration of Yocto. We found this out because the driver would not work. Fortunately, we stumbled upon this document from Intel.

Compile the correct driver

A confusion between the driver of our dongle (rtl8188eu) and the driver of cyL3D’s defunct dongle (rtl8812au) wasted a good amount of our time.… Read more

The walking LED

I started to work on the SOM with Romain a few weeks ago. My objective is simple: we need to be able to test our modules while we wait for our PCBs.

It’s alive !

For this purpose, I took my favorite necromancy book and proceeded to revive CyL3D.

I used this opportunity to get familiar with the tools we use to program the FPGA. I forked the reference project from Aries and tried to communicate with the drivers using only the FPGA.

However I was not able to control the drivers properly, more debugging has to be done. In order to accomplish this debugging, I need to control the our modules using the HPS.… Read more

A little smile for the photo…electric sensor

So, we had to design a small PCB in order to place the photoelectric sensor that allows us to measure the rotation speed (remember, we planned the possibility of using this sensor or a hall effect sensor).

This sensor is a small fork with an emitting infrared diode one one branch and two sensors on the other. When an obstructing object is placed between between the LED and the sensor, it can be detected.

Photoelectric sensor

The PCB will be screwed under the lower mechanical plate. We had an argument to determine if the connector to the mainboard should be on on the same side or the other side of the PCB.… Read more

Mechanical assembly

With the help of a company we are working with, we made tremendous progress in the choice of our mechanical architecture. Here is what we settled with:

Each “floor” of the structure is being held to its neighbours by three spacers in an equilateral triangle. The spacers and plates are made of metal (most likely aluminium) and carry the ground from the body (it is being pulled from the arm).

The 12V power is carried through the motor axis which is isolated from the bottom plate.

LED band PCBs are simply held by friction and by their connector. Appropriate holes in the hat and the middle plate are made to fit the PCBs properly and hold them in place.… Read more

Let’s test all the benches !

Good news today. I completed the testbench connecting the synchronizer and led band controller modules.

This global testbench allowed me to discover and fix new bugs, mainly in the synchonizer module. Everything seems to work as intended now.

The test consists in writing a random frame of data on the led band controller and checking if the simulated driver contains the proper data at the time it should be displayed.

I also tried to change the multiplexing groups, which is an important parameter we will have to set later, and everything still works. I only hope we won’t have too many surprises on the finished product.… Read more

FPGA/HPS: to pin or not to pin?

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

Simulacra and Simulation

I’ve been working for a few days on a global testbench of the system. I am making progress while at the same time integrating the fixes and design changes we decided to make.

This is almost done. Simultaneouly, Romain tests the behaviour of our module on a DE1-SOC dev board, everything is looking good so far.

It’s good to see the synchonization music in action.

Don’t pick on my files

LitControl needs to allow the user to remotely select a file to be played on LitSpin. On this purpose, I created this simple remote file picker in C++/Qt.

The file picker

It uses ssh to remotely list the files in the selected directory and launch a program with the file chosen by the user as an argument. Since out HPS runs on Linux, this is a viable option to simply remote control what is being played on LitSpin.

We will however have to be careful to terminate the previous program running before launching another one (as the 2019 Télécom Robotics team can testify).

Sync me a song

The implementation of the synchronizer is done. The architecture did not change much from this post.

I did unit tests on the submodules of the synchronizer. However a question came to my mind when it comes to testing the global module. How to test such a module without basically reimplementing it in the testbench ?

For the moment I just took a look at the output and checked that it seemed correct. Here is a look at the little music it produces:

Turn timescale
128th of a turn timescale
One multiplexing group writing cycle
One bit for each LED writing cycle

Next, we will have to test if the sync and led band controller modules play nice with each other.