Searching \ for '[PIC]: MPLINK questions' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'MPLINK questions'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: MPLINK questions'
2001\04\25@152206 by Mark Bishop

flavicon
face
I have two non-continuous sections of user memory both 223 bytes long and I
have this application that wants 245 bytes of memory.  How can I split this
up between the two sections so that MPLINK doesn't complain about it being
too big.  I've gone through the .map file and I do see some room in the
first bank but my problem is convincing MPLINK that it is out there.  If
anyone has any suggestions (like the correct syntax for a #pragma statement,
or moving function (ie local) memory out of the primary bank) I would
appreciate it.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\26@080603 by Olin Lathrop

face picon face
> I have two non-continuous sections of user memory both 223 bytes long and
I
> have this application that wants 245 bytes of memory.  How can I split
this
> up between the two sections so that MPLINK doesn't complain about it being
> too big.

You can't.  You will have to modify the program to only require contiguous
chunks of bytes that can fit within individual sections.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\04\26@090443 by Bob Ammerman

picon face
If the problem is a large array:

unsigned char bigarray[245]

You could replace it with two arrays:

unsigned char arr1[128];
unsigned char arr2[245-128];

use the appropriate syntax to put these two arrays into different banks or
whatever.

then

#define bigarray(i)  (((i) & 0x80) ? arr2[(i)&0x7F] : arr1[i])

finally, replace bigarray[...] with bigarray(...) in your code.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


{Original Message removed}

2001\04\26@095752 by Bob Ammerman

picon face
----- Original Message -----
From: "Bob Ammerman" <.....RAMMERMANKILLspamspam.....PRODIGY.NET>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Thursday, April 26, 2001 9:02 AM
Subject: Re: [PIC]: MPLINK questions


{Quote hidden}

or: you could define two functions:

void put_bigarray(unsigned char index, unsigned char val)
{
   if (index & 0x80)
       arr2[index & 0x7F] = val;
   else
       arr1[index] = val;
}

unsigned char get_bigarray(unsigned char index)
{
   return (index & 0x80) ? arr2[index & 0x7F] : arr1[index];
}

This technique has the advantage of (probably) using less code space than
the macro technique.

{Quote hidden}

contiguous
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu



'[PIC]: MPLINK questions'
2002\12\15@133853 by Quentin
flavicon
face
I am learning how to use the linker on MPLAB 6.10.

So far so good, but something I realy don't like is the way you have
declair addresses and registers with GLOBAL and EXTERN, etc. Isn't there
a better way of doing it? Seems like a lot of extra work and when I am
going to do a large program I think it is realy going to irritate me.

The help file refers to a .MAP file, where you can see your memory
usage, etc. I can't find any. Do I have to be set in on a command line?
If so where?

Thanks
--
Quentin
RemoveMEqscspamTakeThisOuTiptech.co.za
http://www.iptech.co.za

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2002\12\15@151033 by Dave Dilatush

picon face
Quentin wrote...

>I am learning how to use the linker on MPLAB 6.10.
>
>So far so good, but something I realy don't like is the way you have
>declair addresses and registers with GLOBAL and EXTERN, etc. Isn't there
>a better way of doing it? Seems like a lot of extra work and when I am
>going to do a large program I think it is realy going to irritate me.

These directives allow you to control the visibility of labels
outside the .asm module in which they are defined, allowing you
to have "public" and "private" labels.

Unless a label is declared GLOBAL in a module, it is visible only
to the code in that particular module and is invisible to all
other modules in a project.  This allows you a great deal of
freedom in naming variables and code labels, and reduces what I
call "namespace clutter."  How many times have you wanted to call
a variable "temp", or a program location "loop", but you couldn't
because those names were already used somewhere else in your
program?  By building your code with the linker, and keeping
those labels private by not declaring them GLOBAL, you can re-use
commonsense names as many times as you want, provided you don't
try to define them more than once in each module.

I don't know whether this is common practice or not (I'm just
learning MPLINK myself), but I've been breaking up my projects
into numerous files, each containing only a small number of
related routines.

The more I use the linker, the more I like it.  Relocatable code
is DEFINITELY the way to fly.

>The help file refers to a .MAP file, where you can see your memory
>usage, etc. I can't find any. Do I have to be set in on a command line?
>If so where?

I haven't used 6.10, but in 5.xx it's in the "Window" pulldown
menu in MPLAB.  There won't be a .map file unless your project
has been built, though.

Hope this helps...

DD

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2002\12\15@202620 by Olin Lathrop

face picon face
> I am learning how to use the linker on MPLAB 6.10.

I'm using MPLAB version 5, which my answers below apply to.

> So far so good, but something I realy don't like is the way you have
> declair addresses and registers with GLOBAL and EXTERN, etc. Isn't there
> a better way of doing it? Seems like a lot of extra work and when I am
> going to do a large program I think it is realy going to irritate me.

GLOBAL and EXTERN are your friends, and don't work any differently in MPLAB
than they do in most other assembler/linker combinations.  It is a good
thing that symbols don't go outside a module unless you explicitly define
them to.  Otherwise it would be a difficult task to keep symbol names unique
accross many modules.

Wanting to GLOBAL and EXTERN too many variables is usually an indication of
bad design or modularization choices.  Sit back and think about your whole
project and identify subsystems that might require some internal state but
have only a limited interface to the rest of the system.  Put each subsystem
in its own module.  You'll also then appreciate that each module gets its
own namespace for local symbols.

I've done dozens of professional PIC projects and use relocatable mode
exclusively.  You can see the details of my general project framework at
http://www.embedinc.com/pic.

See the HOS_UART.ASPIC module at http://www.embedinc.com/pic/hos.htm for a
good example of modularization.  This is an interrupt driven UART handler
with software receive and transmit FIFOs.  The state defined in this module
is the two FIFOs and two scratch registers for use by the interrupt
routines.  Note that all of this state is local, meaning it can't be
accessed directly from outside the module, and none of it is therefore
defined GLOBAL.  The only global symbols exported by this module are the
UART_PUT and UART_GET public subroutines, and the interrupt routine entry
points.  This module does use two flag bits that are global.  These are
defined in the master include file due to my method of allocating global
flag bits with the /FLAG preprocessor directive (native MPASM doesn't
support flag or bit variables directly), but can be thought of as state
exported by this module.

> The help file refers to a .MAP file, where you can see your memory
> usage, etc. I can't find any. Do I have to be set in on a command line?
> If so where?

Yes, there is a command line option to enable/disable the map file.  I'm at
home now and don't have the MPASM manual here, so you'll have to look up the
details yourself.  I always run MPLINK thru my LINKPIC wrapper, which always
causes a map file to be written.  I archive the map file along with other
files for each released version of a project.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2002\12\16@001708 by Quentin

flavicon
face
> Wanting to GLOBAL and EXTERN too many variables is usually an indication of
> bad design or modularization choices.

I am not disputing that relocatable code is the way to go, exactly the
reason why I am looking at the linker (upgrading a 6K 16F876 program to
18F242), and I also see the advantage of having local labels in a module.
The one area where I need a lot of EXTERN is with my delay routines. All
my delay routines are in one module and I use various delays in all the
other modules (From 10ms up to 2s). So in all my other modules I have to
EXTERN all the labels to call delays, which can be quite a few.
Maybe you are right, I should relook at the way I am doing it (such as
only calling a minimum delay and do multiples of it in the module that
called for it), I was just hoping there was an easier way of declaring
EXTERNs.

MAP file, I can find with MPLAB 5.70, but not with 6.10.
--
Quentin
qscEraseMEspam.....iptech.co.za
http://www.iptech.co.za

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2002\12\16@114945 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,
Quentin wrote:
>I am not disputing that relocatable code is the way to go, exactly the
>reason why I am looking at the linker (upgrading a 6K 16F876 program to
>18F242), and I also see the advantage of having local labels in a
module.
>The one area where I need a lot of EXTERN is with my delay routines.
All
>my delay routines are in one module and I use various delays in all the
>other modules (From 10ms up to 2s). So in all my other modules I have
to
>EXTERN all the labels to call delays, which can be quite a few.
>Maybe you are right, I should relook at the way I am doing it (such as
>only calling a minimum delay and do multiples of it in the module that
>called for it), I was just hoping there was an easier way of declaring
>EXTERNs.

Ok, I see where you're comming from, however relocatable code 'requires'
that you do some 'out of the box thinking'. Think about your project,
it's modules and dependacies at an larger scale. Let me summarize my
personal
preference in 'global' thinking, it's not *the way* to do it, hey
someone will
probably say that it will cause rein of fire onto my pic for eternity
but anyway
this is the way I prefer.

All projects have one file called DEFS.INC , in this file you declare
processor, include appropiate processor include file (mplab), clock
and speed (in case they are different aka PLL ), all global defines
and constants(buffers etc), all pins and their uses etc. Basicly each
and everyone
of the other files have this included. Note *no* ram or anything similar
is 'allocated' here.

Then ofcource you need the linker control file, I will not get into the
particulars
but normally you need only small changes in this depending on the
project.

And in a module, for example an uart module with buffers, you declare
the local
ram, write desired routines (GLOBAL where appropriate). Now here comes
the cavecat,
each module (*.asm) also is required to have an associated include file
(*.inc). In this
include file you have the previously declared extern variables/routines
declared as
EXTERN. For example:

In SERIAL.ASM:
<<<<<<<<<<<<cut>>>>>>>>>>>>>>>

;**********************************************************************
; project description etc.
; text , comments etc about the module and dependencies
; version etc..
;**********************************************************************
       #include <DEFS.INC>             ; defines, constants, pins, ram
       #include <MACROS.INC>           ; macro definitions
       #define _SERIAL_DEFS_ONLY       ; define to ignore exporting of
routines/ram
       #include <SERIAL.INC>           ; include for bit flags and
constants
       #undefine _SERIAL_DEFS_ONLY     ; clear define

..ram..
..etc..
;
***********************************************************************
;
;  INIT_UART - Initialises UART
;  bla bla bla...
INIT_UART
       GLOBAL  INIT_UART


<<<<<<<<<<<<cut>>>>>>>>>>>>>>>

               
Then in SERIAL.INC:

<<<<<<<<<<<<cut>>>>>>>>>>>>>>>

;**********************************************************************
; project description etc.
; text , comments etc about the module and dependencies
; version etc..
;**********************************************************************

#ifndef _SERIAL_INC_
#define _SERIAL_INC_

#ifndef _SERIAL_DEFS_ONLY ; check if included locally ( then we skip all
extern definitions )
;+++++        
;       Global functions in this module
;
       
       EXTERN  INIT_UART       ; initialise internal harware uart
       EXTERN  RX_INT_HANDLER  ; called from isr
       EXTERN  TX_INT_HANDLER  ; dito
       EXTERN  TX_ADD_HEX      ; adds a byte to tx buffer as *two*
ascii hex characters (00-FF)
       EXTERN  TX_ADD_NUM8     ; adds a byte to tx buffer as *three*
ascii digits ( 000-255 )
       EXTERN  TX_ADD_BUFFER   ; adds a byte to tx buffer
       EXTERN  RX_GET_BUFFER   ; gets oldest byte from rx buffer ( if
any )
;+++++        
;       Global ram in this module
;
       EXTERN  UART_Flags      ; operating flag mostly error bits

#endif  ; _serial_defs_only

;+++++        
;       Defines/constant to be included both local and global normally
pin/bit definitions
;       and constants related to module only

;+++++
;       Internal usart flags in UART_Flags
;        
#define _RxBufferOverrunErr UART_Flags,0 ; error flag set when buffer is
full for rx buffer
#define _RxParityErr      UART_Flags,1 ; error flag set when incorrect
parity is received
#define _RxOverrunErr     UART_Flags,2 ; h/w overrun flag set when
overrun of uart is detected
#define _RxFramingErr     UART_Flags,3 ; h/w framing error set when
incorrect framing is detected
#define _TxBufferOverrunErr UART_Flags,4 ; error flag set when buffer is
full for tx buffer
#define _TxBufferStopped  UART_Flags,6 ; timeout during wait for buffer
emptying, also disables further sending

#endif

<<<<<<<<<<<<cut>>>>>>>>>>>>>>>


Now the thing is that each external module that need access to the
serial module only
need to include the line '#include <SERIAL.INC>' to access all 'EXTERN'
routines or ram.
The 'trick' with using the *_defs_only define is to get around multiple
declarations
of the same routine/ram (gives errors by the assembler/linker).
This way you can have flags (bits) defined in one location only (inc
file) and this is used both for the local module and global use.

For me this structure gives alot of benefits, pins etc are defined at
one location only,
each module have their flags etc at one location only etc. And I get as
an bonus
alot of modularity.

I hope i managed to explain my thoughts.

/Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2002\12\17@012500 by Quentin

flavicon
face
Thanks Tony!
Yes, that is the way I was hoping to do it.
Will give it a try today.

--
Quentin
RemoveMEqscspam_OUTspamKILLspamiptech.co.za
http://www.iptech.co.za

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu>

More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...