Simple test for uDrive

[moxhamj]

I'm sure there is a cunning way around this - I might do some research on eeprom and I2C ram chips.

Next little project is to try to get an 08M to write a file. I think a lot of things can be simplified - keep the file tiny, minimal handshaking (which isn't needed so much for small files), and use a fixed file size and only try to do one thing, eg an Initialise and then a Write. I'm hoping I can get this down to just a series of Serout commands.

 

[leftyretro]

I'm sure there is a cunning way around this - I might do some research on eeprom and I2C ram chips.

Next little project is to try to get an 08M to write a file. I think a lot of things can be simplified - keep the file tiny, minimal handshaking (which isn't needed so much for small files), and use a fixed file size and only try to do one thing, eg an Initialise and then a Write. I'm hoping I can get this down to just a series of Serout commands.

Should be simple. File names can be one character long name and a write file command can create a new file if doesn't already exists or told to append to an existing file if it does.

Only thing this is a bit limiting is that you have to know and send the exact number of characters you want to write before you issue the write command. That is you can't just leave a file opened and add characters at free will and close when you want, it's a open and write a specific number of characters and close file all in one command. You can reopen later and append characters to it, but again you have to tell it how many characters will be coming before hand. That implies some kind of memory buffering before hand to make transactions to the file efficient.

Lefty

 

[moxhamj]

What about a system that said files are always (say) 100 bytes, you open it saying it will be 100 bytes, and then keep the file open and have a counter running and when it gets to 100 you close off the file and restart the counter?

The only unknown there is how the uDrive responds if the power goes off or the card is removed while in the middle of an open file.

I didn't write any demo code for 'append' but this certainly would be another cunning way to do things. I wonder if you could open a write file and append just 1 byte?

 

[leftyretro]

What about a system that said files are always (say) 100 bytes, you open it saying it will be 100 bytes, and then keep the file open and have a counter running and when it gets to 100 you close off the file and restart the counter?

The only unknown there is how the uDrive responds if the power goes off or the card is removed while in the middle of an open file.

I didn't write any demo code for 'append' but this certainly would be another cunning way to do things. I wonder if you could open a write file and append just 1 byte?

I think the append method is the one that makes the most sense, otherwise you have a open file for writing that can only be closed by filling it with whatever byte count might remain. Having the file open for long periods is inviting trouble I think in case a unplanned reset or power down happens. Maintaining a 100 byte ram buffer and then only appending when full allows the file to be open and closed safely and not exposed for mischief.

The fact that opening/appending/writing the data/closing file is all done with one command (plus the data bytes of course) means the overhead burden is not too bad even for small data clumps. One thing is clear is that this module favors fixed data size reads and writes is not friendly for any kind of variable length strings storage without some help. I can't think of a way to do a read file with out knowing what the string length might be ahead of time.

Lefty

 

[papaof2]

I can't think of a way to do a read file with out knowing what the string length might be ahead of time.
Lefty

I haven't read the detailed specs, but would it be possible to do something like this: prepend a string with a marker byte (something like 254) and a size byte (less than 256 ;-) Open file and read one byte to determine whether a string; read one more byte to get string size; read all of string.

Second option would be to have a unique way of identifying files containing strings (file name?). Then only a single size-of-string byte is needed.

Third option is a data map at the start of the file that identifes where and how big each string is - but then you're doing a mini database/filesystem within the file.

Obviously all of these add overhead to the process on both the PICAXE and PC sides...

John

 

[leftyretro]

I haven't read the detailed specs, but would it be possible to do something like this: prepend a string with a marker byte (something like 254) and a size byte (less than 256 ;-) Open file and read one byte to determine whether a string; read one more byte to get string size; read all of string.

Second option would be to have a unique way of identifying files containing strings (file name?). Then only a single size-of-string byte is needed.

Third option is a data map at the start of the file that identifes where and how big each string is - but then you're doing a mini database/filesystem within the file.

Obviously all of these add overhead to the process on both the PICAXE and PC sides...

John

Yes, there are things to think about for sure. The main advantage of having FAT16 file compatibility is one can take the storage chip out of the micro application and plug it into a PC USB drive and import the data directly to some PC application. This is most useful if the file contents are string based rather then binary data. The problem as I see it is that the uDrive FAT command set does not have a explicit 'close file' command. The file can only closed automatically after having either read or written the exact number of bytes you gave with the opening file read or file write command, no way to 'short circuit' the command and close it.

Maybe someone will come up with a ah ha moment, but I'm more hardware orientated so I dought I will crack this nut.

Lefty

 

[papaof2]

How many bytes are available for a filename?

Would it be possible to include the file length as part of the filename when writing the file? i.e., MYFILE103 would contain exactly 103 characters.

That doesn't improve the details of writing a file, but would make reading it easier.

Writing from the smaller PICAXES appears to be difficult for more than a few bytes...

John

 

[moxhamj]

Papaof2, there are 8 characters in the filename, 3 for the extension and one for the . so MYFILE04.TXT is allowed but MYFILE103 is one character too long. That could work well though, eg if you had 5 of the 8 characters in the name for the name and then 0 to 999 for the number.

It is great brainstorming this. Say you have a large text file, a Help file for instance, and you write it in notepad and save it and then you want it to print out on an LCD when the user hits a certain key. Well, just read the file size and then run a counter till it gets to the end. So I think Read is pretty straightforward.

Write is the more complex one. I have found when working with picaxes and other small microcontrollers, a mindset develops where you are always trying to save bytes, to save space. With an sd card, there is an abundance of space. How about you make all text files 16k long, and you set up a counter when you open the file, write n bytes, and then when you close it, send padding bytes (? a space character) to fill up the rest of the space.

I wonder if the uDrive might allow string manipulation on a picaxe. Define two strings s1 and s2.

Store those on a uDrive as s1.txt and s2.txt as that might make debugging easier.

Some subroutines:
dim s1 as string [in vb.net notation]
becomes in picaxe basic
b0=s
b1=1
gosub definestring

and definestring opens a udrive text file and prints 32 null (zero) characters using the name s1 and adding .txt to the name.

I'm not sure the most efficient way to put text in a string, maybe with a data statement or maybe even on a PC and create the string files before running the program, but a string text file is always 32 bytes and it ends in a null. So
s1="Hello"
is
72 101 108 108 111 0 0 0 0 0 etc

Now write some functions
len(s1) returns the length in b0
and opens the file s1.txt, reads in 32 bytes and stops a counter when the byte read is equal to 0. It will return 5 for the string above.

Left(s1,3) puts the new string back in s1.txt
It opens the file s1.txt for read, reads in 32 bytes, stores them somewhere (mabye with some pokes) up until 3, puts a null (zero) at position 4, keeps reading till it gets to 32, closes the file, reopens it for write, and writes out the 32 bytes (either 0 after the first null if you want to be neat, or just leave the bytes as they were as everything after a null is ignored anyway)

You can add other string functions eg Mid(), Right(), Asc(), Chr(), Hex() etc.

 

[leftyretro]

Well after rereading the uDrive FAT16 commands again I think I miswrote eralier about needing to know the size of a file before opening it for reading.

On issuing a read file command the first response back from the uDrive is four bytes representing the number of bytes in the file, followed by a ACK character, (it doesn't say what it sends if the file doesn't exist, that needs to be tested, but I suspect it just sends a NAK response character). You do have to keep reading all the bytes in the file before the uDrive closes the command out, so you do still need the overhead code of a byte counter so as to know how many bytes remain to be read even if they are 'padding' bytes, before the uDRIVE will close out the file. But that's not too much overhead to deal with. So no need to bury the file size into the file name, although that was a cleaver idea.

So reading prewritten files should not be a problem and dealing with them as raw binary or strings is just a matter of your software routine that is reading and parsing the input data.

Now writing files is still somewhat ackward, but one method might be, if you can predetermine the largest possible file size you would ever want to write, you could just pad the remaining unneeded file size with zero bytes until it closes. It would be a comprimize between the extra padding writing time taken plus the overhead of keeping a running byte count in your code to know how many padding bytes will be needed to be sent once you wished to close the file.

I think it's workable, just can't be treated as a simple serial data stream.

Lefty