Searching \ for '[PIC] Re: Compiler generated interrupt latency' 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/ints.htm?key=interrupt
Search entire site for: 'Re: Compiler generated interrupt latency'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Re: Compiler generated interrupt latency'
2007\09\06@075753 by Xiaofan Chen

face picon face
Adding the [PIC] tag.

On 9/6/07, Morgan Olsson <spam_OUTost011TakeThisOuTspamosterlen.tv> wrote:

> Due to spending most of the time in context save/restore the program fail to handle timer interrupts and external events.
>
> http://forum.microchip.com/tm.aspx?m=279936
>
> Accordign to an answer in that thread it is impossible to make C18
> create time-efficient (non-looping) context save/restore.

I am not an PIC C language expert but the people in the thread like
jtemples (also in PIClist) and dhenry are the real experts.
I think they are saying that your firmware architecture is wrong.

Switching compiler won't help in this case.

As far as I know, it is always good to keep the interrupt service
routine as lean as possible. And it is generally not a very
good idea to call routines inside ISRs.

Regards,
Xiaofan

2007\09\06@104630 by Morgan Olsson

flavicon
face
Den 2007-09-06 13:57:46 skrev Xiaofan Chen <.....xiaofancKILLspamspam@spam@gmail.com>:

> Adding the [PIC] tag.

OOPS, thanks!

> As far as I know, it is always good to keep the interrupt service
> routine as lean as possible. And it is generally not a very
> good idea to call routines inside ISRs.

I agree.
When programming in assembler i have kept interrupt routines very small,
then let the program enter a postprocessing phase with interrupts re-enabled
(And yes i do take care of save/restore in another set)
before returning to main.

However my collegue who programs this is skilled in C on larger systems and do things another way.
I thought it would work that way too, but we was mistaken.

As we are in an hurry to make this work so we can show the customer we try to get it work as my programming guy is used to work, it would take much time to relearn both strategy, tools, and rework the system...

That said, i am now installint PICC-LITE to begin to learn C myself so i can later try a assembler / C mix approch with efficient interrupt system...

--
Morgan Olsson

2007\09\06@112836 by Gerhard Fiedler

picon face
Xiaofan Chen wrote:

>> Accordign to an answer in that thread it is impossible to make C18
>> create time-efficient (non-looping) context save/restore.
>
> I am not an PIC C language expert but the people in the thread like
> jtemples (also in PIClist) and dhenry are the real experts.
> I think they are saying that your firmware architecture is wrong.
>
> Switching compiler won't help in this case.

This may not be true. The new HiTech Pro compiler (not the standard, and
not the lite which is standard) is supposed to read all project source
files for code generation and create smarter code, including only necessary
context saving code. (I haven't yet used it.)

Gerhard

2007\09\06@120800 by John Temples

flavicon
face
On Thu, 6 Sep 2007, Xiaofan Chen wrote:

> On 9/6/07, Morgan Olsson <ost011spamKILLspamosterlen.tv> wrote:
>
>> Due to spending most of the time in context save/restore the program fail to handle timer interrupts and external events.
>>
>> http://forum.microchip.com/tm.aspx?m=279936
>>
>> Accordign to an answer in that thread it is impossible to make C18
>> create time-efficient (non-looping) context save/restore.

Yes, that's true, but that wasn't quite the point.  A sufficiently
small ISR will have little or no context saving in the first place.
If you have a context save that's so large that the compiler needs to
generate looping code, the problem isn't really with the compiler.

> Switching compiler won't help in this case.

Hi-Tech's compilers aren't as limited as C18 in dealing with this kind
of code.  Even the standard compiler will "look into" functions called
by the ISR to determine which managed resources they use in order to
minimize the context save.  Note that this works only if the functions
called by the ISR appear before the ISR in the same translation unit.
I don't know how the PRO compiler handles this situation.

--
John W. Temples, III

2007\09\06@163220 by Ruben Jönsson

flavicon
face
>
> However my collegue who programs this is skilled in C on larger systems and do
> things another way.
> I thought it would work that way too, but we was mistaken.
>
> As we are in an hurry to make this work so we can show the customer we try to
> get it work as my programming guy is used to work, it would take much time to
> relearn both strategy, tools, and rework the system...
>

That may be your problem. A PIC, also a PIC18, can not be treated as a larger
system. Even with a C-compiler you have to be aware of the limitations of the
chip when you design the software. I find that it is quite different to
program, say a PC application compared to an an application in an embedded
environment.

/Ruben

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
.....rubenKILLspamspam.....pp.sbbs.se
==============================

2007\09\06@195456 by Xiaofan Chen

face picon face
On 9/6/07, Morgan Olsson <EraseMEost011spam_OUTspamTakeThisOuTosterlen.tv> wrote:

> As we are in an hurry to make this work so we can show the
> customer we try to get it work as my programming guy is used
> to work, it would take much time to relearn both strategy, tools,
> and rework the system...

I understand your situation especially that you are not the firmware
engineer in the project...

But sometimes it is easier to throw away the design. I've done this
once in the previous job. It was painful experiences since it is
for the hardware part. Basically I had to redesign the things after
almost one year of going into the project.

Regards,
Xiaofan

2007\09\06@231859 by John Chung

picon face

--- John Temples <piclist3spamspam_OUTxargs.com> wrote:

{Quote hidden}

 If I understand your requirement. You want a
compiler to inject context saving code into your ISR?
It is possible that it could be done but the context
that this code injection would work is within a narrow
situation.

 Some thought. If there is a function pointer in the
ISR *how* would the compiler know what to save?

John


PS: If you want to use a compiler that starts
injecting code do consider the possibility of
injection code or modifying code at locations you
don't want......


     
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
answers.yahoo.com/dir/?link=list&sid=396545469

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