[SpiROSE] Rust, Device Trees and Mechanics

Hello! This have been a long time since I’ve posted here. Lots happened!

First the mechanics

The motor we chose was doing lots of noise, so I had to investigate this and try to get a solution to avoid having to buy another motor. I discovered the noise was coming from a broken ball bearing.

The faulty ball bearing was hiding in the bottom of the motor.


After ordering a new ball bearing, the motor was running perfectly… Up to the moment I realized the motor was not the only one to do a big big noise… The planetary gearbox is using 3 needle bearings that does a lot of noise too…

I recycled an old Brushless Motor, a 4 pole 2100kv 3-4S LiPo sensored BLDC motor. This motor is not supposed to fit the low speed requirements (~20-30Hz), so I had to test with the real world load. We engineered PCB prototypes without the components to simulate the load, and mounted them over the newly installed motor.

New sensored motor speed test without load

Load test, with a big protection. We care about our lives 🙂

The two black plates over the vice are the prototype PCBs (pre-sensitized FR4 plate we machined with a CNC to fit the real size). The system is sensored, so we just placed a logic analyzer at the hall effect outputs (and divided by 4 the outputs, as it’s a 4 poles motor). The result is that we can go from ~5Hz to more than 30Hz, so the motor fits perfectly with the load!

Good news: the motor is now fixed in the structure, mechanical engineering is about to end!


Discovering Rust

This have been a long time since I wanted to learn Rust programming language, but :

  • I didn’t have time to learn it
  • I didn’t have a good and simple project to start with

Thus, when I saw we had to make a simple Command Line Utility for our SPI communication with the FPGA, we decided to make it in Rust. The first day was hard. Very hard. I discovered how we use rustup and cargo correctly, how we setup Rust to always develop with the nightly version, and how to cross compile for armv7.

SpiROSE Command Line tool

After hours of questioning myself about how it works, reading the docs, asking questions to people who Rust and error reading, I finally got a working SPI CLI for SpiROSE. Ok, that’s cool, but how do I get the SPI device now?

SPI, Yocto, dtsi

As the current distribution is not really made for embedded (ubuntu), we wanted to try Yocto, a build system made for packaging a GNU/Linux inside embedded systems. Yocto is widely used for that, but has a complex curve of learning. As the time was getting short, we rolled back to ubuntu.

So, how to get SPI device in /dev/spidevX.X? The solution is:

  • Install Spidev module (we recompiled the kernel to integrate it inside)
  • Update the Device Tree Blob given to U-Boot to give the address of the SPI hardware to Spidev and enumerate it inside /dev

As nobody knew about Linux Device Trees in the group, I hardly tried to put the new device in the dtsi, to get the new Device Tree Blob to give to U-Boot.

I finally achieved this tonight. Tomorrow will be reserved for testing the SPI output (already tested with a logic analyzer) by connecting it to our FPGA development board.


Now this week will be full of tests, to get the PCBs ready to use as short as possible!

[SpiROSE] LED Panel, end of place and route

Nothing really interesting for me this week, except place, route, place again, route again, etc.

The LED panel is pretty hard to route because of the constraints we have on it. Here are some stats about it:

  • There are 1920 LEDs, 15 drivers, 4 buffers, and 2 multiplexers inside a panel.
  • The top of the panel must have placeholders of approx. 10x10mm regularly to fix it using brackets, these placeholders will also be used as wires for electrical power input.
  • There will be 5 micro-blocks (a micro-block is a vertical set of 8×48 LEDs, with two drivers on top, one on bottom)

For fun, I looked at the stats from XPedition Layout, and saw there are approximately 12000 vias.

I would never have done everything by hand, it would have been too much repetitive work to check manually after. Hopefully mentor gives some utilities to help us copying blocks, here are the main ones I tried.

Hierarchical design and Instantiation

There are two main ways to design a circuit : by describing it explicitly, using pages to separate functions when possible (and appropriate), or abstracting parts of the schematic by defining new symbols representing a whole function.

The last method comes when the schematic is starting to get so big that it becomes difficult to read the schematics all at once. It is kinda similar to functions in procedural programming languages like C/C++. Another big advantage is the capacity of the symbols to be used more than once, making it easy to reuse a whole block.

This is where hierarchical designs can come in our design: designing a symbol as a whole micro-block makes the schematic approximately 5x smaller, with a guarantee that the micro-blocks will be wired in the exact same way. Finally, instantiating 5 micro-blocks let me place 5 big “components” already wired inside the PCB, and not manually placing and routing the 384 LEDs of the micro-block individually 🙂

Unfortunately, this systems works fine if it is conceived hierarchically from the beginning. If already placed and routed a micro-block, and putting it inside a symbol broke the link between the schematic and the PCB, breaking my place/route I already made…

Clusters and Circuit reuse

Another way of doing it is by using clusters. Cluster (Type 152 as described in the mentor’s documentation) is a type (physically represented by an integer) you can add in a device property. It acts as a group function: put some parts into the same cluster and they will be recognized as ‘equivalent’ parts. Here is how I’ve done this (UB0 is the reference micro-block, already placed/routed, I want to duplicate it and name the duplicated version UB1):

  • Set every LED’s cluster property in UB0 to a different number quickly by selecting the LEDs only (be careful not selecting special symbols like intrapage connector, power symbol, etc.) and using the ‘place text’ in ‘Type 152 – Cluster’ mode with options ‘auto-increment’.
  • Same for all the other devices like IC, resistors, capacitors, etc.
  • At this point there should be one element inside each cluster.
  • Copy paste (including net names) the whole UB0 schematic, and without unselecting it, replace text ‘UB0*’ to ‘UB1*’ with option ‘selected text only’ (I suppose all the different nets start with ‘UB0’, adapt as needed)
  • The schematic is ready!

Now for PCB:

  • Package, forward annotate.
  • Select (in select mode) UB0 parts, nets, vias, etc.
  • Now you have two options: direct paste (using clipboard) or save the selected circuit for future reuse.
  • If you activate licence for ‘Circuit Reuse’, you can save it (inside the ‘Edit’ menu).
  • Otherwise, just right-click and ‘Copy’. From there you should have a pin map assigner window where you can adjust your paste settings (if it does not show, just hit ‘F2’).
  • Oce it’s done, you can paste, and it’s done!

The problem with this being that there is no verification of integrity between the micro-blocks (if you rip/shortcut a wire somewhere in the schematic on one micro-block, you may not be notified).

This is what I applied because it is easier to use when you already have an existing design.


Next week, the last part will be added and the bottom part of the panel will be routed, finally!


[SpiROSE] Driving the LED Drivers with the FPGA

This week was dedicated to writing the SystemVerilog code for driving the TLC5957 LED drivers. The first issue was to get some SystemC tests ready to use. While the tests where being written by someone else, I started writing the SystemVerilog code. Now the code is ready and have been tested on the drivers, but the timings are not correctly set, so the drivers are being incorrectly driven and behave pretty randomly.

The FPGA development have been delayed in order to get the schematics ready quickly. During the same time a more precise analysis of the available encoders have been done, including the mechanical restrictions, connector, communication protocol, etc.

Next week will be dedicated to the shematics and datasheets reading.

[SpiROSE] Mechanical construction, various tests and FPGA design

This week was full of various little tests and tryouts: Power input, Motors, LEDs,  LED Drivers, etc. It was also a week used for designing the FPGA internal architecture and final adjustments for mechanical construction.


Mechanical construction

The mechanical design have been updated due to the lack of some materials in our distributor. The design have been checked and validated back with the mechanics, and the materials have been ordered. The mechanics will start the construction on next week. The motor and his controller have been ordered too.

The updated mechanical design is available here.

FPGA Design

The FPGA architecture have been finished, including clock domains, I/O count, main modules definition, RAM layout, data input specifications, synchronization constraints and drivers control logic. The chosen FPGA (Cyclone III with 40KLE) have been validated to work with this architecture and next week will be used for starting developing on it, to check the timing requirements. The rotative base station schematics can now start.

A note about RAM: last week a basic estimation was done to see if an FPGA could internally store a whole 3D image, but the calculus was erroneous, which leaded us to think that the Cyclone III FPGA was capable of it. The reality is that it can store up to 18 ‘slices’ (we call these micro-blocks), so synchronization is needed.


Various experiments

The LED drivers have been soldered on breakout board, as for the LEDs, and some motors we had have been tested. The goal was to validate our choice of components. Due to mechanical construction starting soon, we ordered the final motor and controller just after the tests in order to have it when the construction starts.


Now the schematics of the rotative base station are ready to start, and the FPGA code have to be written.

See you next week for more details!

SpiROSE: LEDs place and route

My week was dedicated to do the placement tests for the LED PCBs. The schematic for one ‘driver column’ (meaning the number of columns driven by a set of drivers to make a repeatable set) have been done using 3 drivers per ‘driver column’. The placement is:

  • 2 drivers on the top of the circuit, with a ground plane under
  • 3 ‘micro-planes’ of LEDs (a micro-plane is 8*16 LEDs in 8-multiplexing, with column multiplexing)
  • 1 driver on the bottom of the circuit, with a ground plane under

There have been multiple trials for the place and route, the pictures retrace the big steps.

This is the last version on the sunday morning.

Part of a driver being routed.

LEDs main view.

Schematic of 2/3rd of one ‘micro-column’

Details on the routing of the LEDs.


The components are all in the top layer, so that we can put two PCBs back to back without any problem (with an isolation layer between the two to avoid short-circuits).

The place and route step of the LEDs PCB is nearly finished, it should be done before the end of the week.

SpiROSE: Architecture review

This week was about choosing the main components and reviewing the architecture of the project. A big snapshot of the project have been done on 2017-11-03, available here.

Review of the architecture

The architecture looks like this:

(Errata, the original one is in the snapshot slides)

On the fixed structure, a 3-phase brushless motor (with reductor) is controlled by a speed controller itself driven by an STM32F7 DevKit we already have, that receives an estimation of the speed via an Hall effect sensor. This DevKit also have a Human Machine interface and communicates to the Single Board Computer (we’re still looking for…) using a WiFi connection. The SBC is in the Rotary part. It communicates to the FPGA (probably using an HDMI to RGB chip, we’re still looking for high bandwidth outputs on the SBCs to avoid that) and a SPI+UART connection let us have a low-speed communication between both. The SBC also has GPIOs for programming the FPGA.

The FPGA receives the RGB stream and splits it to the ~30 8-multiplexed LED drivers that drives the LEDs. The FPGA is managing the multiplexing using another Hall effect sensor.


What’s next

The FPGA and the SBC are not fully chosen for now. We are still looking for boards with good output bandwidth that fit our requirements (like, not PCIe because of impedance matching issues, and not GPMC as there is no board available anymore). The other parts are chosen.


Next week we have to choose the SBC and FPGA.

Mechanics: (almost?) final chapter

The final design of the mechanics of SpiROSE have finally been chosen! A week full of design decisions, finding a design, testing the mechanical
design, simulating, talking with the mechanics to see if it’s doable, etc.

There have been lots of designs, the most importants are the following.

Blade-based designs

The design pattern is based on a stack of RoseACE blades. Every blade contains 32, 64 or 128 LEDs, and the stack is made of 32 to 42 blades. This
leads to a design looking like the following.

Blade-based design pattern without top arm.

The red squares are the RGB LEDs. A big central axis is used for turning the LEDs and transmitting the electrical ground. A special PCB at the bottom
of the axis is used for the Single Board Computer module, an FPGA and a brush for transmitting the Vcc from the fixed base. Wires connect the blades
to the main rotating PCB.

This design is similar to the design made by Volumen Display. It have the advantage to be modular: you can add or remove blades without changing the
mechanical design of you system, and another advantage of being more aerodynamic (it acts more or less as a big 30cm diameter fan :).)

The issues with this design are mostly mechanical issues. In fact, it is extremely hard to make a stable design this way because of the approx.
1300rpm speed of the blades. The mechanics said it would wobble, and the solution making the wobble to disappear (adding another bearing on top of the
axis) introduces other even harder problems (how to fix the PCBs). The other issue is the occlusion. The central axis makes a big occlusion and the
helicoidal shape of the blades overshadow the lower LEDs, giving the feeling of a big blurred central axis.

Another blade-based alternative design was to stack custom plexiglass(r) laser cut discs, containing the PCB. It looks like the following. The Disks
could be screwed to each other up to the base circular PCB, making the axis. The issue with that design is that the plexiglass would obstruct so much
the light coming from the LEDs that it makes the feeling of an even bigger central axis, instead of solving it…

Plexiglass(r) based axis.

Due to the issues related to this design pattern, it was finally removed from our design space.

Blade-based pattern with top supporting arm.


Plate-based designs

This design pattern is a HARP-like pattern. A big central plate gives a matrix of LEDs. This plate is turning on itself and makes the same shape as
the blade-based design makes. This pattern needs a supporting arm on top, leading to the following design.

The difference with HARP would be the number of LEDs, and the fact that our goal is to remove the occlusion issues they got. The occlusion they got
was due to multiple effects:
– The fact that LEDs are on one face of the PCBs makes the system not able to render anything when the LEDs are not visible to the user’s eyes. The
solution we got was to use two PCBs with LEDs, back to back. It makes possible to always have LEDs facing the user’s eyes.
– The fact that the LEDs have an emission cone (approx. 120°), giving this feeling that there is kind of a central occlusion because the LEDs cannot
illuminate when the user’s eyes are not in the emission cone. To solve this issue, light guides/diffusers will be experimented on LEDs next week to
see what we can do (this subject will be discussed in another post :).)


The winner

The winner of these designs is the Plate-based design, having less mechanical issues. The mechanical design approved by the mechanics is the following. It will be changed a little bit due to motor changes, Budget adjustments, etc. but it will be looking like this one.

Next week is not anymore on the mechanical design, but on the embedded systems and budget choices!

See you next week for more fun!

SpiROSE: how about the mechanics?

This week was full of requirement definitions. How many leds do we put, what bandwidth can we expect between the computer and the display, what technology can we use for [insert stuff here]… Lots of them have been defined, and more than 70 PSSC (Project Specific Success Criteria) have been written. During this time, mechanical drawings have been done to try different mechanical layouts.

The system is based on a main layout : a big squared block makes the fixed part of the system. A big plexiglass© cylinder with a top roof is put
over the block. Inside the fixed cylinder is the rotative part of the display. There have been multiple rotative versions. The idea is to make
something that can infer no occlusion while it’s turning. The induced problems are:
– The PCBs must be fixed without inducing occlusion (when turning)
– The layout of the system where the PCBs are going to be fixed shall not induce occlusion when turning.
– This system must resist without wobbling and have an intertia momentum small enough to respect our security criteria.


Mechanical preview

Example of full design with triangular rotary mechanism


We ended with about 5 designs for the moving part that we’re going to review with the mechanic.
More to be done on next week, as the mechanical drawings should be done at the end of next week!