Home Forums Sparkfun MP3 Shield Library Support Forum Bug's and Feature Fixes

Tagged: ,

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #1663

    I have uncovered several issues that have been a nemesis for myself along with other reports that I have seen at vlsi.fi forum. I would suggest any such reports be detailed here.

    Such as

    The SPI ClockDivider was being over written by each and every SdCard read. Over writing the initialized values from the begin. These SdCard value are marginally functional for playing sound files. However, the VS1053 can not properly respond to Read Registers while simultaneously playing. Hence read when the chip was idle work but reads while playing would give back erratic values.

    I have fixed this in a pending release with the following summary notes:
    added member helpers for SFEMP3Shield::cs_low(), cs_high, dcs_low() and dcs_high, to set SPI DataMode and ClockDivider properly used them to replace digitalWrite of MP3_XCS and MP3_XDCS, to ensure proper SPI settings.
    added member variable of SFEMP3Shield::spiRate as to change speed of Mp3Write and Reads.


    Mp3ReadRegister had issue with FF’ing the upper byte when sign of lower byte was set, due to a carry from shift. This is caused by the following line:
    char response1 = SPI.transfer(0xFF); //Read the first byte
    while(!digitalRead(MP3_DREQ)) ; //Wait for DREQ to go high indicating command is complete
    char response2 = SPI.transfer(0xFF); //Read the second byte
    while(!digitalRead(MP3_DREQ)) ; //Wait for DREQ to go high indicating command is complete

    Where char is not unsigned and its use on response2 causes shift to carry the sign of the previous shift. Changing this to the following fixes this instance:
    unsigned char response2 = SPI.transfer(0xFF); //Read the second byte

    This is why i prefer to use unions in place of shifts  such as

    union twobyte {
    uint16_t word;
    uint8_t  byte[2];
    } ;

    such as below:

    union twobyte resultvalue;

    resultvalue.byte[1] = SPI.transfer(0xFF);
    while(!digitalRead(MP3_DREQ)) ;
    resultvalue.byte[0] = SPI.transfer(0xFF);
    while(!digitalRead(MP3_DREQ)) ;

    return resultvalue.word;

    this way you don’t have to relay on the compiler and op-codes to due an assumed shift as they are not all the same.

    And is in a pending release.


    I have completed an extensive enhancing of the Arduino SFEMP3Shield library and have pushed it up to both Bill’s and my repositories. Labeling it Release 1.0.0

    This new release contains several gremlins and newly requested features. Along with support of different hardware by means of refilling either by timers or interrupts. Finally Bit Rate is now read directly from the VS1053 itself. Notice you can actually increase the play speed and turn on Head Phone Spatial effects.

    [1-9] to play a track

    [s] to stop playing

    [+ or -] to change volume

    [> or <] to increment or decrement play speed by 1 factor

    [i] retrieve current audio information (partial list)

    [e] increment Spatial EarSpeaker, default is 0, wraps after 4

    [p] to pause.

    [r] to resume.

    [r] Resets and initializes VS10xx chip.

    [t] to toggle sine wave test

    [m] perform memory test. reset is needed after to recover.

    [h] this help


    Most notable effort was in creating supporting documentation and trouble shooting. Many of the questions asked on the forums where directly exampled in the new menu features. Along with a printing of the SdCard’s directory listing.


    Extensive support can be found at GitHub project page along with trouble shooting of common problems. As the code has been written with plenty of insightful comments, describing key components, features and reasoning’s in Doxygen markdown style as to directly auto generate html supporting documentation. Which can be found at GitHub project page . Please read through this document and referring linked resources. As it contains additional resources.

    Alex  says:

    Great project!

    But function skipTo is not working for me (((

    It’s always jump to beggining of the file.

    Not to the position in ms.

    It’s so sad (((


    I have fixed this in 1.0.2, released moments ago.

    My bad. The usage of the byterate from the VSdsp broke this feature. Not sure how well it ran before.

    I have fixed it and tested it. Along with putting in a Demo command.

    Note that the codes’ serial input process’s each char, as a whole menu command. This preclude strings, hence the selected offset is hard coded in the example INO. Easy enough to change.

    Warning there is an issue about running past the file’s end. somehow the volume and or track is not able to close correctly.

    Also note that the requested milliseconds is a multiplied by the byte-rate to calculate the desired location. Where the byte-rate is the average, the VSdsp is playing. Hence it jitters a few tens of milliseconds. Should be close enough.

    This helps with Variable rate as it is the average. Noting the VSdsp jitters for even constant bit rate.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.