Hi, >> Basically I'd like to verify that the pearl scripts used to generate >> support for PIC16 MCU's will work with the new* >> PIC16F1939<http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en538148>before >> >> I order 5 or 10 of them.
After skimming through the instruction set of the 16f1939 I think that the 16f1939 should be supportable: Its instruction set is extended compared to, say, the 16f87, but the instructions that existed for the 16f87 still exist and work unmodified. As with the pic16 backend, the enhanced instructions will simply not be issued by SDCC, which results in less than perfect but working code. (If the assembler supports the instructions, you can include hand-written assembler using those instructions.) I (or someone else) would have to look at what the inc2h-script generates from gputils' pic16f1936.inc, or one could just copy a sufficiently similar device header/library and add the missing bits and pieces manually on demand, compile the source for that sufficiently similar device (sdcc -mpic14 -p16fSIMILAR), and ignore/override any processor mismatch warnings/errors during programming. > I was investigating the use of SDCC for the PIC16F1936. Problem is that > SDCC only appears to support two instruction sets, pic14 and pic16. > pic14 refers to the 14 bit opcodes used in the PIC16 series and pic16 to > the PIC18 series. I could not see any support for the enhanced 14 bit > instruction set used in the PIC16F1936 which is different to the > standard instruction set in many ways. I searched for the extra > instructions in the source files and did not find them. Could you shed some light on what you mean by "different"? Have any semantics actually changed? As with the pic18xxxx extended instruction set, the extensions are more C compiler friendly (if it was not already designed to work without them ...) via "stack access" instructions, a proper set of shift/rotate instructions etc., but opposed to the pic18xxxx, where enabling XINST changed the addressing modes of the basic instruction set, the core instruction set of the pic16xxxx stays intact, right? > I did consider adding the support myself but soon realised that I have no > idea how a C compiler works. I have also had a brief look into adding support for the extended instructions several months age (for the pic18xxxx backend), but decided that it was too much work, as making proper use of them would require significant changes to calling conventions/function prologue/epilogue/allocation of temporaries/... and would duplicate a lot of code to also support the basic devices. I fear that the situation is similar with the pic14 backend. Kind regards Raphael -- Karlsruher Institut für Technologie (KIT) Institut für Betriebs- und Dialogsysteme Raphael Neider Akademischer Mitarbeiter Am Fasanengarten 5, Geb. 50.34, Raum 161 76131 Karlsruhe Telefon: +49 721 608-2645 Telefax: +49 721 608-7664 E-Mail: nei...@kit.edu Internet: http://i30www.ira.uka.de/ KIT - Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
