Archive for the ‘testing’ Category

US export regulations

Wednesday, April 20th, 2011

Going to play around with a Coolrunner-II CPLD so I thought it would be a good idea to get Xilinx’ free ISE WebPACK. Guess what, that was a bad idea. The US wants my home address and phone number:

US export regulations require that your First Name, Last Name, Company Name and Shipping Address be verified before Xilinx can fulfill your request. Please provide accurate and complete information for immediate processing. Sorry, addresses with Post Office Boxes and names/addresses with Non-Roman Characters with accents such as grave, tilde or colon are not supported by US export compliance systems.

Fucking nazis…. No way I’ll give them the requested info. Hell they already monitor my bank transactions (do they really think any half decent terrorist uses the ‘system’ and risk a big fat red flag behind their name!?). Filling in bogus info does the trick just fine ;)

On a related matter, Mouser does not sell Xilinx products. Looks like an alternative CPLD is needed for any future development.


Saturday, April 2nd, 2011

Lots-o-markers (sorry no fancy visual thing… can’t insert a map in WordPress?)

Just a 5 minute experiment to see what our public transport peeps have been up to. Seems they opened up their data through an XML based API. Besides it’s a good excuse to take a quick look at Google Maps’ API.

Limit found

Sunday, March 6th, 2011

Hmmm, it seems I’ve crossed a limit in the current setup. Just gave it a 1080p x264 video @10Mbps with DTS 5.1 96 kHz/24 bit @1.5Mbps to chew on. 100% CPU usage and slowed down playback. Still no sound, so the DTS stream might not even play a role. My guess is hardware decoding is not used by mplayer and/or fglrx driver. Let’s call it a challenge =)

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.


Dev boards

Monday, September 27th, 2010

Yee a new ‘toy’ has arrived. After waiting only 3 months to the day, a little carton box containing TI’s MSP430 Launchpad board finally found it’s way to my doorstep. It was cheap, comes with free tools and no shipping costs which is a huge pro if you just want to try a new product. No idea what to do with it yet, but I’m sure something fun can be made with it.

Also very nice are the extras. Apart from the nice box it comes in, it includes 2 controllers (2211 and the 2231 which has an USI and ADC), a 32.768 kHz crystal, headers and an USB cable. And to top it off there are 4 anti-slip pads beneath the PCB (it’s often in the small details). Kudos to TI!

Btw, this thing is actually sold below the actual cost of the parts. Just the 2 LQFP IC’s (a Serial-to-USB Converter and a 16-bit ULP MCU with 55kB Flash and 5120B RAM) are over $10 @1k units.

Speaking of dev boards, ST recently introduced a nice STM32 board. According to ST you can get one for under $10, but I haven’t seen those, not even at the distributors they link to. A more realistic value is €12,55 which boils down to $16,90 incl VAT at today’s exchange rate. Yes that’s right, 160% more than ST advertises with. Still not bad, but saying it’s under $10 is just a big lie.

Anyhow, I’m thinking of getting 1, mainly for quick testing. Right now the Futurlec board and some chips is all I’ve got, which is a bit of a pain when you quickly want to swap boards for some simple testing. Besides that I’m looking forward to giving that ST-link thing a try.

The downside is that ST throws up some barriers. You can only buy the board through big distributors, which for us Europeans means you’re screwed as a private person. These distributors won’t even talk to you unless you place a minimum order value which is way higher than the board alone. ST can learn a thing or two from TI when it comes to bringing their products to a wider audience.

Secondly the whole ST-link thing only comes with Windows software. However no surprise there given their complete lack of non-MS support previously. A bit of a downer, but no show stopper.

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 :)

Another milestone reached

Sunday, September 12th, 2010

Good news, SDIO is working, including an upgrade from Petit FatFs to FatFs.

Basically there were 2 problems. Some time ago I ripped some stuff from the breadboard to tidy things up a bit. Unfortunately this included a wire connecting the PSU to the right most power rail. As fate would have it this is where I attached the 3,3V of the SD card socket to a few days later. As long as the missing connection was well.. missing, the SD card was powered by the SDIO signal lines through the pull-up resistors. This resulted in unexplainable behaviour such a Kinston card to timeout at CMD8 and a Sandisk card never completing the voltage validation cycle.

The other thing were CRC errors during transfers. 25 MHz is simply too much for the current setup, which in all honesty isn’t really surprising given the long and poor connections. A real PCB and some pull-up resistor tweaking should make a speed increase possible. Currently it’s running at 4,2 MHz (simply because 0x0F is an easy to remember CLKDIV value ;)), but what this means in data throughput numbers… no idea yet.

Oh and it uses DMA, which also is a nice addition!

SDIO power up

Wednesday, September 8th, 2010

Time for a little update. SDIO code is ready and under testing, although that’s not exactly going according to plan. After sending CMD8 it times out and the fun is over. A little annoying problem, but interesting nonetheless. For example did you know what the D0 signal looks like directly after setting the power state to on? Now you do ;)

Notice the long power up / supply ramp up time and the voltage it stabilises at.

Desk meets head

Saturday, August 21st, 2010

Finally got a change to pick up the STM32 USART issue again after a few hectic days. Which wasn’t a bad thing since it offered a fresh look and I quickly found the root of the problem. The headerfile containing the list of command defines to control the player defined RESET as well. But since I hadn’t touched that file after migrating existing code to the STM32, I never thought of it. Renaming that specific define solved it all and all pieces of the puzzle fell into place.

There’s just 1 thing bothering me. Why didn’t the compiler warn about a redefinition? Even after explicitly enabling all warnings with -Wall you don’t get a redefinition error.