Searching \ for ' function calls from isr?' 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/index.htm?key=function+calls+isr
Search entire site for: 'function calls from isr?'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] function calls from isr?'
2000\10\30@145225 by Michael Shiloh

flavicon
face
Hi Gang,

Quick question:

I'm using the C2C compiler with a 16C63. I'm writing some code
around an interrupt driven serial port using the on-board USART.
I use a circular buffer to queue characters for transmission.

I have a function to remove a character from the buffer, and I
call this from both an ISR and main code, and I get a warning
for doing so:

Warning: Function '_SerTxBufferRemove' used both in interrupt and main code


Is it not permitted to call a function from both interrupt code
and main code?

Thanks,
Michael

--
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




2000\10\30@150848 by Andrew Kunz

flavicon
face
Usually not.

HiTech PICC allows you to do it, but as the programmer you must guarantee
exclusive access to the function.

The alternative is to just make two copies of the code.

If you think about it, you will probably identify a logic flaw.  What happens if
the buffer is full when the ISR goes to write to it?  Lock-up city!

Andy









Michael Shiloh <spam_OUTmshilohTakeThisOuTspamMEDIABOLIC.COM> on 10/30/2000 02:52:51 PM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>








To:      PICLISTspamKILLspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: function calls from isr?








Hi Gang,

Quick question:

I'm using the C2C compiler with a 16C63. I'm writing some code
around an interrupt driven serial port using the on-board USART.
I use a circular buffer to queue characters for transmission.

I have a function to remove a character from the buffer, and I
call this from both an ISR and main code, and I get a warning
for doing so:

Warning: Function '_SerTxBufferRemove' used both in interrupt and main code


Is it not permitted to call a function from both interrupt code
and main code?

Thanks,
Michael

--
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

--
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




2000\10\30@153919 by Chris Eddy

flavicon
face
Mike;

You are better off flagging the recieved character while you are in the
interrupt, then allowing a main line code function find the flag and process
the character.  Depending on your baud rate and main loop execution period, of
course, but many times the main routine is cruising along so fast that you can
easily catch all chars.

Otherwise, you might buffer them up in the int, and look for a valid complete
message there, like 6 characters (remember to consider lost characters), at
which point you flag the main routine to do something with it.

When you share a buffer, or a flag, or any other variable between main line
code and an interrupt, get in the habbit of declaring it volatile.  This is
especially useful for int types, where accessing a multipart variable
simultaneously would cause gross errors.  This one is a subtle one, you might
read up on it.

Try not to share executable code between int and main line code.  It is a sure
way to fail.

Chris~

Michael Shiloh wrote:

{Quote hidden}

--
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




2000\10\30@155156 by Plunkett, Dennis

flavicon
face
You can use the routine to remove the byte from the buffer, but, you will
have to dissable the interrupt routine before entering the function in the
normal mode. The warning is valid, but indicating that the function could
possibly be re-enterant. This is not a good idea on a PIC, and even HITECH
needs the "Re-entrant" flag set.
So if you have to use the rountine then do somethin loke this: -


interrupt serial(void)
{
       sv_remove_byte();
}

static void
sv_remove_byte (void)
{
       ucp_TX--;               /*etc*/
}



void
v_remove_a_byte (void)
{
       dissable_interrupts();
       sv_remove_byte ();
       enable_interrupts();
}




Dennis










> {Original Message removed}

'[PIC]: Re: function calls from isr?'
2000\10\30@185505 by Michael Shiloh

flavicon
face
As usual, this list offers excellent advice.


On Mon, 30 Oct 2000, Chris Eddy wrote:

> When you share a buffer, or a flag, or any other variable between main line
> code and an interrupt, get in the habbit of declaring it volatile.  This is
> especially useful for int types, where accessing a multipart variable
> simultaneously would cause gross errors.  This one is a subtle one, you might
> read up on it.

As I understand it, the "volatile" keyword is used to tell the compiler
that a variable might change without it knowing about it. This is to
warn the compiler that just because no code has changed the variable, it
doesn't mean that the variable won't change; otherwise, an optimizing
compiler might optimize out some code.

This is often used when the variable represents a hardware register.

My compiler (C2C) doesn't support the volatile keyword, so I guess I
should either turn off optimization or look carefully at the generated
assembly code and make sure that when volatile registers are read they
really are read from hardware.

Does this sound about right to you?




In more general terms, Chris and others warn me away from sharing
executable code between int and main line code. Point taken. Any
comments on sharing variables between int and main line code? I
understand that the goal is to close any opportunity for a variable
to change after you test it but before you act upon it, and then
to take the wrong action.



My original question is below. I should point out that this is for
the transmitter, so the program is putting chars on the buffer, and
the ISR is taking them off and feeding them to TXREG whenever a TXIF
occurs:


{Quote hidden}

--
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




2000\10\30@221046 by Chris Eddy

flavicon
face
Michael Shiloh wrote:

> My compiler (C2C) doesn't support the volatile keyword, so I guess I
> should either turn off optimization or look carefully at the generated
> assembly code and make sure that when volatile registers are read they
> really are read from hardware.
>

Ha! Get a real compiler. Sorry to be so blunt, but look at it this way.. You ought
to generate $800 in about 2 or 3 days.  So why play with inferior products, when
the better ones are very reasonable?

>
> In more general terms, Chris and others warn me away from sharing
> executable code between int and main line code. Point taken. Any
> comments on sharing variables between int and main line code? I

A very solid way to make ints and main line code cooperate is to block execution of
one or the other.  If you want to run main line code without any interruption, then
you simply turn of GIE.  This can be hazardous, though, as you begin to damage your
chances of highly predictable real time response.  So flip over the coin.  Make a
flag, which the main line code sets when it wants to go to work on something, and
if the int runs in this time period, it leaves the variables/item/peripheral/etc
alone for the duration.  This way, you can let the remainder of the interrupts, and
even other portions of the same interrupt, run without compromise.  It is a very
soft way to overlap competing services.  As an example, I did some code where five
devices would share a spi bus.  The interrupt was going to run the analog to
digital converters (2 of the devices) from a regularly timed interrupt (TMR0
divided down).  The other devices, a flash part and two others I forget, were
occasional access.  So I setup this flag, which the main routine set during
access.  During this period, the interrupt would simply skip over the atod
conversions for a brief period.  Since the analog software filter did not run if
there was not a conversion (they were flagged to run from int to main as well) then
I did not compromise my filtered reads.

If you have a case where the int may be already partway through a process (example
when a multi-part process takes multiple interrupts, keep track of phase with
flags), and the main line code would interfere with this op, then make two flags.
One says the int is busy and the mainline may not execute, the other says the main
line is busy and the int may not run.  You can surely see 0xF4240 (million for the
newbies) permutations of this idea.

Chris~

--
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




2000\10\31@044213 by Wollenberg, Frank

flavicon
face
See my insertions below.
Frank

-----Original Message-----
From: Michael Shiloh [.....mshilohKILLspamspam.....MEDIABOLIC.COM]
Sent: Tuesday, October 31, 2000 12:56 AM
To: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
Subject: [PIC]: Re: function calls from isr?

> As I understand it, the "volatile" keyword is used to tell the compiler
> that a variable might change without it knowing about it. This is to
> warn the compiler that just because no code has changed the variable, it
> doesn't mean that the variable won't change; otherwise, an optimizing
> compiler might optimize out some code.
>
> This is often used when the variable represents a hardware register.
This is correct.

> My compiler (C2C) doesn't support the volatile keyword, so I guess I
> should either turn off optimization or look carefully at the generated
> assembly code and make sure that when volatile registers are read they
>  really are read from hardware.
>
> Does this sound about right to you?
At end of your development, you can turn on optimization and look again.

{Quote hidden}

code
> >
> > Is it not permitted to call a function from both interrupt code
> > and main code?
I don't understand, why you are using this function from main(). AFAIK the
only reason for this is to reject your previous char insertion. But at this
time you don't know wether the character has been sent by the isr() or not.

I include one interesting mail from the hitech list. I don't know if the
compiler handling is the same on C2C.

>> guess what I'm asking is:are there any conditions were calling the same
>> function from main() and an ISR is acceptable from the compilers POV?
>
>Yes, if the function uses no local variables in RAM.



--
GSP Sprachtechnologie GmbH
Teltowkanalstr.1, D-12247 Berlin
Tel.:  +49 (0)30 769929-0
Fax:   +49 (0)30 769929-12
eMail: Infospamspam_OUTgsp-berlin.de
Web:   http://www.gsp-berlin.de

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




'[PICLIST] function calls from isr?'
2000\10\31@142054 by Harold M Hallikainen

picon face
       There is probably a potential problem with code re-entrancy. If the
function has some variables that are set in the main code, and the
function gets interrupted and called again in the interrupt, the
variables get clobbered. Your main code then continues with clobbered
variables. If the function stores local variables on the stack (which
would be unusual for a PIC, and could not be done with static locals),
the function would be reentrant and should work. You can simulate
something like this by making the variables of your function part of the
context you save and restore when going in and out of interrupts, though
this may add a considerable overhead to interrupts. Another work around
is to disable interrupts in your main code when calling this function,
then enable them afterwards.



Harold

On Mon, 30 Oct 2000 11:52:51 -0800 Michael Shiloh
<@spam@mshilohKILLspamspamMEDIABOLIC.COM> writes:
{Quote hidden}

FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@170249 by Don Hyde

flavicon
face
I would suspect a reentrancy problem in their implementation of the software
stack for passing variables to functions.  Since constructing a stack frame
may take several instructions, the code created by the compiler could easily
be vulnerable to some sort of reentrancy problem if the same function is
called both at base level and at interrupt level.

It is entirely conceivable that the compiler creates a separate stack for
interrupt code.  With a processor architecture like the PIC, it is not at
all easy to deal with some of these issues in a really general-purpose way.

I have even heard rumors of compilers that construct and analyze a call
tree, then emit non-reentrant code for functions that can never be called
recursively.  Doing that could result in very tight code -- good enough to
be very hard to beat with hand coding, especially after a couple of design
revisions...

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@204728 by Bob Ammerman

picon face
> I have even heard rumors of compilers that construct and analyze a call
> tree, then emit non-reentrant code for functions that can never be called
> recursively.  Doing that could result in very tight code -- good enough to
> be very hard to beat with hand coding, especially after a couple of design
> revisions...

That's not just a rumor, that's basically the way it is done in PIC C
compilers. Otherwise all memory accesses are via FSR and things _really_
start to bog down!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.





'[PICLIST] function calls from isr?'
2000\11\01@150708 by w. v. ooijen / f. hanneman
picon face
> > I have even heard rumors of compilers that construct and analyze a call
> > tree, then emit non-reentrant code for functions that can never be
called
> > recursively.  Doing that could result in very tight code -- good enough
to
> > be very hard to beat with hand coding, especially after a couple of
design
> > revisions...
>
> That's not just a rumor, that's basically the way it is done in PIC C
> compilers. Otherwise all memory accesses are via FSR and things _really_
> start to bog down!

And in non-C compilers (at least in Jal).

Wouter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservTakeThisOuTspammitvma.mit.edu?body=SET%20PICList%20DIGEST




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