You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
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 issue reported on code.google.com by
robhamerling
on 26 Dec 2009 at 10:40The text was updated successfully, but these errors were encountered: