Possible Bridge SD card I/O Bug

Official Hardware Classic Yún
1

I have a weather-related Arduino Yun project I'm building. I wanted to read small BMP image files from the SD card on the Yun but I've run into a problem. It appears the Bridge is reading the bytes incorrectly. I've been working through this issue with Adafruit as the icon will be displayed on their 2.8" TFT and I started with their sample code. At this point we both think there is a bug in the Bridge. There is a thread showing all the steps in troubleshooting we have taken on their forum at this URL.

To display the icon I need to read sets of RGB values and push them to the TFT. What we have observed is that on each 64 byte boundary their is a 'glitch' and the Bridge returns the wrong value and also is at the wrong position in the file. As I said, full details are on the Adafruit forum and I don't want to duplicate it all here but here is a snippet showing the RGB values and position values as we cross a 64 byte boundary. At this point in the file the Bridge should continue reading RGB values of (42, 46, 50) but instead returns (50, 42, 46) and also the position increments by 2 when reading at the boundary going from 6102 to 6104.

42, (6094), (46, (6095), (50, (6096)
42, (6097), (46, (6098), (50, (6099)
42, (6100), (46, (6101), (50, (6102) <------------ Increments by 3 up until this point, then next position is +2 and wrong data
50, (6104), (42, (6105), (46, (6106)
50, (6107), (42, (6108), (46, (6109)

This pattern of wrong data and a position skip continues every 64 bytes through the file.I've verified the file on the SD card is identical to the original BMP using mk5 checksums so I don't think there is any issue with the file itself. Also, I am reading and writing small files with no issue. One thing that may be unique in this sketch is it isn't simply starting with the first byte and reading to the end. It seeks to positions in the file to read the different rows needed to display the icon. Also of note is the sample code works fine with the TFT shield on a regular Arduino using the SD library (but of course I had to modify it for use on the Yun). I am using IDE version 1.5.4.

I'm wondering if the team could check into. As things stand now I'm unable to display icons. I can't post the full sketch as the forum complains the post is too long. But below is the loop that is reading the RGB values when the errors occur.

          for (col=0; col<w; col++) { // For each pixel...
            b = bmpFile.read();
            delay(500);
            int p1 = bmpFile.position();
            g = bmpFile.read();
            delay(500);
            int p2 = bmpFile.position();
            r = bmpFile.read();
            delay(500);
            int p3 = bmpFile.position();
            Console.print(r); Console.print(", (");
            Console.print(p1); Console.print("), (");
            Console.print(g); Console.print(", (");
            Console.print(p2); Console.print("), (");
            Console.print(b); Console.print(", (");
            Console.print(p3); Console.println(")");
            tft.pushColor(tft.color565(r,g,b));
          } // end pixel
2

Hello,
Using the TFT library with the bridge has some issue, take a look here for more information:

http://forum.arduino.cc/index.php?topic=268492.0

3

I downloaded the sketch you posted but it fails to compile for me. The error is

Arduino: 1.5.4 (Mac OS X), Board: "Arduino Yún"

My_foto_bilderrahmen.cpp.o: In function `bmpDraw(char*, unsigned char, unsigned int)':
/Applications/My_foto_bilderrahmen.ino:335: undefined reference to `File::read(void*, unsigned int)'

Based on the File::read documentation in FileSystem it doesn't look like anything other than read() is supported. Is there a different library needed?

4

What sketch do you mean?

The discussions I linked to you is a reference to a problem like your. In the github link there is a possible solution to your problem.

5

Sorry, I was referring to the sketch at the post you linked link. I think you had posted the sketch but it was local_dani_21 instead.

6

I don't know how local_dani's sketch works. Try to modify the library as described on github and try to run the Lalieu's sketch

7

I was able to get the code to work by manually seeking using the kludge below. The seek shouldn't be necessary as it should be seeking to the same place in the file but it gets around the issue (at a performance cost). As far as I can tell (not sure at all) this issue with the Bridge is different from the one you linked to. Apparently Adafruit thinks so as well.

          int pos = bmpFile.position();
          int kludge = 0;
          for (col=0; col<w; col++) { // For each pixel...
            if (kludge > 15) {  // seeking for every RGB set is very slow...
              bmpFile.seek(pos); // kludge to test Bridge fix
              kludge = 0;
            }
            b = bmpFile.read();
            g = bmpFile.read();
            r = bmpFile.read();
            tft.pushColor(tft.color565(r,g,b));
            pos += 3;        // kludge to test Bridge fix
            kludge ++;
          } // end pixel