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:
Robert Pearce ####@####.####
Date:
30 Jan 2007 09:01:26 +0000
Message-Id: <20070130090058.a6472af2.rob@bdt-home.demon.co.uk>
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.
> 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.
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.
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.
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
