Pages: 1 [2]   Go Down
Author Topic: More than 32 bytes to microSD card?  (Read 1836 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Edison Member
*
Karma: 8
Posts: 1411
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
For reading cards, it seems to be the only game in town
The library for the Wave Shield also allows reading. As stated in documentation, it is based on Roland Riegel's SD library:
http://www.roland-riegel.de/sd-reader/index.html
Logged

North Yorkshire, UK
Offline Offline
Faraday Member
**
Karma: 104
Posts: 5531
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I deleted the .o file and it re-compiled fine and worked witout the spelling mistake...

Anyone got any ideas about the issue I commented on before though. It still messes up when appending text...

Thanks,

Mowcius
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 8
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I'd like to comment on this to confirm my understanding - which is:
- a clean file starts with 0x03 (ETX) as the 1st byte.
- there are 0x0A (LF) at the end of each line (of spaces) and at the end of the file (as normal)
- as text is written, it is inserted before the ETX
- but SD.println also appends an ETX to the line
- so after 20 SD.println's, I see 21 ETXs in the file
- I think the SDuFAT lib only cares about the one ETX and maybe the last LF

That's what I see when all goes well, but when using the "hola" example, it has been easy to loose the ETX, and then you're out in the ozone.
I've experienced the same problem. I think it happens when data
written to the file fill exactly a 512 byte sector. Here is a test
sketch:

Code:
#include <mmc.h>
#include <SDuFAT.h>
#include <microfat.h>

char myBuffer[257];

void setup (void) {
  Serial.begin (9600);

  Serial.println ("In order to run this test, hola.txt must be empty.");
  Serial.println ("You can use the hola.txt file included in SDuFAT.zip\n");

  Serial.println ("Send a character to write first block");
  while (Serial.available() == 0);
  Serial.read();
  for (int i=0; i<=256; i++) {
    myBuffer[i] = 'A';
  }
  myBuffer[256] = 0;
  int result = SD.print ("hola.txt", myBuffer);
  Serial.print ("First block written, result = ");
  Serial.println (result, DEC);

  Serial.println ("Send a character to write second block");
  while (Serial.available() == 0);
  Serial.read();
  for (int i=0; i<=256; i++) {
    myBuffer[i] = 'B';
  }
  myBuffer[256] = 0;
  result = SD.print ("hola.txt", myBuffer);
  Serial.print ("Second block written, result = ");
  Serial.println (result, DEC);

  Serial.println ("Send a character to write the final string");
  while (Serial.available() == 0);
  result = SD.print ("hola.txt", "ciao");
  Serial.print ("Final result = ");
  Serial.println (result, DEC);
}

void loop () {}
After the first print, in the file there are 256 'A' followed by 256
ETX, because SDuFAT fills the empty space of the sector with it.

After the second print, in the file there are 256 'A', followed by 256
'B', followed by spaces and a few LF. No ETX: the library "forgets" to
add it in the subsequent sector of the file.

The string "ciao" is never written to the file, because SDuFAT can't
find ETX in it.

Logged

Denver
Offline Offline
God Member
*****
Karma: 20
Posts: 779
Inactive - PM
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Aurelio,
Nice job in demonstrating this bug. I got the predicted result too. I see you put an issue on Blushingboy.net. I hope when it's fixed it corrects the strange behavior I see when writing to MMC with this lib.
Thanks!
Logged

"Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom."
~ Clifford Stoll

0
Offline Offline
Newbie
*
Karma: 0
Posts: 8
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I see you put an issue on Blushingboy.net. I hope when it's fixed it corrects the strange behavior I see when writing to MMC with this lib.
In the meanwhile, there is a simple workaround that allows you to maximize the number of lines written to a file. If you write lines of fixed length l (including newline character(s)), the bug will hit when lcm(l, 512) (lcm = least common multiple: http://en.wikipedia.org/wiki/Least_common_multiple) bytes will have been written to the file.

If you choose an odd number for l, then lcm(l, 512) = l*512: you will be able to write 512 lines to the file, which might be enough for some applications (including mine).
Logged

Pages: 1 [2]   Go Up
Jump to: