From: Eric <jonas@MIT.EDU> - 2005-01-10 06:50:52
|
Hello! I'm starting an embedded project over the next few days that needs to be finished by the end of the month, and I'm looking for a gpl'd C compiler to use; I'm planning on using either the PIC14 or PIC16 (all I really care about is ease of in-circuit prorammability at the moment, and the PIC18F series looks easy enough, given the proliferation of hardware programmer schematics available). I can't find, however, a good summary of the PIC14 and PIC16 support by SDCC; has anyone actually used these ports for pic development, and perhapse could offer some tips on getting started (and what things I should watch out for?) Thanks! ...Eric |
From: George M. G. <gga...@co...> - 2005-01-11 13:44:22
|
Eric, I am using the PIC16 port with 18F252 chips. I use a simple multi-tasking that handles the device initialization and I/O. The only drawback to using SDCC is it does not produce reentrant code which limits me to one "C" task (plan to remove this restriction soon). Code optimization is very good. Data access suffers from PIC limitations, lots of bank selects. The developers are very responsive to user problem reports. Given the current state of SDCC I use it for personal projects such as robots and home automation and definitely not use it for industrial or medical products. George Eric wrote: >Hello! I'm starting an embedded project over the next few days that >needs to be finished by the end of the month, and I'm looking for a >gpl'd C compiler to use; I'm planning on using either the PIC14 or PIC16 >(all I really care about is ease of in-circuit prorammability at the >moment, and the PIC18F series looks easy enough, given the proliferation >of hardware programmer schematics available). > >I can't find, however, a good summary of the PIC14 and PIC16 support by >SDCC; has anyone actually used these ports for pic development, and >perhapse could offer some tips on getting started (and what things I >should watch out for?) > >Thanks! > ...Eric > > >------------------------------------------------------- >The SF.Net email is sponsored by: Beat the post-holiday blues >Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > |
From: Vangelis R. <vr...@ot...> - 2005-01-12 17:57:34
|
----- Original Message -----=20 From: "George M. Gallant" <gga...@co...> To: <sdc...@li...> Subject: Re: [Sdcc-user] Status of PIC16 port > I am using the PIC16 port with 18F252 chips. I use a simple=20 > multi-tasking that handles the device initialization and I/O. > The only drawback to using SDCC is it does not produce > reentrant code which limits me to one "C" task (plan to > remove this restriction soon). I guess that SDCC isn't preserving registers your OS requires in order to be reentrant right? As far as I can remember I always tried to create reentrant code throughout the port. > Code optimization is very good. > Data access suffers from PIC limitations, lots of bank selects. There is a primitive bank select elimination support when accessing the same variable in sequence. I have one question concerning the OS you are using. I guess you've written a set of OS functions that you use from within your tasks. When you have to update the working task, do you update OS functions too? Wouldn't it be nice to burn OS specific code once, and just update the user tasks every time you need it? (Similar to how a bootloader works) I was thinking of such a feature that could be introduced but needs gplink modification. I see it like DLLs (dynamic link libraries). Gplink would create an import .cod file which will only contain symbol relocation data (no executable code, nor RAM/EEPROM data). This import file will be used later to correctly identify all external symbols (the OS functions), but no executable code will be inserted in the final output. So, once you burn the user task in PIC, gplink's relocated OS symbols will point to the correct addresses, thus eliminating the need for = frequent OS updating. How does this seems to you? regards, Vangelis |
From: George M. G. <gga...@co...> - 2005-01-13 03:25:43
|
Vangelis, The scheduler is preemptive. SDCC copies data to/from the users stack to the overlay memory. Saving and restoring this would be both time and memory wastefully. I can switch to an event driven scheme where each task runs to completion and let the interrupt service routines do more work. Your comment on OS functions is right on the mark. I build common functions such as math and I/O into the lower PIC flash address space. Then I only burn the tasks into the upper. Code for reading tachs, PID, and motor drivers for a small robot can be flashed in seconds. Other linkers allow the importation of symbols from another build so that the application can use the symbols. The best I have been able to do is link the entire OS and Application and then hack the resulting hex file to strip the OS. I suspect it could also be done by the flash burn utility by specifying a start of burn address. I have zero expectations that gplink will support anything that is not first put forth by MicroChip. The other SDCC ports are fortunate to have their own assemblers and linkers. In my opinion, the major hole in PIC16 SDCC today is lack of users. Only by having a large and varied user base will the product be stressed and the kinks ironed out. Regards, George Vangelis Rokas wrote: >----- Original Message ----- >From: "George M. Gallant" <gga...@co...> >To: <sdc...@li...> >Subject: Re: [Sdcc-user] Status of PIC16 port > > > > >>I am using the PIC16 port with 18F252 chips. I use a simple >>multi-tasking that handles the device initialization and I/O. >>The only drawback to using SDCC is it does not produce >>reentrant code which limits me to one "C" task (plan to >>remove this restriction soon). >> >> > >I guess that SDCC isn't preserving registers your OS requires >in order to be reentrant right? As far as I can remember I always >tried to create reentrant code throughout the port. > > > >>Code optimization is very good. >>Data access suffers from PIC limitations, lots of bank selects. >> >> > >There is a primitive bank select elimination support when accessing >the same variable in sequence. > > >I have one question concerning the OS you are using. >I guess you've written a set of OS functions that you use >from within your tasks. When you have to update the working >task, do you update OS functions too? >Wouldn't it be nice to burn OS specific code once, and just update >the user tasks every time you need it? (Similar to how a bootloader >works) > >I was thinking of such a feature that could be introduced but needs >gplink modification. I see it like DLLs (dynamic link libraries). >Gplink would create an import .cod file which will only contain >symbol relocation data (no executable code, nor RAM/EEPROM data). > >This import file will be used later to correctly identify all external >symbols (the OS functions), but no executable code will be inserted >in the final output. > >So, once you burn the user task in PIC, gplink's relocated OS symbols >will point to the correct addresses, thus eliminating the need for frequent >OS updating. > >How does this seems to you? > >regards, >Vangelis > > > > >------------------------------------------------------- >The SF.Net email is sponsored by: Beat the post-holiday blues >Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > |