paste those lines here... for the original and the read one.
paste those lines here... for the original and the read one.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
I compared the files again and the only differences are in the last 4 lines.
Here are the last 4 lines of the written file:
:0C03D0000D300C1EE92999006029630023
:04400E00622FFF3FDF
:00000001FF
;PIC16F88
And here are the last 4 lines of what comes back from the read:
:1003D0000D300C1EE929990060296300FF3FFF3FA3
:08400000FF3FFF3FFF3FFF3FC0
:04400E00622FFF3FDF
:00000001FF
probably some unused/modified EEPROM data. Try to erase your PIC (ALL, code, eeprom etc), then reprogram it.
Could be some device id or something like that.
Did you set your configuration fuse in your code or with your winpic software?
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
I tried the full erase and it didn't change anything.
The config fuse is in the code and I didn't change it in the software. I did another test to where I simply opened the original hex file and did a save as. The original was 2762 bytes and the new file was 2851 bytes. I'm thinking it is something with the software now. I'm going to play around with the settings and see if I can figure out what is causing it.
i wouldn't bother too much with that... it could be something like a PIC revision or something like that, which is simply not set in the code, but a Microchip setting... which is way not useful unless you have a silicone issue.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
This line, <strike>I can't totally explain</strike>. It reads 2 (BLANK) program words, as if it's part of the program.
:0C03D0000D300C1EE92999006029630023
:1003D0000D300C1EE929990060296300FF3FFF3FA3
Added: AhHa, the 16F88 Flash is grouped in blocks of 4. The extra 2 words fill in the last block.<hr>
The next line is only in the (Read) version, and is the ID Locations.
They weren't specified in the original hex.
:08400000FF3FFF3FFF3FFF3FC0<hr>
This line is the Config Words (same in both)
:04400E00622FFF3FDF
DT
Last edited by Darrel Taylor; - 20th November 2007 at 20:56. Reason: Block of 4
thanks guys. I appreciate the help. I normally wouldn't bother but I'm trying to learn this stuff and it always makes me wonder when I can't figure something out....even if it doesn't seem to be a problem. On top of that, I'm trying to make sure this simple programmer that I built is actually working the way it is suppose to. I thought a simple write/read would do the trick but that lead me to where I'm at
After my last post I went through winpic800 and played with the options and watched what it did to the output file. I noticed where the 'id' started to come into play as it was not in the original hex. I still wasn't able to figure out the difference in the first lines:
:0C03D0000D300C1EE92999006029630023
:1003D0000D300C1EE929990060296300FF3FFF3FA3
Even after reading Darrel's response I'm still a bit puzzled with these 2. The other lines make sense. Maybe you could explain a little more Darrel?
Here is a link to the actual circuit/application that I'm trying to duplicate.
http://njhurst.com/electronics/watersensor/new/
Maybe this may explain things a little more and you can help me understand.
Well, it's like mister_e said ...
"i wouldn't bother too much with that..."
The minor differences between writing and reading will not interfere with the project you are building.
And IF everything else is correct????? That's a BIG IF.
It should work!
<br>
DT
Here we say... If it's not broken.. don't fix it![]()
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Yes, you two are right.....I need to just let go and move on. I'm sure I will run into something else that will actually be a problem. Anyways, I've built the circuit and loaded the hex file and I'm getting good data back so I guess all is well. thanks again for your help.
Bookmarks