Big program size absurdity

[jhanus]

Hello,

let me get directly to the point, I'm developing a project in assembler.

But I got to a wall, the problem is that I got carried away a bit, and my program size exponentially increased.
So after researching I assumed the problem is when I use 'call' trough more then 255 instructions, because while testing in Proteus it gave me underflow and overflow errors.

To eliminate this problem I disabled some functions and it worked.
After more reading I found potential solution trough division of code to pages and using PCLATH.

Then, while cruising trough datasheet of PIC 16F628a I saw 2048word limit for program(I never got a problem with program size before!) and my HEX file has 2,57 KB (2.637 bytes)...

After that I realized that my previous hex file for 16f84a had 1,97 KB (2.019 bytes) and it worked fine.(16f84a has 1024words)

So, my question is how is this possible?!

 

[Nigel Goodwin]

The HEX file is a number of times larger than the machine code it holds, because it's an ASCII file, and it also contains address and checksum data - don't bother looking at the size of it!. The actual size is reported in the output of the assembler.

The 2K of memory in a 628 is all a single page, so there's no paging problems - except for tables, as they can't cross a 256 byte boundary, unless you take precautions.

 

[picasm]

The size of the hex file is not an indication of the amount of program memory used.
To find this information accurately, open the .lst file produced by the assembler,scroll to the end where is shows the program memory words used and free.
Your other problems with call instructions may to be due to the limitation of the stack being only 8 levels deep, perhaps you are calling too many subroutines from withing subroutines or not always returning to the calling routines.
Alsu, the PCLATH is not normally needed for calls or gotos within 2048 bytes of program as it all fits within the first code page. But if you use "computed goto" tables using the PCL register then it is essential to have PCLATH set correctly or the program will jump to the wrong place.
It is explained in a piclist article here:

 

[jhanus]

OMG, Nigel Goodwin, picasm, thank you very much, I barely use quarter of memory.

I will read trough offered link, because this extremely narrows my possible problems.
Yes I use "computed goto" tables with PCL register, I didn't control PCLATH and this is probably my error.

If I'll have any problems I will post again, thanks!

 

[Nigel Goodwin]

OMG, Nigel Goodwin, picasm, thank you very much, I barely use quarter of memory.

I will read trough offered link, because this extremely narrows my possible problems.
Yes I use "computed goto" tables with PCL register, I didn't control PCLATH and this is probably my error.

Yes, if you use computed goto tables, you MUST set PCLATH accordingly.

 

[jhanus]

I'm back, my project is working, at least in simulator.

But I'm not happy because I fixed the problem, but I don't completely understand how I did it.

What I did is that I put on several places where I use //addwf PCL,f// org(origin) and address, then when I need my computed table I set that address in PCLATH and called it.

My questions are:
1. If I use 16f628a (2048w x14) maximum for PCLATH is 0x07ff, correct?
2. How do I know which address is in some random point in my program?
3. If I write somewhere //org 0x0100 and some code//, but I automatically already filled that memory before what happens?
4. If I put in PCLATH 0x06 and go somewhere(with call) and return, do I need to change PCLATH back how it was before?

I understood that PCLATH is for putting upper part of some address while PCL for lower, am I right or?

Thank you.

 

[Nigel Goodwin]

Either stick your tables in some specific page of memory, and access them accordingly, or set PCLATH in the program itself depending where it is.

If you check my LED matrix tutorial, that uses big tables that cross a number of 256 byte boundaries, and the program sets itself automatically.

How big are your tables?, if they are small an easy solution is to stick them in page zero where they can't move - and that is what my other tutorials all do.

 

[jhanus]

Either stick your tables in some specific page of memory, and access them accordingly, or set PCLATH in the program itself depending where it is.

If you check my LED matrix tutorial, that uses big tables that cross a number of 256 byte boundaries, and the program sets itself automatically.

How big are your tables?, if they are small an easy solution is to stick them in page zero where they can't move - and that is what my other tutorials all do.

I'm going to read your LED matrix tutorial, but can you please answer my questions, because it will tell me much.

What is small table, <256 address(how do I know which address it consumes)?
Is page zero 0x0000 => 0x00ff

My code looks really ugly with all org and PCLATH instructions, can I automatize it somehow? (I will look in your tut if you meant that)

Thanks.

 

[Nigel Goodwin]

I'm going to read your LED matrix tutorial, but can you please answer my questions, because it will tell me much.

What is small table, <256 address(how do I know which address it consumes)?
Is page zero 0x0000 => 0x00ff

Yes, small enough to fit in a single 256 byte page.

My code looks really ugly with all org and PCLATH instructions, can I automatize it somehow? (I will look in your tut if you meant that)

As no one sees your source, and it's supposed to be like that, why worry? - man, it's so horrible, all those MOVLW instruction look so untidy!

An ORG or PCLATH is just as essential as a MOVLW, it's normal.

 

[jhanus]

As no one sees your source, and it's supposed to be like that, why worry? - man, it's so horrible, all those MOVLW instruction look so untidy!

An ORG or PCLATH is just as essential as a MOVLW, it's normal.

But I want it nice and tidy, when after a month I look at a code and say, 'aha this is what I did' and not 'what is this?!'.

I will get back as soon as I read you tutorial, because this is really bugging me.

 

[futz]

But I want it nice and tidy, when after a month I look at a code and say, 'aha this is what I did' and not 'what is this?!'.

That's what comments are for. Document your code with liberal comments that explain what's going on. Yes, they are "messy" and cluttery, but 6 months from now they are what is going to tell you "what on earth was I thinking?!?".

 

[jhanus]

That's what comments are for. Document your code with liberal comments that explain what's going on. Yes, they are "messy" and cluttery, but 6 months from now they are what is going to tell you "what on earth was I thinking?!?".

Yes, but comments combined with tidy code are much more understandable then comments with messy code.

When I see a block of program, I'm trying to make it understandable even without additional comments, while comments should be pointers for easier understanding.

 

[futz]

When I see a block of program, I'm trying to make it understandable even without additional comments, while comments should be pointers for easier understanding.

You could switch to an 18F series PIC. No bank switching required. Tables done in a sensible way instead of hacked with retlw's. They have some new opcodes that cut down the number of commands you have to type to do common things. They're really nice to write code for.

 

[jhanus]

You could switch to an 18F series PIC. No bank switching required. Tables done in a sensible way instead of hacked with retlw's. They have some new opcodes that cut down the number of commands you have to type to do common things. They're really nice to write code for.

Yes, definitely I will go to 18F series and to c programming, but I don't think that I'm ready until I know every register and function of at least 16f628.

 

[futz]

Yes, definitely I will go to 18F series and to c programming, but I don't think that I'm ready until I know every register and function of at least 16f628.

Don't let that stop you. All the PICs (like any MCU product line) are very very similar. Once you learn one, you've got a pretty good handle on all of em. Of course there are differences like more or fewer peripherals and memory, but they're very standardized.

And you don't have to use C on 18F's unless you want to. The "nice to program" comment was regarding asm programming on 18F's. C won't be much, if any, different on an 18F from C on any other PIC. Their being well suited to C is about the chip design, not the human doing the programming.

 

[Nigel Goodwin]

Yes, definitely I will go to 18F series and to c programming, but I don't think that I'm ready until I know every register and function of at least 16f628.

Yes, that's the method I always advise, learn assembler first, then move to a high level language, your assembler knowledge wil make you a MUCH better C programmer.

I always advise starting on the 16F first as well, then moving to the 18F, again the specific hardware limitations of the 16F get you used to the 'MicroChip way'

 

[jhanus]

Yes, that's the method I always advise, learn assembler first, then move to a high level language, your assembler knowledge wil make you a MUCH better C programmer.

I always advise starting on the 16F first as well, then moving to the 18F, again the specific hardware limitations of the 16F get you used to the 'MicroChip way'

Thank you for help, I manged to solve my problem, but more importantly I learned something new and very helpful. (Thanks to Nigel Goodwins tutorials)

But some things are still bugging me:


How do I know on which address is some random instruction in my program? (where do I look)

If I put in PCLATH some address (then do call and return), do I need to change PCLATH back how it was before(because it's not setting itself automatically, but it works even if I don't set back PCLATH to previous condition in)?



Thanks.

 

[atferrari]

What is "random" in that context? Are you sure is it the right expression?

 

[futz]

How do I know on which address is some random instruction in my program? (where do I look)

You can find out where the assembler has assembled it by looking at the .lst (list) file.

 

[jhanus]

You can find out where the assembler has assembled it by looking at the .lst (list) file.

Exactly what I was looking for, thanks.

Is there a possibility to watch it in MPLAB 'directly' after it was assembled(like line numbers, but in this case addresses).