SD Write advice please

[Francis]

I was wondering if there is a cunning way to do the following please. (I see so many clever techniques so I was hoping to learn).

I want to write an array of data bytes to SD.
Trouble is the actual number of valid data bytes varies.

Example: (Apologies if it sounds confusing).
A general array Fred(128) bytes long.
Sometimes all 128 bytes are valid data, but sometimes maybe just 1 or or 20 or whatever bytes are valid (as in numbers I want to store). Noting that sometimes a zero is also valid. The number of valid bytes is always known before writing.

What is the quickest/most efficient way of writing, what is in effect a variable length array using SD.Write(..)?

Or do I just put the SD.Write in a loop repeating X times? (X being the number of valid bytes).

I was just wondering if there was a cunning plan.

Thanks.

[xor]

Probably the simplest method is the same one used for strings. A zero at any point is the end of the string regardless of how large the container array. You can also create a multi-byte delimiter to indicate the end of valid data (if 0 is valid data) Your loop stops reading data when the delimiter has been reached.

All said, your system must also insert the delimiter in the course of events.

[Francis]

Thanks xor. A multi-byte delimter is a neat idea.

Assuming I have a 'buffer' called MyArray size 128 bytes, I was really wondering if:

SD.Write(MyArray,255,13,10)

was significantly quicker than

Loop Start
SD.Write(MyArray(I))
inc I
Loop End
SD.Write(255,13,10)

The problem is that MyArray() may have 1 to 128 valid bytes within it. So writing the whole of MyArray would result in (potentially) a lot of unwanted zeroes written to SD.

It was really a question of speed rather than size.
(My wife agrees).

But based on your first point I guess I could force a minimum of 1 for incoming data bytes. And does SD.Write library routine know to stop writing at a zero? I couldn't see in 'Help' whether that was the case.

I guess the easiest way is to try it....

Thanks for the tips.

[SteveB]

How about making the array 129 bytes long? Byte 0 then contains the number of current valid data bytes in the rest of the array. Bytes 1-128 contain the data.

SteveB

[Steven]

Francis,

The SD library does not have an option at the moment to write an array - it will accept boolean, bit, byte, char, shortint, word, integer, longword, longint, float and string, but not arrays. If I implemented it, it would simply be a repeat until loop. I'd suggest that you use this also, either a set number of times, using a variable to hold the number of bytes to write, or until a delimeter is met. Write a single byte on each loop. You could write this all as an additional subroutine (and even add it to a copy of the SD library in your user library if you wanted).

Regards,

Steve

[Francis]

Thanks Steven.
I did just that, though I wouldn't know how to adjust the (your?) SDFilesystem file to accept an array - especially as I'd have to send an extra variable to tell it how many bytes were valid/useful.

A little question (of minor importance).
Am I right in assuming that a loop in my code which keeps calling the SDFilesystem to send just a single byte-at-a-time would be slower than sending an array to the SDFilesystem where it sends byte-at-a-time within the SDFilesystem routine?
If so, is it significant?
If not, no matter.

Thanks for all the advice.

[Steven]

No, I don't think it would be slower, as the SD library would do something similar to what you are doing. If anything, your method will be faster as the array does not have to first be passed to the library sub (although in practice it would be passed by ref anyway, which would make the difference minimal). If you look at the SD library code, the write byte sub is used to write anything bigger, e.g. a string, as a byte at a time.

Regards,

Steve

[Francis]

Thanks Steve.

[johngb]

You may get a little more speed if you use the PICs indirect addressing - i.e. dropping down into asm to transfer the array