Last week Sibille and I moved our bare-metal code for the processor-PCB (which so far was directly inserted in RAM by the GDB debugger) into the Flash memory proper, and wrote code that will execute from Flash to copy everything in RAM and continue execution from there.
However, we soon noticed a strange bug: the GDB debugger now ignored every breakpoint we tried to set in RAM (breakpoints to parts of the code executed in Flash before the copy to RAM still worked fine). After a lengthy debug session, Alexis determine that it‘s a bug from the GDB debugger and not from our code.… Read more
Yesterday evening, the whole groupe work together to test the power transmission through the ball bearings. Those tests are significant to determine if we need to add a 5V-regulator on the main board, and which regulator we choose for the bottom PCB to account for the tension drop.
Today, Sibille and I ran the final tests for the led-driving PCBs software using Vlaya’s SPI generation code. We wanted to make sure that if the main board sends an entire SPI frame (24 LED configuration instructions and a “TOP” command), the CPU managed to configure all the LEDs and turn them on. It does 🙂
On the nucleo devboard, we can observe 20 out of 24 timers. Have a look at the outputs we measured with the logic analyser :
Today, Xavier and I continued to work on the software for the LED-driving processors. We have obtained fairly satisfying results 🙂
First, we managed to fix the bug explained here for TIM1.
We had just forgot to set one bit (MOE bit) in the configuration : TIM1 is an “advanced timer” and this bit is mandatory to enable the outputs. As for TIM9, it is actually not available on the dev board we use. But it is a “general purpose timer”, so we won’t hopefully have any trouble with it.
Then, with the help of Vlaya, we use her SPI generation code to test our SPI reception.… Read more
These past few days I’ve been working on the animation generator. Here’s a result:
I wrote a generator in C (which will later be the code used on the main board) which has a generate_frame function which will generate the next frame of a procedural animation. The generate_frame function can be called an arbitrary amount of times.
The code can export the frame to a file, which is then read by my animation simulator script I wrote for blender.
The simulator takes a few secondes to read the frames (5 secondes for a 500 frames animation for instance), and can then display the animation in real time (same as in the gif)
The simulator can also render high quality realistic animations as the one you can see in our project presentation , but even a small animation will take a day of rendering
Here’s all the concepts / techniques I have been working on right now (most of them are already implemented) which the generator uses:
The virtual petals are the petals you appear to be seeing go down (age) on our phyllo animations.… Read more
Yesterday we put the flexible plastic tube to isolate the inner metallic tube from the axis on our power transmission (see this post ). With the help of Karim, Sibille and me devised a way to test if power gets across our ball bearings using some large resistors. We were able to see that we can transmit 30 amps, but the resistors’s resistance was too low for proper testing, so we could not test the voltage drop.
It is crucial for us to test the voltage drop, since right now we are transmitting 5V through the ball bearings and powering devices that function on 5V on the rotating part.… Read more
A for loop with index i and stop condition i < x contains a code which prints i and does some non relevant computations. When x is greater than y the code prints i up to x-1 (as you would expect), but when x is smaller than y the code prints i up to 51. The threshold y is slightly random (it hovers around 1120), but the 51 is not. What is happening ?
Well, first here’s more precise information on what actually happens: if x > y the code actually doesn’t print all the values up to y-1, it only prints the first 51 values and the values between y and x-1 .… Read more
I changed the design a little bit in order to ease the printing and make the structure more robust: I removed the openings / holes on the sides and made the whole structure thicker. I also used the Ultimaker 2 printer of the fablab instead of the zortrax since the zortrax are somewhat broken right now. (hopefully it’s not because of all our printings)
I also printed a piece with the same shape and dimensions as our processor PCBs, and it fits perfectly in the structure.… Read more
Today Sibille and I made great strides on the bare-metal code for the led-driving processors.
Yesterday we left off unable to see the PWM outputs on the processor pins. Today we started by remedying an oversight: we set about configuring the clocks.
On top of that, it turns out that yesterday we didn’t pay enough attention when reading the documentation for the board: the documentation includes pinout information for other boards with other processors, and we were looking at the wrong processor…
We were then able to use a Saleae Logic analyser to observe the PWM output. At first, the frequency was off, and we spent much time looking at our clock configuration before realising that the timer prescaler didn’t behave in the way we expected (it turns out that frequency division ration if the prescaler value plus one, which is a neat way of avoiding a “division by zero” type of situation). … Read more