On 05/12/2015 09:38 AM, 'Oliver Seitz' via jallib wrote:
I thought the best thing would be to tell the compiler, that the
memory size is smaller than the actual number, so an
out-of-code-memory-error is thrown, even when there are some bytes left.
The EEPROM-replacement memory MUST be placed at the end, for the
high-endurance cells occupy those adresses.
Such a library would be told how many bytes I intend to use. The
library then would in some way reduce the code space size known to the
compiler and use the then-reserved cells as EEPROM. The only open
question is if the compiler accepts a change of the available code
space after the first PRAGMA CODE statement from the device file.
There are some more considerations, like with re-programming the PIC the
HEF memory must be preserved by the PIC programmer. I have not checked
but I suppose PicKit3 and supporting software are capable of this.
Another concern for a ibrary is to know the amount of available HEF
memory and the row size. I don't know if these properties vary among the
different PICs with HEF. A quick look in the 16f1709 file of MPLAB_X
does show rowsize, so that would e easy to declare as constant in the
device file, but I did not find amount of HEF, so that would have to be
added 'manually' (via the file devicespecific.json).
We have a Jallib library 'flash_data' for the 18fxxjxx group of PICs.
It addresses some of the issues and its method might be model for a HEF
library.
Regards, Rob.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/jallib.
For more options, visit https://groups.google.com/d/optout.
