Dear Borut,
> all enhanced 14 bit devices should be now supported by gputils svn head
> (thanks to Gál Zsolt).
Fantastic, great job! I guess now it's up to me to add proper device
libraries :-D
*hack hack hack*
Device libraries for 12f1840, 16f1507, 16f182{3,4,5,8,9} and
16f193{8,9} are in place in my local tree.
>From the devices contributed by Gál to pic14devices.txt, the 12f1847
and 16f190{2,3,4,6,7} devices are still not present in gputils and
thus have no device libraries in sdcc. As these devices are also not
listed on the Microchip website, I guess these are actually meant to
be 1{2 => 6}F1847 and 16{F => LF}190*. I shall try to verify this and
include those instead (not done yet).
While creating the device libraries, I augmented inc2h.pl to avoid
spitting out duplicate #defines for bit names that are present in
multiple registers or aliased registers. While at it, I also
incorporated Gál Zsolt's suggestion to drop the underscore from the
structured access facilities (PORTA_bits is now PORTAbits).
So, well, now I have a number of options:
1. I can check in only the new files using the old naming scheme
(underscore) for consistency.
2. I can check in the new files using the old naming scheme plus
updated versions of existing header files that have seen changes in
the latest gputils' templates/sources. Some bit names and config flags
have been dropped or renamed, so even this update might break user
code.
3. I can check in the new files using the new naming scheme together
with updated versions of all other device headers to reflect the new
naming scheme (basically a complete rewrite) and the changes made to
gputils' templates/sources from which they are generated. Due to the
changed naming convention, this will most likely break a lot of code
out there (if there is a lot of code out there, that is), but will (a)
simplify further maintenance (no manual modifications on generated
files for now), and (b) bring our headers closer to what the HiTech
compiler is using (as pointed out by Gál). At least in the long run, I
think I want to get here.
... and no, I do not really want to maintain XXX_bits next to XXXbits or use
#ifdef LEGACY_NAMING
#define _BITSUFFIX _bits
#else
#define _BITSUFFIX bits
#endif
/* ... */XXX ## _BITSUFFIX
throughout the library ;-)
Unless otherwise decided, I will commit the new device headers using
the old naming scheme (alternative 1) later this evening.
> I also fixed a nasty bug which made the gputils
> 0.14.0 unusable :-(.
How so? At least all the sdcc/pic14 and pic16 device libraries
compiled, assembled and linked without complaints (not sure about
their actual content, though)?
> I'm still waiting for reports from Gál and Robert
> Pearce about the stability. If everything is OK, I'll probably made an
> other gputils release (0.14.1) before the sdcc 3.1.0 release.
I have added the new device libraries to the list of new pics (to be
enabled at sdcc configure time via configure --enable-new-pics) so
that users with 0.13.* can still build sdcc from scratch. Only users
of the new, enhanced devices will thus have to upgrade their gputils
to >= r631.
To cut a long story short, a new gputils release is certainly welcome
to make them usable again, but sdcc need not be held back should
problems or lack of time show up.
Raphael
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
