Exact match. Not showing close matches.
PICList
Thread
'[PIC] The "CODE" directive'
2005\09\17@152709
by
Sean Schouten
Good evening my friends,
I was reading the MPASM help file and looking at the assembler directives; specifically the RES-Directive. There they have the following code example:
[CODE]
#include p18f452.inc ;Include standard header file
;for the selected device.
UDATA ;This directive allows the
;following data to be placed only
;in the data area.
perimeter res 2 ;Two locations of memory are
;reserved for the label
;'perimeter'. Addresses of the
;memory locations will be
;allocated by MPLINK.
length res 1 ;One location of memory is
;reserved for the label 'length'.
;Address of the memory location
;will be allocated by MPLINK.
width res 1 ;One location of memory is
;reserved for the label 'width'.
;Address of the memory location
;will be allocated by MPLINK.
Start CODE 0x0000 ;Following code will be placed in
;address 0.
[/CODE]
Looking at the last line of code where the CODE-Directive had been utilized, I wondered if they where defining the label START as an ORG 0x00 type of thing for later use in their code. The UDATA at the top threw me off though... I supposed that any UDATA-Directive should be 'finished' off by a CODE-Directive. Am I wrong thinking that?
The thing is that my main program code is at the bottom of the source, and usually where I put my ORG 0x00. If I where to implement the above code in my code, would I replace the ORG 0x00 in the main program code with a simple "Start"-label?
I also presumed that the UDATA-Directive that comes before the RES-directives is a must?
Ah, a last-minute addition to this email: MPASM is complaining that I am using CODE and UDATA in my ASM and telling me that I can only use them when generating an object file... Does that mean that I am not thought of as a likable person in this absolutely MAD world?
Thanks,
Sean.
2005\09\17@155915
by
Jan-Erik Soderholm
Sean Schouten wrote :
> Good evening my friends,
>
> I was reading the MPASM help file and looking at the
> assembler directives;
> specifically the RES-Directive. There they have the following
> code example:
[snipped a bit leaving the rellevant parts...]
{Quote hidden}> UDATA ;This directive allows the
> ;following data to be placed only
> ;in the data area.
>
> length res 1 ;One location of memory is
> width res 1 ;One location of memory is
>
> Start CODE 0x0000 ;Following code will be placed in
> ;address 0.
>
>
> Looking at the last line of code where the CODE-Directive had
> been utilized,
> I wondered if they where defining the label START as an ORG
> 0x00 type of thing for later use in their code.
The CODE directive starts a new "code section". In *this* case
they also specifed a specific program memory address, which
is optional but not unusual when it comes the "reset-point".
But I'd not say "for later use in the code". What do you mean
with that ?
> The UDATA at the top threw me off
> though... I supposed that any UDATA-Directive should be
> 'finished' off by a CODE-Directive.
Right, and it does. Each section (code or data) will be
implicitly ended when starting a new section (code or data)
using the UDATA (or one of it's relatives) or CODE directives.
>
> The thing is that my main program code is at the bottom of
> the source, and usually where I put my ORG 0x00. If I where to
implement the
> above code in my code, would I replace the ORG 0x00 in the main
program
> code with a simple "Start"-label?
You can mix your CODE sections as you like in the source, just don't
put any hardcoded address on any other section then your "reset-
section".
The linker (MPLINK) will sort it out...
> I also presumed that the UDATA-Directive that comes before the
> RES-directives is a must?
I don't think so, if you have s subroutine a bit down in your source
code, you can use an UDATA directive right before it to allocate
any RAM variables you need.
Note that if you have more then one UDATA (or CODE) directive
in one source file (called "module" in MPASM language) they must
have unique names (like "Start" in your example) I think that you
should make it a habit to always put names on all sections, that
makes it much easier to read the MAP file.
> Ah, a last-minute addition to this email: MPASM is
> complaining that I am using CODE and UDATA in my ASM
> and telling me that I can only use them when
> generating an object file...
You have not added a "linker script" to your MPLAB project.
So MPLAB tells MPASM that you're using absolute mode
code, which you aren't...
> Does that mean that I am not thought of as a
> likable person in this absolutely MAD world?
He, I doubt MPASM have any idea whatsoever about that ! :-) :-)
Jan-Erik.
2005\09\17@155915
by
WH Tan
|
Hi,
On 9/18/05, Sean Schouten wrote:
> Looking at the last line of code where the CODE-Directive had been utilized,
> I wondered if they where defining the label START as an ORG 0x00 type of
> thing for later use in their code. The UDATA at the top threw me off
> though... I supposed that any UDATA-Directive should be 'finished' off by a
> CODE-Directive. Am I wrong thinking that?
No, not really must follow this way. But it's a good idea to keep all
the relevant code and RAM in the same module, right? In a big
project, you might have several module (ASM) files, and I think it's a
good idea to place all code with relevant UDATA together.
> The thing is that my main program code is at the bottom of the source, and
> usually where I put my ORG 0x00. If I where to implement the above code in
> my code, would I replace the ORG 0x00 in the main program code with a simple
> "Start"-label?
I not sure what you mean here... but normally I will have
RESET_V code 0x00000
Start:
; instructions go here
goto main ; an example!
> I also presumed that the UDATA-Directive that comes before the
> RES-directives is a must?
Not really. If your module (ASM code) don't need any RAM, then you
could ignore that.
> Ah, a last-minute addition to this email: MPASM is complaining that I am
> using CODE and UDATA in my ASM and telling me that I can only use them when
> generating an object file... Does that mean that I am not thought of as a
> likable person in this absolutely MAD world?
Most likely, you didn't add the linker script to your project. Have you?
Best regards,
--
WH Tan
2005\09\17@160059
by
John Nall
Sean Schouten wrote:
>Good evening my friends,
>
>
Good evening. Use the supplied template files for such stuff and your
life will be happier, your digestion will be smoother, and your chances
of winning the lottery will improve remarkably.
John
2005\09\17@160125
by
olin piclist
Sean Schouten wrote:
> Looking at the last line of code where the CODE-Directive had been
> utilized, I wondered if they where defining the label START as an ORG
> 0x00 type of thing for later use in their code. The UDATA at the top
> threw me off though... I supposed that any UDATA-Directive should be
> 'finished' off by a CODE-Directive. Am I wrong thinking that?
Read about UDATA and CODE in the MPASM manual. UDATA defines an
uninitialized data section, wherease CODE defines a code section. You would
typically put RES directives in a UDATA section and instructions in a CODE
section.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\18@143105
by
Sean Schouten
>
> Read about UDATA and CODE in the MPASM manual. UDATA defines an
> uninitialized data section, wherease CODE defines a code section. You
> would
> typically put RES directives in a UDATA section and instructions in a CODE
> section.
I was reading up on them in the MPASM documentation that I found under MPLAB's help-file. It just didn'n make too much sense to me... But I think I am starting to understand it all now, thanks. I shall experiment a little more as soon as I get back home (I am currently abroad for 3-days).
> Use the supplied template files for such stuff and your
> life will be happier, your digestion will be smoother, and your chances
> of winning the lottery will improve remarkably.
> Hmmm, that does sound real tempting!
Thanks,
Sean
2005\09\19@004257
by
kravnus wolf
I have played with the linker the FIRST time last
nite......
Rule of thumb!
1) the linker aint gcc....
2) all section is relocatable! I don't beleive you
can hardcore the section address and get the linker
to work.
3) remember export symbol......... so that the
label is callable by other object files.
4) STILL aint GCC!!!!!
zzzzzzzzzzzzzzzz.
john
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
2005\09\19@061038
by
kravnus wolf
i stand corrected with (2). it can be assigned to an
absolute address... It will override the linker
settings.
Use the xxxxx.lkr template. It helps a lot. Remember
to remove PROTECTED while experimenting.
John
--- kravnus wolf <spam_OUTkravnusTakeThisOuT
yahoo.com> wrote:
{Quote hidden}> I have played with the linker the FIRST time last
> nite......
>
> Rule of thumb!
> 1) the linker aint gcc....
> 2) all section is relocatable! I don't beleive you
> can hardcore the section address and get the
> linker
> to work.
> 3) remember export symbol......... so that the
> label is callable by other object files.
> 4) STILL aint GCC!!!!!
>
> zzzzzzzzzzzzzzzz.
> john
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
>
http://mail.yahoo.com
> --
2005\09\19@063530
by
Jan-Erik Soderholm
kravnus wolf wrote :
> I have played with the linker the FIRST time last
> nite......
>
> Rule of thumb!
>
> 1) the linker aint gcc....
> ...
> ...
> 4) STILL aint GCC!!!!!
>
> zzzzzzzzzzzzzzzz.
> john
And ?
What I'm I missing ???
Do I need to know what GCC is
to understand this ?
Jan-Erik.
2005\09\19@064340
by
Peter Onion
On Mon, 2005-09-19 at 03:10 -0700, kravnus wolf wrote:
> Use the xxxxx.lkr template. It helps a lot. Remember
> to remove PROTECTED while experimenting.
I don't understand why you say this is necessary ?
Peter
2005\09\19@064906
by
Alan B. Pearce
>> Use the supplied template files for such stuff and
>> your life will be happier, your digestion will be
>> smoother, and your chances of winning the lottery
>> will improve remarkably.
>
> Hmmm, that does sound real tempting!
> Thanks,
> Sean
Well I don't know about improving lottery chances, but look at Olins module
templates in his development environment at http://www.embedinc.com/pic/ as
his whole environment is geared around the relocatable code.
2005\09\19@065243
by
Alan B. Pearce
>2) all section is relocatable! I don't beleive you
> can hardcore the section address and get the linker
> to work.
You can hardcode the address of a code section. Look at how Olin does it for
the start address and interrupt code section in his environment at
http://www.embedinc.com/pic/
2005\09\19@071855
by
John J. McDonough
----- Original Message -----
From: "Peter Onion" <.....ponionKILLspam@spam@alien.bt.co.uk>
Subject: Re: [PIC] The "CODE" directive
>> Use the xxxxx.lkr template. It helps a lot. Remember
>> to remove PROTECTED while experimenting.
>
> I don't understand why you say this is necessary ?
Just gives you a little more flexibility in the .asm code. Whether it makes
sense or not depends, I suppose, on whether you want your dependencies in
the .lkr file or the .asm file. But if you have a PROTECTED section in the
.lkr file, then you can't place another section there in the .asm file. So
I suppose the operative words there are "while experimenting". Kravnus
evidently likes the dependencies in the .asm file.
--McD
2005\09\19@074051
by
olin piclist
kravnus wolf wrote:
> 2) all section is relocatable! I don't beleive you
> can hardcore the section address and get the linker
> to work.
Of course you can. Read the description of the CODE directive.
> 3) remember export symbol......... so that the
> label is callable by other object files.
Of course. What do you expect? Exporting and importing global symbols is
nothing new. Microchip hasn't done anything unusual in this area. I'd be
real amazed if the linker that comes with GCC doesn't deal with global
symbols nearly identically.
> 4) STILL aint GCC!!!!!
I've never used GCC, which I thought was a C compiler and not a linker
anyway. If it's like other C compilers, then it may invoke the linker for
you in some cases.
Anyway, MPLINK is fairly primitive and simple as linkers go, and doesn't
really do anything unusual. I suspect your real problem is not
understanding linkers in general. The fact that you compare MPLINK to GCC
indicates that you've only run other linkers implicitly and never looked at
what was going on under the hood.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\19@075129
by
olin piclist
kravnus wolf wrote:
> Use the xxxxx.lkr template. It helps a lot. Remember
> to remove PROTECTED while experimenting.
The microchip templates have a few problems and outright stupidities. I
think my templates are a lot better. If you install my PIC development
environment at http://www.embedinc.com/pic the templates will be in the
SOURCE > PIC directory all names xxxx.linkpic.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\19@075343
by
olin piclist
Peter Onion wrote:
>> Use the xxxxx.lkr template. It helps a lot. Remember
>> to remove PROTECTED while experimenting.
>
> I don't understand why you say this is necessary ?
Because Microchip did some bone headed things in their linker file
templates. Remember Rule 1.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\19@075430
by
John J. McDonough
----- Original Message -----
From: "Olin Lathrop" <olin_piclistKILLspamembedinc.com>
Subject: Re: [PIC] The "CODE" directive
> kravnus wolf wrote:
>> 4) STILL aint GCC!!!!!
>
> I've never used GCC, which I thought was a C compiler and not a linker
> anyway. If it's like other C compilers, then it may invoke the linker for
> you in some cases.
Thank heavens it ain't gcc (well, ld). Any linker with a 50 screen man
page(!)
--McD
2005\09\19@075546
by
Peter Onion
On Mon, 2005-09-19 at 07:18 -0400, John J. McDonough wrote:
>
> Just gives you a little more flexibility in the .asm code. Whether it makes
> sense or not depends, I suppose, on whether you want your dependencies in
> the .lkr file or the .asm file. But if you have a PROTECTED section in the
> .lkr file, then you can't place another section there in the .asm file. So
> I suppose the operative words there are "while experimenting". Kravnus
> evidently likes the dependencies in the .asm file.
I must be missing something here because all the .lkr files I've used
have PROTECTED sections defined for areas that can't be used (like the
SFRs). In the code space it is used for Config/fuese areas.
Peter
2005\09\19@080519
by
Peter Onion
On Mon, 2005-09-19 at 07:53 -0400, Olin Lathrop wrote:
> Peter Onion wrote:
> >> Use the xxxxx.lkr template. It helps a lot. Remember
> >> to remove PROTECTED while experimenting.
> >
> > I don't understand why you say this is necessary ?
>
> Because Microchip did some bone headed things in their linker file
> templates. Remember Rule 1.
AH, ok. I 've only used a couple of them so I guess I must have been
lucky not to come across any major "bone headedness".
Peter
2005\09\19@081207
by
olin piclist
Peter Onion wrote:
> I must be missing something here because all the .lkr files I've used
> have PROTECTED sections defined for areas that can't be used (like the
> SFRs). In the code space it is used for Config/fuese areas.
No, you're not missing anything. That's what PROTECTED is for (other than
SFR ranges shouldn't be in the linker file in the first place).
Unfortunately the 5th grade dropout Microchip had write their template
linker files doesn't understand it, and a lot of other things too.
Just remember Rule 1 and don't waste time with the Microchip templates.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\19@081750
by
olin piclist
Peter Onion wrote:
> AH, ok. I 've only used a couple of them so I guess I must have been
> lucky not to come across any major "bone headedness".
They weren't so bad in older versions of MPLAB, so you might not have run
into this if it was a while ago.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\19@083332
by
Xiaofan Chen
Any examples with the bad linker script? It is better to give some examples
and feedback to Microchip.
Regards,
Xiaofan
On 9/19/05, Olin Lathrop <.....olin_piclistKILLspam.....embedinc.com> wrote:
>
> They weren't so bad in older versions of MPLAB, so you might not have run
> into this if it was a while ago.
>
2005\09\19@094945
by
olin piclist
Xiaofan Chen wrote:
> Any examples with the bad linker script? It is better to give some
> examples and feedback to Microchip.
They've heard this from me plenty of times.
Dissecting Microchip's examples is usually a waste of time (See Rule 1), but
OK, here is an excerpt of the 16F876 linker file template from MPLAB 7.20:
> CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED
> CODEPAGE NAME=page0 START=0x5 END=0x7FF
This is galactically stupid no matter how you look at it! It doesn't
accomplish what I think the moron writing it was trying to, and causes
serious harm. Note that the interrupt service routine has exactly one
instruction before it ends up in a different memory region. There is no
useful interrupt routine that is only one instruction long. And, you can't
even jump from there to an interrupt routine elsewhere since this PIC has 4
code pages and the PCLATH setting is therefore unknown on interrupt. An
interrupt routine *can't* go anywhere until PCLATH is known, which means it
has to be saved first, which means W was to be saved first, which probably
means STATUS needs to be saved first too. How are you supposed to do all
than in one instruction!!?
Of course the best strategy for an interrupt routine is to put it right at
the interrupt vector (4) in the first place. Some code will end up there,
and it might as well be the interrupt code since it saves a couple of cycles
and at least one instruction. However you will get a "can't fit section"
error from the linker if you try this (not that there is anything you can
try that will work).
And why does the reset vector region need to PROTECTED in the first place?
The linker will place any sections at fixed addresses first. The reset code
should be in a fixed section starting at 0 and the interrupt code at a fixed
section starting at 4. Other relocatable sections will be fit around them
as possible. If the reset code happens to take less than 4 instructions,
what's the harm letting a short relocatable section use the rest? If the
fixed sections collide (reset code more than 4 instructions with interrupt
section starting at 4) then the linker will give an error anyway. PROTECTED
doesn't help there either.
What about a project that doesn't use interrupts? Now you've got an
artificial break after 5 instructions into the reset routine. The linker
will complain that it couldn't fit the section if the reset routine is more
than 5 instructions long, even though there is nothing wrong with that if
interrupts are not being used.
The right answer of course is to leave each page as a whole memory region.
Unfortunately the Example Code Moron just couldn't resist using all those
fancy features. I guess they looked too cool and made the manager think he
was real edjumacated.
> CODEPAGE NAME=page1 START=0x800 END=0xFFF
> CODEPAGE NAME=page2 START=0x1000 END=0x17FF
> CODEPAGE NAME=page3 START=0x1800 END=0x1FFF
> CODEPAGE NAME=.idlocs START=0x2000 END=0x2003 PROTECTED
> CODEPAGE NAME=.config START=0x2007 END=0x2007 PROTECTED
> CODEPAGE NAME=eedata START=0x2100 END=0x21FF PROTECTED
Finally a proper use of PROTECTED. You don't want arbitrary code ending up
in EEPROM or the ID locations if you don't explicitly specify them.
> DATABANK NAME=sfr0 START=0x0 END=0x1F PROTECTED
> DATABANK NAME=sfr1 START=0x80 END=0x9F PROTECTED
> DATABANK NAME=sfr2 START=0x100 END=0x10F PROTECTED
> DATABANK NAME=sfr3 START=0x180 END=0x18F PROTECTED
More stupidity. SFR regions shouldn't be in the linker file at all. At
least they are protected so that ordinary variables won't end up there by
accident. However, if someone tries to put a variable at a fixed address
and accidentally types in the address of an SFR the linker won't complain.
This could happen, for example, if someone did a half-assed job of
converting old absolute code to relocatable from a PIC where available RAM
started before 20h. Granted that would be the result of a mistake, but
defining SFR regions does nothing useful and makes the linker incapable of
catching such mistakes.
{Quote hidden}> DATABANK NAME=gpr0 START=0x20 END=0x6F
> DATABANK NAME=gpr1 START=0xA0 END=0xEF
> DATABANK NAME=gpr2 START=0x110 END=0x16F
> DATABANK NAME=gpr3 START=0x190 END=0x1EF
>
> SHAREBANK NAME=gprnobnk START=0x70 END=0x7F
> SHAREBANK NAME=gprnobnk START=0xF0 END=0xFF
> SHAREBANK NAME=gprnobnk START=0x170 END=0x17F
> SHAREBANK NAME=gprnobnk START=0x1F0 END=0x1FF
>
> SECTION NAME=STARTUP ROM=vectors // Reset and interrupt vectors
> SECTION NAME=PROG1 ROM=page0 // ROM code space - page0
> SECTION NAME=PROG2 ROM=page1 // ROM code space - page1
> SECTION NAME=PROG3 ROM=page2 // ROM code space - page2
> SECTION NAME=PROG4 ROM=page3 // ROM code space - page3
> SECTION NAME=IDLOCS ROM=.idlocs // ID locations
> SECTION NAME=CONFIG ROM=.config // Configuration bits location
> SECTION NAME=DEEPROM ROM=eedata // Data EEPROM
And where is the section for the shared memory in the last 16 bytes of each
bank?
Again, this is a waste of time. See Rule 1 and move on. I strongly suggest
using my own linker file templates over the mess Micrcochip provides.
Install my PIC development environment at http://www.embedinc.com/pic and
the linker templates will be in the SOURCE > PIC directory.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\19@211316
by
kravnus wolf
you don't actually need to know ld(linker)
which is so fonding called by the lovely gcc compiler.
Just that what you know of the ld linker is NOT
quite the same with mplink.
The are similarity between them like relocatable
code and data but the implementation are
quite different.
regards,
john
--- Jan-Erik Soderholm <EraseMEjan-erik.soderholmspam_OUTTakeThisOuTtelia.com>
wrote:
{Quote hidden}> kravnus wolf wrote :
>
> > I have played with the linker the FIRST time last
> > nite......
> >
> > Rule of thumb!
> >
> > 1) the linker aint gcc....
> > ...
> > ...
> > 4) STILL aint GCC!!!!!
> >
> > zzzzzzzzzzzzzzzz.
> > john
>
> And ?
> What I'm I missing ???
> Do I need to know what GCC is
> to understand this ?
>
> Jan-Erik.
>
>
>
> --
2005\09\19@211750
by
kravnus wolf
removing PROTECTED is necessary b'cos you may assign
and object(data/code) to the memory region.
Example
udata ;relocatable by the mplinker
tmp1 res 1 ; assigns a byte of memory in the SFR
If all the SFR is PROTECTED, the linker would
report an error. B'cos there is no place to
put the tmp1 variable in the SFR.
Hope this clears is up.
John
--- Peter Onion <ponionspam_OUTalien.bt.co.uk> wrote:
{Quote hidden}> On Mon, 2005-09-19 at 03:10 -0700, kravnus wolf
> wrote:
>
> > Use the xxxxx.lkr template. It helps a lot.
> Remember
> > to remove PROTECTED while experimenting.
>
> I don't understand why you say this is necessary ?
>
> Peter
>
>
>
> --
2005\09\19@214539
by
kravnus wolf
|
>
> > 3) remember export symbol......... so that the
> > label is callable by other object files.
>
> Of course. What do you expect? Exporting and
> importing global symbols is
> nothing new. Microchip hasn't done anything unusual
> in this area. I'd be
> real amazed if the linker that comes with GCC
> doesn't deal with global
> symbols nearly identically.
all linkers can support export symbols. The point I
was trying to get at was the fact that it allows code
reusablility.
>
> > 4) STILL aint GCC!!!!!
>
> I've never used GCC, which I thought was a C
> compiler and not a linker
> anyway. If it's like other C compilers, then it may
> invoke the linker for
> you in some cases.
>
true.
> Anyway, MPLINK is fairly primitive and simple as
> linkers go, and doesn't
> really do anything unusual. I suspect your real
> problem is not
> understanding linkers in general. The fact that you
> compare MPLINK to GCC
> indicates that you've only run other linkers
> implicitly and never looked at
> what was going on under the hood.
>
I have been trying to compare the mplink with the
other linkers I know. the problem maybe due to the
fact is ALL the linkers I knew was for the X86.
And yes ld is very different from the mplink
in naming convention. mplink has protected while ld is
RO(read only)
regards,
John
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
2005\09\20@033225
by
Jan-Erik Soderholm
kravnus wolf wrote :
> Example
>
> udata ;relocatable by the mplinker
> tmp1 res 1 ; assigns a byte of memory in the SFR
Does it ?
I'm not sure I follow here...
> If all the SFR is PROTECTED, the linker would
> report an error. B'cos there is no place to
> put the tmp1 variable in the SFR.
And why would you need to put
a variable in the *SFR* area ???
Regards,
Jan-Erik.
2005\09\20@050829
by
Peter Onion
On Mon, 2005-09-19 at 18:17 -0700, kravnus wolf wrote:
> removing PROTECTED is necessary b'cos you may assign
> and object(data/code) to the memory region.
>
> Example
>
> udata ;relocatable by the mplinker
> tmp1 res 1 ; assigns a byte of memory in the SFR
>
> If all the SFR is PROTECTED, the linker would
> report an error. B'cos there is no place to
> put the tmp1 variable in the SFR.
>
>
> Hope this clears is up.
No, it shows you don't seem to have understood what is going on !
There are already symbols and names defined for all the SFRs in the
header files so you should not be trying to rename them or put your own
variables in the PROTECTED SFR region. As Olin has pointed out it would
make more sense if the SFR regions were not even mentioned in the .lkr
files.
Are you using the correct header files for the PIC you are programing ?
Peter
2005\09\20@052531
by
Chen Xiao Fan
|
This is because the linker script is supposed not to be used with
this linker script.
C:\Program Files\Microchip\MPASM Suite\Template\Object\f876atempo.asm
Aparently 16f876 becomes matured and the f876tmpo.asm got some
errors inside. Therefore I take f876atempo.asm and put the
header file here.
I know that there are lots of errors in the files of MPLAB installation.
Still "galactically stupid" and "moron" are too strong words.
One more thing, if you count the total number of linkpic files in the
latest Embedinc programming environment, it is 35! There are 520 linker
script files in the MPLAB 7.10 installation!
Regards,
Xiaofan
;**********************************************************************
; This file is a basic code template for object module code *
; generation on the PICmicro PIC16F876A. This file contains the *
; basic code building blocks to build upon. As a project minimum *
; the 16F876A.lkr file will also be required for this file to *
; correctly build. The .lkr files are located in the MPLAB *
; directory. *
; *
; If interrupts are not used all code presented between the *
; code section "INT_VECTOR and code section "MAIN" can be removed. *
; In addition the variable assignments for 'w_temp' and *
; 'status_temp' can be removed. *
; *
; If interrupts are used, as in this template file, the 16F876A.lkr *
; file will need to be modified as follows: Remove the lines *
; CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED *
; and *
; SECTION NAME=STARTUP ROM=vectors *
; and change the start address of the page0 section from 0x5 to 0x0 *
*
; *
; Refer to the MPASM User's Guide for additional information on *
; features of the assembler and linker (Document DS33014). *
; *
; Refer to the respective PICmicro data sheet for additional *
; information on the instruction set. *
; *
;**********************************************************************
{Original Message removed}
2005\09\20@064844
by
Xiaofan Chen
Sorry the first sentence should be as following.
"This is because the linker script is supposed not to be used with
interrupts."
On 9/20/05, Chen Xiao Fan <@spam@xiaofanKILLspamsg.pepperl-fuchs.com> wrote:
{Quote hidden}> This is because the linker script is supposed not to be used with
> this linker script.
>
> C:\Program Files\Microchip\MPASM Suite\Template\Object\f876atempo.asm
>
> Aparently 16f876 becomes matured and the f876tmpo.asm got some
> errors inside. Therefore I take f876atempo.asm and put the
> header file here.
>
> I know that there are lots of errors in the files of MPLAB installation.
> Still "galactically stupid" and "moron" are too strong words.
>
> One more thing, if you count the total number of linkpic files in the
> latest Embedinc programming environment, it is 35! There are 520 linker
> script files in the MPLAB 7.10 installation!
>
> Regards,
> Xiaofan
2005\09\20@070046
by
kravnus wolf
|
|
Yes I am using the correct linker template.
Yes I am wrong and Olin is right. SFR should
not be used for data but there are holes(General
purpose registers) in SFR
that we can use to place variables. Yes is it
dangerous if you go out of the variable b'cos it may
hit other register in the SFR.
The safest best is EEPROM.
John
--- Peter Onion <KILLspamponionKILLspamalien.bt.co.uk> wrote:
{Quote hidden}> On Mon, 2005-09-19 at 18:17 -0700, kravnus wolf
> wrote:
> > removing PROTECTED is necessary b'cos you may
> assign
> > and object(data/code) to the memory region.
> >
> > Example
> >
> > udata ;relocatable by the mplinker
> > tmp1 res 1 ; assigns a byte of memory in the
> SFR
> >
> > If all the SFR is PROTECTED, the linker would
> > report an error. B'cos there is no place to
> > put the tmp1 variable in the SFR.
> >
> >
> > Hope this clears is up.
>
> No, it shows you don't seem to have understood what
> is going on !
>
> There are already symbols and names defined for all
> the SFRs in the
> header files so you should not be trying to rename
> them or put your own
> variables in the PROTECTED SFR region. As Olin has
> pointed out it would
> make more sense if the SFR regions were not even
> mentioned in the .lkr
> files.
>
> Are you using the correct header files for the PIC
> you are programing ?
>
> Peter
>
>
>
>
> --
2005\09\20@070852
by
kravnus wolf
--- Jan-Erik Soderholm <RemoveMEjan-erik.soderholmTakeThisOuTtelia.com>
wrote:
{Quote hidden}> kravnus wolf wrote :
>
> > Example
> >
> > udata ;relocatable by the mplinker
> > tmp1 res 1 ; assigns a byte of memory in the
> SFR
>
> Does it ?
> I'm not sure I follow here...
>
> > If all the SFR is PROTECTED, the linker would
> > report an error. B'cos there is no place to
> > put the tmp1 variable in the SFR.
>
> And why would you need to put
> a variable in the *SFR* area ???
>
you can store a variable in data area away from the
SFR . Thanks for pointing out the error.
john
> Regards,
> Jan-Erik.
>
>
>
> --
2005\09\20@071459
by
kravnus wolf
|
|
Too actually think about it, in the linker template
SFR region == page region..........
ARgh.............
Sorry there, it is not SFR but general purpose
registers...... They even map the general purpose
registers region as protected!
John
--- Peter Onion <spamBeGoneponionspamBeGonealien.bt.co.uk> wrote:
{Quote hidden}> On Mon, 2005-09-19 at 18:17 -0700, kravnus wolf
> wrote:
> > removing PROTECTED is necessary b'cos you may
> assign
> > and object(data/code) to the memory region.
> >
> > Example
> >
> > udata ;relocatable by the mplinker
> > tmp1 res 1 ; assigns a byte of memory in the
> SFR
> >
> > If all the SFR is PROTECTED, the linker would
> > report an error. B'cos there is no place to
> > put the tmp1 variable in the SFR.
> >
> >
> > Hope this clears is up.
>
> No, it shows you don't seem to have understood what
> is going on !
>
> There are already symbols and names defined for all
> the SFRs in the
> header files so you should not be trying to rename
> them or put your own
> variables in the PROTECTED SFR region. As Olin has
> pointed out it would
> make more sense if the SFR regions were not even
> mentioned in the .lkr
> files.
>
> Are you using the correct header files for the PIC
> you are programing ?
>
> Peter
>
>
>
>
> --
2005\09\20@073110
by
John J. McDonough
----- Original Message -----
From: "kravnus wolf" <TakeThisOuTkravnusEraseMEspam_OUTyahoo.com>
Subject: Re: [PIC] The "CODE" directive
> ARgh.............
> Sorry there, it is not SFR but general purpose
> registers...... They even map the general purpose
> registers region as protected!
Which processor has that "feature"?? I haven't run across that.
Maybe it doesn't matter. I'm not so sure you ever want to use Mchip's lkr
files unadulterated anyway. Seems like most of them have some sort of error
or at least an undesireable feature.
--McD
2005\09\20@074158
by
Jan-Erik Soderholm
Xiaofan Chen wrote :
> Sorry the first sentence should be as following.
> "This is because the linker script is supposed not to be used with
> interrupts."
Becuse it doesn't have any *named* code-section at the
interrupt vector address ?
That doesn't stop it from beeing used with interrupts, of course,
just put the interrupt verctor address in your CODE directive
instead and the linker will put the ISR where it belongs.
Yes, this makes the code a *little* less portable between
different PIC architectures where the interrupt vector
address are on different address (e.g. PIC16 vs. PIC18), but
that's a minor problem, IMHO.
Jan-Erik.
>
2005\09\20@074818
by
olin piclist
Chen Xiao Fan wrote:
> One more thing, if you count the total number of linkpic files in the
> latest Embedinc programming environment, it is 35! There are 520 linker
> script files in the MPLAB 7.10 installation!
Yes, but the 35 are a great deal for the price. I make linker files as I
need them whereas Microchip supplies a linker file for each PIC. However,
I've got enough existing linker files that making one for a new PIC is
pretty trivial. I usually start with the 16F876 or 18F252 linker file and
delete the parts that don't apply and adjust the memory ranges accordingly
while looking in the manual for that particular PIC. If I haven't gotten to
a PIC before you want a linker file for it, it will take you a lot less time
to do the same than to mess around with Microchip's broken one.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\20@074853
by
Jan-Erik Soderholm
kravnus wolf wrote :
> ...but there are holes(General purpose registers)
> in SFR that we can use to place variables.
I have never seen that.
Do you have an example device where
there are "holes" in the SFR area that can be used
to "place variables" ?
Or maybe I'm missunderstanding
what you're saying, quite possible... :-)
Regards,
Jan-Erik.
2005\09\20@075308
by
olin piclist
Chen Xiao Fan wrote:
> ; If interrupts are used, as in this template file, the 16F876A.lkr *
> ; file will need to be modified as follows: Remove the lines *
> ; CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED *
> ; and *
> ; SECTION NAME=STARTUP ROM=vectors *
> ; and change the start address of the page0 section from 0x5 to 0x0 *
So why, oh why, are these lines there in the first place!!? There is no
case then they *DO* apply. This sounds like one part of Microchip making
excuses for something another part did. You don't like the term
"gallactially stupid", so I'm at a loss how to describe this.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\20@080452
by
olin piclist
Xiaofan Chen wrote:
> Sorry the first sentence should be as following.
> "This is because the linker script is supposed not to be used with
> interrupts."
See my other post for why this is silly (Microchip's structure, not your
explanation of it). Note that my linker files work equally well whether you
use interrupts or not. In fact its very rare that I have to modify a linker
file for a particular project from the generic version for that PIC. If you
use my environment, you won't be spending much time thinking about linker
files. They "just work" in the vast majority of cases.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\20@080910
by
olin piclist
Jan-Erik Soderholm wrote:
>> "This is because the linker script is supposed not to be used with
>> interrupts."
>
> Becuse it doesn't have any *named* code-section at the
> interrupt vector address ?
No, because they put locations 4 and 5 in different memory regions. You
can't create an absolute section starting at the interrupt vector that is
more than one instruction long. (I still don't understand how
"gallactically stupid" doesn't apply here.)
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\20@082744
by
John J. McDonough
----- Original Message -----
From: "Olin Lathrop" <RemoveMEolin_piclistTakeThisOuTembedinc.com>
Subject: Re: [PIC] The "CODE" directive
> more than one instruction long. (I still don't understand how
> "gallactically stupid" doesn't apply here.)
It's not "gallactically stupid" because it forces you to edit the .lkr file,
which you probably should do anyway. In many cases, the alternative is to
put the memory dependencies in the source code, making it non-portable.
Better, in my mind, to edit the .lkr file and leave the source clean so it
can be used in other contexts.
What is "gallactically stupid" is taking a file from Microchip and assuming
it to be without errors.
--McD
2005\09\20@092115
by
olin piclist
John J. McDonough wrote:
> It's not "gallactically stupid" because it forces you to edit the .lkr
> file, which you probably should do anyway.
I disagree. In the vast majority of cases I can use my generic linker files
and not give them a second thought.
> In many cases, the
> alternative is to put the memory dependencies in the source code,
> making it non-portable. Better, in my mind, to edit the .lkr file and
> leave the source clean so it can be used in other contexts.
The only memory dependencies that end up in the source code is that the
reset location is 0 and the interrupt vector is 4. You can't just blindly
port interrupt code between a PIC 16 and PIC 18 anyway. I deal with this by
having different interrupt templates for the two architectures. These
templates specify the absolute addresses of the interrupt vectors. Porting
interrupt code between these two means copying the user-added part from
around the template and pasting it into the other template. There are
significant differences in the template code (hence two templates) so you
couldn't and wouldn't want to port them anyway. You can see the two
templates QQQ_INTR.ASPIC and QQQ_INTR18.ASPIC at
http://www.embedinc.com/pic.
In any case, how is a linker file going to insulate you from reset and
interrupt vector address changes without causing other problems anyway? You
can't define arbitrary symbols in the linker file, only section names which
have to refer to unique and non-overlapping address ranges. Even if you
create a section called .RESET and start it at location 0 and declare it
PROTECTED, how long do you make it? Either you end up making it too short
and your actual code won't fit, or you make it too long and the remaining
space gets wasted. If you don't use PROTECTED, then there is no way to
guarantee the code starts at the reset vector without a specific address in
the source file.
And interrupts have the same issue but make this more complicated because
the interrupt vector is only 4 locations past the start of the reset
routine.
If you want to symbolically define the reset and interrupt locations, then
these belong in the specific include file for the PIC, not the linker file.
> What is "gallactically stupid" is taking a file from Microchip and
> assuming it to be without errors.
Well yeah, keeping Rule #1 in mind. Unfortunately most newbies have to
learn Rule #1 the hard way. It's unfair to say it's stupid of them not to
know it, since after all it's not to be found in any Microchip
documentation.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
2005\09\20@094958
by
Jan-Erik Soderholm
John J. McDonough wrote :
> It's not "gallactically stupid" because it forces you to edit
> the .lkr file, which you probably should do anyway.
Anyway ? As in "always" ? Even if they are OK ?
> What is "gallactically stupid" is taking a file from
> Microchip and assuming it to be without errors.
I find that to be the most natural thing to do.
Exactly why should one not *expect* "a file from
Microchip" to be without errors ? (Besides of
that you *know* that a specific file is brooken,
of course...)
I've built reloc code for a number of
devices using the supplied linker scripts without
any problems at all. I've not even bothered to
look in them...
I try to learn PIC beginners to use reloc code, but
I've never told them that they should also edit the
linker script. Should I ?
The fact that some LKR's has some problems,
doesn't make them all brooken, does it ?
And the fact that Olin has adopted some LKR's
to his dev environment (and also fixed a few
errors at the same time), doesn't change
that either, IMHO
For the non-professional hobbyist developer,
I find it best to *try* to stick to the scripts
as supplied, that makes it easier to
exchange code with someone else...
Best Regards,
Jan-Erik.
2005\09\20@150632
by
Hopkins
Care to share some of your lessons on relocatable code?
_______________________________________
Roy
Tauranga
New Zealand
_______________________________________
>
> I try to learn PIC beginners to use reloc code, but
> I've never told them that they should also edit the
> linker script. Should I ?
>
> Best Regards,
> Jan-Erik.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date:
20/09/2005
2005\09\20@150758
by
James Newton, Host
2005\09\20@152710
by
Jan-Erik Soderholm
Hopkins wrote :
> Care to share some of your lessons on relocatable code?
Sure ! I didn't know you read Swedish... :-)
No, what I ment was that I show how to write reloc code
on forums and such. I have a Swedish web page which
compair abs and reloc code, but with no real code examples.
Anyway, you don't realy need any "lessons". It's just to
read up a little on UDATA, RES, CODE, GLOBAL, EXTERN
and a few other directives and get going. Maybe using
a few code examples. It's all in the MPASM docs.
Jan-Erik.
2005\09\20@205839
by
Chen Xiao Fan
Agreed. I think the supplied linker scripts are generally
speaking okay to use except for some applications like
bootloader.
For beginners of relocatable codes, I think the supplied
templates under the directory
"C:\Program Files\Microchip\MPASM Suite\Template\Object"
are also a good start.
Microchip documentation "MPASM User's Guide with MPLINK
and MPLIB" is also a good reference. Chapter 6 has only
a few pages to read but is already a good summary.
People only need to spend some hours on Chapter 5/6 and
play with some examples to learn the basics of
relocatable code.
Regards,
Xiaofan
{Original Message removed}
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- Today
- New search...
