Sean Schouten wrote:
> In my initialize sub [in initialization.asm], I have define a set of
> variables using the RES directive. When I try and use the defined
> variables in one of my fan_control subroutines, MPASM bitches;

Right.  Each module has it's own namespace.  This is one of the benefits of
using multiple modules.  You can use a label, like LOOP for example, in a
small module and not have to worry about whether that name has been used in
any other module.

Variable names work the same way.  COUNT in one module is different from
COUNT in another module.  To make variables and other symbols visible
between modules, they have to be explicitly exported where they are defined
and imported where they are used.  GLOBAL exports a symbol and EXTERN
imports it.

However, it's usually best to design the modules so that only that state
that needs to be accessed by other modules is make public.  This implies
it's best to have an init routine per module.  I have my module init
routines initialize any local state, global state exported by that module,
and hardware managed by that module.  For example, let's say the routines in
the AD module take periodic A/D readings, filter them, and export a final
"official" A/D value (a very common thing to do).  The AD_INIT routine would
initialize the filter state which is local to the module, initialize the
exported official A/D value, and set up the A/D and timer hardware to take
the periodic readings.  Everything is nicely encapsulated except for the
official A/D value which any module can import and read at any time.

My PIC development environment at http://www.embedinc.com/pic uses this
architecture.  There are plenty of templates and examples there.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist