Post by thread:[PIC]: MultiPICs = PushMePullYou <-- Cudos

Lance Allen wrote: >Bob Ammerman wrote: > >> Here's a question/contest: >> >> who has built the system containing the most PICs? >> >> I suppose we'll need a few categories: >> >> Most PICs on one board >> >> Most PICs in one box >> >> Most PICs in one room >> >> Most PICs interconnected worldwide via any medium >> > >I am sure this will be puny my many standards but my record is 3 on one board, a >16C74, 16F84 and 16C54 all used to control a powerful stepping motor in very fine >increments of speed.. a sort of DDS, drive a 9 digit LED display, read an encoder >and various other inputs. It worked well too. >Now I would use an (stone the heretic!) Atmel FPslic combined FPGA and AVR core >since I now have access to all the development gear for such beasts at my new job. > Hmmm, this is just the latest weird thought from the weird land somewhere over the rainbow - ie, Boulder, where Dorothy landed after leaving Kansas: People keep wanting to run a PIC off 2 different clocks. So how's about 2 PICs, wired with all pins exactly connected in parallel, except /MCLR and OSC. One goes 20 Mhz, the other 32Khz. When one is going, the other is held in reset /MCLR=low [and all pins float]. Exact interplay details to be worked out. To be called the "2DoNothing" or "pushmepullyou" circuit, or something or other. So how much mA does a PIC draw when held in reset, anyways? Powerdown current = 1.5 uA ?????? - danM -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads

In the wild flurry to be the first to sail a PIC around the world, my poor little pushmepullyou idea was overlooked. This is actually a serious inquiry. Any comments about having dual-clock operation by putting 2 PICs exactly in parallel, with each running off a different clock - say 20mhz vs 32khz ??? See below: ========= Lance Allen wrote: {Quote hidden}>Bob Ammerman wrote: > >> Here's a question/contest: >> >> who has built the system containing the most PICs? >> >> I suppose we'll need a few categories: >> >> Most PICs on one board >> >> Most PICs in one box >> >> Most PICs in one room >> >> Most PICs interconnected worldwide via any medium >> > >I am sure this will be puny my many standards but my record is 3 on one board, a >16C74, 16F84 and 16C54 all used to control a powerful stepping motor in very fine >increments of speed.. a sort of DDS, drive a 9 digit LED display, read an encoder >and various other inputs. It worked well too. >Now I would use an (stone the heretic!) Atmel FPslic combined FPGA and AVR core >since I now have access to all the development gear for such beasts at my new job. > Hmmm, this is just the latest weird thought from the weird land somewhere over the rainbow - ie, Boulder, where Dorothy landed after leaving Kansas: People keep wanting to run a PIC off 2 different clocks. So how's about 2 PICs, wired with all pins exactly connected in parallel, except /MCLR and OSC. One goes 20 Mhz, the other 32Khz. When one is going, the other is held in reset /MCLR=low [and all pins float]. Exact interplay details to be worked out. To be called the "2DoNothing" or "pushmepullyou" circuit, or something or other. So how much mA does a PIC draw when held in reset, anyways? Powerdown current = 1.5 uA ?????? - danM -- 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

Bob Ammerman wrote: >First major problem: > >The 2 PICs will not have the same values in RAM. > >Other than that... not a bad scheme. > >What you would have to do is when changing speeds copy the data from the PIC >that is going to sleep to the one that is going to remain awake. > Since the PICs are held with /MCLR low between ops, you're starting from scratch each time it boots up, so you have to take this into account anyway. -- 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

It is a unique idea, but I suspect that it would be less (in terms of cost, board space, and design headaches) to use some logic to switch a single chip from high to low speed and vice versa. -Adam Dan Michaels wrote: {Quote hidden}> > In the wild flurry to be the first to sail a PIC around > the world, my poor little pushmepullyou idea was overlooked. > > This is actually a serious inquiry. Any comments about having > dual-clock operation by putting 2 PICs exactly in parallel, > with each running off a different clock - say 20mhz vs 32khz ??? > > See below: > ========= > > Lance Allen wrote: > >Bob Ammerman wrote: > > > >> Here's a question/contest: > >> > >> who has built the system containing the most PICs? > >> > >> I suppose we'll need a few categories: > >> > >> Most PICs on one board > >> > >> Most PICs in one box > >> > >> Most PICs in one room > >> > >> Most PICs interconnected worldwide via any medium > >> > > > >I am sure this will be puny my many standards but my record is 3 on one > board, a > >16C74, 16F84 and 16C54 all used to control a powerful stepping motor in > very fine > >increments of speed.. a sort of DDS, drive a 9 digit LED display, read an > encoder > >and various other inputs. It worked well too. > >Now I would use an (stone the heretic!) Atmel FPslic combined FPGA and AVR core > >since I now have access to all the development gear for such beasts at my > new job. > > > > Hmmm, this is just the latest weird thought from the weird > land somewhere over the rainbow - ie, Boulder, where Dorothy > landed after leaving Kansas: > > People keep wanting to run a PIC off 2 different clocks. So > how's about 2 PICs, wired with all pins exactly connected in > parallel, except /MCLR and OSC. One goes 20 Mhz, the other > 32Khz. When one is going, the other is held in reset /MCLR=low > [and all pins float]. Exact interplay details to be worked > out. To be called the "2DoNothing" or "pushmepullyou" circuit, > or something or other. > > So how much mA does a PIC draw when held in reset, anyways? > Powerdown current = 1.5 uA ?????? > > - danM > > -- > 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 -- 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

> This is actually a serious inquiry. Any comments about having > dual-clock operation by putting 2 PICs exactly in parallel, > with each running off a different clock - say 20mhz vs 32khz ??? I don't know how much a PIC draws if held in reset. It's a static CMOS device, so probably very little, but you are still relying on unspeced values. A cleaner way to switch between the PICs would be to control the power directly thru a series FET or something, or maybe have the "off" PIC go to sleep on its own. 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. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, spam_OUTolinTakeThisOuTcognivis.com, http://www.cognivis.com -- 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

At 05:32 PM 10/20/00 -0400, Olin Lathrop wrote: > > This is actually a serious inquiry. Any comments about having > > dual-clock operation by putting 2 PICs exactly in parallel, > > with each running off a different clock - say 20mhz vs 32khz ??? > >I don't know how much a PIC draws if held in reset. It's a static CMOS >device, so probably very little, but you are still relying on unspeced >values. A cleaner way to switch between the PICs would be to control the >power directly thru a series FET or something, or maybe have the "off" >PIC go to sleep on its own. Switching VDD is probably not an option - the ESD protect diodes on the pin will try to power the PIC that is supposed to be dead. >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. dwayne Dwayne Reid <.....dwaynerKILLspam@spam@planet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. -- 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

I think it is an absolutely brilliant idea Dan, dual processing in a very clever form. It also goves the option of having different code in each pic for further control of energy use vs performance. The ram/eeprom issue may be a problem, as the two PIC would not have the same memory, but for some apps this might not matter, and in other apps an external eeprom etc would be useful anyway, they could share it. The only bad point? Maybe the price of two PICs? Maybe you could "push me pull me" with a 12xx pic and a f877 or something, with them sharing some essential pins like the input/buttons, but only the big pic having the output power driver stuff. That might work cool too. "big brain small brain" stuff. :o) -Roman Dan Michaels wrote: {Quote hidden}> > In the wild flurry to be the first to sail a PIC around > the world, my poor little pushmepullyou idea was overlooked. > > This is actually a serious inquiry. Any comments about having > dual-clock operation by putting 2 PICs exactly in parallel, > with each running off a different clock - say 20mhz vs 32khz ??? > > See below: > ========= > > Hmmm, this is just the latest weird thought from the weird > land somewhere over the rainbow - ie, Boulder, where Dorothy > landed after leaving Kansas: > > People keep wanting to run a PIC off 2 different clocks. So > how's about 2 PICs, wired with all pins exactly connected in > parallel, except /MCLR and OSC. One goes 20 Mhz, the other > 32Khz. When one is going, the other is held in reset /MCLR=low > [and all pins float]. Exact interplay details to be worked > out. To be called the "2DoNothing" or "pushmepullyou" circuit, > or something or other. > > So how much mA does a PIC draw when held in reset, anyways? > Powerdown current = 1.5 uA ?????? > > - danM > > -- > 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 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin wrote: >> This is actually a serious inquiry. Any comments about having >> dual-clock operation by putting 2 PICs exactly in parallel, >> with each running off a different clock - say 20mhz vs 32khz ??? > >I don't know how much a PIC draws if held in reset. It's a static CMOS >device, so probably very little, but you are still relying on unspeced >values. Yeah, that was one of my questions. There are powerdown values given in the d/s, like 1.5uA, but am not sure it pertains to /MCLR held continuously at 0. =============== A cleaner way to switch between the PICs would be to control the >power directly thru a series FET or something, or maybe have the "off" >PIC go to sleep on its own. > A suspect there are several ways to deal with the on/off issue, reset/sleep/wakeup interrupts/etc. ============= >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. With a reset hold idea, the PICs always go back to square 1 on powerup, and with other solutions they, pickup where leftoff. These are issues that would have to be dealt with during programming. Using I2C RAM/PROM was one idea for dealing with this, if need be. ============== 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. > You are right. This is more of a solution looking for a problem. It just seemed like such a strange unique idea, who knows what potential it might have. And as someone else also pointed out, paralleling PICs is rather ungainly - certainly with twin-40s, but it might be more reasonable for twin-18s, say. Actually a slightly different idea occurred to me out of this one. Keep the low-power 32khz jobber running continuously to monitor operation of the fast jobber, and as the major timer/controller/monitor of the rest of the system, rather than the other way around. Use the fast one more like a co-processor when you need the oomph. With this arrangement, you might still have both uC's tied with a lot of pins in parallel, I/O, A/D, etc. Alarm trips or A/D level thresholds, little gun powers up the big gun. An assymetrical scheme could use a small 8- or 18-pin device kind of like a wart on the back of a big 28- or 40-pin guy, and "poaching" on only the critical A/D or I/O pins. Hmmmmmmmm. thanks, - dan michaels ============== -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dwayne Reid wrote: ......... {Quote hidden}>>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.

Roman Black wrote: >I think it is an absolutely brilliant idea Dan, dual >processing in a very clever form. It also goves the option of >having different code in each pic for further control of >energy use vs performance. Hi Roman, thanks for the nice comments. OK, at your insistence, I will accept the 2nd gold star for the week - the 1st going to Tobie Horswill for his desire to be the first to navigate a PIC around world in a bottle or small boat. ================== >The ram/eeprom issue may be a problem, as the two PIC would >not have the same memory, but for some apps this might not >matter, and in other apps an external eeprom etc would be >useful anyway, they could share it. Yes, already thought of this. Details would depend upon the app. ============ >The only bad point? Maybe the price of two PICs? Maybe you could >"push me pull me" with a 12xx pic and a f877 or something, with >them sharing some essential pins like the input/buttons, >but only the big pic having the output power driver stuff. >That might work cool too. "big brain small brain" stuff. :o) > Yeah, already thought of this, related in my other msg, before reading your msg. The is the "PICcyBackWartPoacher". Cool, you saw it, too. Come up with a really weird idea, wait about 10 minutes, and suddenly something more realistic springs to mind. best regards, - dan michaels ============== -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

----- Original Message ----- From: Dan Michaels <oricomKILLspamUSWEST.NET> To: <.....PICLISTKILLspam.....MITVMA.MIT.EDU> Sent: Friday, October 20, 2000 3:37 PM Subject: Re: [PIC]: MultiPICs = PushMePullYou <-- Cudos > Bob Ammerman wrote: > >First major problem: > > > >The 2 PICs will not have the same values in RAM. > > > >Other than that... not a bad scheme. > > > >What you would have to do is when changing speeds copy the data from the PIC > >that is going to sleep to the one that is going to remain awake. > > > > Since the PICs are held with /MCLR low between ops, you're starting > from scratch each time it boots up, so you have to take this into > account anyway. I think I'd have the idle PIC in sleep mode rather than MCLR mode. Sleep is a well documented low-power condition, but MCLR isn't. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST

Sorry, ideas don't count, only actual implementations. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: Douglas Wood <douglas_woodspam_OUTARIUSA.COM> To: <@spam@PICLISTKILLspamMITVMA.MIT.EDU> Sent: Friday, October 20, 2000 5:13 PM Subject: Re: [PIC]: MultiPICs = PushMePullYou <-- Cudos > Recently, where I work, we've had difficultly obtaining flash memory chips. > It seems that the world's supply of flash is going into Compact Flash > modules. Anyway, I suggested to the engineer looking for the flash that he > build boards with (large) arrays of 12CE518s on them (each PIC has 16 bytes > of EEPROM). Our flash size needs are in the MBs. I think this idea qualifies > for the last four categories, doesn't it? ;-) > > Douglas Wood > Software Engineer > > {Original Message removed}

On Sun, 22 Oct 2000, Bob Ammerman wrote: > Sorry, ideas don't count, only actual implementations. That's why I didn't suggest mine. Remember Bob's clock? (Congratulations for the /.'ing, Bob - though they were only two years too late.) Well, I had access to excess high efficiency RGB LED's. My ambitious project which I never undertook was to put these extra LED's to use on my bicycle wheels. 4 radial strings of hexagonally-close-packed RGB triads of PWM'd LED's per wheel. I had PCB's for 30 HCP LED's and planned to hack 5 508's to control them - a total of 40 12c508's... A new idea for motion pictures. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use KILLspamlistservKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST

Bob Ammerman wrote: .......... >> >> Since the PICs are held with /MCLR low between ops, you're starting >> from scratch each time it boots up, so you have to take this into >> account anyway. > >I think I'd have the idle PIC in sleep mode rather than MCLR mode. Sleep is >a well documented low-power condition, but MCLR isn't. > Yes, that was one of my 1st questions. And from listening to responses so far, would appear no one knows much about this. - danM -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use RemoveMElistservTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST

Bob Ammerman wrote: >Sorry, ideas don't count, only actual implementations. > Hey, Doug, the rest of the world is to interested in new ideas. Bob is probably funning here [one can only hope]. cheers, - dan michaels ============== {Quote hidden}> >----- Original Message ----- >From: Douglas Wood <spamBeGonedouglas_woodspamBeGoneARIUSA.COM> >To: <TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU> >Sent: Friday, October 20, 2000 5:13 PM >Subject: Re: [PIC]: MultiPICs = PushMePullYou <-- Cudos > > >> Recently, where I work, we've had difficultly obtaining flash memory >chips. >> It seems that the world's supply of flash is going into Compact Flash >> modules. Anyway, I suggested to the engineer looking for the flash that he >> build boards with (large) arrays of 12CE518s on them (each PIC has 16 >bytes >> of EEPROM). Our flash size needs are in the MBs. I think this idea >qualifies >> for the last four categories, doesn't it? ;-) >> >> Douglas Wood >> Software Engineer >> >> {Original Message removed}

From: Bob Ammerman <RemoveMERAMMERMANTakeThisOuTPRODIGY.NET> Subject: Re: [PIC]: MultiPICs = PushMePullYou <-- Cudos {Quote hidden}>Well, As an idea goes, this one was certainly a whopper.... > >But the contest idea I proposed really does have to be limited to >implemented systems. Otherwise somebody would tell us that had designed >millions of PICs into the Stars Wars Defense Shield or some such thing. > >Bob Ammerman >RAm Systems >(contract development of high performance, high function, low-level >software) > I'd like you to prove I didn't! "I'm sorry, but that's classified." -- John Patrick -- N9OU E-mail: j.s.patrickEraseME.....ieee.org -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use EraseMElistservmitvma.mit.edu?body=SET%20PICList%20DIGEST

On Sun, 22 Oct 2000, Bob Ammerman wrote: > > Since the PICs are held with /MCLR low between ops, you're starting > > from scratch each time it boots up, so you have to take this into > > account anyway. > > I think I'd have the idle PIC in sleep mode rather than MCLR mode. Sleep is > a well documented low-power condition, but MCLR isn't. For one thing, clock doesn't stop in reset. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use RemoveMElistservEraseMEEraseMEmitvma.mit.edu?body=SET%20PICList%20DIGEST

Bob Ammerman wrote: >Well, As an idea goes, this one was certainly a whopper.... > >But the contest idea I proposed really does have to be limited to >implemented systems. Otherwise somebody would tell us that had designed >millions of PICs into the Stars Wars Defense Shield or some such thing. > I understand from another thread that Bill Clinton has an aircraft carrier controlled by a PIC. PICs rule. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use RemoveMElistservspam_OUTKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST

John Patrick wrote: {Quote hidden}>From: Bob Ammerman <RemoveMERAMMERMANTakeThisOuTspamPRODIGY.NET> >Subject: Re: [PIC]: MultiPICs = PushMePullYou <-- Cudos > > >>Well, As an idea goes, this one was certainly a whopper.... >> >>But the contest idea I proposed really does have to be limited to >>implemented systems. Otherwise somebody would tell us that had designed >>millions of PICs into the Stars Wars Defense Shield or some such thing. >> >>Bob Ammerman >>RAm Systems >>(contract development of high performance, high function, low-level >>software) >> > > >I'd like you to prove I didn't! > >"I'm sorry, but that's classified." > When I worked for the govt, I worked on stuff that was so secret that if I told you about it, I'd have to kill myself. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use EraseMElistservspamspamBeGonemitvma.mit.edu?body=SET%20PICList%20DIGEST

rich+piclist wrote: >On Sun, 22 Oct 2000, Bob Ammerman wrote: > >> > Since the PICs are held with /MCLR low between ops, you're starting >> > from scratch each time it boots up, so you have to take this into >> > account anyway. >> >> I think I'd have the idle PIC in sleep mode rather than MCLR mode. Sleep is >> a well documented low-power condition, but MCLR isn't. > >For one thing, clock doesn't stop in reset. > Darn, that's a bummer. I looked around the d/s, but it wasn't especially clear [Mchp engineerspeak wins again], so I measured it on the scope. Botta bing. -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestSTOPspamEraseMEmitvma.mit.edu

Guys, That was meant as a joke. This same engineer built a circuit to operate a "coin spitter" using a switch and a flip-flop. (A coin spitter is a device used in vending machines to return change.) After he built this circuit and had it running, he came over to my desk. After he explained the circuit, he commented that our rather "PIC-gungho" engineering manager would probably say that he would have used a PIC. We both laughed -- haha. The very next morning this manager came in and asked Joe (the engineer) what he was working on. Joe explained about the coin spitter circuit, and, as God is my witness, the manager said, "I think I would have used a PIC!" This was just too funny. I made a fake personalized Kansas license plate for the manager that read "IDPICIT". I figured that my (extensive) use of 12C PICs would in some perverted way appeal to our manager!! Douglas Wood Software Engineer {Original Message removed}

On Mon, 23 Oct 2000, Douglas Wood wrote: > Guys, > > That was meant as a joke. This same engineer built a circuit to operate a > "coin spitter" using a switch and a flip-flop. (A coin spitter is a device > used in vending machines to return change.) > > After he built this circuit and had it running, he came over to my desk. > After he explained the circuit, he commented that our rather "PIC-gungho" > engineering manager would probably say that he would have used a PIC. We > both laughed -- haha. > > The very next morning this manager came in and asked Joe (the engineer) what > he was working on. Joe explained about the coin spitter circuit, and, as God > is my witness, the manager said, "I think I would have used a PIC!" This was > just too funny. I made a fake personalized Kansas license plate for the > manager that read "IDPICIT". I figured that my (extensive) use of 12C PICs > would in some perverted way appeal to our manager!! Which reminds me (who said this originally?): "Real engineers know their PICs everyone else picks their nose!" -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

I'm not sure that my current project, a household "hobby" robot, will even com close. It will be using a 16F874 as the main brain and 5-6 F84s for various sub-systems (drive, sensory, user IO, power systems, etc.) but that provides enough for me at the momentt!! ----Original Message----- >From: Dan Michaels <EraseMEoricomEraseMEUSWEST.NET> >To: @spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU >Cc: >Bcc: >Subject: Re: [PIC]: MultiPICs = PushMePullYou <-- Cudos >Type: IPM.Note >Date: Friday, October 20, 2000 4:58 PM > >In the wild flurry to be the first to sail a PIC around >the world, my poor little pushmepullyou idea was overlooked. > >This is actually a serious inquiry. Any comments about having >dual-clock operation by putting 2 PICs exactly in parallel, >with each running off a different clock - say 20mhz vs 32khz ??? > >See below: >========= > >Lance Allen wrote: >>Bob Ammerman wrote: >> >>> Here's a question/contest: >>> >>> who has built the system containing the most PICs? >>> >>> I suppose we'll need a few categories: >>> >>> Most PICs on one board >>> >>> Most PICs in one box >>> >>> Most PICs in one room >>> >>> Most PICs interconnected worldwide via any medium >>> >> >>I am sure this will be puny my many standards but my record is 3 on one >board, a >>16C74, 16F84 and 16C54 all used to control a powerful stepping motor in >very fine >>increments of speed.. a sort of DDS, drive a 9 digit LED display, read an >encoder >>and various other inputs. It worked well too. >>Now I would use an (stone the heretic!) Atmel FPslic combined FPGA and AVR core >>since I now have access to all the development gear for such beasts at my >new job. >> > > >Hmmm, this is just the latest weird thought from the weird >land somewhere over the rainbow - ie, Boulder, where Dorothy >landed after leaving Kansas: > >People keep wanting to run a PIC off 2 different clocks. So >how's about 2 PICs, wired with all pins exactly connected in >parallel, except /MCLR and OSC. One goes 20 Mhz, the other >32Khz. When one is going, the other is held in reset /MCLR=low >[and all pins float]. Exact interplay details to be worked >out. To be called the "2DoNothing" or "pushmepullyou" circuit, >or something or other. > >So how much mA does a PIC draw when held in reset, anyways? >Powerdown current = 1.5 uA ?????? > >- danM > >-- >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 > > > > -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestKILLspammitvma.mit.edu