gnupic: Re: [gnupic] program memory not used with addlw 0xFF (H'3FFF')
Subject:
Re: [gnupic] program memory not used with addlw 0xFF (H'3FFF')
From:
"Nestor A. Marchesini" ####@####.####
Date:
31 Jan 2007 19:05:57 +0000
Message-Id: <45C0E9AD.7080001@xinet.com.ar>
Hi Robert, thank you for answering.
Robert Pearce escribió:
> Hi Nestor,
>
> On Tue, 30 Jan 2007 02:24:07 -0300 you wrote:
>
>> The difference is that gpsim-0.22.0 puts the spaces not used as INVALID
>> H '0000' and MPLAB like H '3FFF'
>> (addlw H'FF')
>>
>
> More significantly, or at least more accurately, GPSim leaves undefined memory regions full of <OS default empty value> whereas MPLAB explicitly fills them with <blank flash value>.
>
> This is probably a misbehaviour of GPSim, although one that _should_not_matter_ to normal properly written code.
>
It happens to me that if the pics come from factory with H '3FFF' (all
the cells in 1) and it is supposed that on having erased them (at least
with PicStartPlus) they turn all the cells to H '3FFF', it should be
assumed H '3FFF' and not H '0000' ... for something the manufacturer
makes it like that not?
>
>> and this concerns fundamentally in the calculation of the
>> checksum under simulation, since I
>> need to simulate the code to obtain the two bytes that are stored in the
>> memory eeprom of data
>>
>
> There is a problem here, that your code is testing for something it does not guarantee. Now it may be that in every practical case, the end product is programmed once and once only with the code, starting from a new blank PIC. In this case, the "unused memory full of 0x3FFF" condition will be true, but it's not explicit in any sense so you can't truly and honestly test for it.
>
Exactly, I cannot assume that the places not used in my code in the new
pics, contain H '3FFF'.
> Your "not very elegant" solution actually makes the hidden assumption explicit, so to my mind it's a perfectly reasonable, correct and quite elegant fix.
>
If, the truth is that the directive FILL me saved and actually it solved
the problem. :-)
> Two other obvious fixes occur to me:
> 1) Change the test code to only test memory defined by your code. This fails to spot changes that cannot affect the functionality, and thus achieves only your customer's intent rather than (necessarily) their stated requirements.
>
Mmm, it would become very complex and I talk the code on having wanted
to do it.
> 2) Use a checksum algorithm that is insensitive to this difference. OK, I can hear the cries of "you what!" already. Suffice to say that a major customer of my employers specify a checksum algorithm that adds in the carry each time. It's not clear why they do so (probably mostly for extra confusion) but the end result is that in most cases, a solid block of 0xFF has the same effect as a block of 0x00
This code I began it a lot of time ago, when still was using MPLAB,
initially, had not had problems, but as the reviews were increasing the
code was growing in size, until I overcame them 2K and there the
difference appeared.
You has the whole reason, it is not possible to compare the efective of
a CRC16 with a simple checksum, I would have to bear it in mind, but
well, alone it was to give a compliment to my client.
Regards
Néstor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 colo
MSN ####@####.####
####@####.####
####@####.####
http://www.deselectronica.com.ar
