Error: Program is too large

[David Stephenson]

I'm getting this error "Error: Program is too large, cannot fit all subroutines into available
program memory".
It seems to happen when a subroputine exceeds 2047 word.
Now I'm using a 16F18326 which according to the datasheet has 16K words divided into 4 pages.
Which I would have thought gives a maximum subroutine size of 4096 words.
Am I mistaken?

CLOSURE NOTE (Anobium) : Not a compiler issue but an architectural constraint. See https://sourceforge.net/p/gcbasic/discussion/579126/thread/a4d2eda2/#fef7 for the closing commentry.

[stan cartwright]

I looked at 16f18326 data sheet and it says- 28 Kbytes Program Flash Memory.
http://ww1.microchip.com/downloads/en/DeviceDoc/40001839B.pdf

[David Stephenson]

Yes 28K bytes, but 16K (14-bit) words.

[stan cartwright]

Showing my ignorance, sorry. I let gcb sort all that out. Where do all the 2 bits go?
Not the place for an explanation :)

[Chris Roper]

As you asked:
General Format for Instructions

[David Stephenson]

They are 14bit to be able to address the 4k page size of the memory.
I'm begining to think this is a complier error as older 16F devices all have 2K code pages so the compiler should allow 4K subroutines for newer 16F devices.

[Anobium]

Please post the complete project, all your files, including your asm, lst, HTML and the h files used. As an attachment. I would be guessing at the reason without the information. 

[David Stephenson]

I've split the subroutine into two so one part is 1681 and the other is 714 words, and it's no problem. If I keep adding crap to the end of the 1681 word sub as soon as it's over 2047 I get the error.
Notice the compiler is avoiding putting more than 2047 words on page 1 (there are 2037 words).

[Anobium]

Please post the complete project, all your files, including your asm, lst, HTML and the h files used. As an attachment. I would be guessing at the reason without the information.

As a zip please .   I can then test against the latest   compiler and the rereference build.

[Anobium]

Please also revert the code to reproduce this issue. Post everything as a zip and as a working solution.

[David Stephenson]

The .h file is not produced (because of the error).

[Anobium]

Let me check this out.

[stan cartwright]

Is it relevant that changing to 328 gives no asm errors

;#chip 16F18326,4
;#config RSTOSC=hfint1, MCLRE=Off, WDTE=off, boren=off, FEXTOSC_OFF, CLKOUTEN_OFF, CP_OFF, WRT_OFF

'wait 10 ms
'unlockpps 'UNLOCK PPS
'    RC1PPS = 0x19            ' RC1<-MSSP1:SDA1(25)
'    SSP1CLKPPS = 0x10        ' RC0->MSSP1:SCL1(16)
'    SSP1DATPPS = 0x11        ' RC1->MSSP1:SDA1(17)
'    RC0PPS = 0x18            ' RC0->MSSP1:SCL1(24)
''t1ckipps=0x05
''ra4pps=0x04
'lockpps 'LOCK PPS
#chip mega328p, 16 ;%%%%%   ALL I DID   %%%%%

[Anobium]

No. Different architecture.

[stan cartwright]

#chip 18f25k22,64 gives no asm errors either

[Chris Roper]

To save even the time:
Different architecture again.

The AVR is obviously different but even within the supported PIC devices
there are different Architectures.

1) Baseline core devices (12-bit) - which are mainly PIC10 and PIC12
devices (With exceptions)
2) Mid-range core devices (14 bit), which is the majority of PIC16 Devices
3) Enhanced mid-range core devices (14 bit) which are the newer PIC16
Devices

and finally

4) PIC18 high end core devices (16 bit).

The limitation is possibly set with the mid-range core in mind, as that is
in the majority, but the new Enhanced mid-range core devices act almost
like the high end core devices.
The problem is that they vary by device so a blanket solution for PIC 16 is
almost impossible now and would need to be device specific.

Cheers
Chris

On 12 February 2018 at 22:33, stan cartwright stanleyella@users.sourceforge.net wrote:

chip 18f25k22,64 gives no asm errors either

---

Error: Program is too large
https://sourceforge.net/p/gcbasic/discussion/579126/thread/a4d2eda2/?limit=25#ada8

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gcbasic/discussion/579126/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Anobium]

@David. Please use your workaround. The compiler is not correctly issuing the correct error message. The root cause of the problem is the page handler with respect to the call SysMultSub32 where the argument is out of range. I have tested with 0.98.02 which is the latest build, I also examined your 0.98.01 generated ASM and found the same issue. Please use the workaround for a few days as this is not a quick fix.

This condition is limited to the 16f microcontrollers.

Feedback on your code - I would recommend using #option explict - you have a lot of undeclared variables.

Thank you for reporting the error - we need to fix this type of errors.

[David Stephenson]

You may have found one problem, but I think there is still the problem of the compiler using a page size of 2K. With the subroutine split the hex file that is produced has a gap at 0xF7 which is 247x8 = 1976 words and it resumes again at 0x0100 =2048 words.
I've looked through the help and I'm still not sure what #option explicit does. Anway I have assigned all variables except byte which the unassigned ones should be by default.

[Anobium]

We have looked and we may need your help.

So, it looks like the issue IS the size of the BMP280CALCT sub, which is taking up 2448 words and therefore will not fit onto any pages. And, the goto and call still have the 11 bits for the address, which would mean a page size of 2^11 or 2048. Where is it stated the page is greater that 2048 words. (Unless the datasheet is wrong, but 11 bits for the address is typical for those chips).

Re #option explicit. Just good practice for all code. Typos, Typos and Typos haunted me but not anymore.

[stan cartwright]

Thanks Chris. It must be 20 years since using asm on 16f628 and 40 pin version. Bank switching and tris was not fun then. That's was brill about basic. I didn't realise 18f was advanced other than used as picaxe x2 chips that have basic rotate comands and some extra math.
I have a microchip xpress eval board that uses a modern pic but only tried it once.

[Anobium]

Hence the reason fpr Great Cow BASIC - remove the complexity and making using microcontrolllers fun.

[mkstevo]

I have to say that #option explicit has saved me from swearing loudly at myself trying to track down peculiar failures in my code due to me having declared a variable initially as:

MkStevo_Swear_Count_For_Today       As Long  'Lots of swearing to count!
MkStevo_Swear_Count_For_Yesterday   As Long  'Lots of swearing yesterday too!

Then made an error later on:

If Swearing = 1 Then
  Let MkStevo_Swear_Count_For_Today = MkStevo_Swear_Count_For_Today + 1
  If MkStevo_Swaer_Count_For_Today > MkStevo_Swear_Count_For_Yesterday Then
      Print "Too much swearing. Calm down!"
  End If
End If

If I'd started my code with #option explicit, the incorrect spelling of the variable: MkStevo_Swaer_Count_For_Today would have been trapped by the compiler and I can correct it before I spend hours looking to see why I never got told to calm down.

Now I could get away with declaring MkStevo_Swear_Count_For_Today as a Byte value. Hmm... Perhaps a Word value would be safer.

[David Stephenson]

I'm now thinking it may be a mistake in the datasheet (memory organization section).
It seems to indicate there are 4 pages. On the other hand the PIC16F1788 also with 16K words has 8 pages. So i feel that the 16F18326 actuually has 8 pages of 2K words. So no option but to split the subroutine.

[Chris Roper]

It is an architecture limitation in the Enhanced Mid-Range devices to foster backwords compatability.
See Here: http://microchipdeveloper.com/8bit:emr-program-memory

in partuiculer this paragraph:

Executing a CALL or GOTO instruction
The CALL and GOTO instructions only have 11 bits available to specify the destination address. PCLATH is used to extend the operand to access all the program memory addresses. When either a CALL or GOTO is executed the 11-bit address from the operand is loaded into PC<10:0> and PCLATH<6:3> is loaded into PC<14:11>.

So 11 bit address = 2048 address range hence the 2K limit for subs.

Cheers
Chris

p.s. The graphic you posted is for accessing Flash as Data Memory which is totaly different to using it as Program Memory, so you may have been looking in the wrong section of the data sheet hence the confusion.

[Anobium]

@ChrisR. Great summary. The link clearly shows the usage.

@David. Case Closed. We will updated the compiler to show which mehtod (a sub or function) that cannot fit in the 2k page.

Summary:

It is an architecture limitation in the Enhanced Mid-Range devices to foster backwords compatability.
See Here: http://microchipdeveloper.com/8bit:emr-program-memory

2k page constraint:

Executing a CALL or GOTO instruction
The CALL and GOTO instructions only have 11 bits available to specify the destination address. PCLATH is used to extend the operand to access all the program memory addresses. When either a CALL or GOTO is executed the 11-bit address from the operand is loaded into PC<10:0> and PCLATH<6:3> is loaded into PC<14:11>.

So, an 11 bit address = 2048 address range hence the 2K limit for methods.