OK, I skimmed over your device's datasheet and found that it indeed
doesn't have the concept of a writing "page", it can be written at any
byte boundary, but it has an erase granularity of 4kiB though.

I think you could round each write size to the next power of 2, so the
14 -byte packet uses a 16-byte block and the 110-to-128-byte packet uses
a 128-byte block. This way it is easier to locate the beginning of each
packet in the memory.

If you have plenty of memory you could write each packet to a 128-byte
block, regardless of it being 14- or 128-byte long. This way you would
have direct random access to any packet at any time without scanning the
memory from the beginning until you find the packet you need.


Isaac


Em 22/12/2013 16:05, Andre Abelian escreveu:
> all, thanks for your replay,
>
> my question was about a method to write and read back data and keep track=
 of it.
> I am not sure why do I need to know the page size? I can write even singl=
e byte when it comes to erase I will erase all after download all. I am usi=
ng SST25VF032 and it is not important to save space at all. mostly the flas=
h will be empty any way.
>
> thanks
>
> AA
>
>
>
> On Sunday, December 22, 2013 5:44 AM, RussellMc <apptechnz@gmail.com> wro=
te:
> =20
> IF it works as you say (and there are not page size considerations as wel=
l)
> then could you not write in 15 or 16 byte blocks?
> Say data + 1 or two status bytes per block.
>
> 14 bytes requires ( 14 + 1 )/15 =3D 1 block
> 128 requires 128/14 =3D 9.14 =3D 10 blocks =3D 10 x 15 =3D 150 bytes.
>
> Using 130 byte blocks as you proposed wastes 112 or 2 bytes for actual da=
ta
> lengths of 14 or 128 bytes.
>
> Using 15 byte blocks wastes 1 or 22 bytes for 14 or 128 byte actual data
> lengths.
>
> Which system is more memory efficient depends on the ratio of the number =
of
> 14 and 128 byte blocks.
>
> Using 16 byte blocks is probably easier on the brain.
>
> ______________
>
> For greater efficiency the first block could specify if it was a single 1=
4
> byte block or a 128 byte block and in the latter case could pack all data
> words except the first full.
> Don't get out of sync :-(.
>
> If eg a 16 byte block was used.
> - 14 =3D 14 + 2 wasted
> =3D 14/16 utilised =3D 87.5% utilised.
>
> - 128 =3D 14 + 7.125 x 16
> =3D 9 x 16 bit blocks =3D 16 bits wasted =3D 88.9% utilised
>
> ___________________
>
> Even if page size considerations require you to buffer to RAM the above m=
ay
> still make storage in Flash easier to manage. Or not.
>
> ______________________
>
> 2:30am. I wonder if that all made sense?
>
>
>                    Russell
>
> "If a packet hits a pocket ...

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.