Host running less than 16MHz

[Anonymous]

I would like to get this library working with an AVR host powered at 3.3V instead of 5V, which means the fastest I could reliably clock it at is 13MHz. How might this effect the performance of this library and the MP3 shield? Would it be possible?

[Michael P. Flaga]

I have ran it just fine at 3.3V. I recall adding some #if’s to properly select on the F_CPU. Not sure if that code only available on my Beta Fork. But even older code will simply run at half the SPI, just fine.

[Anonymous]

I have my Arduino running at 8 MHz. Encountering SPI communication problems:

Can’t access SD card. Do not reformat.

No card, wrong chip select pin, or SPI problem?

SD errorCode: 0X1,0X0

 

I tried dividing all the SPI_CLOCK_DIV’s in SFEMP3Sheild.cpp by two, but still getting problems.

I’m using a non-default SD-CS, and made sure to configure SD_SEL appropriately in SFEMP3ShieldConfig.h.

 

I’m wondering if there is somewhere else I need to set my non-default SD-SEL, or change CLOCK_DIV’s, to accommodate the 8 MHz host..hmm

[Michael P. Flaga]

Note that the SdFat Lib and SFEMP3 lib both set the SPI Mode and Rate just prior to each transfer. This will over write anything you configure. Since each library/driver has a different maximum rate. In early days of SFEMP3 it was configured just at ::begin. But the SdCard changes it to 8Mg and the VS1053 limited to 6 Mg for read back.

It is good practice to not rely on the assumption the SPI is the way you left it. Some other driver may have changed it. Such as adding a SPI Temp Probe or other. Hence your driver should set it prior to enabling the Chip Select.

[Anonymous]

I am so close to getting this working. I am running at 12Mhz on an Atmega 1284p at 3.3V, and using your master library example sketch. The mp3 and SD initialization and serial communication over USB all works fine.

However, after initiating a song for playback, I can only get continuous music playback when I continuously send a volume change command. I’ve tied the increase/decrease volume commands to physical buttons, and I only hear playback while holding either one of the buttons. It’s like the mp3 buffer is not refilling on its own.. The only thing I’ve changed in the code is the pin assignments of MP3_XCS, MP3_XDCS, MP3_DREQ, and MP3_RESET, and SD_SEL.

[Michael P. Flaga]

Ask your self why is it not refilling on its own.

Because the Refill() is not getting executed. What executes the refill(). It is executed once after any command. Hence it plays when sending Volume or constantly holding a button, which is sending a command. But more importantly the refill() is executed when the DREQ is asserted indicating more is needed. Typically the DREQ is connected to an INT pin and its ISR calls the refill(). Or it is polled when configured with USE_MP3_REFILL_MEANS = USE_MP3_Polled.

Either way the refill is not getting automatically done. Likely your INT pin is not what you think it is on the 1284p. The pins_arduino.h is a bit difficult to read and there should be a \variants directory in your hardware directory

I often just make quick sketch for each INT and poke them as to see what is what for new boards.

[Anonymous]

Many thanks for the direction, Michael. Once I used the 1284p equivalent INT0 pin as the MP3_DREQ, it works as expected.

For anyone else reading this, I now see I could also reassign MP3_DREQINT to a different INTx in SFEMP3ShieldConfig.h as an alternative in the future.

[Author]

Posts