First, 4MiB is 4*1024*1024 =3D 4194304, not 4000000. So 4MiB / 128 =3D 32768 =3D 0x8000 =3D 0b1000000000000000 The memory used is the same irrespective of how you start numbering. Counting from 0 to 127 uses the same 128 bytes as Counting from 1 to 128. Just name your first byte as "0" and count up. The beauty of powers of two is that it is easy for a CPU to divide by them, just shift right the bits. Multiplication is just shifting left. Suppose you number your packets starting from zero. To find the start address that the packet will be saved you just need to multiply the packet number by 128, or do a left shift that is the analog to multiplication for a power of two. unsigned long Packet_Start_Address, Packet_Number; .. .. .. Packet_Start_Address =3D Packet_Number * 128; // Will take longer and use much more program memory or Packet_Start_Address =3D Packet_Number << 7; // Much faster and uses minimal program memory To convert from Packet_Start_Address to Packet_Number just do: Packet_Number =3D Packet_Start_Address / 128; or Packet_Number =3D Packet_Start_Address >> 7; Don't waste memory, start storing your data at the packet start address+0. Forget about that thing of using address+1. Isaac Em 22/12/2013 18:06, Andre Abelian escreveu: > Sorry I forgot to mention that the way I calculate byte 0 is not used sin= ce it is starts from 1. > what I am not sure is 1-128 may not be inside sector maybe 0-127 is the w= ay they have it. > > > > On , Andre Abelian wrote: > =20 > 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= what math would you use to save and to read? > if I use sector name then i have to save sector information too. maybe no= t important unless to erase by sector. =20 > 4000000/128=3D31250/8=3D3906 sectors. I 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= of pocket 325=20 > do you think adding start and end character is not necessary then. =20 > > thanks for your time > > AA=20 > > > > 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 trac= k of it. >> I am not sure why do I need to know the page size? I can write even sing= le byte when it comes to erase I will erase all after download all. I am us= ing SST25VF032 and it is not important to save space at all. mostly the fla= sh will be empty any way. >> >> thanks >> >> AA >> >> >> >> On Sunday, December 22, 2013 5:44 AM, RussellMc wr= ote: >> =20 >> IF it works as you say (and there are not page size considerations as we= ll) >> 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 d= ata >> 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 = 14 >> byte block or a 128 byte block and in the latter case could pack all dat= a >> 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 = may >> 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 .