Searching \ for '[PIC] RE: MPLAB v7.1 changes ?' 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/languages.htm?key=mplab
Search entire site for: 'RE: MPLAB v7.1 changes ?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] RE: MPLAB v7.1 changes ?'
2005\05\22@222924 by John Piccirillo

picon face
Thanks for bringing me up-to-date on relocatable code.
I do have the assembler/linker/librarian manual and have
looked at it but as is usually the case this is a reference
and not a tutorial and some of the discussion is only
comprehensible if one is already in the know.

{Quote hidden}

Sorry, a typo.  I did use INT_VECTOR     CODE    0x004 followed by
a simple ISR, just context saving, [code below] but the assembly error was:

Error - section 'INT_VECTOR' can not fit the absolute section.
Section 'INT_VECTOR' start=0x00000004, length=0x00000010

>The CODE is used anywhere where you wan't to start a new code segment.

  I hope you have the patience to tell me how that is used.  Where would
it be useful to have different CODE sections.

>You have some general confusion.  You need to ** READ THE MANUAL **.  In
>this case, that is the MPASM / MPLIB / MPLINK guide.  Understand what all
>the assembler directives do, and how they work with the linker.

Thanks for the help.  I'm not lazy and do look at the manuals first but
this is rather new to me and is not my area of training [which is physics
and astronomy] but I am interested and wish to replace chips like the
BasicX with PICs in my robotics projects.   I like the PIC simplicity,
elegance, speed, and control.

Please feel free to comment on the form of the code.  How do I treat
the portb equate, RES doesn't seem to work.   If I follow the interrupt
vector with a goto iserv and put the ISR down under Main Code, it
assembles.

   list      p=16F84
        #include <p16F84.inc>

INT_DATA                UDATA   0x0C
portb                   equ             0x06
w_temp          RES     1               ; variable used for context saving
status_temp             RES     1               ; variable used for context
saving

;**********************************************************************
RESET_VECTOR  CODE              0x000
                        goto    start

INT_VECTOR      CODE    0x004

                movwf   w_temp
                movf    STATUS,w
                movwf   status_temp

; isr code can go here or be located as a call subroutine elsewhere

                movf    status_temp,w
                movwf   STATUS            ;
                swapf   w_temp,f
                swapf   w_temp,w
                retfie

MAIN    CODE
start           movlw   0x00
                tris    portb
                movlw   0x0f
                movwf   portb

circle  goto    circle

                END

Thanks,

John Piccirillo



2005\05\23@024217 by Jan-Erik Soderholm

face picon face
John Piccirillo wrote :

> >Yes, since it has the same address as "RESET_VECTOR".
>
> Sorry, a typo.  I did use INT_VECTOR     CODE    0x004 followed by
> a simple ISR, just context saving, [code below] but the
> assembly error was:

OK. You better cut-n-paste in the future. Or review your posts
a second time before hitting send... :-)

> Error - section 'INT_VECTOR' can not fit the absolute section.
> Section 'INT_VECTOR' start=0x00000004, length=0x00000010

Of course, the section is 10 bytes (as the message above says)
and if you add more code then that, you get that message. No
problem with that.

> > The CODE is used anywhere where you wan't to start a new
> > code segment.
>
> I hope you have the patience to tell me how that is used.  
> Where would
> it be useful to have different CODE sections.

Different CODE sections will be separatly listed in the MAP file
so you get sizes calculated "for free".
Separatly CODE sections will be individualy placed in the program
memory by the linker. So one can place a hardcoded table in the
middle of the program address area, and the linker will nicely
spread the code segments around that.
If you arrange your source code using multiple ASM files, you
*must* have at least *one* CODE segment/diretive per file (but
can have more then one to make the "job" for the linker easier,
the code more structured and the output of the linker a bit more
"usuable").

> Please feel free to comment on the form of the code.  How do I treat
> the portb equate,

What is "the portb equate" ? PORTB is PORTB...

> RES doesn't seem to work.

RES have noting to to with the SFR's !
You use RES to allocate your variables from the GPR's ("RAM").

> If I follow the
> interrupt vector with a goto iserv and put the ISR down under Main Code,
it
> assembles.

As expected...

>
>     list      p=16F84
>          #include <p16F84.inc>

First, if you don't have any *specific* reason to use the
old/costly F84, make yourself a big favour and use
somthing modern. If it's for general PIC learning, maybe
a rather simple 16F628A would work (still can a lot more
then the F84 at half the price...).

>
> INT_DATA                UDATA   0x0C
> portb                   equ             0x06

PORTB is defined in p16F84.inc. Remove that EQU !!

> w_temp          RES     1               ; variable used for
> context saving
> status_temp             RES     1               ; variable
> used for context
> saving

Yes, that's right. See the MAP file to see the "real" addresses, (even
if they realy doesn't matter...).

{Quote hidden}

Yes, *if* shorter then the lenght of section "INT_VECTOR" in
the linker script (see the LNK file).

{Quote hidden}

TRIS is an "depricated" assembly instruction. Maybe not in the
F84 data sheet, but in practicly any other data sheet from a current
PIC type. Use MOVWF TRISB, instead.

>                  movlw   0x0f
>                  movwf   portb
>
> circle  goto    circle
>
>                  END
>


Regards,
Jan-Erik.



2005\05\23@074505 by olin_piclist

face picon face
John Piccirillo wrote:
> I do have the assembler/linker/librarian manual and have
> looked at it but as is usually the case this is a reference
> and not a tutorial and some of the discussion is only
> comprehensible if one is already in the know.

Not really.  Look again, it's all in there.  When I first started with PICs,
I sat down and read that manual and the data sheet for the first PIC I tried
to use, and was able to get things up and running from there.  The only part
that is missing is generic knowledge from Computing 101.  You do need to
understand at a high level what an assembler, librarian, and linker do and
why you'd want to use each of them.

> Error - section 'INT_VECTOR' can not fit the absolute section.
> Section 'INT_VECTOR' start=0x00000004, length=0x00000010

That's due to a Microchip stupidity in the default linker files.  For some
idiotic reason, they define a section starting at 4 of some small arbitrary
length.  Quite often your ISR will need more space than that.

The right way to do this is to make all of page 0 one section.  Set the code
at the reset and interrupt vectors to absolute addresses 0 and 4
respectively, then let the linker place all other code around it.  I've got
a bunch of tested linker files in my PIC development environment at
http://www.embedinc.com/pic.  These will save you the trouble of modifying
the Microchip ones.

> I hope you have the patience to tell me how that is used.  Where would
> it be useful to have different CODE sections.

Code sections, or sections in general work pretty much the same way as they
do an any other machine.  PIC code sections are not really different than
code sections on Windows.  It sounds like your problem is not so much with
the Microchip assembler/linker as a confusion about assemblers/linkers in
general.  I don't want to repeat Computing 101 here, but briefly, "sections"
are those units in an address space that are placed independently by the
linker.

> How do I treat
> the portb equate, RES doesn't seem to work.

PORTB and all SFRs and bit names within them are defined in the standard
Microchip include files.  You shouldn't try to define them yourself.

> If I follow the interrupt
> vector with a goto iserv and put the ISR down under Main Code, it
> assembles.

Yeah, but that's a bad idea.  Some code will end up at location 4, so it
might as well be the ISR.  At the least this saves one instruction and two
cycles every interrupt.  More importantly, putting a GOTO at the interrupt
vector is a bug in multi-page machines since the value in PCLATH is not
guaranteed.

If you want to see an interrupt routine template, take a look at my
QQQ_INTR.ASPIC module.


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

2005\05\23@081613 by Alan B. Pearce

face picon face
> I hope you have the patience to tell me how that is used.
> Where would it be useful to have different CODE sections.

Ever done OOP programmes? You can (sort of) do encapsulation of your code in
assembler using CODE sections. It does not totally stop you from stuffing
things up (especially in machines with banks, and you forget to make sure
you are in the correct bank) but it does go a long way towards helping
separate things and stop one lot of code from stepping on another lot.

It also allows you to have modules that you can re-use. I now have modules
for I2C (both master and slave) built from the Microchip app notes, Serial
Comms with UART built from Fr. MacGhees picuart file, and an analogue
module, along with a number of miscellaneous others. These were all done
using Olins development environment, and are all re-useable modules by
linking them in.

2005\05\24@090532 by Howard Winter

face
flavicon
picon face
Alan,

On Mon, 23 May 2005 13:16:07 +0100, Alan B. Pearce wrote:

> Ever done OOP programmes? You can (sort of) do encapsulation of your code in assembler using CODE sections.

<nitpick mode>

I think you're talking about Modular Programming, which predates OOP by twenty years or so!  :-)

You can't do OOP in a language like Assembler without some sort of pre-processor and a meta-language to handle
the Object/Property/Method stuff, as far as I know.

</nitpick mode>

Cheers,



2005\05\24@094017 by Alan B. Pearce

face picon face
>I think you're talking about Modular Programming,
>which predates OOP by twenty years or so!  :-)
>
>You can't do OOP in a language like Assembler without
>some sort of pre-processor and a meta-language to handle
>the Object/Property/Method stuff, as far as I know.

Sure, but the net effect is very similar - you write routines within the
module to handle the local details and keep the workings invisible to the
"outside" modules. OK you don't really get the "message sending to objects"
of OOP, you have to write routines instead, but you can do the data hiding.

2005\05\24@103639 by Dave Tweed

face
flavicon
face
"Howard Winter" <spam_OUTHDRWTakeThisOuTspamH2Org.demon.co.uk> wrote:
> <nitpick mode>
> I think you're talking about Modular Programming, which predates OOP by
> twenty years or so!  :-)
>
> You can't do OOP in a language like Assembler without some sort of
> pre-processor and a meta-language to handle the Object/Property/Method
> stuff, as far as I know.
> </nitpick mode>

You can write any "-oriented" style in any language -- it's just a question
of proper documentation and discipline. Yes, some languages are better than
others in terms of enforcing the discipline and automating some of the
documentation, but that shouldn't be an excuse for a Real Programmer :-).

-- Dave Tweed

2005\05\24@104818 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Alan B. Pearce" <.....A.B.PearceKILLspamspam@spam@rl.ac.uk>
Subject: Re: [PIC] RE: MPLAB v7.1 changes ?


> Sure, but the net effect is very similar - you write routines within the
> module to handle the local details and keep the workings invisible to the
> "outside" modules. OK you don't really get the "message sending to
objects"
> of OOP, you have to write routines instead, but you can do the data
hiding.

And the data hiding is a HUGE productivity improvement on the PIC.  Probably
takes a little experience to "get it", but this makes a surprising
improvement.

--McD

2005\05\24@135043 by David Minkler

flavicon
face
John J. McDonough wrote:

>And the data hiding is a HUGE productivity improvement on the PIC.  
>
Why would that be?

Dave


2005\05\24@150954 by olin_piclist

face picon face
David Minkler wrote:
>> And the data hiding is a HUGE productivity improvement on the PIC.
>>
> Why would that be?

Imagine working on a 10,000 line PIC project and having to make sure that
every local symbol in each little routine is unique accross the whole
project.  That's difficult enough if writing the whole thing from scratch.
In reality, some chunks are going to come from previous projects, and they
will can't have local symbols with the same name as any other local symbol
either, even though the imported code may have been written years earlier.


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

2005\05\25@040212 by Alan B. Pearce

face picon face
>>> And the data hiding is a HUGE productivity improvement on the PIC.
>>>
>> Why would that be?
>
>Imagine working on a 10,000 line PIC project and having to make sure
>that every local symbol in each little routine is unique accross the
>whole project.  That's difficult enough if writing the whole thing
>from scratch. In reality, some chunks are going to come from previous
>projects, and they will can't have local symbols with the same name
>as any other local symbol either, even though the imported code may
>have been written years earlier.

For this reason I do prefix all the symbols with their module name - if
nothing else than that I can identify the correct one in the debugger. It
also tends to group them when selecting the symbol name in the debugger.

2005\05\25@045652 by Chen Xiao Fan

face
flavicon
face
Wow, a 10,000 line PIC project, that is a lot! I really admire you.
but then why not use C for it? Probably it will be reduced to
1000-2000 line. :) C is better in "hiding data" than assembly. :)

My 0.5k 12F629 program in assembly is 1400 lines and my 2k 16F872
program in PICC is again about 1400 lines with more comments line. :)

Xiaofan

{Original Message removed}

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