Hi Rob, Is OK to change PLLEN to PLLDIV as is on other compilers but for other registers we must stick with what we have now and take care only on new devices. What we have now must be made "read-only". Fortunately, we are not forced to use gpasm or mpasm to compile our user programs (thanks Kyle). So, we can resist a little longer than other compilers... or, maybe other resources are good enough (as is for Swordfish Basic)?
Otherwise, the problem of not having the same meaning for some registers from PIC to PIC will be the same for all users, not matter what development chain they use. As for your work, is a top quality one, thank you! Also, thank you for that wiki page which permit to easy find the datasheet for any PIC I want because Microchip changed the way you can find a datasheet and is much harder (if not impossible) to use it. >From my POV, I can stick with actual development chain (and the existing number of devices), and hopping here we will have also pointers, records and maybe a FP? Well, pointers and records will be enough. So, who cares about Microchip and his will of conquering the world :-D as long as we still have those cheap devices? Vasi On Nov 13, 10:57 am, Rob Hamerling <[email protected]> wrote: > Hi guys, > > An update about MPLAB 860 > > About 2 weeks ago I wrote: > > > MPLAB 8.60 is available and I'm not particularly happy with it! > > For some unknown reason Microchip has changed many if not all > > descriptions of the oscillator (and some other) configuration bits > > in the .dev files. > > I've spent many hours to adapt the dev2jal script and related helper > files to the changes in MPLAB 8.60. In general I succeeded, but I'm > afraid I cannot get all device files 100% compatible with the previous. > Some fuse_def names have changed: for example for several PICs PLLEN is > now PLLDIV. For a few PICs I've checked with the datasheet and PLLDIV > seems to be in accordance with the datasheet. This means we should > accept this change (and other similar changes). But it means the many > Jallib samples (and probably user programs) don't compile anymore > without errors. The samples can be changed by us, but not the user > programs... > Any suggestions how to proceed (/ consolidate?)? > > There are some issues which make it almost impossible (or only with much > work) to find a solution. Microchip is at some places extremely and > stupidly inconsistent. For example in one .dev file (e.g. 16f876) 'WRT > enabled' means that writing of flash memory is allowed, while in another > .dev file (e.g. 16f876a) the same 'WRT enabled' means writing of flash > is NOT allowed! How am I supposed to know what is meant in a specific > case without reading the datasheet (which may be wrong as well)? VERY > ANNOYING! > > After this experience, the announcement of MPLAB X and after working > almost 3 years on device file generation) I'm beginning to think of > quitting. It's time for another challenge for me. > > Sorry for the negative news, nevertheless: have a nice weekend! > > 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.
