Archive for July, 2010

Farmer blockade stalls Munich’s Olympic bid

Friday, July 30th, 2010

Something completely different:

“Glatz accused state leaders and the local Olympic committee of having simply assumed that the property was theirs to use if the region wins the bid and to have ignored warnings to the contrary.

Great, hope they stand their ground.  Not that it helps, but hereby I offer them official Doucheputje support :D

Expensive pixels

Thursday, July 29th, 2010

Another thought brewing somewhere in the back is manual control of the player. Would be pretty annoying if the remote runs out of power and you’re fresh out of batteries. If it gets manual control, it must give feedback on the player itself. Don’t want to use a LCD based display on the player side and I remember those old, but cool looking, alphanumeric LED like displays. They used to be made by HP, but somewhere along the road Avago Technologies took over.

Anyhow, these display are damned expensive! Not really a proper comparison, but pixel for pixel these things are even waaaaay more expensive than a colour OLED. A 4 character module is half the price of a 320×240 colour OLED including touchscreen… geez… but they remain cool!

Don’t forget a quick look here if you like these modules.

(Photo by svofski *cough* no permission asked, just accept the fact that everything on the net is public property *cough*)

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.

Exploring STM32 part 2; SDIO

Wednesday, July 28th, 2010

Something I’m especially looking forward to is SDIO. It’s an unexpected bonus that comes with the particular STM32 I’ll be using. Of course I could use SPI (it has 3 of those) as is currently the case on the AVR, but where’s the fun in that.

While SDIO supports various things (has anyone actually ever used MMC?), the only thing of interest is SD memory card support. The SDIO features include SD memory card specification v2.0 which means it works with SDHC cards. One thing to remember is that it does not have a SPI compatibility mode. I’ll have no choice but to whip up some new code. Haven’t found any publicly available example yet, so this should be fun.

Now I’m not going into details concerning SD card communication. That’s all neatly written up in the spec and not too hard to understand, so no need to repeat it here. What’s going to make a big difference is speed. Up till now the AVR has been doing SPI @4MHz. With SDIO this goes up to 25MHz. Another difference is that SPI only has 1 data line, while SDIO does 4 bits at a time. It uses push-pull for command transfers, although I have no idea yet what that means.

There’s also a control unit offering power management by disabling card bus output signals and clock. Another neat feature is the command path which has command and response registers. There’s much more, but for now this’ll do.

Oh one potential trick I can’t repeat is reading data from the SD card directly into the decoder. Usually data is read sector sized into some sort of buffer before being processed (e.g. send to the decoder). This means data travels over the SPI bus twice. Now instead of reading an entire sector into a buffer, send the command to read a sector and receive the data 32 bytes at a time keeping as eye on DREQ of the decoder. The decoder has it’s data select signal active (or it won’t process the data), while the controller is only clocking the signal (being the SPI master). This way data travels only once over the bus directly into the decoder. Note this is only valid for audio data processing, not sending commands to the card and decoder, nor processing of card responses. This trick matters a lot for the AVR since it’s operating at it’s upper limit, but the STM32 is so powerful I doubt it will break a sweat without this trick. (please note I have not yet actually tried this nor thought it through all the way, assume this will burn down your house for the time being…)

Just don’t do this. Selecting both SD and the decoder will cause both their outputs to come out of hi-Z. This could potentially destroy both devices.


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

Uploading code using STM32 bootloader

Tuesday, July 27th, 2010

First order of business; figuring out how to get some code into the ARM. According to the 1072 page reference manual it has an embedded boot loader which is programmed by ST during production. It can be used to program the Flash memory through USART1. Before programming 1 of 3 boot modes must be selected. To do this there are 2 pins which must be set to the “System memory” configuration (BOOT0=H and BOOT1=L). Now reset the controller to activate the bootloader.

Hooking it up to a computer requires only RX and TX (USART1_RX/PA10 and USART_TX/PA9). The ordered headerboard comes with a RS-232 transceiver and cable. Now I could use that one, but seeing I have a bunch on FT232R IC’s and breakout boards lying around, I’ll settle for a virtual COM port instead. At first I was expecting having to strip the RS-232 transceiver. But after wrestling my way through a Thai website a schematic of the board was located and pins PA9 and PA10 are readily available. So no modding needed after all.

With the hardware part taken care of all that’s needed is a Flash loader app. Fortunately ST provides a (fully functional?) demo app called “Flash loader demonstrator“. 2 versions are provided; GUI and commandline. Unfortunately both are Windows only.

Replacing AVR with ARM, now what?

Tuesday, July 27th, 2010

Now that the decision has been made, what’s next? I’ve started reading up on the STM32F controller and there are literally thousands of pages of technical stuff. To get through this I’m going to pick some subjects relevant to the musicplayer and make a post on each subject over the coming days/weeks. It might be interesting to anyone reading my blog (lol, is anyone actually reading this?), but the main purpose is to get this stuff clear in my head.

Bye bye anonymous voting?

Monday, July 26th, 2010

A few years back we had electronic voting machines. After Wij vertrouwen stemcomputers niet found various weaknesses in the system (you could manipulate results and read a person’s vote through EM radiation), we the Dutch were back to red pencils and voting ballots.

Last year we got mandatory fingerprints in your passports shoved down out throats. As far as I know our (still demissionary) cabinet has only been talking about storing fingerprints in a central database, but considering their past decisions it’s likely our privacy gets shot to hell again.

Now combine the ballots with fingerprints and who can guarantee there won’t be a mischievous department or organisation trying to match fingerprints on ballots with an unwelcome vote? Think about it…

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.

STM32F103xE vs ATmega328p quick peak

Sunday, July 25th, 2010

Now that the new controller is on its way, it’s time for a small comparison while looking at the musicplayer requirements. The difference is huge. First of all the STM32F is a 32-bit controller with more of everything. In other words it’s like comparing a pig with a chicken and pretty pointless, but well worth a quick look.

First a couple of specs. Just a small selection, I’d recommend the datasheets for a complete list. I’ve also added the LPC2106 for comparison.


  • Low-power 8-bit AVR @20MHz
  • 32 kB Flash, 2 kB SRAM, 1 kB EEPROM
  • 1x SPI, 1x USART
  • Active: 0.2 mA, power-down: 0.1 uA, power-save: 0.75 uA
  • TQFP32 package


  • 32-bit ARM Cortex-M3 core @72MHz
  • 512 kB Flash, 64 kB SRAM
  • 3x SPI, 5x USART
  • SDIO
  • Active: 69 mA, sleep: 45 mA, stop: 35 uA, standby: 3.8 uA
  • LQFP64 package


  • 16/32-bit ARM7TDMI-S core @60MHz
  • 128 kB Flash, 64 kB SRAM
  • 1x SPI, 2x USART
  • Active: 40 mA, idle: 7 mA, power-down: 10 uA
  • Requires 1.8V and 3.3V
  • LQFP48 package

Ignoring the raw numbers, what does this mean for the musicplayer project? It has SDIO, meaning faster SD card access. Playing FLAC files results in lots of data transfers, so the more efficient this handled, the better. Combined with raw processing power this also means FatFs can be fully unleashed. It would also allow sending way more trackinfo to the remote without interrupting playback.

On the AVR I’ve been using its little brother Petit FatFs using FAT32 with 8.3 filenames, single fileaccess and read only. Using the full version means multiple files at once, probably improved shuffle/random functionality and maybe even tag reading.

Alas, having all this advanced circuitry at our disposal has a downside… double lead count and increased power consumption. It’s a subject I haven’t thought about much, but the general idea was to keep power as low as possible. One thought is to use a LiPo battery and small solar cell, so lower power consumption equals longer playtime.

Hmmm, that LPC2106 doesn’t look so bad considering the lead count and power consumption…