Archive for the ‘musicplayer’ Category

Using a SPI DataFlash

Sunday, December 19th, 2010

Memory chips used to be a pain with all their address and data lines, but no more. Today I hooked up the 32 Mbit DataFlash (an Atmel AT25DF321A in case you skipped my previous post) to the Bus Pirate and I can barely believe how easy it was. Here’s a shot of the entire setup:

All you need to do it hook up the SPI lines and apply 3,3V power. As a first test requesting it’s manufacturer and device ID seemed logical:

SPI>[0x9f r:4]
READ: 0x1F 0x47 0x01 0x00

Only 4 bytes are returned, but it indicates the chip is working as it should be. The first byte (0x1F) means Atmel is the manufacturer. The 2nd and 3rd byte hold device information and exactly match the datasheet (AT25DF series with 32-Mbit density). The last byte is optional according the JEDEC standard and appears to be unused. Well this confirmed things were working, so next would be reading and writing data.


STM32 design contest

Sunday, November 21st, 2010

STMicroelectroics distributor EBV Elektronic is hosting a STM32 design contest and sends you a STM32 Discovery Kit for free if you register to participate. Mine arrived yesterday and is a welcome dev board for testing purposes :)

Offcourse I entered the contest as well. The project is called FLACie and I intend to get the official FLAC decoder running on the Cortex-M3 core. There is a port done for the Rockbox project of the FFmpeg decoder, but it’s old (5+ years and from before the reference decoder was optimised) and only works on ARM7TDMI controllers. I’m talking about a port based on the reference decoder and optimised to run on Cortex-M3 controllers. General idea is that if it runs on ARM7TDMI cores it must definitely be possible on Cortex-M3 cores.

If this succeeds the VS1053B decoder can be taken out of the musicplayer design. And since that component is the most expensive one it should have a nice impact on the total component cost. Besides it would be a kicker if this actually works!

To be continued…

On a sidenote; remember my rant about shipping costs? The dev board was send through Deutsche Post from Germany using a normal postage stamp. Thankfully no UPS, DHL or any other expensive customer unfriendly courier. Props to EBV for using the postal system as it’s supposed to be used!

It’s like a black hole sucking up time instead of light <:)

Wednesday, September 29th, 2010

S/PDIF is here to stay

Sunday, September 19th, 2010

With playback working again it was time for another addition; digital out. After some soldering and enabling I2S on the decoder the setup was ready for test run. Hooked the monster up to an Onkyo receiver and voila.

First some details. Currently the VS1053B is configured to output a samplerate of 48 kHz (this is also the highest supported samplerate for all codecs). This goes directly into a CS8406 S/PDIF transmitter which is wired in hardware mode. A second option would be a 96 kHz I2S signal. Even though the decoder support 192 kHz it can only output it with MCLK divided by 2. The CS8406 only supports clock ratios down to 128 * Fs. For 192 kHz to work it must go down to 64 * Fs.

At the moment it only uses TOSLINK, but the final version will also have coaxial output. It’s just that I don’t have the required pulse transformer lying around.

Back to the receiver. It detects the output as a 44,1 kHz PCM signal. For a more isolated test I hooked up AKG K 701 headphones which is know for it reference like quality. And wow, what a thrill. This was simply the best sounding audio I’ve ever heard not coming from a real CD.

I could still hear some things I didn’t like (high tones), but at this time it’s unknown what the cause is. Could be the recording itself (need to compare with original CD), it could be samplerate conversion (48 kHz to 44,1 kHz), could be the setup (just think of how anal audiophiles can be about the smallest things ;)), etc. Just a matter of proper testing, listening and comparing.

Also one thing that’s bothering me is the interference the setup has on my cable TV signal (doesn’t affect HDMI). At the moment I’m just blaming all the breadboard wiring which probably acts like a small transmitter. The board is located almost directly below the inputs of the TV and since the cable signal already is very weak (some stations are half snow even without any other electronics close by), so it’s not directly a problem (not to mention the lack of programmes worth watching… but that’s another story ;))

Did you hear something?

Saturday, September 18th, 2010

The moment of truth has finally arrived; FLAC playback! After going through all the trouble of switching over to a Cortex-M3 controller and SDIO, this is a pretty gratifying moment :D

On the right you’re seeing SD card access reading 512 byte sectors (yellow) and the DREQ signal of the decoder requesting more data (blue). Playing is a 886kpbs FLAC file and just look at the space in between. That means there’s a lot of room for additional functionality.

Some quick notes about clocks;

  • SPI is running at 9 MHz
  • SDIO running at 7.2 MHz
  • Decoder running with recommended 3.5x multiplier and 1.0x addition

Well I’m off listening to some test tracks :)

Anyone up for some disco!?

Thursday, July 29th, 2010

With spare cycles in abundance, one’s mind gets creative. Throw a DSP library and 12-bit ADC’s in the mix and a spectrum analyser is born (although in reality this won’t be so easy). The VS1053b with patch applied also offers a VU meter, so the ingredients for a disco party are all present and accounted for :)

Several components come to mind;

  • Rip up the unfinished LED matrix panel to build something huge;
  • Dual analog VU meter panel that’s somewhere lying around collecting dust;
  • A small one using the 2 RGB matrices for the spectrum (2×8 channels probably won’t be that interesting though) accompanied by LED bargraphs;
  • Go LiQuiD-MP3 style one last time and use a 320×240 Planar EL display.

Although it’s something that won’t get off the ground for some time (need to finish the player first), it won’t hurt to add some sort of expansion port to the player where stuff like this can be hooked up to.


Tuesday, July 27th, 2010

Couldn’t resist and upload the FLAC patch to the VS1053b. Tried the lowest bitrate I could find (877kbps) and started playback. Guess what, it played. Not fluently though, SPI transfers went through the roof and DREQ was active 100% of the time, so it wouldn’t respond to anything. But hey it played better than expected!

Hmmmz… AVR  running @20MHz @5V, add a couple 10+ MHz logic level converters and see what surprise that brings… just sounds a whole lot better after this little experiment :)

Finding the limit and power saving

Monday, July 26th, 2010

Well I’m definitely going to make a 20MHz ATmega328p version just to discover where the limit lies with FLAC. Scratch that… apparently Atmel is working with ‘speed grades’ these days, or in other words “Maximum frequency is dependent on Vcc”. Reaching 20MHz requires at least 4.5V and this poses a bit of a problem since all other components require 3.3V or less. Guess this also explains why the 3.3V Arduino Pro Mini board only comes at 8MHz.

In the mean time I’ve been working on getting some basic functionality to work. Currently working are play, pause and stop playback, play next song, continues playback (instead of just 1 song for testing purposes which got a little repetitive after a while ;)), volume control (up, down and mute) and a debug function outputting decode time, samplerate, bitrate and type of file.

Atm I’m trying to get sleep modes working. Also new is card detection. When no card is inserted the AVR goes into the 0.1 uA power down mode. Insert a card and it starts playing. Not fully working yet , but it’s getting there. Also when playback is stopped it should go into idle mode until the play command is received (saving 4 mA).

A command I haven’t got a clue yet on how to implement is shuffle. If anyone has a suggestion,  feel free to add a comment.

I don’t think she can hold much more Captain! She’s gonna blow!

Sunday, July 25th, 2010

It was doubtful from the start, but by now it’s becoming increasingly clear the AVR isn’t going to cut it when it comes to playing FLAC. It’s close, but even at 20 MHz it’s likely any peaks in bitrate will ruin the party. Since Friday I’m been throwing various MP3 and Ogg Vorbis files at the decoder while monitoring data requests.

While all files played fine some variable bitrate files occasionally showed peaks of over 60% at 256kbps. Now take a FLAC with 4 times the bitrate; 1000kbps (average!). In the current setup the AVR runs at 8MHz. Max speed available is 20MHz, only 2.5 times the current speed. Due to the nature of average bitrates, one can’t predict the exact numbers, but you’ll have a pretty good idea of how this is going to end. Maybe with some clever programming and optimisations it could be done… maybe.. could… Don’t know about you, but I don’t like those words. Would be nice to know where the limit lies in reality, so who knows, maybe I’ll give it a go one day.

Time for plan B. Next post, so check back soon.

Let’s dance!

Friday, July 23rd, 2010

We have lift off! Reading the datasheet has once again proved to be the key. The SCI_CLOCKF register is initialised to 0×00 at power up. This means the decoder’s DSP is working at 12.288MHz with a max SPI write speed of 3.072MHz. The result is 2 fold; either the DSP hasn’t got enough decoding power and/or data transfers go out of sync. The ATmega328  is using it’s max SPI speed of 4MHz, roughly 1MHZ more than the decoder. You don’t have to be a rocket scientist to imagine this is a disaster waiting to happen.