Shop OBEX P1 Docs P2 Docs Learn Events
SD Card Text Formatting When Writing — Parallax Forums

SD Card Text Formatting When Writing

MoZak18MoZak18 Posts: 26
edited 2012-03-06 07:44 in Propeller 1
Hello,

I am curious as to the formatting of text files when writing to an SD card. Since I will be sending an instrument package pretty high up with a weather balloon, I am concerned about losing power (regarding the batteries and cold temperatures) and as a result losing data. In my code, which i have below, I mount the SD card, then enter a repeat loop in which i open the file, write to it, then close it....which essentially results in saving data on each loop cycle. However, my trouble comes with entering the data upon each iteration. Obviously if I simply enter the new data once re-opening the file, it will overwrite the previous data. I have tried using a carriage return, but this always overwrites what was previously written....and the new data is just written further down the page by some amount. I would like to use the position cursor function, but I have to use a variable for the Y position, and I can't get this to work. I have bolded the area of interest in my code below.

con


_clkmode = xtal1 + pll16x
_xinfreq = 5000000


DO = 10
CLK = 11
DI = 12
CS = 13


obj


sdfat : "fsrw"
pst : "parallax serial terminal"


pub demo | mount, n


pst.start(115200)
waitcnt(clkfreq*2 + cnt)


mount := \sdfat.mount_explicit(DO, CLK, DI, CS)
if mount <= 0
pst.str(string(13, "Failed to mount", 13))
abort


pst.str(string(13, "SD card is mounted.", 13))


n := 1


repeat 5
sdfat.popen(string("test.csv"),"w")
pst.str(string("opened", 13))
sdfat.pputs(string(2, 1, n, "work,right,now"))
sdfat.pclose
pst.str(string("closed",13))
n++
waitcnt(160_000_000 + cnt)


sdfat.unmount
pst.str(string(13, "Safe to remove.", 13))



As can be seen I am trying to use the local variable "n" for the Y position in the text file, however, the code won't compile. Any ideas/suggestions as to how I can write my data by opening and closing (i.e. saving) the file without overwriting my previous data? As always, any help would be greatly appreciated.

Thanks

Comments

  • Tracy AllenTracy Allen Posts: 6,664
    edited 2012-03-03 11:28
    I think you want to open the file for append, not write:
    [B]sdfat.popen(string("test.csv"),"a")   ' [COLOR=#0000ff]<---a not w![/COLOR][/B]
    


    attachment.php?attachmentid=78421&d=1297987572
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-03 13:07
    MoZak18: My guess is that you have lots of room on the SD card.
    Why not write a whole sector each time (512B)?
    If you then perform a flush it will ensure that the data is written to the card, and you will not need to close and open the card all the time (I think - please check with Kye).
    Otherwise, you could create a large blank file, and open it as update.
    BTW I am not an expert on these drivers.
  • MagIO2MagIO2 Posts: 2,243
    edited 2012-03-03 13:32
    The idea from cluso99 sounds good to me!

    I have an enhancement for FSRW which allows to have a "swap"-file on the SD-card having any size you want. The access to that file is sector based, whereas you can address the locations to write to by byte-addresses. So, you could write your messages to different sectors by simply choosing the right address:
    address := message_number % size_of_file * 512 + message_number / size_of_file * message_length

    message_number -> guess no explaination needed here ... simply increment with each message written
    size_of_file -> size of the file in bytes
    message_length -> well ... I'd define a fixed message length which divides 512 without any rest. For example 8,16,32.... whatever fits to the max. length of a message you want to write

    What happens then: Accessing a different sector with each message let's the virtual memory write the previous sector to SD card and read the actual one. This way you can only loose one message in case of failure of battery ...

    You can read about virtual memory here: http://forums.parallax.com/showthread.php?117573-Virtual-Memory
  • KyeKye Posts: 2,200
    edited 2012-03-03 15:49
    @Cluso99 - No... you need to close the file that has been opened for writing in FSRW. Or if you are using my library call the flushData function. While it is true that the data will be written to disk. The size of the file will not be recorded. This means you could write 2GB to a file and have it listed as having a size of 0... Windows will find this error when checking the disk if you want to reclaim the space without having to format.
  • rokickirokicki Posts: 1,000
    edited 2012-03-04 00:13
    With fsrw, you do not need to close the file. If you call flush, the current
    data block, the FAT (if needed), and the directory are *all* updated.

    So just write your data and flush when you are done and all should work
    fine, even if power is lost.

    (I do not know if this works with Kye's driver, but I tried to make my routines
    mimic POSIX as much as possible, and in POSIX, flush makes sure the
    data is on the disk and the metadata is updated.)

    -tom
  • KyeKye Posts: 2,200
    edited 2012-03-04 07:32
    @rokicki - Oh, I did not know if you had flush in your library.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-04 16:01
    Kye: I just noticed I had a boot error last night on my working sdcard. I reset and all was fine. This is the first time I have noticed this - probably booted 100 times in the last couple of days. I wonder if there maybe a slight timing issue requiring a slight delay in accessing the card the first time. However, it could be my end because I overclock to 104MHz.
  • KyeKye Posts: 2,200
    edited 2012-03-04 17:55
    I dunno. Lots of stuff can go wrong. If it happened only once, then it was probably a fluke.

    At 104 MHz you are violating the SD card spec of a maximum of 25 MHz clock to the SD card. My driver produces a 25 MHz clock output to the SD card at when the prop chip is running at 100 MHz.

    BTW: MMC cards are not required to work above 20 MHz. So a prop chip running faster than 80 MHz using my driver might have problems with MMC cards.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-03-04 20:31
    Kye: Just thought I would mention it. I havent had problems before with the older fsrw2.6. But you are correct in that I have not checked the speed specs. I will do that when I try to replace the low level driver to get max speed. ATM this is not a problem. With all your nice routines and excellent docs (including the horrible long names that I love to hate - bad for typing, great for understanding - cannot please both sides, and yours is for everyone to learn) it was easy to get running. I also saw where you clear the remining hub so I have patched that for now. Later I will make that, and stopping all cogs configurable.
  • MoZak18MoZak18 Posts: 26
    edited 2012-03-06 07:44
    Tracy Allen,

    The append method worked like a charm! It was too easy! Thank you so very much! Sorry for the delayed response.....and thank you everyone else for your responses!
Sign In or Register to comment.