Reading, writing, erasing flash (16F88)

[RussMartin]

Do you know this, or are you guessing? I don't see how ORing bits is relevant to the question, but I'm anxious to be informed.

If the erased value of the byte is $ff (assume a byte for the purpose), and you write a $ff, nothing changes. If you write an $f0 next time, the low four bits go to logic 0. If you try to rewrite $ff, nothing changes, because the only thing that can change a 0 to a 1 is an erasure. Programming changes 1's to 0's. If you try to rewrite $30, it should change, because you are programming 1's to 0's. But you're right, I am guessing.

I think I see what you mean, but the OR aspect caught in my throat. Isn't any value (0 or 1) ORd with 1 equal to 1? If $F (decimal 16) is in the "erased" location and $A (decimal 10) is being written, doesn't %1111 OR %1010 yield the same %1111? Doesn't %1111 AND %1010 give (brief fanfare) %1010? Did you mean AND?

Okay, you've lost me on this one. Please explain: How does disregarding the 2 least significant bits of the address relate to the value stored at that address?

Say you've got an 8 bit address...256 values possible. If the PIC disregards the bottom 2 bits, it would be addressing 64 possible 'ranges' in 4-byte 'blocks'. Might have something to do with something.

By the same reasoning, if the device disregards the bottom 5 bits, it would address 'ranges' in 32-byte blocks which gives us a couple of interesting coincidences (4-word write blocks, 32-word erase blocks), but it doesn't answer the questions.

My question 4 was, "How does the write function determine whether the address location has been erased?" It looks as if the answer is, "It doesn't!" So for my question 5, "And what happens if WRITECODE is invoked without a prior erasure?", the answer is "garbage results".

Well, the data sheet seems to disagree. According to it: A read returns 1 word from flash; a write must be done as a block of 4 words; and an erase must be done as a block of 32 words.

Yes, of course, you are correct. I got ahead of myself.
I think in these cases, a read-modify-erase-writeback procedure is needed.
If you want to change one byte, you have to read the whole block that is going to be erased, change the byte you want to change, then write back the block in the 4-byte chunks.

Presumably, one "master" erase of many 32-word blocks would be sufficient for a large number of successive writes.

I think they do that for space reasons. Adding all those extra transistors to 'charge' the cells takes up a lot of space from what I've read about flash memory. Start making the 'blocks' small, and you can't fit as much on a chip. Reading is easy, writing is rough, erasing is hard...comparatively speaking.

With respect to the latter, perhaps speed rather than space is the reason, since the hardware is going to have to accomodate the lower of the two numbers (4), regardless.

As for the former: Fortunately, in my intended application, I don't have to go back and modify an already-written value, so a "read-modify-erase-writeback" scheme won't be necessary (he said, thankful). All I need do is log successive values and--very important--easily find where the logging stopped, which appears as if it can be done by looking for the magic $3FFF after the last value written (the answer to C).

I think/hope I can get by with method A: Assuming prior erasure of a large block of locations, simply WRITECODE to Address and then, next time, WRITECODE to Address+1, and so on ad infinitum--or at least until out of available flash.