Searching \ for '[PIC]:Hitec C W 17C processor Context saves' 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=c
Search entire site for: 'Hitec C W 17C processor Context saves'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Hitec C W 17C processor Context saves'
2002\04\02@123445 by Larry G. Nelson Sr.

flavicon
face
One of my clients has a problem with the context saves taking too long in
his interrupt routine. He has moved the ISR to the end of the file and
wants advice on how to pare it down further. He has a very complex system
that is doing real time control but the 80 cycles to get into his interrupt
is very problematic. When we decided on C instead of ASSY we did not
consider this and I need to know if we are working into a situation without
a solution.

Thanks

Larry G. Nelson Sr.
spam_OUTL.NelsonTakeThisOuTspamieee.org
http://www.ultranet.com/~nr

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\02@132717 by Olin Lathrop

face picon face
> One of my clients has a problem with the context saves taking too long in
> his interrupt routine. He has moved the ISR to the end of the file and
> wants advice on how to pare it down further. He has a very complex system
> that is doing real time control but the 80 cycles to get into his
interrupt
> is very problematic. When we decided on C instead of ASSY we did not
> consider this and I need to know if we are working into a situation
without
> a solution.

80 cycles is rediculous!  I just looked at my standard interrupt template
and it will take 22 cycles to get into and out of a full featured interrupt
(FSR and PCLATH saved/restored).  That doesn't include doing any real
interrupt work but does take into account that STATUS is unknown when
jumping to the interrupt exit code.

80 cycles is just waaaaay out of line.  It shows once again that on small
resource limited systems compilers are for high level tasks or low level
programmers.  The obvious answer is to write the interrupt routine in
assembler, duh!  Anyone writing code for tiny systems like PICs should know
the instruction set and be able to write assembler, even if using a compiler
for the majority of the project.  If you're scared of assembler go write GUI
apps in visual basic and forget you ever heard about PICs, or practice
saying "Do you want fries with that?".  If you want to see how it's done in
assembler, check out my template interrupt module at
http://www.embedinc.com/pic.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\02@135423 by Larry G. Nelson Sr.

flavicon
face
I agree. I have assembly routines that are much less also but it seems the
compiler is saving a slew of variables automatically. The programs
structure is very complex and includes a real time operating system
designed for this product. The interrupt structure is also very complex but
strings everything together. The code bloat is not as large as expected but
the context save is a lot bigger than I thought. I am wondering if it is
related to the compilers internal library usage (math functions etc).
Larry


At 01:25 PM 4/2/02 -0500, you wrote:
{Quote hidden}

Larry G. Nelson Sr.
.....L.NelsonKILLspamspam@spam@ieee.org
http://www.ultranet.com/~nr

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\02@141555 by Bob Blick

face picon face
Hi Larry,

Perhaps looking at the context saving code produced by the compiler would
shed some light.

I have never used the 17C version of PICC but the 16C version all the
time. I have never known it to create bloat.

I have seen it be more safe than it absolutely needs to. Also if you use
only a small amount of program memory it still splits the program up into
lots of smaller pieces scattered around the map, which means it needs to
play with PCLATH. It also asserts the ram banks more often than it might
absolutely have to. But nothing to account for the giant bloat you are
experiencing.

Best regards,

Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\02@141811 by Olin Lathrop

face picon face
> I agree. I have assembly routines that are much less also but it seems the
> compiler is saving a slew of variables automatically. The programs
> structure is very complex and includes a real time operating system
> designed for this product. The interrupt structure is also very complex
but
> strings everything together. The code bloat is not as large as expected
but
> the context save is a lot bigger than I thought. I am wondering if it is
> related to the compilers internal library usage (math functions etc).

Maybe it is, even more reason not to use a compiler for the interrupt
routine.  Wanting to do heavy math in an interrupt routine is a red flag for
bad overall software design.  You also need to worry about the stack depth
used in an interrupt, because the stack will be effectively shortened by
that much for the foreground code.  You really need to *know* the stack
depth used in the interrupt routine, which is another reason that using C
runtime libraries in an interrupt makes me nervous.

"Just say NO" to compiled interrupt routines.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\02@144001 by Mike Mansheim

flavicon
face
> I am wondering if it is related to the compilers internal library usage
> (math functions etc).

You could check this by compiling a simple program with a simple
interrupt routine and comparing the two.
Also, the CCS compiler has a directive that lets you replace it's
normal interrupt handler with your own.  I don't remember which C
compiler you are using, but I would think it has something similar.
I seem to remember a thread on this subject a while back (Edson??) -
there might be something useful in the archives.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\02@182832 by Spehro Pefhany

picon face
At 02:17 PM 4/2/02 -0500, you wrote:

>Maybe it is, even more reason not to use a compiler for the interrupt
>routine.  Wanting to do heavy math in an interrupt routine is a red flag for
>bad overall software design.

Sometimes. Other times you may have a DSP-like function where you have to do
4-function math and use lookup tables in interrupts. Last one I did for this
processor I have to save TBLPTRL/TBLPTRH, and PRODH/PRODL as well as FSR
the status and W.  The one I wrote is mostly written in inline assembler
with a
bit of C. It does not allow for nested interrupts. The context save and
restore
take less than 15 cycles each, IIRC.

Actually, before I re-wrote this in assembler I do recall that the compiler
saved a whole bunch of cr*p from its internal registers for doing fixed-point
or FP math. The solution in this case is not to use the compiler functions
for this kind of math, if you need to do it at all in interrupts. I wrote
the multiply routines in assembler so I could get a 16 x 8 multiply and
keep the desired part of the 24 bit result. I'd have had to use 32 bit longs
to do it in C, which would have been much slower, plus all the context
save stuff.

>  You also need to worry about the stack depth
>used in an interrupt, because the stack will be effectively shortened by
>that much for the foreground code.  You really need to *know* the stack
>depth used in the interrupt routine, which is another reason that using C
>runtime libraries in an interrupt makes me nervous.

Nothing stopping you from looking at the code it generates. I've got some
products that have the interrupts written entirely in C, there would not
be any noticeable difference if they were crafted in assembler. It's not
always possible or desirable, though.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
9/11 United we Stand

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\04\03@062614 by michael brown

flavicon
face
> One of my clients has a problem with the context saves taking too long in
> his interrupt routine.

>He has moved the ISR to the end of the file and

Does that have an effect on something?

> wants advice on how to pare it down further. He has a very complex system
> that is doing real time control but the 80 cycles to get into his
interrupt

Ouch!

> is very problematic. When we decided on C instead of ASSY we did not
> consider this and I need to know if we are working into a situation
without
> a solution.

Larry,

I don't know much about the compiler you are using, but maybe this will help
anyway.  I'm using SDCC (not on a PIC) and it lets you declare functions as
"naked".  This causes the compiler to *not* generate any prologue or
epilogue code for the routine (no context save or restore).  It is primarily
intended for interrupt handlers, especially ones written using inline
assembler.  Of course you have to be careful when doing that.  ;-)
Obviously, you will still have to save any context information that the
routine changes

BTW, some people seem to think that using C on a micro is unworkable, or
that the instructions just run slower.  ;-)   There is no reason that an
interrupt routine written in C can't be entered as timely as one written in
assembler.  Unless, the C libraries are poorly written and are disabling
int's thru long stretches of code.  The hardware can't tell the difference
between C and hand-written assembly.

The ironic thing about the ones who insist upon hand-written assembler is
that over time they end up creating a personal library of reusable code.
They tend to tinker and adjust this code to be more general in function, so
that it may be easily reused in a slightly different application.  They also
tend to create large numbers of macros and "program" the linker to it's
limits.  ;-) There is nothing wrong with this, it's just that it ends up
being similar to a higher level language in the end.

The pro side is that the home-made setup may be a little more efficient than
a "generic" compiler that's been ported to the PIC.  It also may be more
compatible with a persons particular line of work, their particular goals
and way of thinking.  The down side is that you can't port it to a new
non-PIC processor without allot of work.  Maintenance must be "somewhat more
than trivial" in just keeping up with the PIC product line changes.

I'm not trying to start an argument, or slight someone else's efforts.  I'm
just saying that statements such as "compilers are for high level tasks or
low level programmers" are not quite true.  Believe you me, I have written
mucho assembler (it's always been a favorite of mine), and for some things,
it's indispensable.  I tend to like a "blend" of the two.

michael brown

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\03@065943 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Olin Lathrop [SMTP:.....olin_piclistKILLspamspam.....EMBEDINC.COM]
> Sent: Tuesday, April 02, 2002 7:25 PM
> To:   EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Subject:      Re: [PIC]:Hitec C W 17C processor Context saves
>
> It shows once again that on small
> resource limited systems compilers are for high level tasks or low level
> programmers.
>
That is most definately a wholy invalid and sweeping statement.  I don't
know about your line of work, but in mine time is money, most especialy time
to market.  Using a C compiler on complex projects cut's development time
dramaticaly.  I agree that if you are trying to squeeze every last cycle out
of a uP then there is no substitute for hand optimised assembler, but those
condtions would tend to suggest the wrong processor was chosen, or costs
needed to be trimmed to the last $0.0001.

Mike

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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