Searching \ for '[PIC] how to calculate if interrupt is required?' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'how to calculate if interrupt is required?'.

Exact match. Not showing close matches.
'[PIC] how to calculate if interrupt is required?'
2007\07\25@164722 by

Hi to all,

1.
I was working on a project that took me 1,5 month to get it done.
After going thru lots of troubles later on I started using interrupts
then all of our problems went a way. My question is how do you guys
calculate or figure out that interrupt is required ?.

2. My second question is how do you calculate how much clock speed needed?
or should I always use 40 mhz. most of the time I use 20 mhz.

thanks

Andre

Andre,

I don't know about anyone else, but I don't have a "Formula" to
determine if I use interrupts or not.
I usually set up an application with interrupts with the assumption that
they will be required.  If they
Are required, then I already set up and good to go.  If not, then no
harm, no foul.  However, in some cases,
I use my judgement based on the application, how many tasks I have that
need to be done, what the priority of each task is, and my experience
with previous applications.  I guess in a way this is a Formula, but not
one in the true sense of the term.

Regarding the clock speed.  You (I) want to have a clock speed that
allows me to get everything done that need
to be done, but is still as slow as possible.  CMOS parts draw higher
current with higher speeds, so you have
to balance clock speed with power consumption, and with having enough
time to process enough instructions to
carry out the needed task(s).   Of course with the PIC's power is
usually not a big problem, but one you still
Need to be aware of.

Hope this helps you out some.

Regards,

Jim

{Original Message removed}
1.
I would say that very few (1 out of 100 ?) *real*
applications/projects could be written without
using interrupts. They are such an integral part
of the processor architecture, so it will be much
harder to *not* use them.

2.
Experience...
Or simply counting cycles for your most common routines.

Regards,
Jan-Erik.

Andre Abelian wrote:
{Quote hidden}

Andre Abelian wrote:

> 1. I was working on a project that took me 1,5 month to get it done.
> After going thru lots of troubles later on I started using interrupts
> then all of our problems went a way. My question is how do you guys
> calculate or figure out that interrupt is required ?.

In bigger processors, I usually have at least a timer interrupt. But in
general, I think this depends mostly on the application and somewhat on the
coding style. I create a rough architecture of the application, based on
the requirements what has to be done how fast, with how much jitter, etc.
With this, it's usually not so difficult to see where interrupts come in.
When you do it the first time, it takes a bit, because you have to compare
polling vs interrupts for every part. With time, you make your experiences

> 2. My second question is how do you calculate how much clock speed
> needed? or should I always use 40 mhz. most of the time I use 20 mhz.

Same as above: find out what the time-critical path is, and what clock
speed you need to get it done. With an interrupt-based architecture, this
is not as simple as counting instruction cycles; you need to take the
interrupts (which not necessarily are in regular intervals) into account.

(like your 20 MHz) and see how much wiggle room you have. It it's not
enough, you go higher. If it's a lot, you may go lower.

Gerhard

> Hi to all,
>
> 1.
> I was working on a project that took me 1,5 month to get it done.
> After going thru lots of troubles later on I started using interrupts
> then all of our problems went a way. My question is how do you guys
> calculate or figure out that interrupt is required ?.
>
> 2. My second question is how do you calculate how much clock speed needed?
>    or should I always use 40 mhz. most of the time I use 20 mhz.
>
>
> thanks
>
> Andre

I've found that interrupt service routines are typically taking I/O data
in to or out of a buffer. I then process the buffer in the main loop. On
recent projects, I've been pushing towards I/O devices that have their own
buffers. I can just pull and process the data in the main loop without the
overhead of interrupts. It's sort of a division of responsibility issue. I
just move the buffering off the PIC.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Experience is a good guide.

The main issue is usually latency.  Assume for a moment a system with
one or more uarts.  When a serial character comes in, can you poll the
uart in time, before the next char arrives?
Can you GUARANTEE that you will?   With interrupts, you can know that
it will be a very short time.  The sticky thing is when you have
multiple interrupt routines, and if they can take some significant
time to execute.  It's always a very good idea to have your interrupt
routines do as little as possible, letting the main line code do the
bulk of the work.

> Experience is a good guide.
>
> The main issue is usually latency.  Assume for a moment a system with
> one or more uarts.  When a serial character comes in, can you poll the
> uart in time, before the next char arrives?
> Can you GUARANTEE that you will?   With interrupts, you can know that
> it will be a very short time.  The sticky thing is when you have
> multiple interrupt routines, and if they can take some significant
> time to execute.  It's always a very good idea to have your interrupt
> routines do as little as possible, letting the main line code do the
> bulk of the work.

Following up on my previous post, in this uart example, the ISR is
typically putting the character in a buffer that is then dealt with in
mainline code. The buffer has to be large enough that it does not overflow
before the mainline code gets to it. A "distributed processing" (sort of)
approach is to use a uart with a big fifo, then let the mainline code deal
with it. That means not using the on-chip uart since they only have a two
to four byte buffer (depending on the chip). However, I recently went to
the FT245R for USB and rely on its buffers. No interrupts needed! Also,
I'm using an SPI 802.11 radio module that has large buffers so I don't
need to have interrupts for it (I would if I used the uart version).

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Andre Abelian wrote:
> Hi to all,
>
> 1.
> I was working on a project that took me 1,5 month to get it done.
> After going thru lots of troubles later on I started using interrupts
> then all of our problems went a way. My question is how do you guys
> calculate or figure out that interrupt is required ?.
>
I use interrupts for almost everything that is routine (that happens all
the time).

> 2. My second question is how do you calculate how much clock speed needed?
>    or should I always use 40 mhz. most of the time I use 20 mhz.
>
>

Actually, speed kills... device current can fly out of sight at 20/40mhz.

I am constantly amazed at how much performance the PIC provides at 4mhz.
I start my projects
there, then double it or triple it when  the device runs out of gas.

--Bob

> thanks
>
> Andre
>
>

> I would say that very few (1 out of 100 ?) *real*
> applications/projects could be written without
> using interrupts. They are such an integral part
> of the processor architecture, so it will be much
> harder to *not* use them.

Jan-Erik, I tend to use interrupt flags rather than the interrupt
enable. My opinion is that it is often enough to know an event
has occurred rather than respond immediately. That, however,
is very dependent on the actual application. Of course it is, and
I use hardware interrupts when necessary

For example, INT0IF=1. It maybe that this flag is set by a push
button, and there's no need to rush to the service routine for that
switch. Detecting in a main loop that the flag is set is sufficient.

OTOH it maybe a trigger, perhaps an AC zero-crossing point or
CCP, in which case the processor must act immediately via the
enabled interrupt system

There's no hard and fast rule for interrupts. You use what is
appropriate. There are some events you have to react to, there
are others you don't. In either case much depends on what else
is going on and whether interrupts enabled/disabled compromises
the work the micro has to do

> 2. Experience...

Absolutely

> 2. My second question is how do you calculate how much clock
> speed needed? or should I always use 40 mhz. most of the time
> I use 20 mhz.

Again, use what is appropriate. Consider power consumption,
cost, accuracy (crystal vs RC) etc

How are tasks ranked ? Are high-speed serial comms the priority,
is time-keeping the priority, a combination of both, do you need
two or more clocks, and so on

A very open-ended question that is best answered by itemising
and prioritising the tasks to be performed in individual cases

On 26/07/07, Bob Axtell <engineercotse.net> wrote:

> Actually, speed kills... device current can fly out of sight at 20/40mhz.

Which reminds me of something I thought of the other day.

The datasheet tells me that the max clock speed is (usually) 20MHz for
my 16F-chips. What would happen if I, say, put a 100MHz clock to the
PIC? Crapped up timing (as if the PIC was on drugs), or core meltdown
due high currents (or similiar)?

--
- Rikard - http://bos.hack.org/cv/
never tried???

Rikard Bosnjakovic wrote:
{Quote hidden}

> What would happen if I, say, put a 100MHz clock to the PIC?

It may work, but unlikely. I've accidentally PLLed a 19.6608
MHz crystal on an 18F4520 and it did run at 78.6432MHz. Some
basic tests seemed to show it was working, but I didn't try all the
modules. It didn't appear to be damaged and worked perfectly
with the correct (9.8304MHz) crystal installed. You may get away
with some slight overclocking, say to 20.48MHz and still stay in
spec. A -20 PIC is guaranteed to run at 20MHz and that's what
Microchip guarantee the specs at. It may fail at 20.2MHz, it may
work at 30MHz. I don't actually know what their factory tolerances
or expectations are. For a one-off you could take a chance. Not
something you should do for production though

> the FT245R for USB and rely on its buffers. No interrupts needed! Also,
> I'm using an SPI 802.11 radio module that has large buffers so I don't
> need to have interrupts for it (I would if I used the uart version).

Interesting.. What device is this?
On 26/07/07, Nicola Perotto <nicolanicolaperotto.it> wrote:

> never tried???

No. The fastest crystal I have at home is 16MHz.

--
- Rikard - http://bos.hack.org/cv/
Rikard Bosnjakovic wrote:
>
> No. The fastest crystal I have at home is 16MHz.
>

You need one of these :

"Crystal-set for PIC processors".

:-) :-)

Jan-Erik.
> The datasheet tells me that the max clock speed is (usually) 20MHz for
> my 16F-chips. What would happen if I, say, put a 100MHz clock to the
> PIC? Crapped up timing (as if the PIC was on drugs), or core meltdown
> due high currents (or similiar)?

Sigh..

No, you won't kill the device, but you know those maximum clock rates
are there for a reason..  Even if it seems to function, there's no
guarantee that the next device will, or if all the instructions will
work, or that ANYTHING will work.   When you color outside the lines,
you enter the land of "anything can happen".
> "Crystal-set for PIC processors".

Hmm.. I hope those are 15pF crystals. The caps are pretty small for
typical 22pF crystals.
On 26/07/07, David VanHorn <microbrixgmail.com> wrote:
> > The datasheet tells me that the max clock speed is (usually) 20MHz for
> > my 16F-chips. What would happen if I, say, put a 100MHz clock to the
> > PIC? Crapped up timing (as if the PIC was on drugs), or core meltdown
> > due high currents (or similiar)?
>
> Sigh..
>
> No, you won't kill the device, but you know those maximum clock rates
> are there for a reason..  Even if it seems to function, there's no
> guarantee that the next device will, or if all the instructions will
> work, or that ANYTHING will work.   When you color outside the lines,
> you enter the land of "anything can happen".

It's most likely a case of "we can't guarantee that you'll make the
timings for the instructions". Slight violations probably won't hurt,
little more will make an instruction behave badly if you hit the worst
case (which you barely if ever do) and a bit more will make it fail.

Try a worst-case such as a maximum carry propagation add (0xFF....FFF
+ 1) or carry propagation sub (0 - 1), multiply with overflow, odd
interrupts etc. They should show you what's wrong with it.

As a last case, they might just have a perfect production line but
make more money if they pretend not to - IE, sell a slow model for the
normal price, "fast" model for a premium - make a profit on the

Regards,
Peter
On 26/07/07, David VanHorn <microbrixgmail.com> wrote:

> Sigh..

There's really no point in sighing. I'm interested in "what" and
"why"-questions, not "can i"-questions. I'm very well aware of that
maximum ratings exist for a reason. If, for example, a component is
rated 50mA max and you feed it with 500mA, it will burn. This is
pretty easy to realise.

What is not that easy to realise, for me, is what happens if you feed
a PIC with a clock rated five times the maximum rating. Please note
I'm was not interested in knowing if it's okay for me to use a clock
with higher rating than the maximum, I was just curious about what
could happen.

As already stated I don't have a crystal that's beyond my PICs'
max-rating, hence the question since I cannot try it on my own.

--
- Rikard - http://bos.hack.org/cv/
> What is not that easy to realise, for me, is what happens if
> you feed a PIC with a clock rated five times the maximum
> rating.

I recall someone overclocking a 16C84 or 16F84 (10 MHz rated) to ~ 16
mhz or so, which seemed to work, but required a good stable 5V. IIRC it
failed at >= 22 MHz.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

About couple of years ago, I overclocked a Tiny11 rated at 6MHz to
11.0592MHz and it worked ok for the application.

Well, I would have lost a quarter if the device burnt :-)

--
Chetan Bhargava
Web: http://www.bhargavaz.net
Blog: http://microz.blogspot.com
> About couple of years ago, I overclocked a Tiny11 rated at
> 6MHz to 11.0592MHz and it worked ok for the application.
>
> Well, I would have lost a quarter if the device burnt :-)

IIRC overclocking at low temperatures and 5.00V has a better chance than
higher tempertaures and wider power range.

Did you check at higher temperatures?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> What is not that easy to realise, for me, is what happens if you feed
> a PIC with a clock rated five times the maximum rating. Please note
> I'm was not interested in knowing if it's okay for me to use a clock
> with higher rating than the maximum, I was just curious about what
> could happen.

Things stop working, in an unpredictable manner, worse as frequency
increases, along a slope of unknown shape.  Even if they work, you
can't depend on it to keep working. If you build another one exactly
the same, that one may or may not work.

I've never really understood the rationale behind "overclocking",
hence the "sigh"..

I can't use an overclocked device in production.
I've never seen a case where writing the code better, or other "legal"
solutions wouldn't achieve the goals.
Even in hobby projects, my fun time is so limited and valuable to me,
that I'm not willing to waste it trying to debug flaky bullshit
problems that would occur from an overclocked processor.

Internally, pretty much everything happens because capacitors (the
gates of fets) are being charged and discharged.  The manufacturer
guarantees that at speed X, in all cases of temperature, voltage, etc
within the data sheet ratings, that everything will perform as
documented.  Beyond that, you're on your own.

Non-deterministic execution is NOT a feature.  :)
> IIRC overclocking at low temperatures and 5.00V has a better chance than
> higher tempertaures and wider power range.

Yeah it was running at 5V, didn't check the current though. Tiny11-6PC
operating voltage range is pretty narrow anyways.

> Did you check at higher temperatures?

No, I just checked at normal room temperature.

--
Chetan Bhargava
Web: http://www.bhargavaz.net
Blog: http://microz.blogspot.com

>-----Original Message-----
>From: piclist-bouncesmit.edu [piclist-bouncesmit.edu]
>On Behalf Of David VanHorn
>Sent: 26 July 2007 19:16
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] how to calculate if interrupt is required?
>
>
>Non-deterministic execution is NOT a feature.  :)

It must be a feature, Microchip included it on many of their later micros, even running at default clock speed :(  I seem get a new errata every week from them.  Seems like the Microsoft beta testing strategy, but the silicon is a lot harder and slower to get fixed.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

> >
> >Non-deterministic execution is NOT a feature.  :)
>
> It must be a feature, Microchip included it on many of their later micros, even running at default clock speed :(  I seem get a new errata every week from them.  Seems like the Microsoft beta testing strategy, but the silicon is a lot harder and slower to get fixed.

If you leave the CKOPT fuse in an AVR in the default state, and then
use an external crystal or resonator, you get much the same effect.
The default mode is a "vittoz" low power oscillator, which has barely
enough amplitude to clock the chip.  Symptoms include slightly slow
baud rates, undebuggable errors that happen once in a few seconds of
operation, emulation problems like doing 2-10 instructions on a
"single step", without actually DOING some/most/all of them, other fun
things.

Why that's the default state is something that I've never heard a good
explanation of.
I've helped a number of people with products they were shipping that
had this problem, with wierd symptoms in some systems, but not all.
Funny how things completely clear up when the clock is actually high
enough amplitude to run the system.

> Rikard Bosnjakovic wrote:

>>The datasheet tells me that the max clock speed is (usually) 20MHz for
>>my 16F-chips. What would happen if I, say, put a 100MHz clock to the
>>PIC? Crapped up timing (as if the PIC was on drugs), or core meltdown
>>due high currents (or similiar)?
>>
I usually overclock them some 20% higher... sounds reasonable to me :)

{Quote hidden}

Including me, thanks ;)  That said I didn't see any problems which could be attributable to the oscillator, even over temperature, but it's nice to now that product is shipping with it set correctly.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

> Including me, thanks ;)  That said I didn't see any problems which could be attributable to the oscillator, even over temperature, but it's nice to now that product is shipping with it set correctly.

We didn't notice it at first.. The baud rate was not off enough to
cause a problem, and I was picked on for "wanting everything to be
perfect".. It was good enough, but it was wrong.  The glitches and
emulation problems didn't seem to be related.
Jan-Erik,

On Thu, 26 Jul 2007 15:39:00 +0200, Jan-Erik Soderholm wrote:

>...
> You need one of these :
>
> "Crystal-set for PIC processors".
>
> :-) :-)

Hmmm... the seller is "Sodjan"... no relation, I suppose?  :-)

Do you sell those to us foreigners that don't speak Swedish?  I haven't checked my stock of crystals recently, but this looks like a good package to
replenish it when necessary.

Cheers,

Howard Winter
St.Albans, England

On 30/07/07, Howard Winter <HDRWh2org.demon.co.uk> wrote:

> Do you sell those to us foreigners that don't speak Swedish?

In the auction, the line "Accepterade köpare:          Internationellt"
roughly means "I accept international bidders".

--
- Rikard - http://bos.hack.org/cv/
Hi.

It's a local Swedish-speaking aucction site (owned
by eBay b.t.w). Part of my busniess is to find nice
(mainly surplus) stuff round the world (mostly through
eBay) and resell to the local hobbyist electronics
market in Sweden.

But by all means, I can ship anywhere. Just send me an
email and we'll arrange everything. See :
other info.

Regards,
Jan-Erik.

Howard Winter wrote:
{Quote hidden}

Hi.
I live in Brazil, and bought components from Jan-Erik some time ago (eBay
auction), and received the parts without any problems. So, I can confirm
that Jan-Erik is very trusty and really can ship anywhere.
Thanks Jan-Erik,
Fabricio.

{Original Message removed}

> Which reminds me of something I thought of the other day.
>
> The datasheet tells me that the max clock speed is (usually) 20MHz for
> my 16F-chips. What would happen if I, say, put a 100MHz clock to the
> PIC? Crapped up timing (as if the PIC was on drugs), or core meltdown
> due high currents (or similiar)?
>
A clock thats too fast can damage a chip by increasing its power
consumption. With what you propose anything synchronised to the main
clock will increase in power consumption by a factor of almost 5. I
don't know if this will produce enough heat to actually damage the chip
but its certainly a possibility.

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