The Return stack holds the full (9bit or 11bit) CALLing address, so you can always Return to the correct place - but, remember, the PA bits are not 'updated' by the Return !

RETURN with Acc as status

On the Return from a subroutine, the Acc is loaded with the value you specify. Wouldn't it be nice if we could Return an 'error' code' ? (eg 0 = no error) - and then do an immediate 'skip on Z' / 'skip nZ' ? Well, we can't - "RETURN (ACC=) 0x00" does not set the Z flag !. .. plus, all the 'skip' instructions (inc/dec and skip, bit test and skip) only 'work' on Registers anyway. Of course we can always 'TEST Acc' before doing the 'skip on Z/nZ', but that 'wastes' an instruction ..

Is there a one instruction 'skip on (Return Acc set) status' ?
 
Well, yes, but it's rather dangerous - and it only 'works' when the Return code (or at least the 'error handler' code) is in the low 256 address locations.
 
When Returning, set the Acc to the 'error code', with 0 for 'no error' or 0xNN for error (where NN = number of instructions to skip i.e. where the error handler code is). On the Return, your code executes an "ADD ACC,PCL" instruction to 'jump on error'.
 
If Acc was returned as '0', this just means execution continues 'in line'. Anything other than 0 will 'jump' to some further address location (i.e. the error routine).
 
Of course this only 'works' if the Error routine address destination (result of the ADD) is in the current page, since ADD ACC,PLC always clears the 9th bit of the program counter, EVEN IF ADDING 0.
 
See also "mini-subroutine using 'Reg return'" below

Mini-subroutines using 'Acc return'

Often a 'main' Subroutine will need to 'Call' some common code as a 'mini-subroutine' - however chances are you have already 'used up' the 16F5x two level Subroutine Return stack (especially likely on the 16F57/9 which has 2k instructions but still only a 2 level Return stack). If the 'mini-subroutine' code doesn't modify the Acc, you can 'Return via Acc' (COPY Acc,PCL) so long as your return destination is in the low 256 locations

To 'call' the mini-subroutine, you load the Acc with PCL, ADD 2 and 'Jump Sub' (rather than 'Call Sub').
 
Of course you can only Jump (and 'Return via Acc') to (and from) the first 256 locations of the current page (i.e. same area where the 'main' subroutine resides), plus the 'Call' now costs 4 CLK's (although the 'Return' is still only 2 CLK) and, since 'Return' is 'COPY Acc,PCL' you don't get the chance to 'return' with a different value in the Acc (so can't use it for simple Data Tables, although a 'word' based Table (which loads data into 2 or more Registers with each 'call') would be a possible use)

Mini-subroutines using 'Reg return'

What to do if the mini-subroutine modifies the Acc ? Well you can place the 'Return' address into a register, at the cost of an extra CLK = 'Call' is LOAD Acc, ADD 3; COPY Acc,rtnReg; JMP sub; (4 instructions, 5 CLK) ..... 'Return' is COPY rtnReg,Acc; COPY Acc,PCL; (3 CLK).

The 'power' of the mini-subroutine is that it can modify it's own 'return' address allowing a direct 'jump on (error) status' - unlike the 'normal' RETURN where one or two extra instructions have to be used after the Return to do a 'jump on status'

Subroutines above the 256 boundary

A JMP (GOTO) specifies 9 bits of address, so you can always 'jump' to a location above the 255 'boundary'. The 'problem' is returning = if you don't Call you can't Return (via the stack). The 'trick' is thus to 'Call' to a location in the first 256 which then immediately 'jumps' (at the cost of +2 CLK's) to the 'real' subroutine code 'beyond the 255 boundary', from which you can always Return just fine.

This trick 'works' for normal subroutines but not for Data Tables == there is no problem with the 'return with value' table entries being in the upper 256 address space - it's the calculated 'jump' into the table that's the issue (when the calculation writes PCL you always end up with bit9 cleared so can only get to the low 256 locations == see Data Tables, below)

Using the PCL reg as a data source

Since the low 8 bits of the Program Counter are always 'readable' (via the PCL register) you can use the PCL as a 'source' in any 'normal' register instruction (as touched on above, you can 'INC Acc' by subtracting PCL then adding PCL (to increment by 2, use 'SUB PCL, NOP, ADD PCL')).

If your Add / SUB instruction is in a program location where the PCL == '0x01', then to INC Acc you only need to 'ADD PCL' (and the same for DEC Acc = SUB PCL).
 
However the overhead of CALLing / RETurning to/from the 'right' PCL location (not to mention saving the 'result' as the Acc is reloaded on a Return) gains us nothing for INC and DEC, although for some rather more complex arithmetic operations (eg calculating n! (N factorial) for probability functions) it may be worth while

In each 'bank' of 256 addresses, there are some 'golden' bit pattern locations (for example, to use the PCL as a 'bit' selector, you could call / goto location 0000 0001, 0000 0010, 0000 0100, 0000 1000 and so on (or 1111 1110, 1111 1101, 1111 1011 ...). Of course using these locations does rather 'fragment' the memory map, however the PIC16F54 has 512 locations, so there are 2 complete sets of 256 PCL values - and GOTO specifies a 9 bit address, so (unlike for the 57/59), for the '54 no actual 'bank addressing' is needed to get to any of these (remember = a CALL instruction can only address the first 256 locations, RETURN is the full 9 bits (or 11bits for 57/59).

Note also that the very top location of Flash memory (0x1FF for the 16F54) is the power-on start address (and if 0x1FF contains a NOP, the next instruction to be executed will be at location 0x000 (i.e. the program counter will 'overflow' and loop back to zero) = so we might want to avoid playing clever tricks with these two locations (you can get still find PCL=0xFF at 0x0FF and PCL 0x00 at 0x100)

You can, of course, write to the PCL. Unlike 'goto' (where the destination is fixed at compile time) writing the PCL allows a 'computed GoTo', although you are limited to the first 256 address locations (writing the PCL always clears the 9th bit of the program counter to 0) of (the currently selected) address bank

The most obvious reason for using a 'computed goto' is to 'fetch data' from that location. Whilst this is facilitated by the 'Return with data in Acc' instruction, it's at this point we discover that there is no 'computed Call' instruction - however there is a way it can be done (see below)

Data Tables

To conserve Register space when outputting ascii character shapes from a data table to a display (7 segment, dot matrix, video), the register containing the 'character code' can also be used as the 'jump offset pointer' (assuming the code that calculates the table offset from the character code is 'reversible')

Computed Jump into a DataTable

A data table is built using a stack of 'RETURN with value (in Acc)' instructions (where 'value' is the data). To 'read' the data you could CALL the data location 'direct' = which is fine if you know what location to CALL at compile time, however at compile time you also know the data value = so why would you not just 'load' it directly ??

What we need, of course, is a 'computed CALL'. Needless to say, no such instruction exists

Instead we start by performing a 'CALL' to the start of the table subroutine with the 'offset' onto the data table in the Accumulator. The subroutine then performs a 'computed Jump' using the 'ADD Acc to PCL' instruction. This takes us to to the actual data location where a 'RETURN with value (in Acc)' instruction returns us directly to the 'main line' code

Since writing the PCL always clears the 9th bit of the program counter, the Data Table values must always be within the low 256 locations - on the 16F54 that means within the bottom half of the 512 program memory (on the F57/9, the low 256 of each bank).

The maximum size of any DataTables is thus 255 (256 minus the computed Jump instruction at the start of the table) per 'bank'. The 16F54 has 1 'bank', so supports a max data table of 255 values (less any used for Subroutines), the 57/59 both have 4 banks (i.e. 2k of program space) so are limited to 4x255 = 2020 bytes of Data Table

For the 16F57/9 with multi-bank Data Tables, the 'calling' code would need to 'pre-set' the PA bits (and thus the Data Table bank) and then Call the 'jump to table' subroutine code which would be 'duplicated' in each of the 'banks'. The PA bits would thus select the appropriate table code in the appropriate bank.

NOTE that the PA bits are NOT 'updated' automatically by 'where you are' = they always contain the values you 'set', even after you Return to a different bank (or the Program Counter 'steps' into a new bank)

Conserving low address space

To conserve low address space, the bulk of most Subroutine code can be placed into the high address space - the initial subroutine Call must be to low space but you can then 'divert' control by using an immediate Jump into the actual code in high space (of the same bank)

This is possible because a Jump (and Return) supports 9 bits, whilst a Call supports only 8 bits (as does a computed jumps, using 'Add Acc,PCL' etc)

Speeding up the Call sequence

The 'classical' method to speeding up a data table read sequence is to 'unwind the Calls' i.e. write each Call 'longhand' as an individual snippet of code. This eliminates loops / pointer increments, at a 'cost' of extra program space

The main requirement for faster look-up is typically a need to 'output' the values looked up 'as fast as possible'. So my example below puts the data onto a set of PORT pins (for example, lookup a series of character 'shapes' for a 7-segment display - or even for a video display (perhaps with the support of an extrernal 'shift register')

Take, for example, the following 'unwound' code snippet :-/p> ; Code snippet (duplicate this for however many Calls you need). Assumes the Table pointers have been pre-calculated and placed into INDF reg set. ; Each snippet loads the (next) INDF Register and then Call's the table to do the look-up and finally output a byte ; (note this is still a 'computed Call', so the sequence can always be ended early by setting the RegN contents to cause a jump outside the table) ; Numbers in brackets () below = the number of instruction cycles used Copy RegNx to Acc ;get the next reg offset (1) Call table ;Call the table (2) ; table performs a computed jump (2) to the required entry which then Returns with data (2) Copy Acc, PORT ;finally, o/p the data (1) ; ;... (next 3 instruction snippet, RegN01..Nnn ) ; ;table Add Acc, PCL ; jump to the requested entry (2) [or past the end of table] ; RETURN with data ;each entry (2) ...

The above code will output 1 data byte every 8 CPU clk cycles at a 'cost' of 3 extra instructions for each output after the first. If we want to output (say) a date and time (to 1/100ths of a second), then we have 7 date + 6 time (dd mmm yy hh:ss.ss) with spaces and delimiters = 16 'shapes'. This 'costs' 3x16 = 48 instructions and takes 128 CLK cycles

Note that the output sequence can be terminated 'early' (i.e. before the entire set of 'snippets' completes) with a jump (past) the end of the table.
 
However this will leave an 'orphan' Return address on the stack, not a problem for any baseline CPU BUT the midrange Stack will quickly 'fill up' and when it overflows execution will be aborted (with a jump to 0 ?)

Speeding up the snippet

What slows the reading of the data table (above) is the need for a 'multi-step' sequence "Call, computed Jump, Return" sequence. The computed Jump is 'forced' (there is no way to compute a Call destination), and the "Return with value" is the only way to load the ACC and execute a program branch in a single instruction. So any 'saving' has to be in the 'Call'. So, what happens if we skip the 'Call' and just let the table 'Return with value' ?

Well, on all baseline PICs, Return is ALWAYS to the current ToS. On a Return, ToS is over-written by BoS (so then TosS = BoS). If we Return again without a Call, this (and all subsequent) Return will go to the exact same place !

So if we can set-up BoS to some specific Return address BEFORE the first computed Jump into the table (i.e. before the first Return), then we can skip the Call !

To setup the stack so all Returns arrive back at 'here', all we have to do is execute a CALL from 'here' twice without performing a Return. Once this is 'set up', you can do a 'computed' Jump straight into the table from 'anywhere' knowing the table Return will always arrive back 'here'.
 
This trick works fine with the baseline PICs. You can't do it with the 'midrange' PIC's (the midrange CPU will 'abort' a Return from an 'empty' stack by performing a 'reset' i.e. execute a jump to address 0x000).
 
However you can 'sort of' do it with other 'more clever' PIC's that deal with aan empty stack return by jumping to a hard-wired 'exception' address (where you could have code waiting)

Terminating the data read loop

Before going further, we have to note that the 'drawback' of a 'Return without Call' is that the Return will keep going back to the exact same address. This means you can't write an 'in-line' data read sequence, so it looks like what we gain by skipping the Call will be lost by 'counting' the Table loop ... or is it ?

What happens if we write :-

Well, the above code will 'run for ever' outputting 1 data byte every 7 CPU clk cycles, but only so long as the jump destination (PCL+Acc) is within the 'Return with value' data table. So, to terminate the sequence, we just set the last offset value in the Index register stack to 'point' somewhere other than within the data table.

Note that the above code must all be the low 256 locations - when the PCL is written, the 9th bit of the Program Counter is reset to zero = that means 'add offset to PCL' will ALWAYS take you to somewhere in the first 256 address locations
 
It's to be noted that Zero (0x00) is often used to 'terminate' character strings (0 is not a 'normal' ascii value) and adding 0 to the PCL 'jumps' to the next instruction i.e. 'falls through'.

An alternative method of 'terminating' the loop is to setup the Timer/Counter to 'Interrupt' after however many bytes you want to output (i.e. set Timer Count = 7 * the output count)

NB. 'Return without Call' depends on setting up an 'empty' stack so you know where the Return is going to be

The ToS=BoS 'Return here' loop code

The stack consists of 2 registers, ToS (Top of Stack) and BoS (Bottom of Stack). On a Call, ToS is copied to BoS and CALL+1 is copied to ToS. On a RETurn, ToS is copied to PC and BoS copied to ToS.
 
So, to setup ToS=BoS 'all' we have to do es execute a 'double stack push' (or 'double Call') at the very 'top' of the data look-up loop.

If this all has to fit withing 256 bytes, then the max. data table is now 256 - 6 - 2 = 248 entries (so if the table is storing ascii character shapes in a 8x8 font, we have space for 248/8 = 31 characters, just enough for my PIC Time and Date on screen display (OSD) )

To avoid the need to use an Index register for the final 'goto Jump' and the actual 'JUMP somewhere', the Table can be modified so that the last entry outputs the 'end of line' (space) and doesn't Return) as below :-

Maximum DataTable read rates (no Return, no Call)

There is just one further way to maximise the data table read rate = 'unwind' the Return loop by having each Table entry output it's own data and then jump (in)directly to the next entry to be output. Unfortunately, this 'multiplies up' each data table entry by N extra instructions, so is of limited use (i.e. only for small tables)

Above outputs 1 byte per 6 CLK's, however each table entry is 5 instructions, so the max. table size is now 256/5 = 51 entries

The 16F54 has space for one table, however the 57/9, with 2k instructions words has space for 4 such tables. Dedicating all 4 tables to ascii Font store means we have 204 entries which is enough room for only 25 characters (in an 8x8 font). This allows a numeric date/time display (0-9, -, :, am, pm, space etc)

To squeeze additional characters into the font table, see 'Character FONT (shape) packing' below and my PIC18F OSD display project

Max data output, pre-loading registers from the data table

Finally we arrive at the maximum possible output speed. By pre-loading the Registers with the data to be output we can achieve 2 clk's per byte

The maximum possible speed using 'indexed' output is 5 clks, however this is done at the expense of not testing for an 'end of line', so some 'external' means of stopping the loop will be needed :-)

If we use register contents = 0 as an 'end of line flag' (or the FSR count 'overflow' into some significant bit is used) we get a 'controlled' loop of 6 clks (although we might as well be using the table)

Using Register contents 0 as end of line flag (0 is output on last cycle)

Using the FSR reaching some significant bit = end of line (last FSR is not used, not output)

Direct shape output

For an OSD / VTI (On Screen Display / Video Time Inserter) the number of characters 'per line' is typically low and the display position is usually 'fixed' on the far right of the screen (i.e. at the 'end of the scan line'). In this case, rather than use the character code registers as 'pointers' to the shape, the shapes can be 'looked up slowly' before the output point is reached and stored in a second set of registers. Output can then be achieved at CPU clk rate (using ROTL PORT to shift bits) with only a small inter-character gap delay

The above is 9 CPU Clk's per byte output but avoids the need for an external Shift Register

Remember, from above, bytes can be output at 2 clk rate. An external shift register would thus be running at 4 x the CPU clk rate i.e OSC rate. See my On Screen Display project pages

Packing text (ASCII character codes)

There is a whole field of study dedicated to compression, compaction and encoding of data. Whilst I consider here only the 'simple' methods applicable to text, even this can become complex (for example, 'word substitution' (using short-cut codes) demands a knowledge of the likely text (eg narrative, program code) that will need to be encoded). Hopefully I provide enough 'pointers' to get you started

All PIC's suffer from the massive drawback of having very few registers (RAM). If we want to store multi-character ascii strings as 'variables' it makes sense to 'pack' the data.

In the 'old days' of early computers, often 3 characters were packed into 2 bytes (so 33% space saving), however this was achieved by reducing the character set to 40 ! (typically 26 uppercase only characters, 10 numbers and 3 punctuation (typically space, dot, carriage return/line feed) plus an 'escape' code (which allowed other characters to be defined 'long hand')
 
The '3 into 2' trick works because although 40 characters requires 6 bits, 40 x 40 x 40 is only 64,000 (i.e. less than 64k) and only needs 16bits, not 6+6+6 = 18bits. To store the '6 bit' ascii, you place the first char into a 16bit word, multiply by 40, add the next char, multiply by 40 and then add the final character
 
To 'unpack' the ascii, the 16 bit value has to be successively divided (1st char = quotient of full value divide by 1600, 2nd char = quotient of first remainder divided by 40, 3rd char = remainder). All of which is fine when you have a computer with a 1 cycle 16bit hardware multiple/divide ALU (but limited storage)

These days we typically require lower-case characters as well as extensive punctuation (and the low end PIC devices lack multiple/divide circuits :-) ). Most ascii sets contain at least 96 characters (7 bits), however there are still a few techniques that can save space when large blocks of text (such as a screen display) have to be stored.

8 into 7

The first is the simplest - if only 7 bits are used, each byte has one 'spare' bit, so 7 bytes have 7 spare bits and these can be used to store an 8th character (saving 1 byte in 8).

6 into 5

The next trick also makes use of the 8th bit - however this relies on the fact that 'on average' English words are a bit less than 5 characters long. Instead of storing the 'space' (at the end of the word) as a character, we store it in the 8th bit, thus saving one byte in 6 (on average)

3 into 2

The final trick is to note that in 'normal' text very few characters are 'upper case', numbers or 'punctuation marks'. Reducing the 'common' character set to 26 lower-case letters (with room for 6 additional characters, obviously '.', 'space' and EOL plus whatever supports the text that's going to be shown (';:-' or '')) which means we only have to store 5 bits for each 'common character'.

We can thus store 3 characters in 2 bytes (15 bits) with one bit 'spare' as a 'flag' (to indicate that this byte is a 7 bit character and not part of a 3 character word). This is similar to the '3 into 2' packing used in the 'old days', but without the multiple/divide overhead.

Packing is on 'complete sets of 3' successive 'common characters' ('space' is a 'common character', so strings consisting of lower case with spaces will all get packed). Occasionally, individual (or sets of 2) common characters will have to be left 'un-encoded' (7 bits spans the whole character set) so compression will be 'less than' 1 byte in 3 (especially for text without long strings of 'common characters'). Unpacking is as follows :-

Note the flag bit is '1 means packed byte', so we don't have to do any unpacking when the end of line '0x00' code is seen

Actual compression (encoding) of text

So far (above) I have only looked at simple 'save 1 byte in N' packing approaches, however the last of these (3 into 2) 'points the way' to the use of 'compression coding'. Of course actually compression (eg .zip) is likely to far exceed any benefit, however if we are only using 96 ascii values in a 7 bit (127) code range we have 31 'unused codes' (0x00-0x1F) - and these can be used as 'key codes' to replace (up to) 31 'common words' in the text you are (currently) storing. The good bit about this trick is that you can use it IN ADDITION to the '8 into 7' / '6 into 5' or '3 into 2' method above !

Of course it's going to make '3 into 2' rather less efficient, since the 'common character' strings will be 'split up' every time a 'common word' is removed and a 'key code' inserted (except when the key code turns out to be one of the more 'common characters' !)

Holding 96 ASCII characters in a 7 bit value means we have 127-96 = 31 'spare' codes, although, in practice only 30 are 'available' (since 0x00 is reserved for the 'end of line code'). To avoid the need for complex programming, the 30 codes could be simply assigned to the first 30 'duplicate' words found in the 'text store'

To maximise the space 'saved', the first occasion of a duplicate word has to be replaced as well. This means replacing the word with the code and then 'shuffling up' the rest of the text in the store.

The drawback of this scheme is that only the first 30 duplicates are 'compressed' - so more frequent duplicates that occur later in the text will be left 'uncompressed' - and when the text being stored is for a screen display the 'duplicate store' can quickly become 'stale' or out of date (as duplicated words are 'scrolled off the top' of the display :-) )

One alternative to the 'just use the first 30' is to pre-program 'common' English words (such as 'the'), however (and especially if it's a terminal display screen) the text that needs to be stored may not be 'common English'.

If you want to define your own 'common word' set, I suggest you analyse the contents of some text-like files (for example your web page 'source' files) which you expect your PIC to store (eg for display).

Finally there is the 'variable word Look-Up-Table' approach. Only really possible with the 'high end' PIC's with lots of program space (and some EEPROM storage) you program the PIC to perform it's own 'common word analysis', choose it's own 'key words' and 'update' it's word substitution LUT (in EEPROM) 'on the fly' :-)

Of course, by the time we start building solutions with high end PIC's we will, no doubt, be using external serial RAM storage - so the 'lack of space' problem goes away (and is replaced with output speed issues :-) )

Character FONT (shape) packing

Another typical requirement is to store 'bit maps', for example to define character shapes. A 'basic' character font is 8 lines of 5 bits (8x5), which can be simply stored 'packed' into 3 16bit words (so 6 bytes, rather than 8). Flipping the bit map by 90 degrees (5x8) reduces the count to 5 bytes, however 'unpacking' becomes 'a bit more complex' :-)

Since the shape look-up table will be in program (Flash) space, the constraint is typically read-out speed, not space. So splitting the table into 'scan lines' is likely to be the better approach, even if it results in poor space utilisation

When space is tight, it's worth noting a few bytes can still be saved (without adding overhead to the 'read out') by 'pointer manipulation' (assuming there's enough time between read-outs to do so)

The most obvious is 'space' - we only need to store 1 byte (because every scan line through a space is the same) = so the 'space' pointer not be changed between scan lines.
 
Less obvious is the 'substitution' of letters/numbers (for example, numeral 1 for lower case l, numeral 0 for uppercase 0)

It's also to be noted that an 8x8 font TYPICALLY includes the 'inter-character gap' i.e. the 'last bit' in the byte is always 'blank' for text (but not graphics characters). Whilst there is no time to set/reset bits during output, there's nothing to stop you 'dropping' the last bit from the external circuits (shift register) by 'not turning on' that i/o line (in text mode) - which opens up the possibility of using that bit as a 'flag' ...

Next up, it's worth noting that the 'top' few scan lines through many lower-case letters are 'blank' (in an 8x font, 14 characters (acemnopqruvwuz) all start with 3 blank lines). Further, very very few characters have a 'descender' (gpqy_), all of which points to possible savings

The problem is always with read-out speed. We will always want to 'clock out' the font shapes at the maximum possible speed, which means we have no time during actual output to 'check bits' or 'decide to choose another byte'.
 
If, however, output is performed using 'pointer' look-ups (variable jumps into the font table), there may be time to 'adjust' the pointers in some simple ways before starting the output. For example, in text mode, the 8th bit of the font could be used as a 'double me' flag (many characters have 'duplicate' scan lines in their shapes)

For more on text and font packing, see my PIC OSD and PIC VGA display projects

Timing delays using Return

A CALL to any existing RETURN 'costs' a single new instruction but gets you a 4 CLK delay == but don't forget - the Acc is overwritten (although Status is unaffected). Since the Acc is 'lost' anyway, to get longer delays, you can CALL into any code prior to a RETURN that only effects the Acc (but you might need to watch out for Status bits being changed)

A 2 clock single instruction inline delay (that does not effect the stack) is achieved with a "GOTO $+1"

Using the 16F5x STATUS register (03)

The Status register is actually a real register (unlike the INDR pointer 'register', the PORT control (TRIS) 'register', the OPTION 'register' and the W 'register' (Accumulator), none of which are real registers at all). Further, all 8 bits are implemented (see below re: PA bits) - unlike the register 'bank' bits (FSR bits 5-7)

What happens to the Status bits when the Status Register itself is specified as the 'destination' of some instruction ?
 
Well, first the TO/PD bits are not 'writable' at all, and second, if the instruction itself is one that effects ANY 'flag bit' (i.e. any of Z,DC,C) then the 'write' to all 3 bits is ignored (Bit Set/Clr doesn't effect the 'flags', so will work on Z,DC,C just fine, as will Nibble swap, COPY Acc to Status and (oddly) INC / DEC Skip if Z (since PD is only 0 after a SLEEP and TO is only 0 after a WDT Time-out, you will be hard pressed to get the skip to take place)

The 'Z' flag is auto-updated by most instructions, whilst b1 (DC = Digit Carry) flag is updated only on Add or Subtract and Bit 0 (Cy), is only updated on Add/Subtract and Rotate (which is via Carry). Since Bit Set and Bit Clear allows the flags to be accessed, we can 'play' with the values.

Since Rotate is via Cy, manipulating the Cy flag can be quite useful = see later for "how to 'bit shift' 5 bits using the 4 bit PORT A"

It's worth noting that the state of the Cy / DC flags are inverted after a Subtract. Specifically, on Add Cy and DC are 'set' on carry, on Subtract, they are set on 'no borrow' (i.e. 0 = borrow, 1 = none). This is a real pain to remember (and prompted me to 'invent' two extra 'flag macros', specifically "BRA_Bw dest" = Branch (jump to dest) if Borrow, and "BRA_nB dest" = Branch (jump to dest) if no Borrow)

Using the PA bits

The top 3 bits of the Status register are 3 PA bits, which exist on all 16F5x devices, despite the fact that PA2 (= b7) is not used on any of them, and PA1 (b6) & PA0 (b5) are only used by the 16F57/9.

The PIC manual says "Using PA3 (or PA1/0 on the 16F54) is 'not recommended'", however PA3=b7 in particular makes an excellent 'custom Status flag', especially as you can 'ROTL Status to the Acc' to copy it (b7) into Cy (b0) and then ROTR Cy into somewhere else

Using the 16F54 FSR (reg 04)

The FSR (reg 4) is the 'pointer' register for use with INDF (reg 0) indirect addressing into the register stack. When using indirect addressing, you can 'flip' the FSR pointer between 2 registers by using the INVert instruction ("COMF 4,1" or, as I like to code it, 'INV FSR').

You can only 'pair up' outside the 'special reg' set. For the 16F54, the first general reg is at address 0x07 (0,0111) - it's "complement" is at 0x18 1,1000 - the next pair 0x09 (0,1001) with 0x16 (1,0110) .. and so on).
 
The 16F54 has 25 registers (address 0x07-0x1F i.e. 0,0111 to 1,1111, inclusive). Of the 25, 16 can be 'paired' together using 'INV FSR' to flip between them (the 7 registers at the top of the address range would 'pair' with one of the special registers (0-6)). The full list is :-

FSR bits 5-7 are the 'bank select' bits. On the 16F54, all 3 bits are 'unimplemented' (and will read as 1), on the 16F57 only bits 5 & 6 are implemented (7 is '1') = only on the 16F59 are all 3 bits implemented

The unimplemented 3 bits always read as '1', no matter what instruction is operated on it - so, for example, on a 16F54, "CLR reg4" will set Reg4=0xE0)

For how the 'register bank' system works on the 16F57/9, see below

Adding 8 (0 1000) to the FSR thus allows you to 'cycle' around 4 specific registers, starting at 0x07, 0x0F, 0x17 and finally 0x1F. Note that this is only possible with the one specific 'set' on the 16F54.

If FSR is set to 0 (i.e. pointing at the 'indirect' INDR 'dummy' reg location), any read operation using INDF will return 0 - and (by implication) any write will be ignored

16F57/59 register addressing

Understanding the 16F57/59 register bank addressing system is not easy.

The 8 bit register 'address' should be regarded as a 4 bit address (0-3), a 1 bit 'bank enable' (4) and a 3 bit 'bank select' (5,6,7).
 
When bit4 = 0, one of the 16 'common set' registers will be accessed, irrespective of the 'bank select' bits. The 'common set' includes all the Special (control and status) registers (INDF, PORT, actual Status etc) so these are always accessible, irrespective of the 'bank' bits.
 
When bit4 = 1, access is to one of the 16 'upper' registers, as determined by the bank select bits.
 
The 16F54 has one 'bank' (register address 0x10-0x1F). Of the 16 'common' registers (0x00-0x0F), the first X are Special, so it has 16 + = GP registers.
 
The 16F57 has 4 register 'banks' (10-1F, 30-3F, 50-5F, 70-7F)= 64 GP registers, which, when added to the 8 GP registers in the 'common set' (the low 16) gives us 72 registers in total. Note that the FSR contains 7 bits (the 8th == 1) so can address any of the 'banked' registers (but only in 'sets' of 16 - incrementing 'off the top' of a GP set will 'drop back' to the 'common set' !)
 
The 16F59 has 8 banks of 32 (00-1F .. E0-FF). This gives it 8x16 = 128 GP registers. Since the first 10 of the common set are 'Special' (control) registers, there are only 6 'fixed' GP registers (0A-0F) for a total of 128+6 = 134. The FSR contains 8 bits

Note that 'incrementing' the FSR is very dangerous (as it will happily 'roll over' from the top of one bank (eg address 1F) to the bottom of the next (20) which then maps to a Special register.

Using Rotate

You can both 'unpack' a register (extract it's bits) and control the 'unpack loop' using the same register with a Rotate instruction.

The trick is to note that Rotate is via the Carry bit, so on each rotate the current state of Cy is 'shifted in' at one end of the register (and the bit at the other end is 'shifted out' to Cy). To 'control' the bit loop, you start by setting Cy, so on the first Rotate the byte gains a '1' at the 'shift in' end (so it is now non-zero).
 
On all subsequent Rotates you clear the Cy bit first, so 0's are 'shifted in'. You can then 'exit the loop' when the byte is Zero (which you have to Test for, since Rotate has no effect on the Z flag)

Packing a register (shifting in) is similar, however in this case you start with the register set to 1000 0000 or 0000 0001 (i.e. all 0 except the 'end bit'

On each rotate instruction, the Cy bit is rotated into one end of the register and the other end bit shifted out to Cy.
 
If you bracnh on the state of Cy, on the last bit in, the '1' end bit will be shifted out

PORT registers

Reading the data bits from the PORT 'register' ALWAYS gets the actual value on the actual pins, irrespective of the mode (and not the value in the (output) register) EVEN IF the PORT pins are set to 'output'

It's quite possible for the pin to be 'pulled' in the opposite direction of it's 'data out' value by some external circuit (for example, it could be shorted to Gnd)

This means you have to be very careful when using any command that writes the 'result' back to the 'source' - for example, ADD Acc,PORT will read the PORT pins, add the value in the Acc and write the result to the PORT o/p latch.

Only if the entire PORT is set to 'output' mode (rather than input = tri-state) will Acc be added to the latch contents and even then, only if the o/p pin state is not being 'overridden' by some external circuit 'back drive'

PORT A, bits 4-7 (and E bits 0-3) are 'unimplemented' and always read as 0, which could be of some use (for example, ROTL PORTA,Acc gets the pin state into Acc b1-4 whilst clearing the Cy, ROTR PORT E,Acc is similar (PORT E pins 7-4 end up in Acc 6-3 with Cy clear)

Note that the PORT pin changes state at the end of the instruction execution (i.e. on the trailing edge of OSC 4), whilst the PORT pin is 'read' during the first 1/4 CLK (i.e. end of first OSC cycle) of the instruction

If you Write to the PORT (latch) and then immediately Read back from the same PORT (pins), there is a single OSC between the two operations. This means that the new pin state has to 'settle' within 1 OSC if it is to be read back correctly

The TRIS command sets the pin 'mode' (i.e input or output) latch (it's not a register, it can't be 'read'). If you TRIS the pin to output mode, the pin is driven Lo or Hi depending on the PORT register data value. To avoid 'glitches', set the PORT data value before switching the pin to o/p mode

High speed serial output ('bit banging')

The maximum possible speed is 'one (OSC/4) instruction per bit' - which means using the Rotate through Carry instruction - and using a whole 8 bit PORT for full byte serial comms

Both the 16F57 and 16F59 have sufficient i/o pins to allow a set of 8 i/o's to be 'dedicated' to serial output.
 
The 16F54, however, has only one 8 bit PORT (plus one 4 bit), so you might well have to 'double use' some of the PORT B (8 bit 'serial out') pins.
 
Note, by the way, that because the 'shift' is actually a 'Rotate via Carry' you can gain an extra bit 'for free' by pre-setting the Cy bit (i.e. you can shift out 5 bit data using the 4 bit port or 9 bits via the byte port)

The byte to be transmitted is copied into a PORT register and then a sequence of 7 'Rotate' instructions is used to shift all the bits out

From RS232 serial comms spec. we note each byte requires a 'start bit' (Lo) followed by the 8 data bits (bit 0 first) then one or more 'stop' bits (Hi).

Bit 0 of the PORT is thus defined as the 'serial Tx' line, and is pulled Hi with a 10k resistor (so when the PORT is set to 'input' mode, the serial Tx = 'idle' = Hi). The remaining 7 bits of the PORT can be left 'n/c', however all 8 pins must be 'enabled' as outputs before serial Tx starts (remember - reading the PORT gets the pin state, not the o/p latch values).

The 7 'n/c' pins could also be used as inputs (when the serial comms is not in use), however careful circuit design is required to ensure that, when set to o/p mode (during serial transmission), the PORT o/p latch value 'overrides' any input signal level

To read a byte, one i/o pin (b0 if MSB is senr first, or b7 if LSB) is used as the Serial in and the other 7 bits set to output. As the bytes is shifted in it is built up be storing the first 7 bits on the data output latches. The last 'read' command gets the 7 bits of saved data plus the last input bit

Outputting 5x8 character bit maps

A PIC based OSD / VTI (On Screen Display / Video Time Inserter) will need to output bit-mapped characters at video rates. The 16F5x series is spec. limited to 20MHz OSC, so the CPU CLK is only 4MHz and thus even at 1 CLK per bit the 'bit map' characters will be about 3x slower than normal video bit rates (so each bit is at least 3 pixels wide)

Overclocking the 16F5x to 24MHz gets us a 6MHz video rate (assuming we can do 1 bit per CPU clock) which is 'acceptable' for interleaved TV video (but not for VGA, where we need a 24MHz data rate for the most basic 640x480 display). For VGA, we thus need a PIC supporting at least a 48MHz OSC (12 MHz CPU clk) OR use an external shift register (with an 8x8 bit map and load it at 2 CPU clk per byte whilst clocking at OSC rate)

The 16F54 PORTA consists of 4 bits (0-3) only. HOWEVER it can be used to support a 5 bit wide character map if the bit3 pin is used as the actual output !

Four bits of the map are loaded into b3-b0 and the 5th bit loaded into Cy, so the first 'Rotate Left PORTA' shifts Cy into b0 (to set this up, the 5 bit map would be Rotated right into Cy before starting the output). NB. To support this approach, the bit maps will need to be held 'mirror imaged'

Note also that the pin is either Hi or Lo (i.e. not 'tri-state'), so if we want to 'superimpose' text on the existing video stream we will need to 'buffer' the pin with an external transistor

Max speed output using a single i/o pin (bit banging)

If one of the 'end' bits are used (b0 or b7), it is possible to output in 3 instructions whilst preserving the 'contents' of the rest of the output register

If we don't care about preserving the other bits, the whole PORT is defined as an output and a single instruction ROTATE shifts the bits along

The maximum continuous o/p is 9 bits (8 byte + Cy), after which 1+ clk time has to be spent loading the next byte (and Cy).

Next page :- PICAXE Serial link

[top]