Roman Black Sound (btc)

[Bruce]

Roman. Very nice utility you have there. Nice work. I was totally surprised when I ran Darrels' example, and it sounded as good as it did. Way impressive.

Darrel. I'm always impressed with your macros. I'm really surprised I don't see more of the #V option used in Microchip macro examples. That ImportSound macro was really impressive work. I would have to call that one "art". You just don't see this. Even in some of the more advanced code examples from engineers that work for Mchip.

You really should write more articles on using built-in PBP macros & using various MPASM macro options. Honestly.

I also like your use of the EXT option with PBP. Timer1 VAR WORD EXT is really cool, as long as some newbie doesn't setup an 18F part for a 16-bit R/W timer..;o}

This project has some very serious potential. Background sounds with ints is a major hint. I would bet this could even beat something like the SpeakJet with a little more work.

I'm looking forward to seeing where this one lands for sure..;o}

[THE_RB]

OK thanks for writing that all up Darrel, it all seems to make sense now.

You are right in that it is probably the best solution for everybody for me just to export the sound data already in the formats you need for PBP. So I need to add 3 export options to the BTc Encoder export menu!

Lets see if I got this right;
(with all formats bits are played from left to right)

1. retlw format for 14 bit core PICs;
Ok so if I understand you right you want NO ORG statements at all and the sound data formatted vertically like this;
retlw 0x55 ;
retlw 0x46 ; (etc)

2. DA (or DW which do you prefer?) for 14 bit core PICs;
DA 0x1551, (x8 words per line?)
(where there are 14 bits from the BTc data stream, and left padded with 2 zeros)

2. DW (or DB ?) for 16 bit core PICs;
DW 0x5546, (how many per line?)
(or) DB 0x55, 0x46 (etc)
(obviously 16 bits of sound data or 8 bits of sound data)

I have time over the next 2 weeks to add these 3 export options, if you could just answer the above queries that would be great!

Re the "small" 14 bit core PICs, the 16F876/877 are still very popular with the hobby crowd and with 15625 Hz playback they will fit about 4 seconds of sound in internal rom which is quite a lot, plenty for talking remote controls and simple user feedback systems etc.

To Bruce- I agree totally that a cut down int driven version is a good thing. Part of the reason I added freq resampling to the BTc Encode was so people can play sound at any bitrate their int uses, ie like 4mHz/inst and 256 inst/int gives 15,625 Hz which has been a popular playback freq. All the int needs to do it output one bit every int, as you can image that suits low power PIC projects. I have some .asm code of my own for cut down apps which is crude but I will put it up on my page soon anyway. Believe me it has nothing like the elegance of Darrel's code above!

Also re sound quality, I think maximising volume of Darrel's samples would have given even better sound quality. As the PCM noise is of a fixed amplitude, pumping the signal volume to the max BEFORE encoding yields a major improvement in sound quality.

[Darrel Taylor]

Roman,

Looks like you got it all straight.
As for the preferences, I'd like to put a hold on that for a moment.

Just talking about how to do it, has brought up new ideas that may help make things more compatible between the varieties of PIC's.

I'm playing with it here to see if I can make it work or not.
It's really just the same stuff as above, but with better options.
I'll let you know soon.

Regards,

[Archangel]

Hi Roman,
Just a quick note to say Thank You, as it was your linistepper that got me interested in PICs.
JS

[Darrel Taylor]

Roman,

OK, wasn't sure before. But I am now.

I have an import function that works on ANY PIC. (ASM or PBP)
With a single exported btc file format.

Conversions to 14-bit data or retlw are handled by MPASM (if necessary).

Just need to make the player work with each type, and I'm good to go.

Please HOLD!
<br>

[GioppY]

IMHO the attached sample works at 22050Hz 1 bit
it uses a 12F675 @20MHz and an external I2C eeprom (24C256)
The i2cread statement needs about 170uS to respond(@ 20MHz); i suppose that 44100Hz sampling rate can be obtained.
Have fun.
Regards
Gianni

[GioppY]

Obviously the eeprom must be pre loaded with the binary file (filename.btc)
A simple file transfer through com port could be interesting.
Regards
Gianni

[Darrel Taylor]

Darrel. I'm always impressed with your macros. I'm really surprised I don't see more of the #V option used in Microchip macro examples. That ImportSound macro was really impressive work. I would have to call that one "art". You just don't see this. Even in some of the more advanced code examples from engineers that work for Mchip.

WOW, thanks Bruce!
I thought it was cool too, but "Art"?

And if I wrote it all down, those guy's at mchip would make more money by impressing their bosses. Microchip would make more money by selling more chips. And at best, I get $100 a page, and loose all my best tricks.

I also like your use of the EXT option with PBP. Timer1 VAR WORD EXT is really cool, as long as some newbie doesn't setup an 18F part for a 16-bit R/W timer..;o}

Yeah, I should probably stop showing that, just for the Newb reason.
Or maybe just add an FDA warning on the label....

<dl><dt>Warning:</dt><dd>Using this program could result is severe gastrointestinal diseases, most commonly in the form of acid reflux, or unspecified severe heartburn. Other symptoms may include but are not limited to, nausea, vomiting, diarrhea, hair loss, or pulmonary problems such as heart attack or stroke.

Symptoms may subside after setting the timer's RD16 bit to 0. </dd></dl>

[ScaleRobotics]

It could probably be made to work in pic16 chips .... but why not pic18? The include files in his post#5 of this thread were written for PIC18 chips.

Darrel says I2C is too slow:

I did some experimenting with storing the sound in external EEPROM.
And for sure, you have to be using the MSSP module to read the data.
SHIFTIN or I2CREAD can't keep up with the higher bitrates.

[schu4647]

Roman Blacks board answers the question for me. He is selling a board that takes in the output from his program. It runs on a 16f micro at 20mhz and with a 1 megabit I2C eeprom can store 24 seconds of sound.

http://www.blackrobotics.com/Brains_...ontrollers.htm

It could probably be made to work in pic16 chips .... but why not pic18? The include files in his post#5 of this thread were written for PIC18 chips.

Darrel says I2C is too slow: