I started writing the code for the FPGA module which will be feeding the LED drivers. It corresponds to the “LED Driver driver” from our FPGA architecture diagram. In order to have a functional system as soon as possible once we receive the PCB I am also building a test bench to test the module. So far I have assertions on the timing requirements (hold times, setup times, etc.), the validity of the output data and on the internal state machine coherence. I will first finish the test bench and then the module.
Concerning the timing requirements, there are 7 different LAT commands. The datasheet of the TLC5957 indicates the setup time before a rising edge of SCLK for 6 of them. However, there is a diagram of the application note of the driver (Figure 7 of SLVUAF0) suggesting that there is also a setup time to respect for the 7th command. Does anyone from spirose have additional information on that?
It’s been a long time since the last post. I’ve been busy finished the routing of our vertical PCB. We use 4 layers, layer 2 being a GND plane.
Here is the routing layer by layer, with explanations:
Since we’re done (modulo reviewing) with the PCB, we started thinking about the FPGA architecture.
We came up with an architecture based on 4 modules.
We will use the Altera On-chip Memory IP as our per-driver buffers. It is practical since it has an AXI-compatible interface that we can use to easily connect to the HPS.
A synchronizer module will be in charge of time-keeping in order to load and display data at the right time. It will also select which column to display.
The data provider will load data from the memory and pass them to the LED-driver driver.
Finally, the LED-driver driver is in charge of creating the SIN/LAT signals. It will both send data to the driver (as requested per the data provider), and display those data (as requested per the synchronizer)
Last time, I routed the power supply. Since then, I placed and routed all the components and added the ground planes. We’re now waiting for the teachers to review the boards. Below is a screenshot of Xpedition PCB showing what I’ve got so far (ground planes are not displayed, but they’re there):
The green traces are VCC (3.3V). It’s not obvious from the colouring, but some parts of these VCC traces are on the back of the PCB. U3 (the tiny chip above D2) is a LDO regulator (LT1762) that drops the 14.8V VBAT voltage from the LiPo battery (J2) to 5V for the U5 3.3V-to-5V level shifter used for the SPIs (the connectors on the left). U1 is a LT1765 switching power supply for the 3.3V rail. U2 is the STM32H7 MCU. Finally, there’s an SD card (J1) and an ESP32-DevkitC for network connectivity (U4).
This week, we did a few corrections and improvements on the schematics and started the the actual design of the PCBs.
We chose the plexiglass sphere for bouLED. Its internal diameter is 350mm so we took a margin and reduced the triangles’ sides to 179mm. This was enough information to place the LEDs. Having done the triangle design with OpenScad revealed helpful to check the placing as I imported a DXF version of it in Mentor’s software, as Alexis suggested. I was also happy that we chose a rather regular LED repartition, so I could use grids instead of manually copying 78 coordinates.
For the routing, however, we’ll need to know the positions of the screw holes in the PCB. Hichem is currently working on that, designing the pieces with SolidWorks. (I started doing it with FreeCAD but the SolidWorks lobby had the last word.)
This will be a 2-layer PCB, with a ground plane on the bottom. The voltage regulator will go on the back side of the PCB, with the jumpers.
I started placing the 3V3 buck converter first. Here’s what it looks like on the schematic:
The LT1765 switches at a high frequency (1.25MHz), which constrains the routing. The datasheet explains that the most important thing is to make the path from pin 3 to pin 2 through D2 and C2 as short as possible. My layout looks like that so far:
Vias to the ground plane aren’t pictured, but the path I was talking about is really short, and I think it will do the trick. The layout and schematics have yet to be reviewed, though.
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.
We had a long discussion with a student from SpiROSE (last year’s project with a rotative LED panel). He told us the problem they faced with the motor and ESC (Electronic Speed Controller). They could not get a constant speed output from the motor because the ESC was overheating, causing a shutdown and a boot up. It was caused by the motor asking too much current. The motor was one the had on hand and not perfectly fitted to their use. It was rated at 2100 RPM per Volt. While turning at 1500 RPM the ESC pulled 5A on 12V from the power supply, the same 60W would go to the motor, but to rotate at 1500 RPM it only needed 0.7V so the output current from the ESC was closing in on the max output, which caused overheating.
Another problem was to convey the power through the axis. They had to scrub the anodising paint from the top of the motor to make a connexion to a ball bearing which was connected to the motor shaft. I would like if possible to stay away from passing to much power through the ball bearing as it can cause sparks and damage the balls. To replace this connection I am looking toward brush slip rings.
As we are proceeding with the schematics and the PCB placing, we are realizing that we will need more than a single PCB to make everything fit. We will then design an horizontal PCB, very much like SpiRose, though ours will be rectangular for budgetary reasons and it will only host our voltage regulators. The interface between the horizontal and vertical PCBs will be three big pads: GND, 3.3V and 5V. Hence, no signal integrity concerns (at least not at this interface). I placed our 12 to 5V converter on Xpedition Layout while conforming to the PCB layout guide of the module.
Furthermore, it appears that the PCB size of 190 by 190mm that we initially chose will be problematic for us to solder the LED automatically: the problem being the width of the PCB. I was going through the process of routing the LED drivers so that we could be stacking five of them on each side of the panel (according to our previous PCB layout idea), but that will have to be abandoned in order to make our PCB thinner. We will put 4 driver on each side and 2 above.
Last friday we had a class about signal integrity. As we learnt about all the problems we could have, I finally understood the use of all the bypass capacitors and some of the other esoteric symbols or annotation that are no longer a mystery (such as 0-ohm resistors or DNI annotations)
Thus, I had to update the schematic of the ULPI/USB subsystem of our project. You can see it below. Here are some important changes :
Disconnected the oscillator ENA pin : according to the datasheet, having the pin on high impedance does enable the oscillator.
Added USB power distribution switch, the TPS2051C that is needed not to break our USB device. It limits the current of our usb device to 500mA.
Added bypass capacitor to oscillator and power switch.
Updated power supply capacitors
Added 10K resistor for VBUS, connected to a 10uF capacitor that should be enough for our system. The USB 2.0 specification recommends a 120uF capacitor for hosts but we do not intend to hot-plug our USB device or have a cable between our device and our system.
Added names to everything.
Connected the RESETBn pin to our nRST.
As such, our ULPI/USB system should work. However, I have a doubt about whether or not I should add a resistor on the wire between the oscillator’s CLK and the USB3320C REFCLK. Our development kit has a resistor on its schematic, but the oscillator’s datasheet does not mention to put a resistor on the CLK output. If anybody has an idea about it, I’d be happy to hear it.
Today, I started drawing the main board’s schematics. It’s not finished yet: the decoupling capacitors have yet to be chosen and I’m not done with the STM32H7 (pins like VBAT, VREF, BOOT0, etc.). As a teaser, here’s the power supply:
It takes a 14.80V input (from a 4S LiPo) and steps it down to 3.3V. That’s not the right buck converter (it should be a LT1765-3.3), but the pinout is the same, so when it’s done I’ll only have to change U1. The SDHDN_n pin is left floating on purpose, according to the datasheet.
Here’s a sneak peek at the unfinished parts of the schematic: