Perhaps your device doesn't have this limitation and may be programmed
at byte granularity and may accept multiple writes to each page without
erasing, but that is not true for every FLASH device in existence.

Most high-capacity FLASH devices can accept just one write to each page
before the page must be erased, even if the subsequent writes will only
change '1' bits to '0'. That=B4s because the memory writes a CRC/ECC to a
reserved additional area for each page. It is unlikely that the CRC/ECC
will have only '1' bits changed to '0'.
Besides, each additional write to a page will stress the previous data
written to the page, so the older data will "fade" away.

As I said in my previous post, there is a maximum number of writes a
cell can endure and it seems to be 100,000 for your device, so it is
recommended that you implement some sort of wear balancing, that is, do
each write to a different page and try to distribute the writes and
erases across the device.

The method of buffering the data to a RAM buffer and writing one full
page at a time can save a lot of writing time and wearing of the memory
cells. One 512-byte page programmed in 16-byte blocks will wear 32 times
faster than if it is programmed only when full.


You could create or use an existing FLASH file-system that implement
wear-balancing. It would be much simpler for you, you don't need to keep
track where in the device the data is really stored, all you will see
are files that you can seek, read and write into.


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
.