Sunday, September 20, 2015

GPASM object files

As part of the work on my home automation system, I've been doing a lot of assembly programming for the PIC16F688. That is my chosen microcontroller for all the various embedded systems around the house.

One of the particular issues that I've run into, is that I've divided the code into modules (like a good little boy). The gputils toolchain supports separate compilation, relocatable code, and linking. SWEET! But this is assembly code. I can't instantiate the I2C slave or master code for a particular pair of pins on the '688. There are tight timing loops, so the code must directly reference the correct port and pin (as opposed to variably-defined values).

One of my control boards talks to TWO I2C busses, and can operate as both slave and master on both busses. Since I must directly reference the port/pin, this means that I need separate compilations of the assembly code for each bus. And then I run into the problem: symbol conflict.

My solution is to rewrite symbols within the library modules for each bus instantiation. So the "start" function for the I2C master (I2C_M_start in the library's object file) is rewritten to HOUSE_I2C_M_start and LOCAL_I2C_M_start.

This works out really well, though I just ran into a problem where one library refers to another library. Not only do I need to rewrite the entrypoint symbols, but also the external reference symbols.

All of this rewriting is done with some Python code. The object files are COFF files, so I wrote a minimalist library to work with GPASM's object files (rather than generic COFF files). Using that library, I have a support script to add prefixes like HOUSE_ or LOCAL_.

Here are my support scripts:

    If you're dealing with PIC object files, then maybe the above scripts will be helpful.

    As an aside, I find it rather amusing to go back to assembly programming days, yet find myself still enmeshed within libraries, object files, and linkers.

    1 comment:

    Daniel Rall said...

    You'd think that the state of the art would've advanced a bit, eh?