fsrw write

mctrivia

I am playing with writing to the sd card. I can get it to create the file but it does not write anything to the file. I know I am probably missing something obvious.

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000


OBJ

  rr    : "RealRandom"
  sd    : "fsrw"

VAR
  byte rand0[noparse][[/noparse]128] 'holds 32 random longs        
  byte rand1[noparse][[/noparse]128] 'holds 32 random longs
  byte bank       'which is being used
  long stack[noparse][[/noparse]1000]
PUB start | temp, x, y

  bank:=-1

  'start RealRandom
  rr.start
   
  'start sd card recorder
  cognew(writeData,@stack) 
  
  'start generating numbers
  repeat

    'write to buffer 0
    bank:=0
    repeat x from 0 to 31
      temp := rr.random
      repeat y from 0 to 3
        rand0[noparse][[/noparse]x*4+y]:=temp & $FF
        temp := temp >> 8 

    'write to buffer 1
    bank:=1    
    repeat x from 0 to 31
      temp := rr.random
      repeat y from 0 to 3
        rand1[noparse][[/noparse]x*4+y]:=temp & $FF
        temp := temp >> 8  


PUB writeData | r
  'Mount SD Drive
  sd.mount(0)

  ' Create or overwrite file
  r := sd.popen(string("otp00002.bin"), "w")
  
  'write 1 cluster worth of data to a file
  repeat

    'wait for the random number generator to be writing to 1
    repeat until bank==1

    'write rand0 to the file
    sd.pwrite(rand0, 128)

    'wait for the random number generator to be writing to 0
    repeat until bank==0

    'write rand1 to the file
    sd.pwrite(rand1, 128)

  sd.pclose

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

Mike Green

You need to use "@" as in "sd.pwrite(@rand0,128)".

You also need to synchronize the random number generator to the write routine in case the write routine is slower than the generator. The random number generator will keep on filling the buffers, one at a time, without waiting for the write routine to finish writing the buffer. If there's enough write delay, the generator will overwrite the buffer before the write routines finishes. This could happen if the SD card is waiting for an erase cycle or needs to do wear levelling which can take 100ms or more sometimes.

Post Edited (Mike Green) : 4/18/2009 3:33:14 AM GMT

mctrivia

ya problems like that are definetly something i need to figure out. i will code in checks to prevent that. at the moment i can't get it to write anything to the card good or bad even with changing to @rand0. I am letting it run for 5 min on each try. should take 16ms to fill the buffer so after 5 min there should be something writen to the file.

Note: I have modified rr.random to wait $A000 instead of $4000 because i want a 0.5ms delay instead.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

localroger

The most likely problem is that you are remounting the drive every time you do a new access. Mount wipes the data buffers. fsrw SHOULD be smart enough to recognize that it's already mounted but it isn't. You mount once, when you start the card, and you never do it again unless you want to turn the prop off or remove the card. fsrw has other problems that will emerge churning data at this rate but it SHOULD lock while operations are performed instead of failing. And it usually does, but in a churn of this aggressiveness I wouldn't be surprised to see that it falls over.

mctrivia

figured it out. since the file is never closed properly it never gets writen to the card itself. removing the main repeat writes to samples to the card and stops.

now to get it to fill 1 cluster, pause rand generation if sd is not keeping up.....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

rokicki

fsrw is not architected to work across cogs. Any sort of concurrent access between
cogs will cause things to fail. (Of course you are not doing this, but I'm just
saying, in case other people try to use it multi-threaded).

On flushing, or prohibiting remounts---fsrw explicitly and intentionally does neither;
it depends on the programmer to use it correctly. In particular, flushing automatically
is exactly the wrong thing to do if the user switches cards and then initiates a mount.

You might want to just open the file with "w+" (append mode). Alternatively, put a
pflush in there every once in a while.

mctrivia

what I ended up doing is changing the main repeat to

repeat x from 0 to 63


this way it generates a 16k file(1 cluster) and stops. now to see if someone has writen a byte to string conversion or write one myself and make the code step to the next file name after each cluster.

Attached file is 16k resulting file.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

jazzed

In this case filename contains an the address of the string so you don't use @.
It doesn't really matter because you have enough space here since you only need 2 bytes,
but the var byte filename[noparse][[/noparse]15] should be var word filename or var long filename.
Can't help you with Tom's file methods.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

mctrivia

changing to word fixed the problem it seems. My code so far. Will let run for the night and see what i get.

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000


OBJ

  rr    : "RealRandom"
  sd    : "fsrw"    

VAR
  byte rand0[noparse][[/noparse]128] 'holds 32 random longs        
  byte rand1[noparse][[/noparse]128] 'holds 32 random longs
  byte rngbank       'which is being used
  byte sdbank
  long stack[noparse][[/noparse]1000]

  word filename[noparse][[/noparse]15]
PUB start | temp, x, y
  'initialise rng
  rngbank:=-1

  'start RealRandom
  rr.start
   
  'start sd card recorder
  cognew(writeData,@stack) 
  
  'start generating numbers
  repeat
    'make sure buffer 0 is not being writen to the sd card
    repeat until sdbank<>0   

    'write to buffer 0
    repeat until sdbank<>0
    rngbank:=0
    repeat x from 0 to 31
      temp := rr.random
      repeat y from 0 to 3
        rand0[noparse][[/noparse]x*4+y]:=temp & $FF
        temp := temp >> 8 

    'make sure buffer 1 is not being writen to the sd card
    repeat until sdbank<>1 
        
    'write to buffer 1
    rngbank:=1    
    repeat x from 0 to 31
      temp := rr.random
      repeat y from 0 to 3
        rand1[noparse][[/noparse]x*4+y]:=temp & $FF
        temp := temp >> 8  


PUB writeData | r,x,i 
  'initialie write wrotine
  sdbank:=-1
  filename:=String("OTP00000.BIN")
 
  'Mount SD Drive
  sd.mount(0)

  
  'Generate 512MB of files
  repeat i from 0 to 32767
    
    r:=i
    filename:=(r/10000)+48
    r//=10000
    filename:=(r/1000)+48
    r//=1000
    filename:=(r/100)+48
    r//=100
    filename[noparse][[/noparse]6]:=(r/10)+48
    r//=10
    filename[noparse][[/noparse]7]:=(r)+48
    
    'Create or overwrite file 
    r := sd.popen(filename, "w")
  
    'write 1 cluster worth of data to a file
    repeat x from 0 to 63

      'wait for the random number generator to be writing to 1
      repeat until rngbank==1

      'write rand0 to the file
      sdbank:=0
      sd.pwrite(@rand0, 128)
      sdbank:=-1
    
      'wait for the random number generator to be writing to 0
      repeat until rngbank==0

      'write rand1 to the file
      sdbank:=1
      sd.pwrite(@rand1, 128)
      sdbank:=-1
    sd.pclose  

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.