Vaclav, can you please add a feature request to both sdcc and gputils fearture request trackers?
Borut On 21. 02. 2012 21:31, Raphael Neider wrote: > Dear Vaclav, > >> For one project I started to use PIC16F721. I haven't noticed that it is >> still not yet supported. > The PI16F72[01] parts are not yet supported in gputils, which is where > SDCC / I obtain my information for the device headers and libraries > (SFR names and addresses). So the first will be to get support into > gputils (maybe Borut can help here?) and then bug me or more > preferable this list or even better a feature request tracker again > for support in sdcc. > >> How hard will be to get it supported ? > > From my first glance at the datasheet, the device seems to be a > regular (i.e., non-enhanced) 14-bit core. If that is the case, > supporting it should be easy: include the device specification in > devices/include/pic14/pic14devices.txt, add it to > devices/non-free/lib/pic14/devices.txt, generate the pic16f720.c and > .h files (from gputils header/p16f720.inc -- once it is there), > recompile sdcc (at least the pic14 libraries) and you are done :-) > If the 16f72[01]'s instruction set differs from the regular and > enhanced devices, supporting them can easily take more time (weeks, > even months). > >> I can help with testing, my application is not complicated, just USART, LEDs >> and LCD 2x16. But time is going fast... I could write it in ASM, but SDCC >> would be better. > In the meantime, you can always build your project for a reasonably > similar part (similar with respect to instruction set -- so far there > are regular and enhanced pic14 devices out there). > If you include the other part's pic16f<?>.c and pic16f<?>.h in your > project, you can even change the addresses of most SFRs (those that > are not accessed in precompiled libraries) to match those of the > 16f72[01]. > Compile for the device, obtain the .hex and flash it into the device > -- IIRC the .hex file is processor-agnostic so that should work (the > .o/.lib files have part codes encoded within them, preventing sdcc > from building the library once for all "reasonably similar" parts). > > Be careful, though, with the config bits: getting them wrong might > easily break something and in ... interesting ways. > > > Hope that helps > > Raphael > ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
