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