Archive for the ‘ARM’ Category

Parts arriving

Thursday, August 5th, 2010


Components started arriving again. Normally this is nothing special, but this time I’ve got a surprise for you (and unexpectedly got one myself…). I’ve been in limbo as to which MCU to use. The AVR is missing a few much needed cycles for FLAC, while the STM32 is overkill. Browsing through Farnell’s catalog, I ran into the Stellaris LM3S800 series which looked like a good middle choice. Not much peripherals, but running at 50MHz for a price of not too much more than the ATmega328p. As good fortune would have it, they had the LM3S818 on sale. It’s almost the same as standard LM3S800, except that it has a few extra things such as 6 ADC channels, 6 PWM pins and a quadrature encoder, but at the expense of I2C and some GPIO (ADC pins can not also be used as GPIO). Let’s see where this takes us.

Unfortunately after unpacking I discovered I made a mistake while selecting components. Instead of 0805 sized capacitors 1 strip had 0402 sized ones… 500 of them… How on earth am I going to solder those… LOL, probably not. To give you an idea of how tiny these little buggers are, they almost fit between the ridges of my fingers:

And that’s not all, it seems I’m fresh out of 28-pin SOIC adapters, so even though all the digital audio out components are present, I can’t use them yet (the CS8406 transmitter is too expensive to just smack on some half baked support board (or even worse a wire web)). Patience my dear readers ;)

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.

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.

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.

ATmega328p

  • 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

STM32F103RET

  • 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

LPC2106

  • 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…

Plan B: Moar powa!

Sunday, July 25th, 2010

A couple of requirements first;

  • ARM Cortex core;
  • 64-pins max;
  • Offline development.

Choosing a Cortex is for the simple reason I always wanted to play with one and it’s the successor of the ARM7TDMI-S core (e.g. NXP’s LPC2000 family). The 64-pin count is to keep the thing solderable (or so I’m hoping since that’ll be a first). Offline development is a strange one, but recently these kind of tools are starting to need an online connection. Take the mbed compiler for example – you need to be online to compile your own software. WTF!? The reason they’re giving in the tour is this: “It’s all online, so you don’t need to be a sys-admin to start. Infact, you don’t have to install or setup anything to get started”. More WTF!? You’re about to play with a very advanced controller and you worry about setting up your dev environment? Please, stay away from controllers, stay very far away. Not to mention the fact you’re dead in the water if your ISP (or theirs) messes things up. No thanks, I’d rather control my own software.

Anyhow… got a little sidetracked there. NXP has some nice options such as the LPC1100 family with an ARM Cortex-M0 core which could be a nice match fro he musicplayer. But unfortunately it’s too new and not decently available yet. We’ve also got TI’s Stellaris family¬†also having a Cortex-M3 core. Last but not least there’s ST’s STM32F family. And the good news is these controllers are available, including a development header board. So I’ve placed an order and if all goes well it should be here in a week or 2. It’s a bit of overkill, but that’s something for another post.