Forum Replies Created

Viewing 15 posts - 1 through 15 (of 204 total)
  • Author
    Posts
  • in reply to: ESP8266 support #3577

    thanks for your feed back. However at this time I do not foresee being able to schedule to provide any additional significant features to this project. In GitHub under Network you can view all the public forks of the project. Perhaps someone has already done this.

    I suspect there may be other issues. Where I do not recall if the SdFAT Library supports the ESP8266.

    in reply to: Playing other files (aac,wma,ogg) than mp3 #3571

    I just  tried out http://techslides.com/demos/samples/sample.aac with the current version FilePlayer.ino and it worked fine.

    Looking at your images, i see that it looks like you are using an older version. specifically in the dump of your help I see

    ” [###] Enter index of file to play, zero pad! e.g. 01-65534″

    the current version prints the following:

    ” [0####] Enter index of file to play, zero pad! e.g. 01-65534″

    This is important as I suspect that the problem is that you are not preceding the file index with a ZERO. if the initial digit is 0 then it will used the index location of the directory. example “05” will play “test.aac”, where “5” will play “TRACK005.wma”. This allows the sketch to be backwards compatible. Leading with a non-zero is the original demo.

    Note that the VS1053 chip does not even see the file name, rather it auto detects the file format. The file extension is simply used to filter out none audio files from the List command. Where the Play command uses the same filter to find the files.

     

     

    in reply to: FilePlayer.ino Compiles but will not upload #3561

    I am glad to hear you solved it. Kudo’s for re-flashing the bootloader.

    in reply to: FilePlayer.ino Compiles but will not upload #3559

    I thought I had responded earlier, about the ordering. The ATmega328 only has a few K of RAM. That is not enough to do a lot, noting the SdFat uses a huge chunk of that, leaving less. Take into consideration the above example directory dump is 220 bytes, to display the names of the 17 files is a 1/4K. Given that a Directory can have thousands of files, there is just not enough RAM to store all that and then sort it.

    Rather the routine I implemented is typical for small micros, in that it operates ONE LINE at a TIME. printing that lines description and then reusing the RAM buffer for the next line. Where the selection is actually by its Offset in the list. Where the list is reproducibly presented by the SdCard. And the SdFAT lib function for dumping the Directory Listing is simply dumping the FAT, in the order it was created. Hence it is not sorted. So that it has infinite scalability.

    Good Luck.

    in reply to: FilePlayer.ino Compiles but will not upload #3554

    I got good news and bad news;

    I went and got an UNO and SFEMP3 shield over lunch. So the good news is that it worked for me, from a fresh pull of the repo. It compiled, loaded, verified, ran. The menu’s worked and even played a file. I am using WIN7, Arduino IDE 1.6.7 and it compiled FilePlayer.ino using SdFatLib 20131225

    Bad news is that I don’t know why yours is failing. I suspect it is not to do with the code itself. And still suspect some bad program space. I see the MP3Shield_Library_Demo.ino has a image size of 28164 bytes and the FilePlayer.ino has a size of 30016 bytes, some 1800 bytes larger. Or power on the Uno, perhaps there is local power issue with the supply to the 16U2. However, as you have not stated the COM port is not disappearing, then that is unlikely. So more likely an issue with the 328 itself. Either bootloader or power or bad flash.

     

    in reply to: FilePlayer.ino Compiles but will not upload #3552

    Ok, it starts and get most of the way. or at least a big chunk. I suspect your UNO has some bad flash sector near the end. Or possibly a power issue. The key point is that it is starting then becoming not responsive. Try it on another PC, or use a powered HUB, or with the +12Vdc connected. Or try another Uno.

    I have on a few occasions worn out my Flash, I test nearly every line of code and that means re-flashing the chip a huge amount. The Flash program memory only can be flashed 10,000 times. That sounds like a lot. But when I get going I flash it nearly 100 times a night for months on end and such have had some just die at some points of the flashing.

    That usually yields a verify error. Here it is just loosing sync. So it may be a power issue over time or a bad version of bootloader.

    hard to tell.

    in reply to: FilePlayer.ino Compiles but will not upload #3549

    hmm,

    The symptom as described is a bit odd and not really coherent. The issue is that down loading has really nothing to do with compiling. I don’t have a Uno at hand this moment, to completely verify your statement.

    However, something does come to mind; The more recent versions of SdFat Lib have deprecated a command used in the FilePlayer.ino, and such will fail to compile. The SFEMP3 repo has 20131225 inside it, which will compile.

    Is it possible that your compile/verify environment is not the same as your compile/upload?

    I may be able to find an Uno later today.

     

    I would mention that I have never seen “<em style=”margin: 0px; padding: 0px; border: 0px; outline: 0px; font-size: 13px; vertical-align: baseline; color: #9e9e9e; font-family: Arial; line-height: 19px; background: #fbfbfb;”>avrdude: stk500_recv(): programmer is not responding<span style=”line-height: 1.5;”>”  as a result of source code. Rather the AVRDUDE not finding the serial port. Under File/Preferences check the Show Verbose output during compile and upload. You will likely see the debug of Avrdude sending out the poll messages. </span>

    One thing can be that the Serial Port is busy or already in use. Another parent instance of Arduino may have it. Note that children from the same instance share it. But if the IDE is ran a 2nd time this can readily happen.

     

    in reply to: Not all the songs are playing with the Random Play Code #3544

    I assume you are referring to https://gist.github.com/mpflaga/5800889

    as per https://www.arduino.cc/en/Reference/Random

    random(max)
    random(min, max)

    where the GIST example is set to 5, so I believe it outputs a range from 0-4 randomly.

    In your comments I am not hearing that the order is repeatable. If that were the case you could try a different random seed and see if that changes the behavior “randomSeed(analogRead(0));” However I do believe it is a random seed, as the seed is after the MP3 and SdCard init, where the SdCard has asynchronous timing responses, sufficiently random.

    I not your above line of code “rantrack = random(0);” This should only output a range of zero to zero or just zero, not good.

    I will say with small ranges Random can quiet often be very repeatable, sounds like you really want pseudo random, in that it does not play repeats.  So I have updated the above GIST as not to replay repeats. It does compile, but I have not tested it. However, it is straight forward and expect it to.

    in reply to: Arduino 101 Support #3541

    I have not looked at the Arduino 101. Likely won’t for some time.

    My first thoughts are

    1) Not sure if the SdFat Lib work on it alone.

    2) that its pin functions are different.

    a) Interupts may be on different pins.

    i) could try to use it in Soft Polling mode without interrupts.

    b) The SPI are different pins.

    So you may want to start with looking at these concepts first.

    The SPI is the most important. The SdCard and VS1053 both use it. So one needs to make sure it is wired correctly. Then need to make sure the SdCard works with the SdFat standard QuickStart.ino and VS1053 CS disabled.

    If that works then the VS1053 should start to work.

    in reply to: vs_plg_to_bin.pl script not accepting .plg files? #3537

    <div class=”db-modal-title-text” style=”display: inline;”>vs1063a-patches-190 at</div>
    <h2 class=”db-modal-title” style=”margin: 0px; line-height: normal; padding: 20px 32px; font-size: 18px; box-sizing: content-box; font-weight: normal; min-height: 24px; flex-shrink: 0; border-top-left-radius: 4px; border-top-right-radius: 4px; color: #3d464d; font-family: ‘Open Sans’, ‘lucida grande’, ‘Segoe UI’, arial, verdana, ‘lucida sans unicode’, tahoma, sans-serif; background-image: none; background-attachment: initial; background-size: initial; background-origin: initial; background-clip: initial; background-position: initial; background-repeat: initial;”>https://www.dropbox.com/sh/c43rp3jhkxd627c/AAB8iQ9J7puj8hgnSQin38tha?dl=0</h2&gt;

    in reply to: vs_plg_to_bin.pl script not accepting .plg files? #3535

    @ARGV is a system variable that is an array of the arguments passed in. It’s index is zero based. Hence $ARGV[0] is the first argument and [1] is the 2nd, etc…

    for some reason your command line is not accepting the arguments. I use Active Perl for windows. It does not really sound like a problem with the script itself. but the local OS’s command line interface calling perl. Perhaps try “perl vs_plg_to_bin.pl patchefl.053” or put quotes around each argument. It may not be being parsed by the command line interpreter.

    I was able to re-run them on the latest patches by VLSI and put some of them at https://www.dropbox.com/home/Public/vs1053b-patches230

    in reply to: TotalLenght of a Mp3 file ? #3531

    There are several “getter’s” included in the library. Note several of them only work for certain file formats. Obvious, since not all contain wrappers that include everything. The entire library of code is document ed http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/

    I would recommend searching the web documentation for the following the search is in the upper right.

    void SFEMP3Shield::getTrackInfo(uint8_t offset, char* infobuffer){

    void SFEMP3Shield::trackArtist(char* infobuffer){

    void SFEMP3Shield::trackTitle(char* infobuffer){

    void SFEMP3Shield::trackAlbum(char* infobuffer){

    void SFEMP3Shield::getAudioInfo() {

    void SFEMP3Shield::getBitRateFromMP3File(char* fileName) {

    int8_t SFEMP3Shield::getVUmeter() {

    int8_t SFEMP3Shield::setVUmeter(int8_t enable) {

    int16_t SFEMP3Shield::getVUlevel() {

    Example: http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/class_s_f_e_m_p3_shield.html#a6a4b776e45e151a7c330d91a9e88fb78

    You may need to also do some direct file access and properities and some math to calculate totals. Note some file formats have variable bit rates. These may change on the fly.

    in reply to: Easy Transfer Array Populating (from SD?) #3529

    Followup. I am not sure about how you plan on updating the SdCard. Seams like you would have to pull it out update it with different values and put it back in. That may cause problems with the SdCard library.

    In an attempt to deal with that the SD.open() is performed each time and closed, each time. So it may be able to be removed. I have not tried that. However, the Arduino SD library is not a really Hot Plug. So go at your own risk. and may need to improve on my Try/Excepts.

    in reply to: Easy Transfer Array Populating (from SD?) #3528

    Sounds like a good plan.

    I believe the lock up is from

    int arraydata[];

     

    in the struct. This does not specify a length. Hence it was simply a pointer to a single INT not really an array and the memcopy over wrote from that point, locking the code up, when used by the ET.sendData().

    I was able to get https://gist.github.com/mpflaga/c1f957f4f5146b990c28daa8d82fb16e to not lock up, printing out the results to monitor. I did not test the ET feature to a RX. But assume it works, as it does not lock up.

    The inherent danger of using MemCopy is that it can over/under write things. Hence pointers are safer, but a bit tricky to understand and follow.

    the SdCard example I see had several typo’s. So not sure if it even works. But I have compiled it into a solution similar to your specification at https://gist.github.com/mpflaga/1a9d0ad89258f069d5c0c2d6a6b10e5e this posted GIST does compile. I did not actually try it with a SdCard, (not one handy), but it seems like it should work.

    Assuming this works, be mindful of the Scope of an entity and its true length.

    happy Blinking.

     

    in reply to: Easy Transfer Array Populating (from SD?) #3526

    please note that arraydata[] and mydata.arraydata[] are two different entities.

    The line of code in the main loop:
    <p class=”MsoPlainText”>int arraydata[] = {0x000001,0x1000ff,0x10ff00,0x10ffff,0xff0001};</p>
    <p class=”MsoPlainText”>creates a new instance of memory, unique from mydata. The “int” at the beginning is the initializer.</p>
    <p class=”MsoPlainText”>The simplest fix is to copy one array to another. See the below example where memcpy() does this.</p>
    <p class=”MsoPlainText”>void loop() {</p>
    <p class=”MsoPlainText”> //this is how you access the variables. [name of the group].[variable name]</p>
    <p class=”MsoPlainText”>  int arraydata[] = {0x31,0x100032,0x33,0x34,0x35};</p>
    <p class=”MsoPlainText”>  memcpy(mydata.arraydata, arraydata, sizeof(arraydata));</p>
    <p class=”MsoPlainText”> //send the data</p>
    <p class=”MsoPlainText”>Alternatively you can use pointers. as not use twice the memory.</p>

Viewing 15 posts - 1 through 15 (of 204 total)