FSRW Trick?

JonnyMac · 2012-08-26 20:19

At EFX-TEK we've added a uSD card option to our HC-8+ and our friend K.C. Oaks -- the author of Vixen (www.vixenlights.com) -- has created an export facility so that we can read and play files created by Vixen on the HC-8+ (or any other Propeller board with a uSD). Now we want to go the other way. The reason is that we have a customer who wants to do puppet animation in real-time from a VEX transmitter; this part is easy, I've already created a program that translates the VEX joystick data to servo outputs. What he'd like me to to now is save those movements to a file that can be imported to Vixen for modification.

Here's the rub: the Vixen data file has a 3-word header that holds the number of channels, the frame timing, and the number of frames. There is now way to know how many frames will be recorded so I wrote 0 to this. After recording the data I closed the file, re-opened it, then re-wrote the header with the frame count. The problem is that the file is now truncated just past the header -- I've lost the data.

Is there a solution (with FSRW -- not interested in any other SD card objects)?

Mike Green · 2012-08-26 20:32

You can't do it without modifying FSRW. You have to close the file, open it for reading, read the first block, modify the first block of the file, then, with a new method, use the low-level SD card I/O to rewrite the first block. Since the file is opened for reading only, when it's closed, the directory entry won't be changed so the file won't be truncated.

Use pfillbuf as a model.

kuroneko · 2012-08-26 20:33

Have you tried append mode? The version I have here doesn't seem to check the mode for subsequent writes (i.e. doesn't reposition prior each write).

lonesock · 2012-08-26 20:34

I think if you change "datablock" from a PRI to a PUB, you could store the raw block address upon opening the file for the 1st (creation) time. safe_spi is configured as a singleton, so you can declare one instance of fsrw, and another instance of safe_spi without wasting any extra space. Once you are done with the file, use safe_spi directly to read that initial block into Hub RAM, poke your values into the right location, then save that block again.

Too much of a hack?

Jonathan

Ariba · 2012-08-26 21:06

I have added these 3 methodes to the fsrw object, which gives low level access to the sectors (blocks):

pub getStartSector
  return fclust<<clustershift + dataregion

pub readSector(n, buff)
  sdspi.readblock(n,buff)

pub writeSector(n, buff)
  sdspi.writeblock(n,buff)

Now you can just modify the first sector of the file to write your word. Something like that (assuming the 3 words in the header are 16bit values):

VAR
  word sbuf[256]

PUB....
 \fsrw.popen(string("filename"),"r")
 n := fsrw.getStartSector
 fsrw.pclose

' Write third word:
 \fsrw.readSector(n,@sbuf)
 sbuf[2] := newValue
 \fsrw.writeSector(n,@sbuf)

Andy

Jim Fouch · 2012-08-27 06:19

Jonny,

You could open the file you created then create a 2nd file with the new header and then rewrite the second file by reading back from the 1st. Kind of a kludge, but should work.

MacTuxLin · 2012-08-27 06:30

How about, before you're writing the data, move the position to just after the 3 word then start writing. Then, once you've gotten the header information, open the file & write those?

Dave Hein · 2012-08-27 07:32

kuroneko wrote: »

Have you tried append mode? The version I have here doesn't seem to check the mode for subsequent writes (i.e. doesn't reposition prior each write).

I'm pretty sure that kuroneko is correct. You can open an existing file in append mode, and then seek to the beginning of the file to re-write that area while leaving the rest of the file intact.

JonnyMac · 2012-08-27 09:46

You could open the file you created then create a 2nd file with the new header and then rewrite the second file by reading back from the 1st. Kind of a kludge, but should work.

FSRW only allows one open file, otherwise this is what I would have done.

You can open an existing file in append mode, and then seek to the beginning of the file to re-write that area while leaving the rest of the file intact.

I tried append, seek to 0, rewrite the header. Seek doesn't work unless you're in the first sector of the file.

I've given up on this. My PC program will open the file and ignore the frames count in the header. It can determine frames in the file from the number of channels specified by the header and the number of bytes in file: (filebytes - 6) / channels.

Jim Fouch · 2012-08-27 09:56

I'm pretty sure you can create TWO object references and open a second file with the second reference. I don't use the object alot, but I think I have seen examples where it has been done.

Dave Hein · 2012-08-27 09:58

seek works correctly in FSRW 2.6. There was a problem with seek in the earlier version, which I believe was FSRW 1.6.

JonnyMac · 2012-08-27 13:15

This note comes right out of FSRW 2.6 -- note that seek is not supported for write.

{{
'   Seek.  Right now will only seek within the current cluster.
'   Added for PrEdit so he can debug; do not use with files larger
'   than one cluster (and make that cluster size 32K please.)
'
'   Returns -1 on failure.  Make sure to check this return code!
'
'   We only support reads right now (but writes won"t be too hard to
'   add).
}}

Reopening the file in append mode causes seek to fail.

JonnyMac · 2012-08-27 13:17

I'm pretty sure you can create TWO object references and open a second file with the second reference. I don't use the object alot, but I think I have seen examples where it has been done.

I don't want to do that when I can adapt my import program on the PC to deal with the problem. What I really want is a better SD object with the speed of FSRW and the ability to work with multiple files (two would make me happy). I'm kind of hoping that the SD support on the Propeller II will lead Chip down this path and he'll write such a beast (for the P1 and P2, of course).

Dave Hein · 2012-08-27 14:28

I ran a few tests, and seek works OK in the read mode, but it doesn't seem to work in the write or append mode. FSRW does allow having more than one file open at a time. You just need to have a seperate object for each file, such as

obj
  file1 : "fsrw"
  file2 : "fsrw"

Tracy Allen · 2012-08-27 16:36

With regard to the comment in FSRW, here is Rokicki's reply about seeking within clusters. Somewhere in that thread he also talks about adding seek for write, not yet implemented.

Also here is a link to the seek-and-ye-shall-find thread corrected link where Tomas and Jonathan got the seek function working in version FSRW24, then came the date/time support. It is a very informative thread.

SRLM · 2012-08-27 16:40

Tracy Allen wrote: »

With regard to the comment in FSRW, here is Rokicki's reply about seeking within clusters. Somewhere in that thread he also talks about adding seek for write, not yet implemented.

Also here is a link to the seek-and-ye-shall-find thread where Tomas and Jonathan got the seek function working in version FSRW24, then came the date/time support. It is a very informative thread.

I think this is the correct link: http://forums.parallax.com/showthread.php?116391-FSRW-Walk-Right-Back-(seek-and-ye-shall-find)

FSRW Trick?

Comments