I am really grateful for all your assistance but please....in most of your answers i feel that you criticize me for using 16F and asm. Guys, I will move up with C in future, but now I am in the middle of a project that I am trying to finish.
Please share your knowledge but dont tell me to stop everything and upgrade my μC.
No offence Takao, I know you want to help me but i need to go all the way with 16f628A or 16f648A.

 

I am really grateful for all your assistance but please....in most of your answers i feel that you criticize me for using 16F and asm. Guys, I will move up with C in future, but now I am in the middle of a project that I am trying to finish.
Please share your knowledge but dont tell me to stop everything and upgrade my μC.
No offence Takao, I know you want to help me but i need to go all the way with 16f628A or 16f648A.

Hmm. I must apologize for that. Go through the project in assembler, yes. It is possible. It depends how many topics you maintain, and how many sub menus.

 

Problem solved.
My approach was to use a second table having more info such as state machine, eeprom addr, bytes to read etc, for every menu/submenu that was executing some code on "enter". I extended my state machine routine and everything worked flawesly!
I am very glad I've reached this point.
Now I need a nice idea about how to set the cursor moving area.:
eg.
line 1 ,col 4
line 1 ,col 8
line 1 ,col 16
etc.
So for the above example, if the cursor is on column 4 and moves on the right, it should go on column 8 and then on column 16.
I was thinking of using 2 bytes to store the allowed position on the lcd. each bit "1" would mean that the cursor is allowed to be placed there and a bit "0" whould be the opposite. So b'00010001' and b'00000001' would mean that the cursor can move only on column 4,8 and 16.
Any other approaches?

 

That sounds workable but it's very dependent on exactly how you code for each table.

I tend to erase (draw blank spaces) over my entire "cursor" area then just draw the cursor at the new updated position. I've essentially got the possible positions hard coded in the mix.

(Note I make no comments about doing this in assembly, just an overall scheme.)

 

The post is now old but I'd like to say that my project is now finished. It took a little longer than I expected but I was learning new stuff all the time. I moved to 16f648a and occupied 3.5k of memory (the board uses i2c with ds1307, LCD hd44780 and four buttons ). Several additions were made which did not exist in initial plan, such as the i2c for using ds1307 instead of 1302. The menu is 70 items deep. Works perfectly.
Now some conclusions...
My project would be easier if I had a push and pop! I know you will say "I've told you about 18F" but any way, this was the first time I made such a big application.
Paging...an other pain in the ass! I worked the issue out pretty neat and learned really a lot about how the linker works. I'd say it worthed the trouble using the 16F since I gained so much extra knowledge and I've made pretty cool libs for my future projects... but in future, I'll consider a 18F or maybe the enhanced 16F for project above 2k with large data tables.
Finally...the ASM issue. Well, I suspect that if I had tried to make this project in C, it wouldn't even fit in the Pic. Things were pretty clear with asm. When ever a bug arised, I debuged it and worked it out. I don't think that debugging would be that is easy if I had use C, as I would have to understand all the weird asm instructions that the complier would use. I admit, that i made a small C application and analysed the asm code to see how the compiler would manage data tables but I also admit that when I made the same code in asm, my code was almost 40% less in size. Optimizing seems to be a great issue in C.
Thank you all for your help.

 

It's great to read about how things worked out.
I used assembler myself for a number of years.
However, larger projects sometimes turned into an unmanageable state.
I still have one project actually containing LCD menu's, I2C, and EEPROM access.
About 20 individual assembler files.
It is not impossible to maintain, but it is painful mainly because of the banking issues.

Actually if you use C, you can increase complexity of code a lot.
You can access individual bitfields with a much smaller number of code lines.
In C, let say 3 or 5 lines, in assembler almost a screen page.

And then you can pack information into tables. If you don't need full 8bits, you can use individual bits. I have done that in C.
And I wrote C code that is so complex that myself, I am not able to code it reasonably in assembler.

There is some overhead for data tables (aka strings or char arrays).
For direct access the compiler will create a table with individual 8-bit entries (for each small string).
If you create an array of pointers, the compiler will create a table with 2 8bit entries each.
For my projects, this turns out to be less than 100 words in total. Neglible if you compare it to 2K.

And yes pointer dereferencing is somehow costly using embedded C. You need about 25 words each time. Sometimes you can combine access, or reuse already computed pointers. As a result, 18F chips have 8K or 16K memory at least.

If you want to reuse code that includes banking on a different chip, you will run into trouble. In C, you don't really need to deal with the banking.

 

The main thing I faced with data tables is that I used up space so quickly. I'll explain...
I was sending chars in LCD that could range from 1-127 bits. Thus theoritically, I could store 2 chars per memory word (14bit). This would work only if had direct access in flash memory. Since I didn't, i used RETLW (dt) to return every byte and occupied 2 bytes of mem. In the enchanced 16f, i would store 2 chars per memory word (using db instead of dt) and I would read the flash memory directly. Thus, the space needed for the text would be half in size in the enchanced 16F or 18F than in the mid range 16F.
Paging issue becomes a real ISSUE if you dont use linker script files. If you do, then I believe that you can recompile the code for a different chip without a lot of effort. The linker will do the job as long as the programmer (human) has done his job properly.

 

I wrote helper code that moved the data from program FLASH into an external EEPROM. This was done in several "chunks". Each time I had recompile as well. After that I also need additional code to read from the EEPROM (particulary the LCD menu parser).

My experience after dealing with PICs for a number of years is that for one-off circuits, or small batches, it does not make sense to try to use a smaller PIC (in order to save money). The total funds I spent on equipment and components are in the 1000s of $ range.

It can make sense for mass production however. If you produce 1000 PCBs, and can save 50 cent, you save $500. Also consider the hourly rate for professional programmers. It might not be worth it to deal with it for several days.

Same for larger volumes of data for instance bitmaps for LCD. In order to make developement easier, maybe simply use a .BMP memory dump, and write it to a serial FLASH chip. If you mass produce a gadget, it makes sense to consider .JPG, including to purchase code for that from 3rd parties.

What I mean is that modern technology is so complex, you really would have a hard time implementing it in assembler. Ready-made libraries often already exist, and almost all of them are written in C language.
Actually this was forcing me to start using C- when I wanted to use the Microchip USB stack. After that, I never really used assembler again.