Isaac, sure I can fit 128 bytes and each pocket make it 128 bytes regardless of 14= byte. now question is how do you locate? each sector is 1024 byte and it can be split in 8*128. when data comes in w= hat math would you use to save and to read? if I use sector name then i have to save sector information too. maybe not = important unless to erase by sector. =A0=A0 4000000/128=3D31250/8=3D3906 sectors. =A0I think it will be easy just to ke= ep adding every 128 bytes and 31250 is the max number. lets say if I want to get pocket number 325 I would do the fallowing then 325 * 128 =3D 41600 - 128 =3D 41472 + 1 =3D 41473 should be the beginning o= f pocket 325=A0 do you think adding start and end character is not necessary then. =A0 thanks for your time AA=A0 On Sunday, December 22, 2013 11:27 AM, Isaac Marino Bavaresco wrote: =20 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 wro= te: >=A0=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? > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 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 --=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 .