Is there some compelling reason you choose a PIC with such a small amount of flash when you are concerned with overrunning that bound?

For another buck fifty you can up the memory from 14KB to 128KB, same package; perifs you need check yourself.

I'll always start off a major project with a large memory. If desired I can cut back on this once my code is nearing the final wrap.

 

I will continue this project, which is quite involved, in C. However from what I've seen so far from the xc8 asm output I would not be surprised if I rewrite at least some of the slower elements in asm afterwards. I may even be forced to switch to full asm before the end The waste is truly shocking. My code is already taking 5% of the 16f886 program space and it doesn't do anything substantive yet.

It's not a bad idea to start in C, get it working, and convert to asm where necessary.

 

The reason I'm using 16F886 on this board is because I used the same on my last asm project and it was plenty powerful enough. The demands of this project are similar and so I thought it sensible to stick to something I was familiar with. I didn't expect transitioning to C to change the demands on program memory/instruction cycles significantly

 

how much time I wasted on such a simple bug.

It is a great feature actually.

When I use those LCDs, i typically don't initialize them so I can use the blocks to adjust contrast.

Once the contrast is set, you can then work on the code.

Here's the online solution: https://electrosome.com/lcd-pic-mplab-xc8/

I don't like that type of solutions in that it is not modular. In the end, you want to create a set of LCD routines that can be reused in your next project, be it a PIC or a AVR or a STM32....

Otherwise, there really is no reason to invest in a piece of code.

 

Agreed, had I known the behaviour beforehand I would have got the contrast right before doing anything else.

I'm only going to be using PICs for the medium term so lcd.h should be modular enough for me

 

Unless you are always working on really simple stuff orr pushing the performance envelope all the time, you will find that coding in a high level language like C iss the way to go.

Ok I think I'm totally sold on this. I spent Sunday coding and the rate of development was phenomenal. I'm spinning a wheel connected to a motor and from the back EMF the PIC is printing out mph, period and Vpk-pk on an LCD. Coding up C's sprintf in asm alone would be a few evening's work. Then for free I get 16bit int handling, float division, etc... Now that I've touched sprintf and float division once the required asm is already consuming program memory so I don't think the memory should increase at such a fast rate as I add in more and more business logic. I think I'll switch to PIC18F2620 which is pin-pin compatible with PIC16F886 but with 5* the program memory, 2* clock max, and an enhanced instruction set.