Hi Rob, 2010/11/13 Rob Hamerling <[email protected]>
> > 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?)? > If possible, a deprecated message would help, but I don't know if it's possible... Jallib device files are somewhat tied to Microchip's dev files, even with all the normalization you've done (greatly). So I'd say you can't avoid this kind of things. Some brief documentation could explain how to migrate existing code. Do you have some sort of metrics ? How many PICs have changed regarding PLLEN/PLLDIV ? How many PIC's families ? Are these PICs known to be widely used ? In general, if you think it could help, at each MPLAB release, you could check dev files to have a good overview of what's changed, which PICs have been added, etc... (and I understand this is what you do). If you wonder if it's worth using this new release, we could then decide together according to your feedback and metrics. I know you want to provide device files for *every* PIC but it is sometimes also good to ignore a release because, admittedly there are improvements, still current device files are *good enough* (this is not pejorative :)) and these improvements don't worth the work involved to integrate them, and the noise they produce. That could be a naive point of view though... Another point would be to allow, somehow in the code, to plug user code defining his own device file, maybe based on an existing one. This way, if for any reason his PIC isn't supported in current release, he has the opportunity fill in missing code. And maybe report. > > 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! > So I understand this wasn't the case before, that is, in our current device files. Correct me if I'm wrong but both datasheets say the same thing: WTR = 1 means we can write. This may be an error from Microchip. Which may be fixed in next release, so the work you would have done here would be lost... This would typically contribute to a very bad metric: PICs widely used, potential error ? > 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. > This will be a huge loss for jallib but I understand you point of view. As Joep suggested, what about waiting for MPLAB X ? And is MPLAB X that ugly ? I mean, did you finally find device files and how did they look like ? Keep us informed with your new challenges anyway ! :) Cheers, Seb -- 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.
