On 30 Oct 2018 at 8:32, David Duffy (AVD) wrote:

> I need to take a couple of steps back and see what's going on.
> Following=20
> the advisory about the 32-bit floating point changes, there are "no
> room=20
> for xxx" errors.

I cringe every time I see that "no room" message.
=20
> The original code given to me did compile, but had little room left
> over=20
> for both data and program space.=A0 Over the last couple of months I
> had=20
> made small changes and it has always compiled.

I have an old 16F877A project constantly nudging the flash size limt. I'm c=
onstanlty=20
using #define around sections of working code to drop them out so I can mak=
e=20
additions/changes, then optimise/tweak till everything fits again. I actual=
ly have a=20
fortuitously placed line in my source code which reads // asm("  NOP"); and=
=20
strangely it can sometimes make the code fit by adding it. (When really gra=
sping for=20
the last few handfuls of program words I imagine it makes a difference what=
 blocks=20
get located where and how the unused space does or doesn't come together,=20
considering page boundaries and everything).

> I was only when I moved to mplabx 5.05 and xc8 2.00 that things
> turned=20
> weird.=A0 I've now installed mplabx 4.15 and xc8 1.45 but the code
> that=20
> used to compile now doesn't so something else is going on.

Hope you find that something else. MPLAB version I wouldn't expect to affec=
t code=20
size, but I guess plug-ins like MCC could, and compliler version would for =
sure.=20

Where possible I sometimes tell the compiler I'm using a larger chip and se=
e if it=20
can compile to get a feel for how much over size it is. Good luck~!


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.