FSRW Reading Problems?

John A. Zoidberg · 2010-12-06 07:23

Hello there,

I've just followed the Gadget Gangster's tutorials on the SD cards, and I've successfully created a file with a short text inside.

When I tried reading another file, it does the job, but then the terminal spraying out other gibberish and continued doing so.

Here is the code:

... (other code) ...
sdfat.popen(string("TEST2.TXT"), "r")
waitcnt(200_000 + cnt)
sdfat.pread(buffer,26)
pst.str(buffer)
... (other code) ...

The test2.txt contains the string "abcdefghijklmnopqrstuvwxyz".

When I put "sdfat.pread(buffer,25)", it went until "abc...xy" only, without the z.
When it's "sdfat.pread(buffer,26)", it went "abc...xyz" and other accompanying gibberish.

Any ideas how to solve this?

Mike Green · 2010-12-06 07:31

.pread, in your case, reads up to 26 bytes from the file. This 26 bytes has no punctuation or delimiters in it unless you included some kind of punctuation when you wrote the file. The .str call on the other hand, expects the address of a string of characters terminated with a zero byte. .pread doesn't supply that.

The way to fix this is either to zero the buffer before you read into it (so there are zero bytes left after any data read in) or to check the actual number of characters read with .pread and use that to put a zero byte at the end of the data. Make sure that the buffer is large enough for what you read plus one extra byte for the terminator. Also remember that .pread will also return -1 (if I remember correctly) if it's at the end of the file.

A third option would be to read the characters one at a time with .pchar and output them using .out.

John A. Zoidberg · 2010-12-06 07:42

Thanks for the quick reply. Also, I can't seem to find a "Sentinel" or the "EOF" on the text file I've created on the computer.

I'm not sure whether the .pread would find an EOF inside, and that explains why the other gibberish came right on the last element of the buffer.

I've also zeroed the contents of the buffer - didn't work though.

I'll try the "return -1" option if it's available.

Mike Green · 2010-12-06 07:58

There's no EOF recorded in the file itself unless you put something there. The file size is recorded in the directory and that's used to indicate the end of the file.

I checked the FSRW code. The -1 is returned by .pgetc at the end of the file. .pread returns a negative number on an error. Attempting to read at the end of the file is an error. I think .pread will read what's available and return the amount read. On the next read, when there's nothing left to read in the file, it will return the negative number.

Zeroing the buffer before reading should work. Remember that, for reading up to 26 bytes, you need a 27 byte buffer to allow for a zero byte at the end.

John A. Zoidberg · 2010-12-06 08:02

Thanks for the reply. I'll fix that part of the program.

Also, I noticed that my 10MHz crystal @ PLL 8x = 80MHz wouldn't mount the SD card at all, until I had to use the default PLL 1x. Any ideas why it happened?

Or I should need 5MHz crystals for all the Props? Thanks.

Mike Green · 2010-12-06 08:56

There's nothing wrong with using a 10MHz crystal and PLL8X. I've used this combination with an SD card and it worked fine for me. You should use XTAL2 rather than XTAL1, but I'm not sure it would make much difference at 10MHz. You do have to be even more careful about short direct connections between the crystal and the Propeller at 10MHz than 5MHz. You also have to be careful to avoid running other signals adjacent to the crystal. Without detailed information about your setup, it would be hard to advise you about why the SD card wouldn't mount. If you don't have them, try pullups on the SD card signals. Something between 2.2K and 4.7K should work.

John A. Zoidberg · 2010-12-06 09:29

Well, the crystal is just next to the +3.3V rail on a breadboard. Must I put capacitors on the crystal? Liek 20~39pF or so? I'll add the pull-ups and double check the connections again.

Mike Green · 2010-12-06 09:42

Do not put additional capacitors on the crystal. The Propeller has appropriate capacitance internal to the chip.

You're using a breadboard. That's probably the problem. Breadboards have significant capacitance and that can load the crystal. Sometimes with breadboards and high frequency oscillators, you have to actually solder the crystal to the IC pins rather than using the breadboard. You may do better with a 5MHz crystal and the breadboard.

John A. Zoidberg · 2010-12-06 09:55

Mike Green wrote: »

Do not put additional capacitors on the crystal. The Propeller has appropriate capacitance internal to the chip.

You're using a breadboard. That's probably the problem. Breadboards have significant capacitance and that can load the crystal. Sometimes with breadboards and high frequency oscillators, you have to actually solder the crystal to the IC pins rather than using the breadboard. You may do better with a 5MHz crystal and the breadboard.

No wonder all the Prop tutorials w/ breadboard recommends the 5MHz crystals.

I'll stock on the 5MHz crystals by today too.

FSRW Reading Problems?

Comments