Filling hex file with 0x3FFF

[Rusttree]

I'm looking at Nigel's example hex file for the 16F88 to blink an LED (). I noticed the empty addresses are filled with 0x3FFF, making the hex file quite large. Is that necessary or is it just a "just-to-be-sure" measure that I could skip for now?

Thanks.

 

[tunedwolf]

it just means that those locations in the program memory are unwritten, in their "empty" state

 

[tunedwolf]

The entire memory array is written, not just the data that is your program, therefore after your data is written, the rest of the array is filled with nothing, or "erased" or "empty" values.

 

[mramos1]

The PIC has a smaller word pattern than the 16 bit machines (0xFFFF). It is filling them with ones. When you erase the PIC it probably does that.

Why is this a problem?

 

[Rusttree]

I'm actually asking specifically about writing those words during programming. I know that when the chip is erased, all the data bits go high (0x3FFF for a 14-bit word), so I was wondering if explicitly writing 0x3FFF into those addresses was necessary. I'm guessing not.

There's no problem either way, I'm just hoping to decrease the programming time if I don't need to write tons of empty memory addresses.

 

[hjames]

Most programming SW/HW should automatically skip these bytes. Worst case, there should be some configuration options buried somewhere.

 

[Nigel Goodwin]

I'm looking at Nigel's example hex file for the 16F88 to blink an LED (). I noticed the empty addresses are filled with 0x3FFF, making the hex file quite large. Is that necessary or is it just a "just-to-be-sure" measure that I could skip for now?

Actually that file is nothing to do with me, and I don't know what it was generated by that would cause all the blank bytes to be written to the HEX file?.

Many programmers would write ALL the bytes in the HEX file, and older MicroChip ones tend to write the entire device regardless of HEX file size - but WinPicProg writes only the required bytes, and even skips individual blank ones - which is what makes it fast.

You can't actually write 0x3FFF, because just like an EPROM you can only make high bits low - erasing the device makes ALL the bits high (again, just like an EPROM) and you can then program them low - so attempting to write 0x3FFF does nothing.

 

[evandude]

I would suspect that any programming software that was any good would be smart enough to not waste its time explicitly writing those bytes. If you want to find out, you should have no trouble simply deleting the lines in the HEX file that contain only 0x3FFF's. (not counting the colon, first 8 characters, or last 2 characters of each line, which are part of the HEX file format)

if you do that, you can then simply compare the time it takes to program the PIC with and without those lines included and deduce whether your software is bothering to write them or not.