I've mastered the SAMA5D4 just in time for chapter 3 closure. The end of a chapter is the right time to look back and reflect.
The world is unfair for people that don't know. I have this powerful board in my hands. And I can't get anything usable out of it. I struggle tremendously and blog (some may say whine) about that. Then magic happens. The first program compiles. That first program runs. The board says 'hello'. Having a working program speeds things up. Finally, you can check things out. Change something. Does it still work? No? Why not? Take a step back. Having that reference point - a working example - is the stepping stone to all further endeavors.
Looking back, it's hard to understand why it took that long. In hindsight, it's all not that difficult. Hindsight is 20/20. That's why the world is unfair for people that don't know. I know now. The progress in the last few days may be a factor 100 more than what I was able to achieve the previous two months. The blog series tells the story. |
Finish the Light Organ
At very start of the enchanted objects, I stole the Arduino Light Organ design from Daniel Herrera. Unchanged.
Why should I change it? It works perfectly.
But with the SAMA5D4 working, I needed something to practice my skills. And (repeating myself today) having a working example is an ideal starting position.
The Arduino example works. So I ported Daniel's code. I also ported the fft-fix Arduino library that he's using (by itself already a port originating from pre-1990 work of Tom Roberts).
In my port, I tried to stay as close as possible to the designs of the original code. I only made tactical changes to make it work on the Xplained board.
You can see that in the attached source code. I've spent 0% to do proper design. When porting something, my favorite way is to stay as close as I can to the original.
I focus on getting it working, not on proper design or reuse. The less confuscated the work, the easier to compare it with the original. Refactoring into proper classes, parameterising and clubbing into reusable parts is for later.
Go ahead and look at the code that I attached to this post. It's very visible that I did the port that way. It's still riddled with debug comments - something that helps me to see where I've done tests and result checking between the Arduino and SAMA5D4. And lots of actions are repeated where a generic function would be appropriate. I may do that later. Or someone else - trying to master the SAMA5D4 - may get their hands dirty and post a sanitized version.
Looking at the FFT Results
The Organ uses Fast Fourier Transforms to turn the sampled audio signal into buckets of audio frequency spectrum. In this design, 128 samples are turned into 64 buckets, from the low side to the high side.
Bright minds may be able to do the full calculation of the covered bandwidth based on my scope's screen capture.
The high part of the blue signal indicates how long one sample burst takes. And I take 128 samples each time. Post the calculations in the comments, please.
SAMA5D4 92ms / 129 samples
ARDUINO 3.86ms / 128 samples
| I made a mistake here and measured* the inner time between two samples instead of the time to take 128 samples. Below is the old capture that shows the wrong info.
This changes the picture a bit, because the sample time is now longer than on Arduino, and I'll have to optimize code instead of adding _nops.
|
I've recorded the FFT result of a 20Hz, 200Hz, 2kHz a,d 20 kHz signal. My program printed the resulting spectrum array on the linux console.
Here's a chart of the results. It's not yet a very good outcome. 20Hz and 20 kHZ give an outcome as expected, at the low and high side of the spectrum.
But I'm not yet satisfied with how the 200Hz and 2kHz signals are calculated. The 2kHz has peaks lower in spectrum than the 200Hz signal.
Since I used a clean sinus wave as input, this shouldn't happen.
The plot below, based upon the four tests, shows that the situation is rather fuzzy in the middle part. You can also see a huge peak of the 20kHz signal.
The skew in my results may be based (is very likely based) on the sample speed. In particular the 2kHz signal behaves badly.
I'll try to slow it down* speed it up and get to the same sample speed as the Arduino. That'll give better results.
These are the captures of the four input signals, taken while doing the exercise:
Side story: Perpetuum Ebner
The small workshop that the brothers Steidinger ran was one of the first in Germany to build gramophone 'clockworks'. That isn't strange, because they were clock mechanism makers. We're talking early 1900's here. The audio industry was still in its very early days. The brothers - both fine craftsmen - made clockworks that could compete with the best. At last their small company was making some money. But they didn't escape the faith of many brother based companies: they didn't get along. Both had a juxtaposed view on the business. They didn't get along. It got so bad that the situation couldn't last. Their separation wasn't friendly. Josef left, and his share of the company was payed out in cogs and springs. Christian's story is known to all. He created an electrical/spring powered gramophone motor combination (dual drive -> hence the name DUAL). The DUAL brand still brings a tear to the eye of many strong men. For Josef, it was back to off. With no money and just a pile of spring motor parts a s capital, he rented the sawmill next to Sankt-Georgen station. He calls his humble business "Perpetuum Schwarzwälder Federmotoren und Automatenwerke". And it's 1911. Another 3 years and it's wartime. Things are about to change for Josef and many other fine mechanics factories in Germany. |
* I made a mistake in my time measurement for sampling. On the Arduino I measured the time to take 128 samples, on the SAMA5D I measured the time to take one sample.I've corrected the post, but left the original info in place for reference.
Top Comments