Audio from PIC SPI

[Synergy6]

Hello,

I am currently in the process of designing an audio player.
The plans is as follows,

PIC Microcontroller (receives commands via I2C on which file to play, Outputs file data via SPI)
SPI DAC, Takes SPI data and turns it analogue (better than PWM??)
Audio amplifier (D CLASS, takes analogue data and amplifies it.)
MEMORY, Havnt yet decided on SDcard or FRAM or similar.


The PIC needs to stream the audio out through the SPI at 44.100KHz. Is there a way to set this or keep it under control?? If i just send data as fast as possible i would far exceed this speed.
Is there anything in particular i would need to consider when selecting the appropriate PIC??

Thanks in advance.

[Benj]

Sounds like an interesting project, you'll have to keep us updated on how you get on.

The PIC needs to stream the audio out through the SPI at 44.100KHz. Is there a way to set this or keep it under control??

I would create a timer interrupt that will fire at 44.1KHz and this way on each interrupt you can simply write the next data to the DAC.

Is there anything in particular i would need to consider when selecting the appropriate PIC??

Speed will be an issue, I would recommend one of the EP 16-bit PIC devices as these have a max speed of 70MIPs (140MHz).

MEMORY, Havnt yet decided on SDcard or FRAM or similar.

SD card will be easier to load with data e.g. a WAV file, but you will have to perform buffering when doing things like moving to the next file sector. FRAM will be more effort to load with data but will then stream out much simpler.

An example of streaming audio from an SD card can be found here. Macros start with WAVxxx
viewtopic.php?f=54&t=16848&p=73371#p73371

[Synergy6]

Hi Ben,

Thanks for the quick reply.

Timer is a good shout, i think i can work that one out.

PIC Speed, is it simply a case of faster the better? I assume that if streaming at 44.1KHz but clock speed of 140MHz then there is loads of time between interrupts to be gathering data from the memory. If this were the case could you help me calculate how much data could be captured. This will help me work out how much data i should try and get from the memory and put into the buffer.

I think i will try and work with the FRAM, saves me having SD Card slots etc. In its final application the user wont be able to get to the board so it makes sense to me.

Im off to look for a decent PIC

Thanks for the advice, hopefully i am on the right path now.

[QMESAR]

Im off to look for a decent PIC

You do not have to look very far just look st the MATRIX ECIO40P16 and you have dent dsPIC33EP which is designed for signal processing stuff I would guess a great fit for your application

[Benj]

Hello,

44.1Khz x 16-bit samples = 88,200 bytes per second of memory required in raw form e.g. WAV file format.

It depends on the quality you need but I have found 8KHz x 16-bit samples is pretty good quality for most purposes. This equates to 16,000 bytes per second.

Beware some memory devices (and broadband providers) specify the amount of memory in Kb not KB, Kb is a thousand bits which equates to 125 bytes.

[Synergy6]

Slightly off topic but i just need to clarify something...

On the DSPIC33EP32GS202 that i have selected to use, The chip doesnt have any specific SPI port. Instead there are "RPxx" pins.
Is there any restriction as to which pin can be mapped for a specific task??

[QMESAR]

On the DSPIC33EP32GS202 that i have selected to use, The chip doesnt have any specific SPI port. Instead there are "RPxx" pins.
Is there any restriction as to which pin can be mapped for a specific task??

You should check the datasheet in chapter Peripheral Pin select, peripherals do not map to every pin on the device it is relatively flexible however there are some restrictions on some devices.
just a note the GS devices are specifically for Switch mode power supplies I think a GP or a MU device would suite you better

[Synergy6]

I did look at the GP and MC versions, but they run at half the speed. Only 60MHz instead of 140MHz.

There shouldnt be a problem using the GS version should there??

[QMESAR]

There shouldnt be a problem using the GS version should there??

No not at all however they are much more expensive than the other ones ,they have special ADC's and PWM modules,
This is a good device for your application and runs at 70MHZ (140Mhz clock)
dsPIC33EP256Mu806 ( see MATRIX ECIO P16) or the bigger brother dsPIC33EP512MU810

[Synergy6]

I have actually just realised that this PIC is not supported in Flowcode. The MC version is but its not as fast.
Is this chip a no go Ben?

[QMESAR]

The MU versions are supported in FC and they run at 140MHZ
look here at the MATRIX Datasheet
http://www.flowcode.co.uk/webshop/40-pin ... -ecio.html

[Benj]

I'll get them on the list, the compiler seems to support them so hopefully shouldn't be a massive issue. However they are untested and so time critical applications may suffer.

From what I have seen the EP devices come in two flavours, the 60 MIPs 120MHz variant and the 70 MIPs 140 MHz variant. Most chips should have options for which speed is available.

I have had a lot of success with the MU and GU range, we did the ECIO40P16 based on the MU device and I believe the GU devices have been used to host our Ghost technology up to Flowkit v2, all running at 70MIPs.

The EB091 uses the same chip and this is what I used for my PIXL TABL project.
https://www.instructables.com/id/RGB-LE ... ing-Table/

[Synergy6]

The MU series are physically too big for the application, space is limited. I have just checked the datasheet for the,

DSPIC33EP32MC202 and it says it can do 60MIPS, In the description it said 60MHz which is why i dismissed it. Its on the flowcode list so i think i should be good to go.

[QMESAR]

The MU series are physically too big for the application, space is limited. I have just checked the datasheet for the,
DSPIC33EP32MC202 and it says it can do 60MIPS, In the description it said 60MHz which is why i dismissed it. Its on the flowcode list so i think i should be good to go.

This is only a question of the package you choose, all members of the family are available in all the package types, the device number has nothing to do with the physical size its the package type that determine the size

[Synergy6]

So i have chosen a DAC for this project. 16bit DAC are silly money and a bit over complicated for my needs. So i have gone for a 12bit DAC. I am told that the loss of quality will be minimal and hardly even noticeable.

[Benj]

We use the AD5662 16-bit DAC on the EB086 board.

Schematic available here.
http://www.flowcode.co.uk/old_site/resources/getr ... php?id=720

However as you say if your sticking to the sample rate of 44.1KHz then a 12-bit DAC would likely be almost as good.

If you were dropping the frequency to save on data say to 8KHz or 16KHz then the 16-bit DAC would make more sense to keep the quality high.

[Synergy6]

Ben, Maybe you can help with something.

The PWM on the DSPIC33, it seems to be split into 2 pins, a High and a Low.
How does this work? Can i essentially use the PWM as a 16bit DAC?

If it were 1 16bit PWM pin then i could understand it, but since its split i dont get how it could be used?

[Benj]

Hello,

That's the advanced motor control PWM that we don't support. We use the much more basic CCP (capture compare) PWM which is a single pin output as you would expect.

Yes you could use PWM to create an analogue waveform, I have done so before. From experience a DAC does a much better job and the resulting audio is much cleaner.

Also keep in mind running at 70 MIPs with a 16-bit period (65535) and a /1 prescaler the fastest frequency you can output would be 1.068KHz.

Ideally a PWM based analogue output needs at least 3 periods to settle correctly which would mean at 16-bit resolutions it's more like 356Hz output which is far too low.

If you dropped the output resolution to 12-bit period (4095) then the fastest frequency you can output would be 17.089KHz.