I try to make work the VS1053B with the CC3000 breakout.
Before CC3000 init, I can trigger an operation (playing an audio file) on the VS1053.
But if I'm trying to do that after the CC3000 init (cc3000.begin()), the SD.open() inside the Adafruit_VS1053_FilePlayer::startPlayingFile() fails.
Could that be related to that ? (in the CC3000 tutorial) :
On the breakout, be aware that the MISO (data out from module) pin does not go 'high impedance' when CS is driven high. Check the shield for how we use a 74AHC125 to manually tri-state this pin when it's shared with an SD card.
jonlab wrote:Is this possible to solder this SOT-25 on the mega proto-shield (Adafruit #192) on the SOIC area ?
Nope. An SOT-23-5 package is 3mm wide if you measure from the tips of the pins on one side to the tips of the pins on the other side. The space between the pads of an SOIC-8 footprint is 4mm wide.
I am a little bit afraid of the SOT-25 integration (soldering and on what board I would solder it), and I am running out of physical space to put another big DIP IC somewhere and my prototype has to be finished soon !
So maybe I'll take a shortcut of having the CC3000 talking on the hardware SPI alone, and put the OLED screen and VS1053 on 3 other pins (shared software SPI). No issue with that ? What is the benefit of hardware SPI VS software SPI ?
Thanks !
jonlab wrote:Is this possible to solder this SOT-25 on the mega proto-shield (Adafruit #192) on the SOIC area ?
Nope. An SOT-23-5 package is 3mm wide if you measure from the tips of the pins on one side to the tips of the pins on the other side. The space between the pads of an SOIC-8 footprint is 4mm wide.
Ok, so I tried to put the CC3000 on hardware SPI and the VS1053 and SSD1306 on software SPI.
But, the SD card library does not allow the SD to be used over software SPI, no ?
What can I do ?
I wanted to try to put the CC3000 on software SPI and all the others (incuding SD) on hardware, but there is no software SPI option on the CC3000 library, right ? I'm trying to see what work or issue would be involved on adding a software SPI option on the CC3000.
Ok, so I ended up doing that :
-CC3000 on the hardware SPI, alone ! Bad boy !
-VS1053 + SD + SSD1306 on software SPI.
Changes in the standard SD Arduino lib (because the SD init functions do not allow to switch on software SPI) :
in SD/utility/Sd2Card.h :
jonlab wrote:Ah yes, you do have a breakout board ready to use for the SOT-25 (SOT-25 was not mentioned on the product page)...
Different vendors call the same package by different names. There's SOT-25, SOT-23-5, SOT-323-5, SOT-323-SC5, SOT-353, TSSOP5, etc. It's one of those "standards are wonderful, every company should have a few" things.
Looks like you found a solution before I even had a chance to check back though.. bravo!
Actually, having switched to software SPI, I don't know if it is related but the MP3 playing on the VS1053B is a little bit "garbled". I feel that sometimes a block is lost or swapped with another or something like that.
What could that be ?
I have to investigate further...
The ATmega328P's hardware SPI is a lot faster than software SPI. You might not be getting data to the VS1053B fast enough. Normally that would just produce skips and gaps, but MP3 is a data compression format that extracts audio signals from key data points. A zero in the right place could do funky things to the calculations.
You might also be seeing issues with interrupts. The CC3000 is interrupt-driven, and that can do wierd things to the timing of software data protocols.
Ok.
I checked in the VS1053 lib, and data is sent by chuncks of 32 bytes : 32 bytes read of the SD, then 32 bits sent to the VS1053.
And both of them over software SPI.
So, that could be a problem.... I feel that you are right, the data transfer is not fast enough.
Is there a way to have a bigger buffer on the VS1053 ? Or maybe raise latency (this is not too important in my app, I can add even 200 or 300 ms of latency).
So, if I am doing the opposite than what I am doing, I would put the CC3000 on software SPI and all the others on hardware SPI (SD / oled screen / VS1053).
But, there is no way to talk to the CC3000 over software SPI ?
There is only one hardware SPI on the mega, right ?
I implemented audio recording on my project and unfortunately the software SPI is really not fast enough to read the bytes from the VS1053 and write to SD without losing the sync. I record in ADPCM mono @ 22050 Hz (so this is roughly 11kB/s)
Parts of my audio is missing on the recording !
Obvious when I look at timings :
//------------------------------------------------------------------------------
/** nop to tune soft SPI timing */
#define nop asm volatile ("nop\n\t")
//------------------------------------------------------------------------------
/** Soft SPI receive */
uint8_t spiRec(void) {
uint8_t data = 0;
// no interrupts during byte receive - about 8 us
cli();
// output pin high - like sending 0XFF
fastDigitalWrite(SPI_MOSI_PIN, HIGH);
for (uint8_t i = 0; i < 8; i++) {
fastDigitalWrite(SPI_SCK_PIN, HIGH);
// adjust so SCK is nice
nop;
nop;
data <<= 1;
if (fastDigitalRead(SPI_MISO_PIN)) data |= 1;
fastDigitalWrite(SPI_SCK_PIN, LOW);
}
// enable interrupts
sei();
return data;
}
//------------------------------------------------------------------------------
/** Soft SPI send */
void spiSend(uint8_t data) {
// no interrupts during byte send - about 8 us
cli();
for (uint8_t i = 0; i < 8; i++) {
fastDigitalWrite(SPI_SCK_PIN, LOW);
fastDigitalWrite(SPI_MOSI_PIN, data & 0X80);
data <<= 1;
fastDigitalWrite(SPI_SCK_PIN, HIGH);
}
// hold SCK high for a few ns
nop;
nop;
nop;
nop;
fastDigitalWrite(SPI_SCK_PIN, LOW);
// enable interrupts
sei();
}
Software SPI is inherently slower than hardware SPI.
The SPI hardware takes its clock from the main crystal oscillator, and can run at half the crystal frequency.. sending and receiving one bit every two ticks of the system clock. Software SPI needs two ticks of the system clock to toggle the SCK pin high and low, plus the overhead of reading and writing data to the MISO and MOSI pins.
You might be able to tweak the software SPI code for a better data rate, but its theoretical limit is less than half as fast as the hardware version.