A few questions directed towards Steve about his player, but anyone else is free to jump in and answer them as well.
OK built the circuit, tweaked the SD card routines to the newer syntax, did a few other code swaps as I used an EasyPic5 development board and the 2x16 pins were different. Anyway it's up and running now, and actually produces pretty good audio, at least from my very limited testing thus far.
So my hats of to Steve, job well done!
Now on to a few questions,
1. I looked into trying to wrap my head around measuring impedance but lost my way pretty fast, so my question is what is the output impedance of the circuit, is it below the 50K threshold that say an LM386 would be happy with?
2. Crystal selection, in the circuit it's spec'd as 20MHz, I didn't have a 20MHz crystal laying around so I dropped in an 20MHz resonator, into the Easypic5 board. Don't know if it was a conflict with the developer board or what but playback was slowwwww. It still worked but was stuck in mud. But after looking things over I questioned the 20MHz value, so I popped in the default 8MHz crystal and it sprung to life, timing appears to be just slightly off, adding about 1 second to every 60. So my question is three fold in this regard:
a. Is 20MHz correct in the diagram, or should it be 8MHz?
b. The clock is set to 32 in the code, with HSPLL, How does that work with a 20MHZ crystal, doesn't this point towards an 8MHz crystal?
c In the code 'Const TimerReload = 65036' where is this value derived from? And how would one calculate it for different sample rates?
I probably have a few other questions but they are not coming to me off the top of my head right now, so this is a good start.
SDMMCWavPlayer
Moderators: David Barker, Jerry Messina
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Lets start with the easy one first...the timing.
You're right, the circuit should have an 8MHz osc, not the 20MHz shown in the diagram.
Since it's setup for HSPLL mode, this runs the uC at F=32MHz. The timers run at F/4, which
in this case is 8MHz (0.125us per tick). The code is setup assuming the wav file sample rate
is 16000Hz, which is 62.5us per sample. To figure out how many timer ticks you need, divide
the 62.5us sample rate by 0.125us timer tick and you get the timer reload value, which is
62.5us/0.125us = 500. Pic timers count up and generate an interrupt when they overflow FFFF->0,
so you reload the timer with the max count 65536 - 500 = 65036. Note: this doesn't account for
the few instruction cycles that it takes to actually get the intr and reload the timer, which
is why you see it gain time over the course of 60 seconds. You can correct for this if you take
a look at the code generated and count the instruction cycles of overhead. It's usually somewhere
in the range of 10 cycles or so as a ballpark figure.
Now, the output...
As far as the output impedance goes, it's pretty high and going to vary quite a bit over the freq
range, starting out high and decreasing as the frequency increases. If it helps figuring it out,
the R-2R ladder has a pretty constant impedance of R, which is 10K as shown. But, if you want to
drive an amp like the LM386, your actually going to want to INCREASE the output impedance! As shown,
with a 50K load like the LM386 presents, the output voltage would be about +/-800mV. The LM386 has
a max input voltage spec of +/-400mV, so you'd be overdriving the input by quite a bit. If you change
the 47K/4.7nF RC low-pass filter values to something like 200K/2.2nF, you should be in better shape.
That would give you a max output of +/-380mV driving 50K, and give about the same sort of filtering
(down ~16dB at 8KHz) as the original.
Jerry
You're right, the circuit should have an 8MHz osc, not the 20MHz shown in the diagram.
Since it's setup for HSPLL mode, this runs the uC at F=32MHz. The timers run at F/4, which
in this case is 8MHz (0.125us per tick). The code is setup assuming the wav file sample rate
is 16000Hz, which is 62.5us per sample. To figure out how many timer ticks you need, divide
the 62.5us sample rate by 0.125us timer tick and you get the timer reload value, which is
62.5us/0.125us = 500. Pic timers count up and generate an interrupt when they overflow FFFF->0,
so you reload the timer with the max count 65536 - 500 = 65036. Note: this doesn't account for
the few instruction cycles that it takes to actually get the intr and reload the timer, which
is why you see it gain time over the course of 60 seconds. You can correct for this if you take
a look at the code generated and count the instruction cycles of overhead. It's usually somewhere
in the range of 10 cycles or so as a ballpark figure.
Now, the output...
As far as the output impedance goes, it's pretty high and going to vary quite a bit over the freq
range, starting out high and decreasing as the frequency increases. If it helps figuring it out,
the R-2R ladder has a pretty constant impedance of R, which is 10K as shown. But, if you want to
drive an amp like the LM386, your actually going to want to INCREASE the output impedance! As shown,
with a 50K load like the LM386 presents, the output voltage would be about +/-800mV. The LM386 has
a max input voltage spec of +/-400mV, so you'd be overdriving the input by quite a bit. If you change
the 47K/4.7nF RC low-pass filter values to something like 200K/2.2nF, you should be in better shape.
That would give you a max output of +/-380mV driving 50K, and give about the same sort of filtering
(down ~16dB at 8KHz) as the original.
Jerry
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Thanks I will, just need to wrap my head around the whole thing.Steven wrote:Hi - thanks for the kind comments and thanks also for your detailed answer Jerry. Sorry, the 20MHz in the diagram was a mistake on my part - thanks for spotting. Enjoy tinkering.
Also any thoughts on a port to the new PIC18F45K20? And any input on what the 64MHz clock speed on the 18F45K20 might be able perform with the existing code and a few tweaks, maybe 16-Bit 22kHz playback or ?
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
It's hard to guesstimate what the upper limit would be. A lot of that would depend on the performance of Steve's SD filesystem, and I haven't used that. For 22KHz 16-bit playback, you'd need a minimum of 2x22K=44KB/sec read performance, or you'll eventually underflow the buffer.
The intr routine could be tweaked to handle this speed (if it doesn't meet it already)...I just don't know about the rest of it. From Steve's comments, it seems like 16K was about the upper limit @32MHz, but I'm not sure where the bottleneck is. Remember that as you push the intr frequency faster, that leaves less time for the main loop to read and buffer the sdcard data.
If you want to extend it past 8-bits, you're probably going to have to drop the R-2R ladder approach and use a real DAC. At 8 bits, you're already asking for 1 part in 256 of accuracy, or better than 0.5% match.
The intr routine could be tweaked to handle this speed (if it doesn't meet it already)...I just don't know about the rest of it. From Steve's comments, it seems like 16K was about the upper limit @32MHz, but I'm not sure where the bottleneck is. Remember that as you push the intr frequency faster, that leaves less time for the main loop to read and buffer the sdcard data.
If you want to extend it past 8-bits, you're probably going to have to drop the R-2R ladder approach and use a real DAC. At 8 bits, you're already asking for 1 part in 256 of accuracy, or better than 0.5% match.
I actually want to drop it already but I'm not having much luck finding many 8-bit DACs that are reasonably priced and suited. 10, 12, 16 no problem there seems to be plenty of those to choose from, admittedly I have not looked real hard though.Jerry Messina wrote:If you want to extend it past 8-bits, you're probably going to have to drop the R-2R ladder approach and use a real DAC.
Right now I have to spend the time to at least move the R-2R later to a soldered board, the stab lock board has outlived it's usefulness for this project.
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Yeh, that doesn't surprise me. It's been a long time since I looked for a parallel 8-bit dac... most of them these days that are that small have some sort of serial interface. The old stuff is probably outrageously priced.
If you find a larger one that you're happy with, you can just connect the 8 bits up to the dac's upper bits, and ground the lsbs you're not using. That way, you'd even be able to play with extending the resolution as desired.
If you find a larger one that you're happy with, you can just connect the 8 bits up to the dac's upper bits, and ground the lsbs you're not using. That way, you'd even be able to play with extending the resolution as desired.
Here you are:CocaCola wrote:I actually want to drop it already but I'm not having much luck finding many 8-bit DACs that are reasonably priced and suited. 10, 12, 16 no problem there seems to be plenty of those to choose from, admittedly I have not looked real hard though.Jerry Messina wrote:If you want to extend it past 8-bits, you're probably going to have to drop the R-2R ladder approach and use a real DAC.
Right now I have to spend the time to at least move the R-2R later to a soldered board, the stab lock board has outlived it's usefulness for this project.
http://search.digikey.com/scripts/DkSea ... 24KRZ-1-ND
$10 a pop, really doesn't really meet my reasonable cost criteria as it instantly doubles the cost of the circuit.MattH wrote:Here you are:
http://search.digikey.com/scripts/DkSea ... 24KRZ-1-ND
OK back for round two since the forum was so helpful last time.
So here is the deal, like I said previously I was really impressed with the little wav player, so much so that I would hopefully like to expand upon it's design. Maybe in the reverse direction most would take but it better fits my ideas on application right now.
What I would like to do is yank out the SD card read routines and replace them with some sort of IC based memory like an EEPROM or flash chip. In principle it seems easy, as I believe the core play routines can pretty much be left alone and it should require a much simpler read routine instead of the full blown SD file system, but in practice it's a little beyond me right now.
So I'm hoping someone can grab my hand and help me out.
I know cost wise the EEPROM or flash chip doesn't make sense but for a few applications I would like to explore where potting of the circuit might be necessary and the removable card isn't practical in that application. Also in my application it would be a single sound of 1-3 seconds so not overly burdensome in memory requirements. Although a simple file system where a few tracks could be loaded would be cool, even if it's only one track per EEPROM to make the most basic file system of simply selecting the appropriate EEPROM to play.
So if anyone would like to entertain showing me the way that would be great!
I found a similar IC based player normnet did but right now I'm hoping to stick with the Swordfish design and it's simplicity.
BTW I just picked up some PIC18F45K20 chips so I hope to explore the possibility of squeezing a little more sound quality out of the original design as well in due time.
So here is the deal, like I said previously I was really impressed with the little wav player, so much so that I would hopefully like to expand upon it's design. Maybe in the reverse direction most would take but it better fits my ideas on application right now.
What I would like to do is yank out the SD card read routines and replace them with some sort of IC based memory like an EEPROM or flash chip. In principle it seems easy, as I believe the core play routines can pretty much be left alone and it should require a much simpler read routine instead of the full blown SD file system, but in practice it's a little beyond me right now.
So I'm hoping someone can grab my hand and help me out.
I know cost wise the EEPROM or flash chip doesn't make sense but for a few applications I would like to explore where potting of the circuit might be necessary and the removable card isn't practical in that application. Also in my application it would be a single sound of 1-3 seconds so not overly burdensome in memory requirements. Although a simple file system where a few tracks could be loaded would be cool, even if it's only one track per EEPROM to make the most basic file system of simply selecting the appropriate EEPROM to play.
So if anyone would like to entertain showing me the way that would be great!
I found a similar IC based player normnet did but right now I'm hoping to stick with the Swordfish design and it's simplicity.
BTW I just picked up some PIC18F45K20 chips so I hope to explore the possibility of squeezing a little more sound quality out of the original design as well in due time.
Just a friendly bump, anyone willing to help out on porting an embedded memory solution? As I said it's a little beyond me right now but I'm willing to push the learning curve.
Right now I'm leaning towards the SST 32Mbit SPI Serial Flash instead of an SD card.
http://www.sst.com/dotAsset/40373.pdf
Any thoughts?
Right now I'm leaning towards the SST 32Mbit SPI Serial Flash instead of an SD card.
http://www.sst.com/dotAsset/40373.pdf
Any thoughts?
See M25P32 PIC Audio.CocaCola wrote:Just a friendly bump, anyone willing to help out on porting an embedded memory solution? As I said it's a little beyond me right now but I'm willing to push the learning curve.
Right now I'm leaning towards the SST 32Mbit SPI Serial Flash instead of an SD card.
http://www.sst.com/dotAsset/40373.pdf
Any thoughts?
Warning other compiler.
ST M25P32 32Mbit SPI serial flash.
Their should be a newer version though.
Don't be intimidated by the code length.
Just start with porting the READ_ID: subroutine and go from there.
Norm