SFRs of 18Fs outside AccesBank declared 'shared'

[GoogleCodeExporter]

The device files for the 18Fs have all SFRs and their subfields declared as
'shared' even those which are not in the AccessBank. 

Original issue reported on code.google.com by robhamerling on 23 May 2009 at 12:49

[GoogleCodeExporter]

This issue was initially reported as a problem with the combination of 18F14K50 
and
the USB libaries, but after some analysis the problem appeared to be of much 
more
general nature.
As far as I understand the addressing mechanism of the 18Fs ;-) and the way the 
JalV2
compiler handles 'shared' memory only GPRs with address below the
'AccessBankSplitOffset' and SFRs with address of (0xF00 + AccessBankSplitOffset)
until 0xFFF (incl.) may be declared as 'shared'.
For 18Fs without SFRs below the AccessBankSplitOffset there is no problem. And 
for
18Fs with such SFRs these registers are most of the times for 'special 
purposes',
like for CAN modules (and USB!). So the effect of this bug is limited. 
I have a fix for the dev2jal script which generates the device files. But I 
have no
means to actually test this fix these days. A 'visual check' however shows it 
solves
the issue.

The question is: shall I update the device files now, that is before release 
0.3?
Since I have currently only limited access to the Internet it may take some 
time.... 

Rob.

Original comment by robhamerling on 23 May 2009 at 1:10

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

0.3 release is ready, only announcement is missing... Let's release, and keep 
this
known bug in mind. Since 0.3 is done, this means you can update your device 
files as
you want !

Seb 

Original comment by sebastie...@gmail.com on 23 May 2009 at 1:19

[GoogleCodeExporter]

A fix has been applied to the dev2jal script.
The device files have been refresehd as of version 1014.
Note: the fix has been tested only marginally ...

Original comment by robhamerling on 25 May 2009 at 3:41

• Changed state: Fixed