Hi Kiste,
On 12/28/11 07:34 am, Oliver Seitz wrote:
Memory allocation is primarily the concern of the
compiler.
Right. But it can't do that job better than the device files permit :-)
We agree!!
On most of the popular 16f chips, there is space for 96 bytes of ram
from 0x20 to 0x7f, where implemented cells are at the upper end and the
upmost 16 bytes are shared. So addresses 0x7e and 0x7f should be used by
the compiler, makes up to 94 continuous bytes from 0x20 to 0x7d.
Here's two examples where this is not the case:
PIC16F57 / 59:
Unshared ram cells are 0x10-0x1f, 0x30-0x3f, 0x50-0x5f... while the
shared cells lie below them at 0x0a-0x0f. So here the compiler should
use the lowest addresses 0x0a and 0x0b, while 0x0c-0x0f should be
declared as unshared.
The 16f54,57,59 were originally in Jallib but have been excluded later!
From a message of Kyle in Jallist, beginning of 2010:
It has recently come to my attention that the 16F59, 16F54 and
16F57 are not supported by JALv2. This is due to the way MicroChip
decided to support data banks on these chips. Supporting these
(especially the '59) would be quite a bit of work, so unless I hear
>> an out cry they will remain unsupported and I will document them
as such.
PIC16F76 / 77:
It is true there are 96 bytes from 0x20 to 0x7f with the upper 16
bytes shared. But this is not the biggest chunk. There are address
ranges 0x110-0x17f and 0x190-0x1ff, one of which would give 112
continuous bytes when combined with the shared memory. So here it
would be best not to declare "shared as unshared" from 0x70 to 0x7d
with the compiler bytes 0x7e,0x7f, but use the range e.g. 0x170 to 0x17d.
That might be a good idea!
If any of this is too complicated, I'm perfectly happy with every
extra byte in any chunk size.
Up till now the dev2jal script handles memory assignment by interpreting
.lkr files (of MPASM) and 'exception' handling for several groups of
PICs. I'm in the process of moving data memory specifications to a table
(devicespecific.json). It is some initial work to get the info to it,
but the table is rather static so maintenance is probably minor. Big
advantages: (1) it simplifies the Dev2jal script significantly, no more
interpreting .lkr files and no more special handling of groups of PICs,
and (2) it allows fine tuning of the data memory specification for every
individual PIC.
BTW There is another table with info for individual PICs: pinmap.py.
Maintenance of this one is much more work!
Right now I'm a bit unhappy with the
situation on a pic12f615, on which 25% of the ram is shared ;-)
That will improve after the coming release!
Regards, Rob.
--
R. Hamerling, Netherlands --- http://www.robh.nl
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
