Searching \ for '[OT]: Choice of microcontroller, microprocessor an' 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=choice+microcontroller
Search entire site for: 'Choice of microcontroller, microprocessor an'.

Exact match. Not showing close matches.
PICList Thread
'[OT]: Choice of microcontroller, microprocessor an'
2001\04\18@021127 by Michael Pont

flavicon
face
Dear PICList members,

This is some way off topic...

I'm on something of a mission.  I've spent the last three years seeking to
demonstrate that software architectures using a single, timer-based,
interrupt are both (1) very predictable and - hence - reliable, and (2) easy
to use, even for those new to embedded systems.  This form of
'time-triggered' architecture has been the focus of my university research
and teaching.

I've done my previous work using the 8051 family, and am now aiming to build
a range of demonstration systems using some other popular microcontroller,
microprocessor and DSP families.

This is the list of platforms I intend to cover in the next phase of this
work:

8051
PIC

Infineon C166/167
ARM

TMS320xxx

80x86


Have I missed anything out?  Should I drop any of these suggestions?

If any members of PICList are willing to venture an opinion, I'd be
interested to hear it.

Best wishes,

Michael.

+================================================================+

 Michael J. Pont
 http://www.le.ac.uk/engineering/mjp9/.

+================================================================+

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


2001\04\18@024322 by Your.message.of.Tue

flavicon
   I've spent the last three years seeking to demonstrate that software
   architectures using a single, timer-based, interrupt are both (1) very
   predictable and - hence - reliable, and (2) easy to use, even for
   those new to embedded systems.

Interesting idea.  You should probably look at the Scenix (now Ubicom)
"virtual peripheral" stuff, since it sounds rather similar.  They're
somewhat PIC compatible.

   This is the list of platforms I intend to cover in the next
   phase of this work:
   8051    PIC    Infineon C166/167    ARM    TMS320xxx    80x86

You definately need to add some motorola architectures - too bad they have
so many different ones to choose from.  How about 68hc908xx (midrange flash
microcontroller), Coldfire (more or less 68000-like, and especially
interesting because of it's used in the Palm handhelds), and PowerPC.

The TI MSP430 and the Atmel AVR are also of interest, at least to me.


   If any members of PICList are willing to venture an opinion, I'd be
   interested to hear it.

So you have the single timer interrupt handle all "time-critical" IO?  Or
something fancier in the way of scheduling non-interrupt-level tasks?

Sounds like one major problem is that you can lose prioritization of the
tasks you need to do during interrupts (which would normally happen because
of different interrupt priorities, if the processor is so equipped.)

What sort of timer interrupt frequency are you looking at, and what
percentage of the time do you plan on spending in the interrupt service
routine?  Seems like you'd need to have quite a high interrupt rate to
handle even moderate-speed popular IO methods (ie 500+ Hz to handle 9600bps
UART.)  (I don't really know if people consider 500Hz to be a high
interrupt rate for a timer.  Cisco's IOS timer is 4ms, a DEC-20 is 60Hz,
and an IBMPC is about 20Hz, right?)

BillW

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


2001\04\18@042406 by Bob Ammerman

picon face
I find your thesis very interesting. I can see the sense of it, tho' you are
limiting performance to gain simplicity -- so what's new :-)

I'm not sure what implementing this idea on all those platforms does to
further your thesis, but all the mentioned platforms make sense.

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

{Original Message removed}

2001\04\18@092119 by Michael Pont

flavicon
face
Bill,

> So you have the single timer interrupt handle all "time-critical" IO?  Or
> something fancier in the way of scheduling non-interrupt-level tasks?
>
> Sounds like one major problem is that you can lose prioritization of the
> tasks you need to do during interrupts (which would normally happen
> because of different interrupt priorities, if the processor is so
> equipped.)
>
> What sort of timer interrupt frequency are you looking at, and what
> percentage of the time do you plan on spending in the interrupt service
> routine?  Seems like you'd need to have quite a high interrupt rate to
> handle even moderate-speed popular IO methods (ie 500+ Hz to
> handle 9600bps UART.)
> (I don't really know if people consider 500Hz to be a high
> interrupt rate for a timer.  Cisco's IOS timer is 4ms, a DEC-20 is 60Hz,
> and an IBMPC is about 20Hz, right?)

There is only a *single* active interrupt source (the timer used to drive
the system).  In most cases, the architecture is a (pure) co-operative
scheduler: tasks can be scheduled to run (usually periodically) at set
times.  Each task, once started, runs to completion.  All of the code (all
of it) is in 'C'.

The typical interrupt frequency is 1000 Hz: even on an 8051, the scheduler
uses a small percentage (around 5% is typical on a basic device, 12 MHz
clock frequency).  With more modern 8051 chips, the load drops to very low
levels.

I'm not claiming that this architecture is unique in any way (I borrowed it
from the aircraft industry, where it is the norm).  Neither am I claiming
that it is the right solution for *all* systems.

> You definately need to add some motorola architectures - too bad they have
> so many different ones to choose from.  How about 68hc908xx (midrange
>flash
> microcontroller), Coldfire (more or less 68000-like, and especially
> interesting because of it's used in the Palm handhelds), and PowerPC.

The PowerPC is a good idea, and is now on my list - thanks.

> The TI MSP430 and the Atmel AVR are also of interest, at least to me.

I'd like to cover the AVR devices, but I'm currently finding that Atmel are
being very 'difficult' with copyright issues: even getting permission to
publish pinouts of their chips in my latest book is proving an uphill
struggle .  I don't want to spend my life in court, so the AVR family won't
be covered in my next project: it's their loss...

Best wishes,

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


2001\04\18@093619 by Alan B. Pearce

face picon face
>I'd like to cover the AVR devices, but I'm currently finding that Atmel are
>being very 'difficult' with copyright issues: even getting permission to
>publish pinouts of their chips in my latest book is proving an uphill
>struggle .  I don't want to spend my life in court, so the AVR family won't
>be covered in my next project: it's their loss...

I would even go as far as to say something along the lines of "AVR devices
have not been covered in this publication due to problems with copyright
permissions" to make it obvious you tried and were not allowed.

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


2001\04\18@095916 by Peter Tiang

flavicon
face
Don't forget Motorola's range of 8-bit MCU.
They are the top selling 8-bit MCU in the world.

Regards,
Peter Tiang

{Original Message removed}

2001\04\18@101138 by Michael Pont

flavicon
face
Bob,

> I'm not sure what implementing this idea on all those
> platforms does to further your thesis, but all the mentioned
> platforms make sense.

The previous work I have published in this area used only the 8051 family.
Although this is now a very extensive family, its members obviously cannot
compete (in terms of processor power, and - to a lesser extent - memory
resources) with some of the processors I listed.  This limited the range of
applications that I could consider: as a result, it can be argued that I
have, to date, only demonstrated the effectiveness of this approach for a
limited range of comparatively low-performance systems.

My intention in this new project is to explore the limits of the
time-triggered architecture by building a number of demonstrator systems
using the various processor families mentioned in my previous e-mail.  The
final list of demonstrators has not yet been finalised, but it will probably
include a cruise-control application, a speech recognition system, and a
large-scale CMFD (condition monitoring and fault diagnosis) system, since
these are application areas in which I have some experience.  Again, all of
the applications will be created in 'C'.

At the end of the project, full details of various demonstrators will be
published.  At this stage, other university departments and companies will
be free to try and demonstrate that their favourite solution (e.g. real-time
operating system, assembly-language framework, multi-interrupt architecture,
or whatever) can solve these problems more effectively...

Best wishes,

Michael.

{Original Message removed}

2001\04\18@102606 by Michael Pont

flavicon
face
> Don't forget Motorola's range of 8-bit MCU.
> They are the top selling 8-bit MCU in the world.

Is this correct?

The 'rumours' I hear suggest that - together - the various members of the
(vast) 8051 family account for more than 50% of the 8-bit microcontroller
market - and have the largest share (around 30%) of the microcontroller
market as a whole.   (In addition, in Myke Predko's latest PIC book, he
suggests that the PC is in second position.)

If anyone has a reliable source of more accurate figures, I'd be interested
to hear them.

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


2001\04\18@125328 by Peter Tiang
flavicon
face
   Well according to a 1998 report #1 is Motorola, #2 is NEC

   http://www.techweb.com/se/directlink.cgi?EBN19980330S0009

   Microchip was not even in the top 10 list.

   Of course, this does not really tell you the actual # of units
   shipped, but the fact that Motorola shipped its 2nd billionth
   68HC05 in April 1997 gives us an idea.

   According to another report:

   http://www.edtn.com/news/nov06/110698bnews3.html

   8-bit MCU account for half of Motorola's 1998
   US$1.6b revenue from MCU sales, making Motorola
   the world largest MCU vendor.

   The PIC is popular due to its accessibility, but
   that does not mean it's really shipping in volume.

Regards,
Peter Tiang

{Original Message removed}

2001\04\19@042452 by uter van ooijen & floortje hanneman

picon face
> I'm on something of a mission.  I've spent the last three years seeking to
> demonstrate that software architectures using a single, timer-based,
> interrupt are both (1) very predictable and - hence - reliable, and (2)
easy
> to use, even for those new to embedded systems.

With only one interrupt, how do you handle a combination of tasks, for
instance
- task at 100 kHz taking 5 uS (uses 50%, 50% left over)
- task at 1kHz taking 100 uS (uses 10%, 40% left over)
This is the same problem that makes it hard to make arbitrary combinations
of Ubicom/Scenix virtual peripherals.

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


2001\04\19@050723 by Roman Black

flavicon
face
wouter van ooijen & floortje hanneman wrote:
>
> > I'm on something of a mission.  I've spent the last three years seeking to
> > demonstrate that software architectures using a single, timer-based,
> > interrupt are both (1) very predictable and - hence - reliable, and (2)
> easy
> > to use, even for those new to embedded systems.
>
> With only one interrupt, how do you handle a combination of tasks, for
> instance
> - task at 100 kHz taking 5 uS (uses 50%, 50% left over)
> - task at 1kHz taking 100 uS (uses 10%, 40% left over)


That's a good point, but I too like using one single
timer based interrupt where possible. I use a few tricks,
like resetting timer1 4 insts after timer0, so they
remain almost in sync, and this makes timer1 guaranteed
to overflow actually during the timer0 int. That means
I can update both timer overflows in the one interrupt,
and guarantees that no other processes are being executed
at the time either of the two timers are overflowing.

In your case above I would have one int at 100kHz. Obviously
this would need an external int clock source on a PIC!
Then every 100 ints (1kHz) I would set a flag, and when
this is detected do the other process outside the int
handler. This is even superior to your dual-int system
as the 100kHz task is maintained even during the 1kHz
task. With dual ints the 100kHz task would be neglected
during the slower task.

It is quite possible to have only one int (say on timer0
overflow), and do a number of regular timed process all
with their own heirarchy of priority. I often use the 16F84
for tasks that push it's limits, because we buy them in
bulk and I always have lots handy. Only one timer... :o)
-Roman

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


2001\04\19@175440 by Bruce Cannon

picon face
Wouter:

I didn't understand your question.  Doesn't one have to set priorities in
any system where two events might begin at the same time?  And in any system
with multiple tasks performed by one execution unit, don't we always face
situations where one task will 'want' to begin while another is being
executed?  Seems to me that independent hardware is the only way around
those characteristics?

Bruce Cannon
Silicon Crucible
(510) 787-6870
1228 Ceres ST Crockett CA 94525

Remember: electronics is changing your world...for good!

> With only one interrupt, how do you handle a combination of tasks, for
> instance
> - task at 100 kHz taking 5 uS (uses 50%, 50% left over)
> - task at 1kHz taking 100 uS (uses 10%, 40% left over)
> This is the same problem that makes it hard to make arbitrary combinations
> of Ubicom/Scenix virtual peripherals.

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


2001\04\20@014000 by uter van ooijen & floortje hanneman

picon face
> I didn't understand your question.  Doesn't one have to set priorities in
> > With only one interrupt, how do you handle a combination of tasks, for
> > instance
> > - task at 100 kHz taking 5 uS (uses 50%, 50% left over)
> > - task at 1kHz taking 100 uS (uses 10%, 40% left over)
> > This is the same problem that makes it hard to make arbitrary
combinations
> > of Ubicom/Scenix virtual peripherals.

Maybe I was not clear enough, I'll add the deadlines:
- task at 100 kHz taking 5 uS, deadline does not matter because it is the
highest priority task (uses 50%, 50% left over)
- task at 1kHz taking 100 uS, deadline must be at least 200 uS because only
50% CPU remains (uses 10%, 40% left over)
- main task, uses the leftover CPU time (40%)
But note that this is just an example. Deadline analysis shows that this
combination can be scheduled on one CPU, but I can not imagine a way to
implement this using only one non-nestable interrupt as on 14-bit PICs (that
is the real problem, not the one timer).

Wouter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@024455 by Michael Pont

flavicon
face
Wouter,

You are, of course, right.

Co-operative, time-triggered architectures have many advantages (easy to
build, easy to understand, very predictable).  However, in some
circumstances there can be a need to run both long tasks (e.g. 100 ms
duration every 1000 ms) and one or more short frequent task (e.g. 0.1 ms
duration every 1 ms); these two requirements can conflict in a co-operative
system, where - for all tasks, under all circumstances - the (worst-case)
task duration must satisfy the condition:

 Tick Interval < Task duration

Where this condition is not satisfied, there are several ways of meeting the
need for both 'frequent' and 'long' tasks.  For example, by using a faster
processor, or a faster oscillator you can shorten the task durations .
Alternatively, you can sometimes make use of timeout code (to avoid
excessive task durations), or re-design long tasks so that they are
implemented in more frequent calls to short tasks (this is a common and very
effective solution, usually overlooked).

However, even these solutions cannot always match the requirements, and
there are two other alternatives:

1.
Use a (time-triggered) multi-processor architecture.  This solves most
problems, at the cost of one (or more) additional processors

2.
If you are determined to use a single processor, use a 'hybrid' scheduler.
This is still time-triggered (and can still be written entirely in C).  It
can safely support a single pre-emptive task, and as many co-operative tasks
as you need.  The pre-emptive task can interrupt any of the co-operative
tasks, but cannot itself be interrupted.  It's not as predictable as the
(pure) co-operative, time-triggered, solution, but it is reliable (and it's
not a perfect world).

These are all areas I have explored in detail over the last few years.

Best wishes,

Michael.

Michael J. Pont
http://www.le.ac.uk/engineering/mjp9/

{Original Message removed}

2001\04\20@030458 by uter van ooijen & floortje hanneman

picon face
> If you are determined to use a single processor, use a 'hybrid' scheduler.

But that gives still less flexibility than a deadline-based scheduler, which
can also offer fully predictable deadlines. IMHO the best solution - when
nested interrupts are available, or when you have access to the stack - is
still the deadline-based scheduling. Sadly the PIC (14-bit) does not fall
into this category.

On a single-interrupt architecture like the PIC (14b) a lot can still be
done by carefull coding, but I have not found a good way to write re-useable
(library) code for time-driven tasks which must be able to co-operate with
an arbitrary set of other (higher or lower deadline) tasks. But as said,
this certainly does not rule out all kinds of nifty implementations of a
specific set of tasks.

Wouter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@033229 by Bill Westfield

face picon face
> > - task at 100 kHz taking 5 uS (uses 50%, 50% left over)
> > - task at 1kHz taking 100 uS (uses 10%, 40% left over)

I beleive that things are only going to be "simple" when the tasks that need
to be done at interrupt level are much shorter than the interrupt interval.
So you couldn't have a 100uS length task if you had devices that needed
serviced at 100kHz (that's every 10us, right?)

Seems to me that it's pretty dependent on having a relatively small set of
peripherals to poll, and/or good decoding to make polling them easy.  We
used to gain a lot of cycles (usually) on out 16-port async card because we
had implemented a per-board register(s) that sumarized the interrupt status
of all 32 interrupt sources on the board.  So finding the one port in 96
that had or needed data (all at the same interrupt level) was a lot easier
than scanning 96 UART status registers.

When you get to having a lot of io devices, it's nice if your interrupt
hardware gives you as much information as possible to narrow down the sorce
of the interrupt.  Vectoring helps, and some chips have internal (but
externally daisy-chainable) schemes to tell you which port need service
(complete with rotating priority), as well as loading up the appropriate
context for you to manipulate...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@041955 by Peter L. Peres

picon face
wouter van ooijen & floortje hanneman <.....wfKILLspamspam.....XS4ALL.NL> wrote:
> With only one interrupt, how do you handle a combination of tasks, for
> instance
>  - task at 100 kHz taking 5 uS (uses 50%, 50% left over)
> - task at 1kHz taking 100 uS (uses 10%, 40% left over)
> This is the same problem that makes it hard to make arbitrary
> combinations
> of Ubicom/Scenix virtual peripherals.

There is no problem at all with the scenario you describe. As long as the
100us task can accept a latency of 5us+overhead. The timer will run
(preferrably) at the highest possible speed, or at least 100kHz and the
100kHz task will be interruptible.

The problems begin when latency is not acceptable or when repeatable
timing is required (temporal determinism) afaik. Thus running an I2C
peripheral and a RS232 receiver in parallel begins to be interesting.

One conceptual solution for small systems is to make sure that there is
only one critically timed task running at any given time (I2C peripheral
does not function at the same time the RS232 receiver does f.ex.). This
requires some clever thinking beforehead that has nothing to do with
coding. However, it works. It is also possible to interleave tasks by hand
using a script and markup in the source. I have done this, it is not fun,
but it works.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@064636 by Roman Black

flavicon
face
wouter van ooijen & floortje hanneman wrote:
{Quote hidden}

I must be real thick. :o) I still don't see what
the problem is. I regularly schedule harder tasks
than this with only one int, timer based.

1. main int 100kHz (top priority, always int)
2. every 100 ints, at the end of the int handler
we set a flag for task 2.
3. At regular points throughout the main code
(as often as possible) we check the task two
flag and exit from main code to perform task 2
until it is done.
4. all priorities are maintained and it works
fine up to 100% of timeslice being used, at which
point it starts reducing time given the lowest
priority code, which is the main code.

-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@071805 by uter van ooijen & floortje hanneman

picon face
> I must be real thick. :o) I still don't see what
> the problem is. I regularly schedule harder tasks
> than this with only one int, timer based.
>
> 1. main int 100kHz (top priority, always int)
> 2. every 100 ints, at the end of the int handler
> we set a flag for task 2.
> 3. At regular points throughout the main code
> (as often as possible) we check the task two
> flag and exit from main code to perform task 2
> until it is done.
> 4. all priorities are maintained and it works
> fine up to 100% of timeslice being used, at which
> point it starts reducing time given the lowest
> priority code, which is the main code.

We are talking about different things. I am looking for a general solution,
which (IHMO) does not exists, while you state that (IYHO?) for a particular
set of tasks a working program can be made (which I do not deny).

Your solution is not general enough for me because the main task must, at
regular points (frequency at least 1/ deadline of task2) check for the flag,
which can be very annoying (for instance in the middle of a
compiler-supplied floating point multiply routine). And I don't like the
fact that the main task must know the timing details of the other task(s).

Wouter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@074704 by Roman Black

flavicon
face
wouter van ooijen & floortje hanneman wrote:
{Quote hidden}

Thanks for explaining Wouter. I get what you mean
now. I'm very hardware oriented and think in less
"general" terms than you do. I've never coded a
"general" solution to a problem yet, i'll leave
that to Microsoft. ;o)

But the system I described is (almost) valid as
a type of manual nested interrupt. Using your
example of a long floating point math function in
the main code, you were prepared to have it
interrupted anyway.

My method is worse than a real interrupt because
you have to actually check the flag during your
big functions. BUT, it is also better than a real
interrupt because you get some control
of when your manual "interrupt" occurs. I find
this is a good trade-off and can give some powerful
(but not general?) solutions. :o)

You could code it as a more general approach using
a single call to the manual int routine which
you insert at many places during your big code
functions. Then you could customise the manual
int routine itself, maybe even handling more than
one "int" and more than one task, giving you a
similar "general" functionality to a real interrupt.
Obviously your manual int can do similar context
saving to a real int, because call,btfss,return
do not affect flags or w contents.
Does that make sense?
And you get more control of WHEN it happens.

-Roman

General = solves a number of problems badly...
Specific = solves one problem extremely well...
;o)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@080718 by uter van ooijen & floortje hanneman

picon face
> General = solves a number of problems badly...
> Specific = solves one problem extremely well...

Right, so I prefer a general solution to solve 99% of my problems (for which
a mediocre solution is sufficient), so I can devote 100% of my energy to the
remaining 1% which is really hard an requires a clever solution...

Doesn't that sound a bit like the assembler-versus-compiler wars? A compiler
is quick and mediocre compared to hand-crafted assembly, but also a lot
quicker than a human assembly writer!

But I think we both understand each others wievpoint: relly clever things
can be done by cooperative multitasking (that is what you describe), but you
must deisgn your whole application with this approach in mind (that might
become a problem when do don't design your whoole application:
compiler-inserted stuff, 3d-party libraries etc.)

Wouter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@081925 by Roman Black

flavicon
face
wouter van ooijen & floortje hanneman wrote:
>
> > General = solves a number of problems badly...
> > Specific = solves one problem extremely well...
>
> Right, so I prefer a general solution to solve 99% of my problems (for which
> a mediocre solution is sufficient), so I can devote 100% of my energy to the
> remaining 1% which is really hard an requires a clever solution...

Ha ha! Hey, you were the guy who wanted a 100kHz task
of max priority and a 1kHz task of high priority and
a main task which uses all the rest of your timeslice...
That sounds like a VERY specific problem to me. ;o)


> Doesn't that sound a bit like the assembler-versus-compiler wars? A compiler
> is quick and mediocre compared to hand-crafted assembly, but also a lot
> quicker than a human assembly writer!
>
> But I think we both understand each others wievpoint: relly clever things
> can be done by cooperative multitasking (that is what you describe), but you
> must deisgn your whole application with this approach in mind (that might
> become a problem when do don't design your whoole application:
> compiler-inserted stuff, 3d-party libraries etc.)

Absolutely agree. There's always going to be the C++
guys, and i'll probably always be a C-- guy. And I
guess we all have our place. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\20@184143 by michael brown

flavicon
face
Forgive me if I am missing something here.  Also, when it comes to Pics I am
probably on slightly
more knowledgeable than your average garden slug. :-)

But, can't you re-enable interrupts within the 1Khz high priority routine so
that the 100Khz max priority routine
will be entered right away.  As long as you use different save areas for the
STATUS, W,  etc.
shouldn't the interrupts "unwind" (or perhaps yoyo) with no ill effects.  Of
course you couldn't enable
interrupts from within the max priority routine as this could lead to
overlapping or recursive destruction
of the register save areas.  And of course I am "ass/u/meing" that its ok to
interrupt the 1Khz priority
routine and that you wont cause the stack to overflow in the worst case
situation.

Michael Brown
Instant Net Solutions
http://www.KillerPCs.net

{Original Message removed}

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