John,
Yes you're right. The file got corrupted (again!). The 0x03 char was overwritten.
I accidentally removed one of the start or stop charasters (can't remember which)
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 was using Filelogger with no problems and I liked the way it didn't need a special file and the file could grow. But now I must read from the card, and I wish SDuFAT could do that too.
I am using MMC instead of SD cards (bought the wrong part!) and they seem to be more "delicate" then the SD.
For the sake of other's with problems, here are 2 observations for both types of cards:
- If you format, or even copy, files, on a card using something like a card slot in a printer, the card may not work.
(true for SDuFAT or FileLogger). - You can screw up a card to the point where it wont work even after a "proper" format.
(I've brought them back by doing a low level format in my camera!)
I don't expect there's much to respond to in this - just wanted to get it down. I'll keep plugging (and unplugging) away with SDuFAT. For reading cards, it seems to be the only game in town.
John