Searching \ for 'Profiler and Stack Depth. Was: Re: WHY USE PICs??' 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: 'Profiler and Stack Depth. Was: Re: WHY USE PICs??'.

Truncated match.
PICList Thread
'Profiler and Stack Depth. Was: Re: WHY USE PICs??'
1999\03\12@122335 by Harold Hallikainen

picon face
On Thu, 11 Mar 1999 12:28:19 -0800 Gerhard Fiedler <spam_OUTlistsTakeThisOuTspamHOME.COM>
writes:
>At 09:48 03/11/99 +0000, Mike Harrison wrote:
>>>Whaaaat??? PIC doesn't has internal UART? duhhh! Grade: -E
>>
>>Why pay for that extra silicon when you can do it so easily in
>>software?
>
>what's the max bps you get out of a pic/avr/scenix firmware serial
>receiver, running in the background (ie. on interrupts) at 4MHz clock?
>and
>how much processing power (%) is left?
>

       Speaking of...  A profiler for PIC code would be great!  We could
then find out how much time is left and where all our time is being
spent.
       Another problem...  I tend to structure my code with the use of
subroutines.  The main loop might have a half dozen calls, and those
routines might do another call.  Same thing for interrupts.  The ISR
consists of save context, btfsc, call something, btfsc, call something,
restore context.  I've gotta be real careful to not run out of stack
space!  I'[m using the 16c74a and to avoid running out of stack space, I
disabled interrupts before doing a subroutine call over a certain depth
in the main code.  Now I'm getting overrun errors on the uart (receiving
at 250 kbps).  I guess that I can keep the structure and get rid of stack
usage by going to macros instead of subroutines.
       Any comments?


Harold



Harold Hallikainen
.....haroldKILLspamspam@spam@hallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\03\12@124220 by Anderson, Roger

picon face
You could try not calling subroutines in the interrupt routine.
Instead just set a flag and exit. Then check for the flag in the main
loop.  This may slow down response time though.

Roger

> {Original Message removed}

1999\03\12@125233 by Wagner Lipnharski

picon face
Harold Hallikainen wrote:
>
>         Speaking of...  A profiler for PIC code would be great!  We could
> then find out how much time is left and where all our time is being
> spent.
>         Another problem...  I tend to structure my code with the use of
> subroutines.  The main loop might have a half dozen calls, and those
> routines might do another call.  Same thing for interrupts.  The ISR
> consists of save context, btfsc, call something, btfsc, call something,
> restore context.  I've gotta be real careful to not run out of stack
> space!  I'[m using the 16c74a and to avoid running out of stack space, I
> disabled interrupts before doing a subroutine call over a certain depth
> in the main code.  Now I'm getting overrun errors on the uart (receiving
> at 250 kbps).  I guess that I can keep the structure and get rid of stack
> usage by going to macros instead of subroutines.
>         Any comments?
>
> Harold
>

Harold, this is a chalenge between
programming_code_memory_availability versus
stack+processor_idle_availability.

For long time I fought trying to understand which one
is the most important or would be more available.

I installed a simple subroutine that first innitialize
all the stack space with a pattern, lets say 33h, then
at every while I check the stack from the end to the
beginning, to find out where it is not 33h, so I get
the information how far the machine used the stack
already.  After a while it will give you the maximum.

Another routine running in a real batch partition,
lowest priority just looping and counting a 128 bits
counter.  After a preset time, the value in that counter
will tell me how much in "idle" the machine was.
A simple instruction cycles per counter step will give
you how many machine cycles per second you have available.

For sure, using as much as possible the programming code
memory, avoiding calls and returns, speed up the system.
The use of macros is a must in this situations, if not
you will have several copies of the same routine at the
source code, leading to possible mistakes and turning it
very difficult to change and do maintenance.

I use a very small Serial-LCD (2pins) to show me all the
time (once a second) the highest stack usage during
software development.  I sell those LCDs (3 x $10.00,
check my webpage "offers").  Before that, or I was using
much stack space (with less space for variables) or I
was near the limit (without knowing it) and sometimes
going in a big problem of stack pointer invading the
variables area.
--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:   http:/http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\03\12@132825 by Ralph Stickley

flavicon
face
One quick way to keep the structure but loose the stack:

#define ReturnInt     goto retInt

where the interrupt routine has a label:

// interrupt at 0x04
// save stack, etc.
// parse interrupt flags and goto interrupt specific routine

retInt:         // return here from all interrupt routines
//   restore stack
  reti

and each interrupt routine

xxxIntService:
  ...
  ReturnInt

Also, to get around a large stack, I've implemented an event
driven task switcher - an interrupt or any routine sets a bit flag
(within a 16 bit variable) and that event gets executed (in
priority (bit 0 - bit 15 ) order) by the main event loop.  Additionally, I have
a 16 counters that get
decremented every timer tick (1 ms) and when they hit zero,
the event flag associated with that timer gets set.  Thus, I have
no delay loops, but the programming environment is slightly
different from a simple polled/interrupt driven system.

I am using every interrupt and every on-chip
feature of the 16c74 (except the spi port, which didn't work
right when I tried it (but I just got some code that should
work from someone else on the list.:-))  All available code space
is filled, but 1/2 of the second bank is still available.  So
far, only 5 bytes are required on the stack.

Something like that may help.

Ralph


*Microsoft has a Y2K problem: its called Linux!*
*Microsoft ?? Is that some kind of toilet paper ??*

1999\03\12@141019 by Scott Dattalo

face
flavicon
face
On Fri, 12 Mar 1999, Harold Hallikainen wrote:

>
>         Speaking of...  A profiler for PIC code would be great!  We could
> then find out how much time is left and where all our time is being
> spent.

This something I've been wanting to add to gpsim. Right now, gpsim traces
everything that happens. However, nothing is currently done with that
information (other than allowing the user to browse it). It would be easy
to parse the trace buffer and obtain profiling information. Expect this in
0.0.13

Scott

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