Yeah, but if you get the propeller platform USB from gadet gangster, you already get the micro sd in place. And it's only 50 and it has everything you need really, except for video and audio out but thts easy to get.
Like Peter pointed out, the quiescent current of an SD card is very low when it is asleep (which happens automatically) and anyway for zero-power there can be a p-channel FET under Prop control in line with the SD card power supply (and pullup resistors if any have to be tied to the switched power). From power up to disk mounted, file opened, 250 bytes written, file closed, dismounted and power turned off takes 0.25 second. For frequent card access, leave it mounted, for infrequent access turn it completely off. Quantitatively there is certain point where turning the card power fully on and off is more efficient than leaving it on.
I have a situation where an SD card has to hold sound files that can be changed by the end user simply by changing the card. What happens when you get tired of one bell and want to hear another?
@Sonic. No, most of the 0.25 second is spent initializing after power up and mounting the card. The actual writing of the data, even opening and flushing/closing the file, are a very small fraction of that time. I have quantitative data on that somewhere. The ratio is what is useful for determining whether it is more power efficient to turn it off completely vs leaving it on.
Ah, I asked because you said the time for a file that was 250 bytes was .25 seconds, so I figured a ratio, but basing it off of the numbers I should have gotten 1/1000, which still might not be right. I don't know a ratio to determine size compared to voltage consumtion and all that, but thanks for little facts! I appreciate it!
The format for playing from HUB RAM (loaded from eeprom) is:
8-bit PCM mono 16000 or 8000 sample/second WAV
Ok gang, we've made a little progress this afternoon.
I grabbed a copy of Audacity and ran my magic dinger through that.
Out came a 14K wav file that plays on the Propeller using Rayman's example.
That leaves 18K for program space, so I think we are back on track.
Then I took a wild guess - it looked like the second ding started about 1/4 of the way
into the wav file. So I payed the ding-ding, then jumped past the first and played
a single. That was done by copying the play function in the example.
wOw. It worked. (There's that big grin again!)
except...
There is a bad crunch after the second (single) ding.
10 - 20 ms or so maybe? It's not there in the full wav file.
I'm guessing I'm reading out past the end of the wav file?
But I don't quite completely understand what the example is up to yet.
Ray? What do you think?
I've (hopefully] blocked the code here, and added the wav file as Bells.zip
8000:
dcnt:=10000
16000:
dcnt:=5000
other:
return false
'jump over header
pWav+=44 'ignore rest of header (so you better have the right file format!)
'Get ready for fast loop
n--
i:=0
NextCnt:=cnt+1500
'Play loop
repeat i from 0 to n
NextCnt+=dcnt ' need this to be 5000 for 16KSPS @ 80 MHz
waitcnt(NextCnt)
FRQA:=(byte[pWav+i])<<24
FRQB:=FRQA
pWav+=3600 ' jump past the first ding
i:=0
repeat i from 0 to n
NextCnt+=dcnt ' need this to be 5000 for 16KSPS @ 80 MHz
waitcnt(NextCnt)
FRQA:=(byte[pWav+i])<<24
FRQB:=FRQA
return true
DAT
WAV byte
'File "test8a.wav" ' <--- put your 8-bit PCM mono 16000 or 8000 sample/second WAV filename here
'File "test8b.wav" ' <--- put your 8-bit PCM mono 16000 or 8000 sample/second WAV filename here
'File "test8c.wav" ' <--- put your 8-bit PCM mono 16000 or 8000 sample/second WAV filename here
File "bell2a.wav"
With audacity you can zoom in on the samples, and look at and even edit the actual sound wave, so you would be able to tell where it dropped out, or even went wrong.
There is a bad crunch after the second (single) ding. 10 - 20 ms or so maybe? It's not there in the full wav file.
I'm guessing I'm reading out past the end of the wav file?
Correct. You advance pWav by 3600 but use the original length (n). So either adjust n as well (n -= 3600) or read less in the second loop (and keep n intact).
Other than changing the wav file format (there are zillions of 'em) all I did was fade out at the end.
I thought maybe the data was cutting off abruptly. But not...
There is no =+. Have a look at the manual (rev 1.2, page 43 which lists most if not all of them). Following through to the relevant page(s) you'll find lots of explanations and examples, e.g. += on page 149. HTH
There is no =+. Have a look at the manual (rev 1.2, page 43 which lists most if not all of them). Following through to the relevant page(s) you'll find lots of explanations and examples, e.g. += on page 149. HTH
Ok. Thank you.
Like Mom said, when all else fails, read the manual...
I always thought reading the manual was fun. Honestly, if I didn't read the manual of my PS2 back in 2000, I wouldn't have been interested in electronics.
Comments
I have a situation where an SD card has to hold sound files that can be changed by the end user simply by changing the card. What happens when you get tired of one bell and want to hear another?
Ok gang, we've made a little progress this afternoon.
I grabbed a copy of Audacity and ran my magic dinger through that.
Out came a 14K wav file that plays on the Propeller using Rayman's example.
That leaves 18K for program space, so I think we are back on track.
Then I took a wild guess - it looked like the second ding started about 1/4 of the way
into the wav file. So I payed the ding-ding, then jumped past the first and played
a single. That was done by copying the play function in the example.
wOw. It worked. (There's that big grin again!)
except...
There is a bad crunch after the second (single) ding.
10 - 20 ms or so maybe? It's not there in the full wav file.
I'm guessing I'm reading out past the end of the wav file?
But I don't quite completely understand what the example is up to yet.
Ray? What do you think?
I've (hopefully] blocked the code here, and added the wav file as Bells.zip
8000: dcnt:=10000 16000: dcnt:=5000 other: return false 'jump over header pWav+=44 'ignore rest of header (so you better have the right file format!) 'Get ready for fast loop n-- i:=0 NextCnt:=cnt+1500 'Play loop repeat i from 0 to n NextCnt+=dcnt ' need this to be 5000 for 16KSPS @ 80 MHz waitcnt(NextCnt) FRQA:=(byte[pWav+i])<<24 FRQB:=FRQA pWav+=3600 ' jump past the first ding i:=0 repeat i from 0 to n NextCnt+=dcnt ' need this to be 5000 for 16KSPS @ 80 MHz waitcnt(NextCnt) FRQA:=(byte[pWav+i])<<24 FRQB:=FRQA return true DAT WAV byte 'File "test8a.wav" ' <--- put your 8-bit PCM mono 16000 or 8000 sample/second WAV filename here 'File "test8b.wav" ' <--- put your 8-bit PCM mono 16000 or 8000 sample/second WAV filename here 'File "test8c.wav" ' <--- put your 8-bit PCM mono 16000 or 8000 sample/second WAV filename here File "bell2a.wav"I thought maybe the data was cutting off abruptly. But not...
I thought so, but wasn't quite sure how to write it.
These double character operators are all new to me - and very strange.
To the point:
is += the same as =+ ??
.
Is there a primer on this stuff somewhere?
Ok. Thank you.
Like Mom said, when all else fails, read the manual...
399 pages of PDF.
And I can't take it in the bathroom with me.
I can't think of anything more inclined to make my eyes bleed.
http://www.youtube.com/watch?v=EGeoG0KQa68
Come on, Martin. It's 8 bit stuff...
I know I'm sixteen bit.....
Well... If the task is too difficult, I can understand...