Searching \ for '[PIC] Splitting assemblies in to multiple files' 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: 'Splitting assemblies in to multiple files'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Splitting assemblies in to multiple files'
2004\10\10@092553 by olin_piclist

face picon face
Mark Mcgee wrote:
> At my first attempt at coding my first PIC program, I think I bit off
> more than I can chew.  I attempted to separate my program in to a few
> assembly files for structure and convenience thus;

That's what you should do.  Splitting up a large piece of software into
multiple modules is one of the cornerstones of good software engineering.

> main.asm for the main program (org 0x000 and CODE directives inside)

This doesn't make sense.  ORG is for the old obsolete absolute mode, CODE is
for relocatable mode.  The two shouldn't be mixed.  You should be using CODE
and forget that ORG ever existed.

> init.asm for initialisation code (has a CODE directive)
> udc.asm for user data
> irp.asm for interrupt request processing (org 0x004 - ISR_ADDR label
> undefined error on build?)

Again, use CODE, not ORG.

> I discovered that I couldn't use CBLOCK and then use extern <label>
> in another file for my data.  So I'm using UDC and RES instructions -
> is this right?

CBLOCK is another holdover from archaic mode.  It is currently reserved for
irresponsibly written software and Microchip example code.  RES is the
correct way to allocate RAM.  Note the important distinction that RES
actually **allocates** RAM, whereas CBLOCK, EQU, and the like create symbols
with values that only you know are intended to be RAM addresses.  I don't
know what UDC is.

> Furthermore, in (IIRC) the interrupts documentation from Microchip,
> they provide some MACROS for saving and restoring registers
> (PUSH/POP) in the interrupt handler, which seem to be causing all
> sorts of build problems.

I don't know anything about these.  You should never use a macro whithout at
least once looking at it and understanding what it does.  If a canned macro
doesn't work, write out the instructions manually and figure out what is
going on.  Once you find the right way to do what you want, you can fix the
macro or create your own.

> Also the debugger won't now start on my first instruction for some
> reason.  I have used org 0x000 followed by a GOTO Main, then a CODE
> statement inside which the Main label presides, maybe this is wrong?

I am surprised this even assembled.  I thought ORG wasn't allowed in
relocatable mode, and CODE not allowed in absolute mode.  Maybe recent
versions of MPASM allow ORG?  Anyway, stay away from ORG.  There is nothing
it can do that CODE can't.

> Unfortunately I don't have access to the code from here otherwise I'd
> post what I have so far.

I don't want to see the whole thing, but maybe the definition of the reset
vector, the interrupt vector, and how the first bit of relocatable code gets
run at startup would be useful.

> Any suggestions on how to develop (for 16F628A - cos that's what I
> have) multiple assembly file project would be very welcome!

I do this all the time.  The MPLAB environment provides the bare tools, but
a lot of niceties are missing, especially some that allow good software
design with relocatable mode.  As a result, I've developed my own layer over
the MPLAB build tools.  It is available for free at
http://www.embedinc.com/pic.  This includes several complete projects, all
of which use multiple modules in relocatable mode.  There are also template
modules that make it easy to create the structure of a new project.


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

2004\10\10@183405 by Matthew Miller

flavicon
face
Hi Olin,

Thanks for your input! I didn't start this thread, but I've got an interest
in splitting my next project among multiple files. I'm also interested in
your PIC environment (being able to do away with most bank switching is very
attractive!)

Thanks, Matthew.

--
If you stew apples like cranberries, they taste more like prunes than
rhubarb does. -- Groucho Marx
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\11@052820 by Alan B. Pearce

face picon face
>Hi Olin,
>
>Thanks for your input! I didn't start this thread,
>but I've got an interest in splitting my next project
>among multiple files. I'm also interested in your PIC
>environment (being able to do away with most bank
>switching is very attractive!)

Well be careful. Olin's environment does not do away with bank switching.
What it does is allow a number of macros to take the guesswork out of the
bank switching morass. You place a macro before each register reference
(more or less), and it only generates code if code is actually needed. This
just makes it harder to make mistakes - but not impossible.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\11@062046 by Russell McMahon

face
flavicon
face
> This just makes it harder to make mistakes - but not impossible.

Valuable engineering (and life) lesson.

It is NEVER impossible to make mistakes.
Just possible to make it appear that it is impossible to make mistakes.


       RM

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

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