From: Bastiaan v. K. <bas...@gm...> - 2012-03-10 11:57:42
|
Hi, I recently started a project using the PIC18F1230, which, as i found out afterwards, isn't supported by SDCC. Since gputils does support it, i figured following the 'Adding new devices to the port' from the manual should get me there. However, i stopped at step 4 since i seem to be missing the 'pics.all' file. Before i continue with this; is the manual up-to-date here, is this the (best) way to get a new chip supported? Thanks, -Bastiaan |
From: Raphael N. <rn...@we...> - 2012-03-10 15:02:58
|
Hi Bastiaan, > Before i continue with this; is the manual up-to-date here, Not sure about this, I think the procedure may have changed somewhat in the meantime. > is this the (best) way to get a new chip supported? Adding a device yourself certainly is among the best ways to get a new chip supported -- unless the procedure does not work as described in the manual. The second best way is to drop a line to the sdcc-user (or sdcc-devel) mailing list and request addition of a new device ;-) (The best way would have been to file a feature request with the according sourceforge tracker, but we'll leave that for your next request.) I'll see if addition the device poses any problems and otherwise add it in the course of this weekend. Raphael |
From: Raphael N. <rn...@we...> - 2012-03-10 17:59:25
|
Hi again! > I recently started a project using the PIC18F1230, which, as i found > out afterwards, isn't supported by SDCC. This is to inform you that SDCC supports the 18f1230/18f1330 device family starting with svn r7422. I introduced another ADC/USART style for the I/O library (which becomes more and more unmaintainable), which is completely untested apart from "it compiles". Any feedback is encouraged. Happy coding. Raphael |
From: Alain P. <ala...@fr...> - 2012-03-10 22:39:10
Attachments:
signature.asc
|
Hi, Le samedi 10 mars 2012 18:59:17, Raphael Neider a écrit : > Hi again! > > > I recently started a project using the PIC18F1230, which, as i found > > out afterwards, isn't supported by SDCC. > > This is to inform you that SDCC supports the 18f1230/18f1330 device > family starting with svn r7422. > I introduced another ADC/USART style for the I/O library (which > becomes more and more unmaintainable), which is completely untested > apart from "it compiles". > Any feedback is encouraged. https://sourceforge.net/tracker/?func=detail&aid=3495815&group_id=599&atid=100599 Regards, Alain |
From: Raphael N. <rn...@we...> - 2012-03-11 00:01:19
|
Hi, >> Any feedback is encouraged. > > https://sourceforge.net/tracker/?func=detail&aid=3495815&group_id=599&atid=100599 "Ask, and you shall receive" ;-) Fixed in r7424. |
From: Bastiaan v. K. <bas...@gm...> - 2012-03-11 09:32:39
|
Hi, You're the best! Will test this over the next few days, and report back Regards, -Bastiaan On Sat, Mar 10, 2012 at 6:59 PM, Raphael Neider <rn...@we...> wrote: > Hi again! > >> I recently started a project using the PIC18F1230, which, as i found >> out afterwards, isn't supported by SDCC. > > This is to inform you that SDCC supports the 18f1230/18f1330 device > family starting with svn r7422. > I introduced another ADC/USART style for the I/O library (which > becomes more and more unmaintainable), which is completely untested > apart from "it compiles". > Any feedback is encouraged. > > Happy coding. > > 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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Bastiaan v. K. <bas...@gm...> - 2012-03-14 16:58:42
|
Hi, I'm running into a problem with my 18f1230 project (I keep this here instead of creating a new tracker item, or..?) Anyways, I have a rather basic project, uart with printf, ADC. For the hardware/peripheral interfacing i use my own functions. It compiles on a 18f1320 with the right MCU/register changes. When i compile this for the 18f1230 the linker bails out with the message: error: missing definition for symbol "_SSPBUF", required by "strmmssp.o" Which it's right about, this MCU doesn't have an SSP interface. But why is this linked in? When I override this by defining an empty strmmssp function, the linker stops at error: no target memory available for section "S_strmputchar____stream_putchar" Which sounds as if i'm out of flash. However, same code compiled for the 18f1320 results in something far smaller than the 4096bytes i should have here. Any pointers? Thanks, -Bastiaan On Sun, Mar 11, 2012 at 10:32 AM, Bastiaan van Kesteren <bas...@gm...> wrote: > Hi, > > You're the best! Will test this over the next few days, and report back > > Regards, > -Bastiaan > > On Sat, Mar 10, 2012 at 6:59 PM, Raphael Neider <rn...@we...> wrote: >> Hi again! >> >>> I recently started a project using the PIC18F1230, which, as i found >>> out afterwards, isn't supported by SDCC. >> >> This is to inform you that SDCC supports the 18f1230/18f1330 device >> family starting with svn r7422. >> I introduced another ADC/USART style for the I/O library (which >> becomes more and more unmaintainable), which is completely untested >> apart from "it compiles". >> Any feedback is encouraged. >> >> Happy coding. >> >> 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 >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Raphael N. <rn...@we...> - 2012-03-14 22:09:31
|
Hi, > When i compile this for the 18f1230 the linker bails out with the message: > > error: missing definition for symbol "_SSPBUF", required by "strmmssp.o" > > Which it's right about, this MCU doesn't have an SSP interface. But > why is this linked in? This is due to the libc18f putchar routine, which allows to target "streams" such as USART, MSSP, or a user-defined putchar() implementation via the FILE argument of the fprintf-routines (which are used to implement *printf()): The first-level putchar (__stream_putchar) has hard references to the mssp implementation in it :-(. > When I override this by defining an empty > strmmssp function, the linker stops at > > error: no target memory available for section "S_strmputchar____stream_putchar" > > Which sounds as if i'm out of flash. However, same code compiled for > the 18f1320 results in something far smaller than the 4096bytes i > should have here. > > Any pointers? I guess you are using printf/fprintf/vfprintf/sprintf, which eats up your code space? In case you are just using printf, try #define printf printf_tiny early in your sources and recompile with a stripped down (and much smaller) variant of printf. Make sure to eliminate EACH AND EVERY reference to printf -- otherwise you will just pull in even more code (printf_tiny) without getting rid of printf. If you are using other members of the printf-family, get rid of them. Unfortunately there are no _tiny replacements in the library, so you will need to come up with something of your own. If this does not help, please post the .o file which fails to link for the 18f1230. The relocation records in there (see 'gpvo output.o') might reveal which other large functions are being pulled in. You can also inspect the .hex file as generated for the 18f1320 and make sure the highest address used there does not exceed whatever is present on the 18f1230. For my demo project (little more than printf("foo")), the resulting .hex spanned just over 0x1100 (4,2 KiB) ... Raphael |
From: Bastiaan v. K. <bas...@gm...> - 2012-03-15 20:31:45
|
Hi Raphael, Thanks again. You are right about the printf size thing; disabling that makes the compilation work, so the rest is up to me :) Does make me wander; why does the "_SSPBUF" not come up on the 18f1320 (which doesn't have an SSP interface either)? And what's the best way to check the flash-usage of a resulting hex? I did a 'cat output.lst | grep "code size"' and summed the numbers, which for the 18f1320 with printf enabled resulted in something around 1800 bytes. If that where correct, it would have fitted in the 18f1230, so this method obviously isn't the right way to go.. Regards, -Bastiaan On Wed, Mar 14, 2012 at 11:09 PM, Raphael Neider <rn...@we...> wrote: > Hi, > >> When i compile this for the 18f1230 the linker bails out with the message: >> >> error: missing definition for symbol "_SSPBUF", required by "strmmssp.o" >> >> Which it's right about, this MCU doesn't have an SSP interface. But >> why is this linked in? > > This is due to the libc18f putchar routine, which allows to target > "streams" such as USART, MSSP, or a user-defined putchar() > implementation via the FILE argument of the fprintf-routines (which > are used to implement *printf()): The first-level putchar > (__stream_putchar) has hard references to the mssp implementation in > it :-(. > >> When I override this by defining an empty >> strmmssp function, the linker stops at >> >> error: no target memory available for section "S_strmputchar____stream_putchar" >> >> Which sounds as if i'm out of flash. However, same code compiled for >> the 18f1320 results in something far smaller than the 4096bytes i >> should have here. >> >> Any pointers? > > I guess you are using printf/fprintf/vfprintf/sprintf, which eats up > your code space? > > In case you are just using printf, try > #define printf printf_tiny > early in your sources and recompile with a stripped down (and much > smaller) variant of printf. > Make sure to eliminate EACH AND EVERY reference to printf -- otherwise > you will just pull in even more code (printf_tiny) without getting rid > of printf. > > If you are using other members of the printf-family, get rid of them. > Unfortunately there are no _tiny replacements in the library, so you > will need to come up with something of your own. > > If this does not help, please post the .o file which fails to link for > the 18f1230. The relocation records in there (see 'gpvo output.o') > might reveal which other large functions are being pulled in. You can > also inspect the .hex file as generated for the 18f1320 and make sure > the highest address used there does not exceed whatever is present on > the 18f1230. For my demo project (little more than printf("foo")), the > resulting .hex spanned just over 0x1100 (4,2 KiB) ... > > > 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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |