RandoSY / jallib

Automatically exported from code.google.com/p/jallib
0 stars 0 forks source link

Fuse_def keywords normalisation #105

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
From the beginning I have been struggling with the fuse_def declarations
for the device files. The main problem is the inconsistency in the
Microchip information. Datasheets, mplab .dev files. mpasm .inc files
frequently use different names, values or descriptions for the same thing.

Recently I discovered that the __CONFIG specification in MPASM is
deprecated and replaced by CONFIG. Even worse: for some newer (18F) PICs
__CONFIG is even not supported anymore and the use of CONFIG is mandatory.
However CONFIG requires the use of keywords in stead of symbolic names for
bit patterns.  So a change of the compiler is required to produce workable
.asm files for these newer PICs. This means the compiler has to know the
relation between Jallib fuse_def names and keywords and the corresponding
MPASM names and keywords. 

It seems time to refacture the 'pragma fuse_def' declarations in the device
files in such a way that it uses the same keywords and names as MPASM. With
some 'manipulation' the mpasm names can be derived from the mpasm .inc
files. I think it will not be too difficult to convert the .inc
declarations to proper 'pragma fuse-def' declarations.  As far as I can see
this would be an acceptable solution for the compiler. 
This change will probably involve all samples and other existing programs. 

Althought this may solve a problem, unfortunately the mpasm CONFIG keywords
are not always the same as the bit filed names in the datasheets. Since our
credo is that the datasheet is the boss, we have a dilemma!

Original issue reported on code.google.com by robhamerling on 26 Dec 2009 at 10:40

GoogleCodeExporter commented 8 years ago
I have been experimenting to extract pragma fuse_def information from the mpasm 
.inc
files. Attached you can find the result for an 18f2685. For comparison the 
second
attached file is the same copied from the current device file. The formats 
differ a
little, but the contents are basically the same. 
Essential is that the fuse_def names and keywords (symbolic values) are the 
same as
supported by mpasm. For example: 
In a JAL program you could specify 'pragma target OSC HSPLL', which corresponds 
in
mpasm to '  CONFIG OSC = HSPLL' 
The bit mask specifications become obsolete. These should probably maintained 
during
a transition period (predecated) but the syntax may be altered over time. 

One issues might be: some 'keywords' are numeric. I think JalV2 doesn't like 
that,
but these could be prefixed with a letter, like also done in the current device
files. Suggestions?

Question: would this really help the compiler?

Original comment by robhamerling on 26 Dec 2009 at 2:35

Attachments:

GoogleCodeExporter commented 8 years ago
Hi Rob, 

I am glad you are looking into this issue.  It has been bothering me 
for some time. 

I feel strongly that JALV2 should  generate ASM files that are 
compatible with MPASM (no warnings or errors), and furthermore, that 
HEX files from JALV2 should be identical to those generated by MPASM. 
These are important and powerful tools to validate large portions of 
JALV2 itself. 

If we can help in this effort, let us know.  At a minimum, we can 
revise and re-test our sample apps to make sure they still work 
properly. 

Thank you, 
William 

Original comment by bvwe...@gmail.com on 26 Dec 2009 at 4:12