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