I’m thinking of using an LPC2148 in an MP3 player project. This project would use SPI to read/write data on the MMC card, control the VS1002 decoder chip, as well as write display data to SparkFun’s OLED display.
I’m a little concerned that, with three devices on the same SPI bus, I may experience problems with the audio output.
Worst Case Scenario: say I have to write a full screen of pixel data to the display, while a high-bitrate MP# is playing through the VS1002. Will I have time to refresh the display, read the next block of data from the MMC card, and pump it to the VS1002, before the decoder finishes “playing” the current block of data? How “fast” is SPI, anyway (the LPC will run on a 12MHz xtal, with an internal SYSCLK of 60MHz)?
Remember there are 2 SPI ports on the 2148. You could dedicate one to the audio stuff and put an interrupt in there every so often to write your audio to the MP3 player, then continue with your other stuff. Here’s a quick calculation of maximum datarates:
SPI0
From the user manual on p. 178 -
The SPI0 rate may be calculated as: PCLK / SPCCR0 value. The PCLK rate is CCLK /VPB divider rate as determined by the VPBDIV register contents.
On the same page -
"The value of [SPCCR0] must always be an even number. As a result, bit 0 must always be 0. The value of the register must also always be greater than or equal to 8.
Therefore, with CCLK as 60 MHz (its maximum), PCLK as CCLK/1 or 60 MHz (its maximum, also), and SPCCR0 at 8 (its minimum), your SPI data rate is 60MHz/8 = **7.5Mbps**.
SPI1
Check out page 190 of the user manual -
Given that CPSDVR is the prescale
divider, and the VPB clock PCLK clocks the prescaler, the bit
frequency is PCLK / (CPSDVSR * [SCR+1]).
Therefore, with PCLK at 60MHz, CPSDVSR at 2 (its minimum in master mode…minimum in slave mode is 12…see pp. 191/192), and SCR at 0 (its minimum…see p. 190), your SPI data rate is 60MHZ/(2*(0+1)) = 30Mbps. Whoa, momma!
I remember roach making a comment in the PIC forum(I think) about the Nokia LCD, and 20Mbps (or was it 20MBps… think it was the first), but this may be a solution.
Not sure why I posted this, just wanted to tell someone my thoughts!
Well, really, if anyone’s looking for fast display refreshes and, like, full-frame video or something, they’re not going to go about it in SPI. I’m just thinking of switching to SPI from the 9-bit parallel mode on the OLED display, to save some pins and traces…
your SPI data rate is 60MHZ/(2*(0+1)) = 30Mbps. Whoa, momma!
your SPI data rate is 60MHZ/(2*(0+1)) = 30Mbps. Whoa, momma!
the LCD cant eat data that fast. so your going to need to tame the ARM down a bit first to allow the LCD to gulp down the data input. during those times when the LCD is telling you to wait is when you send / get data from the other devices.
My approach would be an OS or something there of. i have already done what your saying. don’t get me wrong i am not saying it wont work. however using an OS makes is much simpler. one task talks to the LCD while another talks the MP3 part in my case an MAS3587F, another task talks to the flash, and yet another task talks to the touchscreen. this way the time talking to everything is sliced up nicely and things just flow.
…during those times when the LCD is telling you to wait…
. Don’t remember where, but somewhere in the forums, someone was complaining that the OLED display doesn’t have a “busy” signal. ie: it’ll never tell me to “wait”. Am I wrong in thinking the SPI protocol accounts for clock disparities between peripherals, the way I2C does? Would this “wait” functionality be handled in the LPC’s hardware SPI?
My approach would be an OS or something there of. i have already done what your saying. don’t get me wrong i am not saying it wont work. however using an OS makes is much simpler. one task talks to the LCD while another talks the MP3 part in my case an MAS3587F, another task talks to the flash, and yet another task talks to the touchscreen. this way the time talking to everything is sliced up nicely and things just flow.
Hmmm… Well, I’d heard of all those RTOS project, but never really “got” what it was all about. After about ten seconds of research, it looks like the most attractive features of running an OS, rather that custom firmware, seem to be code reuseability and multi-tasking.
The light-bulb has been switched on. This is AWESOME.
Am I wrong in thinking the SPI protocol accounts for clock disparities between peripherals, the way I2C does?
no it will not, what you have to do is control your SPI speed at the rate at which the LCD can swallow the data at. in the mean time you talk to the other devices. without an OS this takes a bit more work to talk to all the devices to give them the illusions they are all working simultaneously.
with an OS its a walk in the park.
The light-bulb has been switched on. This is AWESOME.
I too was once where you are at now. I thought to myself what in the world would i ever need and RTOS for. that is just crazy. all i can tell you is this. stick with it. now that i have been using them i cant imagine doing a project without it. it allows me to do SO MUCH MORE and in less time than straight line code (thats what i call a non RTOS programming).
I am using CrossWorks for my ARM compiler, it comes with a “Tasking library” with is basically another word for RTOS.
