Issue 194 in jallib: Device files with MPLAB-X

[jal...@googlecode.com]

Status: New
Owner: robhamerling
Labels: Type-Enhancement Priority-Medium Component-Device

New issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

The device files are currently derived from MPLAB.
Since Microchip will eventually not support MPLAB anymore in favour of
MPLAB-X, it is required to switch to MPLAB-X.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[jal...@googlecode.com]

Updates:
Status: Started

Comment #1 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Probably MPLAB-X seems to contain similar data for PICs as MPLAB, but the
format is significantly different (XML). This requires a substantial
redesign of the Jal2dev script. A first analysis showed to me that the data
is much more consistent, which could result in simplification of the script.

[jal...@googlecode.com]

Comment #2 on issue 194 by ppa...@sfr.fr: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hi,
I had the same reasoning.
If you refer to the .pic files, they already exist with MPLAB-8.
I've managed to parse .pic files for the next version of PMP and it is far
easier to parse, using some xml component it's even easier; there's less
inconsistencies (some are still there, thanks MCHP - it would have been too
easy).
They contain a bit more information, a lot of them are esoteric-voodoo MCHP
internal use only; the .inc files and aliases may be built from this
information; there's although the hw pinout information / pin aliases (only
one package - the default one, it seems to be mainly the DIP one or the QFP
if there's no DIP).
Regards,
Philippe.

[jal...@googlecode.com]

Comment #3 on issue 194 by sebastie...@gmail.com: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Data is much more consistent ? That's great news, though surprising :)
Seb

[jal...@googlecode.com]

Comment #4 on issue 194 by ppa...@sfr.fr: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Well, we may assume that the MCHP generates the .dev and .inc files by some
parsing of the .pic file.
The .pic file contains all the information, the MCHP parser may have
glitches so the .dev file contains some surprises, the .inc and .dev files
are sometimes not coherent to each other.
If you parse the .pic your way, you may correct that or introduce your own
inconsistencies, but generally speaking the .dev problems may be avoided by
cross comparing some data that are in the .pic and not in the .dev (or
differently shown or dispatched between .dev and .inc files).
There is still a few name conflicts between some assembler reserved words,
register names, register field names and pin names, you still have to use
your own logic to solve that...
For the next version of PMP I definitely adopted the .pic parsing way.
Since PMP is still using an external assembler, it generates the
processor's .inc file automatically to be consistent with the .pic parsing
and the MCHP's .inc files are no more used.
Regards,
Philippe.

[jal...@googlecode.com]

Comment #5 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

I didn't know the .PIC files are already in MPLAB-8 (I never searched).

Thanks(!) to the (bad) wheather here I have made some progress in
building .jal files from the .pic files, but there is still a lot to be
done. The more progress I made the more confident I became about being
able to generate the device files from the .pic files.
My first goal is to get the same contents as the current device files
(except maybe for the sequence of declarations). With every change of my
script I always compare the new device files with the current Jallib files
to detect differences. I'll continue to do that with device files from
MPLAB-X .pic files.

The .inc file were never used by me, and I don't think I'll need these in
the future. I did use the .lkr files for the data memory specifications.
I'll see if I can get rid of these when using the .pic files.

Philippe, pardon me, but what is 'PMP'? (Sorry when I forgot).

I think the info about physical pins is not of use for the device files,
but we may find it useful later.

Although it maybe more work, I prefer to do the parsing of the .pic files
myself. That allows me to make the necessary corrections 'inline' (I've
already encountered some strange things, e.g. for the 16f526/527).

Rob.

[jal...@googlecode.com]

Comment #6 on issue 194 by ppa...@sfr.fr: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Currently the .lkr contains only one information that cannot be found in
the .pic file, this is the reservation of code and data segments for
debugging tools. All other information may be found in the .pic file.

The pin information may replace the mechanism you've used to find
additional aliases (I read DS analysis with pdf2txt somewhere?).

Which strange things for '526/527?
I also mentioned "ghost PICs" in the MCHP's forums
(http://www.microchip.com/forums/m721003.aspx). There are some PICs that
are in the list since a long time that do not exist (not even a preliminary
DS), that programmers are proud to "support", compilers too, including
JAL...

;-) PMP is Pic Micro Pascal.

Regards,
Philippe.

[jal...@googlecode.com]

Comment #7 on issue 194 by sebastie...@gmail.com: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

@DS analysis: yes, for the first creation/load, there were a full datasheet
parsing of pins with there functions. Since then, produced file is manually
maintained, as datasheet parsing isn't something stable (both datasheets
and pdf2txt can have impacts, invalidating parser).
Seb

[jal...@googlecode.com]

Comment #8 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

w.r.t. comment#6:
Parsing the PIC files proved to be more complex than I thought at first
sight, especially for the bigger and newer PICs. Many PIC files
include 'module' files as a whole or partly, even multiple times different
parts of the same module file. Then the included contents may be modified
or sub-parts may be removed. It is sort of macro-processing system.
I decided to split the Jallib device file generation process from
MPLAB-X .pic files in two scripts:
(1) Generate 'expanded' PIC files with all the module included and modified
as described above. When this script is faultless (will it ever be?) it
needs to be run only once for every new MPLAB-X release.
(2) Generate Jallib device files from these expanded PIC files.
Script 1 is already quite complete and working pretty well. Script 2 is
essentially working too, but I still need to copy many parts of the current
dev2jal script for all the extensions like the pseudo variables, aliases
and naming normalizations.

Notes:
The 'strange' things with 526/527 are for example the size of configuration
words. I'll round the figures to 'word'.
We decided long ago to generate Jallib device files only for PICs of which
a datasheet is published, and to release only device files when at least
one blink-a-led or other sample for a PIC (or a group of PICs described in
the same datasheet) has been tested and proved to work. So Philippe, tell
us which Jallib device file is for a ghost PIC.

[jal...@googlecode.com]

Comment #9 on issue 194 by philippe...@pmpcomp.fr: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Rob,

Maybe you didn't followed my link to mchp forum above: the PIC12F520 is a
ghost PIC.

I didn't analylize the mplab-x .pic files deeply yet, just the MPLAB-8 ones
for now. Glad to know that I'll have to appreciate these "macros" too...

Regards,
Philippe.

[jal...@googlecode.com]

Comment #10 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

On "macros": They was there in MPLAB-8 files too, and I remember now that I
ignored them, not having time to investigate on what they was. Big mistake:
Some register definitions disappeared in my final devices database - their
inclusion is mandatory. I have to rework that as quick as possible now.
Thanks for the information...

[jal...@googlecode.com]

Comment #11 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

And now I know why I ignored them: The .module files was not joined along
with .pic files in MPLAB-8 packages...

[jal...@googlecode.com]

Comment #12 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hi Rob,

I'm done with these "macros" for my software.
It's a lot of fun to figure out how it works with the offset, excludes and
so on...

Meanwhile, I was checking the coherency between the new .pic data and the
old .dev-based ones - e.g., for the new base-line PIC16F570 I've heard
about recently - and I was unlucky to find an error (who's surprised?): the
MPLAB-X .pic says it has only 2 code sections (wrong) but the DS and
the .lkr says it has 4 (right). The MPLAB-8 .dev says it has 2 (wrong, but
if based on the .pic this is a coherent)...
We definitely need automatic checking procedures. For now, I guess that I
will rely more on the .lkr than on the .pic files for sections.

Regards,

[jal...@googlecode.com]

Comment #13 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

You were quick with the module include/macro/exclude (compared to my
speed!).
When you generate 'expanded' files, we might compare these to check each
others results (= correct each others faults).

You should upgrade to mplab-x 1.80, in which for the 16f570 I see 4
CodeSectors.

Regards, Rob.

[jal...@googlecode.com]

Comment #14 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hi Rob,
I'm not faster, I had started the parsing since a long time, so I had the
tools. The macros was not obvious at first read, isn't it?
Unfortunately I do not generate an expanded text file but directly a
proprietary binary database (~7 Mb for all processors / SFRS / sections /
pins / misc.; whole generation takes ~4 min on my workstation); like that
the compiler loads data directly in its format, no further parsing is
needed.
For MPLAB-X, I will upgrade, thanks.
The '570 was quite recent and its DS is still preliminary so I understand,
but there's other issues in the GPR segments: I found errors with
some "shadowidref" that was missing, giving incoherent mappings.
Curiously, the strange-named 12'529T39A & 12'529T48A have exactly the same
errors than the 16'570...
As said before, the .lkr is more reliable for mapping the shared segments
and mirrored registers. I still don't know from which data the .lkr files
are made...
I know you don't use the pins definitions but just to say: many processors
have the same duplicated RG5 pin definition...
I'm focusing now in adding more coherency checks, a method to apply patches
after .pic parsing and to detect / report changes between MCHP releases.
So it's not over, I guess we will detect more errors that will need new
workarounds.
We are doing the MCHP quality check! Do we'll send tickets for MPLAB
improvement? Well, as some errors are still there years after signaling
some, I'm not sure I will spend time another time...

Best regards,
Philippe.

[jal...@googlecode.com]

Comment #15 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hi,
Just upgraded to MPLAB-X 1.85...
For the 16'570 its OK for code segments as you said but it's still not OK
for the GPR segments as I said above...
Although my parser filters out files that are not PIC10, 12, 16 & 18, it
fails now with this new strange "PIC18F47GT00.PIC" file (what's that?). I
have to investigate this a bit more.
New surprises at each release... Need to upgrade my file name filter!
BTW: Do you support RF PICs in JALLIB (PICRF*.PIC)?

Regards,

[jal...@googlecode.com]

Comment #16 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Ok, I've installed mplab-x 1.85 now too.
I didn't notice with 1.80, but this version contains .dev files, which seem
to be the same as those of mplab 8.91 (at least the dates are equal). I
wonder if these will remain present in future versions of mplab-x. If yes I
may have wasted my time on exploring the .pic files....

I've excluded the rfPICs from the device file generation. I think nobody
ever requested support in Jal and I don't know if these are supported by
the compiler.

Regards,
Rob

[jal...@googlecode.com]

Comment #17 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hi,
Where did you find the .dev files in the 1.85?
I can't see where they are.
Regards,
Philippe.

[jal...@googlecode.com]

Comment #18 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

On my W7 system in the directory:
C:\Program Files\Microchip\MPLAB IDE\Device
Regards, Rob.

[jal...@googlecode.com]

Comment #19 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hem, this is the MPLAB-8 install directory, not MPLAB-X?

[jal...@googlecode.com]

Comment #20 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

My mistake! I've installed both MPLAB-X and MPLAB on the same system. When
looking at dates of the directories: the .dev files must be of the MPLAB
install.
Sorry for my misleading comments... I better remove 'm (later). Rob.

[jal...@googlecode.com]

Comment #21 on issue 194 by philippe...@pmpcomp.fr: Device files with
MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

So we got a scare...
MPLAB-8 & MPLAB-X are normally in separate sub-folders so they may coexist.
AFAIK you should not remove .dev files because they may be required if you
plan to use MPLAB-8.

BTW: Did you noticed that there's tons of duplicated .jar files?
e.g., .\MPLABX\mplab_ide\mplablibs\modules\ext files are duplicated
into .\MPLABX\mplab_ide\bin\lib.
Source of confusion, wasted disk space, download time, ...

[jal...@googlecode.com]

Comment #22 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

I've excluded the rfPICs from the device file generation. I think nobody
ever requested support in Jal and I don't know if these are supported by
the compiler.

[jal...@googlecode.com]

Comment #23 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Progress report:

I'm reaching the point where the generation process from MPLAB-X files
produces reasonable looking JalV2 device files. Previously I kept a new set
separated from the committed set and used a script for a more-or-less
automated compare of device files. This way I checked if changes were
applied correctly and other parts were unchanged. Kdiff3 is very helpful
to compare partly changed files!

However the MPLAB-X .pic files use a different sequence of bits within a
byte than the MPLAB .dev files and addresses of registers and bit-offsets
rely on this sequence. Thus the device files will change accordingly. For
example: were the pins of portA declared in sequence pin_A7 to pin_A0, in
the new device files the sequence will be pin_A0 to pin_A7. The compiler
doesn't care, but it makes an automated comparison between new and old
files almost impossible. So I can think only of a visual compare of about
500 device files.
Anyone a suggestion for a better method?

Compiling the samples may detect errors too, but I think most samples and
libraries use only small parts of the device files, and errors in other
parts may remain undetected.

Even when I would be ready to commit the new device files I'll have to wait
for the JalV2 2.4q compiler because some changes need 2.4q (such as the
removed 'shared' keyword of variables in shared memory).

BTW I have also new device files generated from MPLAB 8.91 waiting to be
committed because of the missing 2.4q release! I think I prefer to commit
these set first (and suggest to do a Jallib release before switching to
device files from MPLAB-X)

Regards, Rob.

[mattschinkel]

>Anyone a suggestion for a better method?

Can you do a replace before a compare?

 

Matt.

[Rob Hamerling]

On 2013/07/15 10:59, mattschinkel wrote:
> >Anyone a suggestion for a better method?
>
> Can you do a replace before a compare?

I'm afraid I don't understand what your mean by this.
Which device files (where) would you want me to replace?

Regards, Rob.

--
R. Hamerling, Netherlands --- http://www.robh.nl

[Eur van Andel]

On 13 jul. 2013, at 21:00, jal...@googlecode.com wrote:

> Anyone a suggestion for a better method?

If the device files contain the same info, you could sort them before you compare. Most of the statements in a device file are one line.

What language will the generator be in? If python, I and others might be able to help.

Can you post a new version of a (big) device file so we can think about comparing methods?

I just programmed a big obscure PIC, the 18F67K22, where I use all but two pins. They all work. Don't worry too much about untested parts of device files.

[Rob Hamerling]

On 2013/07/15 15:55, Eur van Andel wrote:

> If the device files contain the same info, you could sort them

> beforeyou compare. Most of the statements in a device file are one line.

That might help indeed.

> What language will the generator be in? If python, I and others might be able to help.

My script to generate device files is written in Rexx. But I don't see
that this is relevant for comparing two sets of files.
I've very little experience with Python.

>
> Can you post a new version of a (big) device file so we can think about comparing methods?

If I think I'm about ready I could post one of the files.

>
> I just programmed a big obscure PIC, the 18F67K22, where I use all

> buttwo pins. They all work. Don't worry too much about untested parts
> of device files.

When the compile doesn't complain with the samples I'm pretty sure there
are very few errors.

[Rob Hamerling]

Hi Eur,

On 2013/07/15 15:55, Eur van Andel wrote:

> If the device files contain the same info, you could sort them before
> you compare. Most of the statements in a device file are one line.

I tried with a compare after sort, but it worked out only partly. It's
fine for equal lines, like to check addresses of SFRs and offsets of bit
fields, but for unqual lines, especially missing and extra lines it's
not always obvious where these belong. The visual compare with kdiff3
works better.

At the moment I've more than 60% of the 1100 samples compiling without
errors or warnings. Hopefully the 20-80 rule doesn't apply to get the
rest working.....

[Joep Suijs]

Hi Rob,

Would it help if you sorted both files and then use a diff tool?

Regards,

Joep

2013/7/21 Rob Hamerling <robham...@gmail.com>

--
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 jallib+unsubscribe@googlegroups.com.
To post to this group, send email to jal...@googlegroups.com.
Visit this group at http://groups.google.com/group/jallib.
For more options, visit https://groups.google.com/groups/opt_out.

[Sebastien Lelong]

Hi Rob,

If you send to me two or more files you'd like to compare as an example, I can also have a look and see which magical command line may help...

Cheers

Seb

To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

To post to this group, send email to jal...@googlegroups.com.
Visit this group at http://groups.google.com/group/jallib.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Sébastien Lelong

[Rob Hamerling]

Hi Joep,

On 2013/07/21 11:59, Joep Suijs wrote:

> Would it help if you sorted both files and then use a diff tool?

That's what I did! And it didn't help me very much.

As soon as I have a device file of a bigger PIC looking reasonably good
I'll put it on a place where you (and everybody else who wants to help)
can download it for test/comparison purposes. But these days it's too
hot in my office to make serious progress!

[Joep Suijs]

Hi Rob,

It was brave of you to start with this conversion. It would be next to a mirical if you can reach the same quality as you did with the previous one.

As you might have guessed, it is hot here too. Also only a very small portion of my time is spent on JAL these days, giving priority to a C++ robotics framework...

Regards,

Joep

2013/7/21 Rob Hamerling <robham...@gmail.com>

[Rob Hamerling]

Hi Joep,

On 2013/07/21 22:10, Joep Suijs wrote:

> It was brave of you to start with this conversion. It would be next to a
> mirical if you can reach the same quality as you did with the previous one.

No miracles, just lots of time and hard work! But thanks for the
encouragement!

I've added a device file for the 18f4550 to the test/device directory.
All samples for this PIC compile OK, but I have not tested any of these.
If anyone could test 'm, fine!!!
For the moment I would be glad with a better, less time consuming method
than kdiff3-assisted visual compare of all old and new files.

[jal...@googlecode.com]

Comment #24 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Some more progress!
Of the 1107 Jallib samples there are only 25 left which don't compile
without errors. In about 15 cases the compiler (2.4q beta dd June 8)
reports skip errors, an issue under investigation by Kyle. Of the other
failing samples the causes are various: missing pin_a0 or pin_A0_direction,
and other 'minor' problems I'll try to solve.
A few samples (about 10) had to be changed because a change in one of more
fuse_def statements in the new device files.
With the switch from MPLAB .dev to MPLAB-X .pic files I discovered some
errors in the current device files. For example multiplexed SFRs (using the
same address) are not in all cases correctly supported by a pseudo
variable. This will be fixed with this set of device files.
I'll put some more of the new device files in the test/device directory for
test purposes those who want to help with this development.

[Sebastien Lelong]

Hi Rob

Does a sample compiled with "old" device files produce the same Hex file as with "new" ones ? I guess no, that'd be too easy to compare, but I'm asking just in case... ;)

Cheers
Seb

[Rob Hamerling]

Hi Seb,

On 2013/07/25 10:29, Sebastien Lelong wrote:

> Does a sample compiled with "old" device files produce the same Hex file
> as with "new" ones ? I guess no, that'd be too easy to compare, but I'm
> asking just in case... ;)

I don't know, I didn't make this kind of comparison yet. I'm already
glad that the samples compile! But thinking about it: I suppose the hex
files should match! Why not? The program and functional libraries make
the hex file. Supposing there are no errors in the adresses and offsets
it should not matter in which sequence these declarations are in the
device file. The port-shadowing and similar 'tricks' could make a
difference.

BTW: My main concern are the addresses, because in the .pic files the
addresses of SFRs are not explicitly specified per SFR. The
start-addresses of banks are specified, the SFR addresses must be
derived from the sequence in a bank (a matter of counting, taking into
account address gaps, 'shared' SFRs, multi-byte specs, etc.).

[jal...@googlecode.com]

Comment #25 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

The pic2edc script is ready as far as I can see, but the edc2jal script is
certainly not. Nevertheless - just to make sure my time and work for these
new scripts are not wasted (for example when I become victim of a train
crash) - I've added these scripts already to the tools directory.
Preliminary versions of device files of some popular PICs are uploaded in
the test/device library for those who like the game 'search the ten
differences'.

[jal...@googlecode.com]

Comment #26 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

All available MPLAB-X derived device files uploaded to /test/device.

When you compare the new device files with the current files note that no
variables are declared 'shared' anymore. The only place where variables
(addresses) are declared 'shared' is with the 'pragma shared' line.
I think this needs compiler 2.4q.

When testing these device files use the latest 2.4q-beta compiler. You may
encounter 'skip errors' or 'branch errors'. This is an issue with the
compiler (under investigation by Kyle), not with the device files. Of the
current Jallib samples 15 produce these kinds of errors.

Rob.

[jal...@googlecode.com]

Comment #27 on issue 194 by sebastie...@gmail.com: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Hi Rob, I tested some of my samples for jaluino bee, 18f27j53 based: blink,
serial hw, rtc, sd card, rtc, everything works nicely ! I had to update:

-pragma target SOSCSEL HS_CP
+pragma target SOSCSEL HP

that's all :)

Cheers,
Seb

[jal...@googlecode.com]

Comment #28 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Thanks Seb! I wish there were more people like you. Feedback is very
meagre.

Yes, several fuse_def keywords have changed (in MPLAB-X 1.85 compared to
MPLAB 8.91). That happened previously as well when migrating to a newer
MPLAB version.
Generally the new keywords better match the description, so I have left it
(changed), and some of the samples have to be changed.

In the meantime I found more issues especially with the midrange. I'll
update the test/device directory.

The latest JalV2 2.4q-beta (2 aug) fixed the 'skip errors' which appeared
with about 15 samples. So all samples compile OK now.

Rob.

[Joep Suijs]

Comment #28 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

Thanks Seb!  I wish there were more people like you. Feedback is very meagre.

I am sorry you get so little response on all the hard work you're doing. Having said that, it is not very likely you get feedback from me in the near future either. Most of my development is in C++ these days and the litte jal that remains is currently not linked to jallib svn since it lacks proper i2c eeprom libs ;)

Joep.

[jal...@googlecode.com]

Updates:
Status: Fixed

Comment #29 on issue 194 by robhamerling: Device files with MPLAB-X
http://code.google.com/p/jallib/issues/detail?id=194

No error reports: issue closed!

Scripts to generate device files, several tool files and the documentation
are adapted for use of MPLAB-X 1.95 and committed.