For anyone interested, the code of our project is available on GitHub at the following address:
Last week, while Pierre was working on the routing of the PCB, I’ve been working on software. What I’ve done is basically a function to get a file on the SD card, and a function that reads and interprets the file as an ILDA file. This is the first brick of our chain of programs, and the data will then be processed by the main program to send the appropriate commands to the galvanometers and the laser.
Hi! Last week has been mostly about PCB design. We’re still waiting for our galvanometers and lasers to arrive… Hopefully we’ll have them soon. In the meantime we can’t make much progress about the PCB itself but we corrected some problems.
About the input of the galvanometers, I made a mistake in the voltage adaptation circuit: when the scanner is at its maximum angle, it should be either at -5V/5V or 5V/-5V (positive input/negative input). So we had to adapt the system so that when the ADC outputs 0V, it outputs -5V/5V; when 3.1V (max) 5V/-5V; when 1.55V, 0/0. That means we have to change the resistors values: R1 = 1kΩ, R2 = 2.21kΩ. As Mr Polti pointed out, we also have an issue with the component used: the ADA4941-1 has an output voltage swing of +/-2.9V, which isn’t enough to generate the desired signal. So we decided to make our own adaptation circuit with two ampops that will have the good characteristics (for example, the ADA4666-2 works). The circuit is as follow:
Meanwhile, I also worked a bit on coding the basic I/O functions of the main controller: I started with connecting the SD slot, testing my code on the development boards we use in practical works this year, OLIMEX STM32-E407. I haven’t been able to test it though, as the only microSD card I have is the on in my smartphone, and I failed to get it out of the phone.
Because finishing the design of the PCB is now the priority task, I’ve been working on several parts of it: namely, linking the SD card connector and the galvanometer drivers.
The microSD card connector we found in ExpeditionPCB is manufactured by JAE (Japan Aviation Electronics). The pins correspond to those of the microSD standard and are linked to one of the SPI interfaces available on the STM32F7. MicroSD cards can work on supply voltage from 2.7 to 3.3V, so we just use the same 3.3V supply as the F7.
The drivers of the galvanometer work with a balanced analog input ranging from 0 to 5V. Since the DAC of the F7 outputs a single-ended signal ranging from 0 to 3.1V (according to the datasheet), this is an issue we had to resolve.
We basically had to convert an analog single-ended signal to a balanced one, and amplify it with a 5/3.1 ratio. We achieved this by using an ADA4941-1 amplifier with two resistances, as represented below.
This circuit is composed of a non-inverting amplifier (taking IN and FB as entry), which, with the resistances of 10kΩ and 6.2kΩ, multiplies the signal by 1+3.1/5 = 1.62 = 5/3.1 (approximately). Then a inverting amplifier with a gain of 1, create a signal symmetric to the OUTP signal with respect to the REF signal value. We set REF at 5V so that the signal can have a 5V range around the offset value of 5V. That’s also why we linked the REF signal to the GND port of the driver, so that the driver can see the signal as a balanced signal.
I didn’t have much time last week to work on the project due to the Athens week. I had a wonderful time in Prague but I wasn’t able to work on the project.
On these last days I’ve been focusing on trying to make FreeRTOS work on a STM32F4xx development card, i. e. making the official demo for this board work. Sadly, the official demo is actually designed to be compiled with the IAR compiler, and we’d rather use GCC for our project instead of a trial version of some non-free compiler. I’ve found a demo using GCC and a makefile on the Internet, but for some reason, once compiled using GDB will work even if the GDB server isn’t launched, which makes me think the Makefile already opens one (which is not good because it is not launched on our board). I’ll try for the next time to have a more deeply understanding of how a FreeRTOS program works, and I’ll try to fix that issue.
In 2 days, we defined the architecture of our project and most notably, we establish that we’ll be using 3 microcontrollers: a main controller from the STM32F7 family, a smaller one from the STM32F3xx family, whose main purpose will be to switch off the laser when it doesn’t move to comply with security norms, and an ESP32 for the network.
It seemed then logical to try and begin learning to use FreeRTOS, as we were used to work with ChibiOS in practical courses. That’s why I copied a demo for STM32F4xx cards, which we happen to have used during the practical works. In the next week I’ll try to learn how the kernel works in order to set up a SPI interface and maybe, if I have the time, a code to access an SD card, using the STM32F4xx. The code will be eventually reused on our final STM32F7 if functional.
We chose to use the “GitHub workflow” because it’s simpler. The “Merge Request” feature of GitLab will help us apply this flow well.
LASMO will need to get data from the storage devices where the animations will be stored. For that reason, we need to add to our PCB a USB connector and a SD connector, as well as identify the electrical needs of the devices once connected and active. So I looked for what kind of SD cards and USB drives were fitted for LASMO. (streaming of ILDA files). Thanks to Pierre, we know that we’ll need a debit of approximately 500 kbps.
SD cards are divided in 3 categories according to their storage capacity, and are granted a speed class among 11 possibles.
According to this table, all the speed classes on the market are fitted for the application.
As for power supply, it is kind of standardized. Indeed, accessing SD cards with an SPI bus requires a voltage of 3.3V. After looking at the cards available for example on Mouser, the typical supply current is between 30 mA and 100 mA.
Thanks to the presentation on USB we had a moment ago, we know that USB 2.0 and USB 3.0 deliver theoritical debits up to 480 Mbps and 5Gbps respectively. That is largely enough for what we need.
We had arguments over which type of connector will be the best (between USB-A and USB-C) . We finally decided to go with the most common (for the moment) USB-A.
As for the power supply, if the voltage is almost always 5V, the current does change with the version of the protocol: maximum 500 mA for USB 2.0 and maximum 900 mA for USB3.0.