Hi,

> I realised some useful scripts deep in the sdcc tree in the last days
> ( and this mailing-list also ). That is why I can try how is it
> working my 16F1938 device with sdcc.

Great!

> 5.) Here is the most important for me. I modified
> /sdcc/device/non-free/lib/pic14/libdev/mkall.sh file becasuse of:
>  a.) - my svn directory is other than it was in the file
>  b.) - the script want to save the pic_____.h files into the
> /sdcc/device/include/pic14 directory instead of the
> /sdcc/device/non-free/include/pic14/ directory.

The mkall.sh was primarily intended for my own convenience and is thus
pretty specific. I'm glad you could make it work for you.

> 6.) I have to add - #define NO_BIT_DEFINES - lines to the pic16f____.c
> files in the /sdcc/device/non-free/lib/pic14/libdev directory because
> some bit defines are twice in the file. ( I think I had to remove
> additional defines from the file manually. )

This problem has now surfaced for multiple devices, usually due to the
introduction of alternative names for various SFRs: the script
currently does not track which bit-names have already been #defined
and emits #defines for the same bit in each of the resulting structs.
I could try to improve, basically deferring the output of the #defines
to the end of the script and making sure that each symbol is defined
at most once. Since the current approach fails loudly and requires
only a one-time fixup of the generated header, fixing the inc2h-script
has low priority for me. Contributions are welcome ;-)

> The library are compiled for 16F877 in this situation. I did
> modification on the next two file to compiling libraries for 16f1938:
> /sdcc/device/non-free/lib/pic14/Makefile.common.in
> and
> /sdcc/device/lib/pic14/Makefile.common.in
> I should change the ARCH variable from 877 to 1938
>
> My question is that are there any simplier way to do this?

No, currently there is no easy way. I am planning to create a second
library (libsdcce) for the enhanced cores, at least including proper
routines for generic pointer access and probably a fixed
_sdcc_gsinit_startup() routine.
One could introduce a configure switch to select the device used for
library creation, but since that does not quite suffice (some
hand-crafted assembly code needs to be modified), I doubt that would
do much good.

> Are there
> any parameter for the make process which forces the compiler to
> re-compiling the library files? I do it manualy by go into the
> /sdcc/device/non-free/lib/pic14 and /sdcc/device/lib/pic14 directories
> and started - make clean - and than in the /sdcc directory - make -.

That seems to be the proper way to do it. I am not aware of a simpler way.

> Did I something wrong with mkall.sh script because the generated .h
> files gives error messages without the NO_BIT_DEFINES option?

As said earlier, inc2h is too stupid to deal with duplicate bit-names.
Nothing wrong on your side.

Thank you (and the other users!) for reporting your efforts, results
and problems: It's always good to know that somebody is interested.

Kind regards
Raphael

------------------------------------------------------------------------------
RSA® 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

Reply via email to