Tamas Rudnai wrote:
> Because in my opinion it leads to laziness, it's like the C++ style
> "here we need a variable so lets just create it". And then hard to
> organise in which section it should be in, what will be the best to
> avoid to much bankings or to use overlays to be able to use less ram.

I specify the bank most variables go in at assembly time, and generally put
individual local variables of a module (as apposed to buffers or arrays) in
the same bank.  That allows for automatic assembly time bank settings, and
minimizes bank switching between modules.  I also usually put global
variables in one known bank.  On PIC 18 I usually use the access bank for
global variables.

The constants GBANKADR and LBANKADR are addresses within the banks chosen
for global and local registers.  These constants are used with my DBANKIF
macro to set the banking state for access to those variables.  DBANKIF
tracks the bank setting at assembly time, and only produces the minimum
instructions to switch from the current bank to the new.

> Maybe I'm wrong on this but using section definitions (udata,
> udata_ovr, udata_acs whatever) + res all over my code feel like messy
> to me.

It's definitely better than the alternative of not having self contained
modules with their own namespace.  Besides, variable definitions wouldn't be
"all over the code".  Generaly you do this in the same place at the top of
every module.  My module templates make this easy.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist