Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

16F628 - How many lines of assembly code...

Status
Not open for further replies.

Jon Wilder

Active Member
...would it take to exceed the program EEPROM space?

While I have picked up PIC programming pretty quickly I'm still learning about this particular chip so I have a couple of beginner questions -

Speaking of memory, in order to address all of the general purpose RAM locations, would bank switching be required to access RAM locations 0xA0 - 0xAF?

Also...when learning a mid-range PIC such as the 16F628, with writing assembly how difficult is it to migrate to the higher level PICs such as the PIC18 series?
 
Yes the 16F use bank switching, the 18F much less so. It's actually easier to code for the 18F over the 16F, also your code will most likely be smaller.
The 18F1320 is a nice 18pin chip.
 
As the 16F628 has 2k of memory and instructions use 1 location each then it will take 2048 lines of assembly to fill it. No banking of program memory is required as there is only 1 bank.

The RAM located in bank 1 will require bank switching to access it or it can be accessed via the FSR register.

As Bill stated, the 18Fs are easier to program.

Mike.
 
Just to elaborate on Pommie's statement.

Bankswitching for GPR is based on a 7 bit memory BANK = 0-127 bytes. GPR bank 0 = 0-127, bank1=128-255 etc.

Bankswitching for FSR referenced GPR is based on a 8 bit memory Bank = 0-255 bytes, so FSR considers GPR Banks 0 & 1 as a single bank (0).
Bankswitching for the Goto/Call instructions is based on an 11 bit bank = 0-2047 bytes per bank of code RAM

Now, the spec sheet on each PIC will declare what sections of the GPR banks are allocated for system registers like 'STATUS" or TRISA.
Thus the remainder is free for your use.


The STATUS register governs which bank you are addressing, bits 5,6 govern the regular instruction bank, and bit 7 governs the FSR referenced bank.
The PCLATH register's lower 5 bits are system copied to the high 5 bits of the 13 bit wide program counter. A 13 bit wide PC can address 2^13 bytes = 8192 locations.
For goto and call commands, bits 3 & 4 of the PCLATH governs which of the possible 4, 2kb code memory banks you are working in.

EPROM memory is NOT code memory NOR is it GPR memory. They are all separate.





EPROM memory is very slow in writing but fast in reading, but can only be read via a single GPR system variable...thus it's usually a sequential operation to get data into and out of EPROM. It can be written to like a million times. It needs no power to hold its memory.
Code space memory (flash) cannot usually be written to by your code unless u use a fairly modern device like the 16F886. It has about a 100,000 write capability and cannot retain data without power.
GPR memory is STATIC RAM and is quite fast, but limited to under 512 bytes in midrange devices. Does not retain data without power.

So if your prg variable needs does not exceed the available free bytes in the <127 byte bank0 AND your Code is < 2048 bytes, you never have to bankswitch.
I have found it useful to place all my high usage routines in code bank 0 (like math, debounce, BCD 7 seg) , and to store data tables etc in the upper banks of code space. Of course for a 16F628 you don't have code space switching concerns as you only have 1 bank. Also, its useful to allocate a block of 'multibank' gpr addresses to, say, 8 reusable temp variables. These 'temp' variables are not persistent across routines and can be freely used by EVERY part of your code. Thus frequent GPR bank switching is nearly eliminated by having these workhorse variables. I use the w-reg as a free means of transferring byte data between routines, thus the output of routine A becomes the input of Routine B via the w-reg. Once u are consistent with this things become a lot simpler.
 
Last edited:
Status
Not open for further replies.

Latest threads

Back
Top