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 <rnei...@web.de> 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
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
