Dwayne Reid wrote:
.........
>>One problem with this whole concept is that each PIC will have its own local
>>state.  You might be able to get around this by using a shared IIC ram or
>>something.  I suppose this is all possible but it feels rather "messy".
>>That usually means it's time to step back and look at the overall problem
>>you are trying to solve again.
>
>But that is the neat thing about Dan's idea - the 'inactive' pic really
>*IS* inactive!  Its in reset.  There is no state to maintain.
>
>What that means is that you could have one program for the low speed / low
>power mode and a completely different program for the high speed
>mode.  Both programs (pics) share the same i/o lines.  All that is required
>is a couple of inverters to switch the MCLR lines.  The inverters would be
>cross-coupled so that one pic is always running with the 'input' of one of
>the inverters tied to an i/o line.  Switching from one pic to the other
>would be as simple as setting that line to the opposite state.
>
>It sounds like a workable concept.
>


Thanks Dwayne, obviously there are various kinds of problems with any
new arrangement, but heck to an engineer, a problem is just something
looking for a solution [sorry about the sophomoric moralizing - he, he].

Vis-a-vis your "cross-coupled inverters", I figure you wouldn't really
need these. You might have something like one PIC wakes up the other,
which then checks the I/O state of the system, matches it, and puts
the first to sleep. You could also put series Rs in critical lines to
guarantee against outputs accidentally fighting each other.

And actually, if you check my latest idea in another msg - ie, the
PICcyBackWartPoacher schema - the slow PIC might never go to sleep.
This whole thing is just a casual brainstorming exercise.

best regards,
- Dan Michaels
Oricom Technologies
===================

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