A METHOD FOR PIC ASSEMBLY CODE INTEGRATION AND REUSE - Part 1

As you may guess from the fancy title, the method I'm suggesting deals
with modularization of programs, which means to view a system (the
program) as a structured collection of components (routines or sets of
routines).

Most of the structure is defined by a client-server relation between
components. If for a given a component there is another that uses it we
say that the first is the server and the second the client in this
relationship. A component may have several clients and several servers
too.

It is illustrative to graph this structure in an orderly manner, putting
the clients on top of the servers. For example:


                            TEXT_DISPLAY
                              |      |
                ---------------      ------------------
                |                                     |
                |                                     |
      FILLING_A_TEXT_BUFFER-------------    READING_A_TEXT_BUFFER
            |         |                |              |
            |         -------------    ------------   |
            |                     |               |   |
    KEYBOARD_INTERFACE     SERIAL_INTERFACE     EEPROM_SUPPORT


A critical issue in programming a system like this is the allocation of
variables. By that I mean giving an address to each variable each
component uses.

If you use no strategy at all and allocate everything by hand using "EQU"s
you will have to do some work every time you create a new variable. Lets
say you are working with the keyboard interface module in the previous
example and need a new variable for it. What address will you use? You
would have to run through all the other source code to find an unused one.
Or you could do the same thing with less work if you allocate the
registers in order and write down the next free one. But what happens when
you want to use the keyboard interface in another project, maybe with
other components you had also already programmed? It's a lot of work,
and it's a routine that requires none of your creativity. Hey! What do you
have your PC for?

The same scheme can be automatized in several ways. One is what Microchip
suggests with the use of unseeded "CBLOCK"s. With this methods the
assembler will linearly assign addresses to all variables at compile-time.
That solves the problems as long as you don't run out of registers.

If you do run out of registers the solution will surely be overlapping
(assigning the same address to) variables that are never "active" at the
same time. That's where the method I'm suggesting comes to play. It is a
way of automatizing this job without sacrifizing any modularity.

The implementation of the method consists of several macros that give a
high-level-language look to the declaration of variables in your code and
make most of the job for you.

I'll give you just a tip here and I'll continue in other messages. The
question is: What variables can you overlap? Recall the previous graph.
You can't be sure if you can overlap variables belonging to
"FILLING_A_TEXT_BUFFER" with others from "KEYBOARD_INTERFACE" because both
components might be active at the same time. I mean, "FILLING..." could be
active waiting for "KEYBOARD..." to perform a service, and "KEYBOARD..."
would then be active performing it.

But notice that surely "KEYBOARD..." and "SERIAL_INTERFACE" will never be
active at the same time! So you may overlap their variables. This has some
exceptions to which I will refer to later.

That is the heart of the method, I recognize it is an almost stupid idea
and that I'm not discovering America but it took quite a while for me to
sit down, think and develop it, and its conclusions turned out being very
useful to me.

If I don't receive complaints for using so much of this space I'll
continue later. I will be glad to receive feedback from you. Do you have
any other strategies for doing this? Can you see something wrong in what
I'm saying? Did you think of this too?

Regards!
                                                        Andres
                                                aajordj@aleph.fi.uba.ar