> From: Frank Vorstenbosch <.....frankKILLspam@spam@FALSTAFF.DEMON.CO.UK>
> To: PICLISTKILLspamMITVMA.MIT.EDU
> Subject: Re: Beginners question on increasing pic internal clock spee
> Date: Wednesday, June 17, 1998 3:01 PM
>
> > Is there presently anyway I can get a Pic16c54 or any other Pic for that
> > matter to be able to execute code at 1 nanosecond per instruction? If
> > not possible with Pics are there any other microcontrollers that can
> > execute instructions this fast? Thanx in advance for for responding.
>
> I think the best you can do cheaply nowadays is about 250MIPS in a
> microprocessor.  My current favourite is the StrongARM, which will do
> internal cycles at 235Mhz, with a bus of up to 66MHz.  This requires
> 32-bit memory though (ROM and RAM).
>
> Alternatively, you can use programmable logic to build a state machine --
> this will go up to the same kind of speed if you've got fast devices.
> Using ECL it should be possible to hit 500-600MHz clock rates.  Beyond
> that you're talking transmission lines anyway, so you can use transmission
> lines as delay elements.  Programmability goes out of the window, of course.
>
> Try to see if the problem you're trying to solve can be approached from
> a different angle (massive parallelism, improved algorithms, off-the-shelf
> test&measurement kit, etc.).
>
> Frank

> You have a better chance of getting a good answer back from members
> of the PIC list if you make the problem as specific as possible.
> For example, if the person asking the question had said:
> "Can I use a PIC to measure a frequency that is greater than 1 Mhz?"
> then I could readily give them a number of inexpensive PIC based
> solutions. And a few that don't require a PIC at all.
>
> No, you can not "soup up" the PIC to run with a 4 GIGA Hz clock.
> That option is out. But as Frank intimates in his response below,
> there may well be other things you can do with the PIC to make it
> do things that you might *think* you needed a 4 GHz clock to
> accomplish. Tell us in general terms at least what you want to
> do. If no one here has a PIC way of doing that, then just
> maybe some one can aim you in some other direction that *will* work
> for you. Or at least you will know right up front that you are
> seeking to do the impossible.
>
> Input. We need more input! Otherwise it does not compute!
>
> Fr. Tom McGahee
>
> ----------
> > From: Frank Vorstenbosch <frankspam_OUTFALSTAFF.DEMON.CO.UK>
> > To: @spam@PICLISTKILLspamMITVMA.MIT.EDU
> > Subject: Re: Beginners question on increasing pic internal clock spee
> > Date: Wednesday, June 17, 1998 3:01 PM
> >
> > > Is there presently anyway I can get a Pic16c54 or any other Pic for that
> > > matter to be able to execute code at 1 nanosecond per instruction? If
> > > not possible with Pics are there any other microcontrollers that can
> > > execute instructions this fast? Thanx in advance for for responding.
> >
> > I think the best you can do cheaply nowadays is about 250MIPS in a
> > microprocessor.  My current favourite is the StrongARM, which will do
> > internal cycles at 235Mhz, with a bus of up to 66MHz.  This requires
> > 32-bit memory though (ROM and RAM).
> >
> > Alternatively, you can use programmable logic to build a state machine --
> > this will go up to the same kind of speed if you've got fast devices.
> > Using ECL it should be possible to hit 500-600MHz clock rates.  Beyond
> > that you're talking transmission lines anyway, so you can use transmission
> > lines as delay elements.  Programmability goes out of the window, of course.
> >
> > Try to see if the problem you're trying to solve can be approached from
> > a different angle (massive parallelism, improved algorithms, off-the-shelf
> > test&measurement kit, etc.).
> >
> > Frank

>that would translate into approximately 1nanosecond per foot. I would like
>to use
>a PIC to do all the conversions( time to feet and/or yards) and drive an LCD
>display. Any help will be greatly appreciated."
>
>Ok...everybody together now....."You're doing it all wrong!"
>
>That's a great idea, in principle, but as you've already observed,
>it's hard to put into practice because of the annoyingly fast rate
>that light moves about. Galileo had the same problem, *way* back when.
>
>This problem has already been solved, and you don't even need two radio
>transmitters to solve it. One will do.
>
>Create a radio signal of some reasonable frequency, say 902MHz. That's the
>ISM band in the US, a fairly un-regulated area to work in. Apply a modulating
>signal such that the carrrier frequency is swept up and down over a range.
>This is technology you can get off-the-shelf. Point your signal at the
>distant target, where you've installed an antenna, configured as a reflector.
>You don't actually *have* to use a reflecting antenna, but it'll make
>the signal discrimination a lot easier. At 900MHZ, these things don't have
>to be very large.
>
>The transmitting antenna sends out a signal, and it sweeps up in frequency. One
>round-trip-time later, the receiving antenna begins to pick up the signal
>that's been reflected back from the reflecting antenna at the other end. But
>right now, the transmitter is sending a signal that's higher in frequency
>than it was when it started, and so there's a difference in frequency between
>the transmitted and received signals. And that difference is proportional to
>the round-trip-time, and hence the distance. Using a mixing circuit, combine
>a little of the transmitter signal with the received signal. This will generate
>sum and difference signals, and you filter out the carrier frequency and the
>sum, and keep the difference. At zero distance, there's no difference between
>the two, and the difference frequency goes to zero (DC). As the distance
>increases, the difference frequency goes up. The sweep rate of the modulation
>provides the scale factor, and now all you have to sense is a signal that's
>somewhere in the audio range of frequencies. That's a *much* easier problem!
>
>Note that you can also determine speed this way; set the sweep to zero for a
>fixed frequency, and the difference tells you whether the target is moving
>or not, and how fast. Alternate sweeping with fixed frequency, and you can
>also tell which way it's going! This is some of the science behind radar guns.
>
>This works with light, too, and it's the principle behind things like laser
>rangefinders. Even cameras have things like this, these days, so it's not
>an expensive problem to solve.
>
>The ARRL handbook will have an assortment of useful information on RF design,
>which is where you need to be looking. A PIC could probably do the sweep
>control and the signal detection, but you've got other things to figure out
>that dwarf simple things like the control circuit.
>
>Mark G. Forbes, R & D Engineer  |  Acres Gaming, Inc.    (541) 766-2515
>KC7LZD                          |  815 NW 9th Street     (541) 753-7524 fax
>RemoveMEforbesmTakeThisOuTpeak.org                |  Corvallis, OR 97330
>http://www.peak.org/~forbesm
>mforbesEraseME.....acresgaming.com
>
>"There has been an alarming increase in the number of things I know nothing
>about."
>---Anomalous
>
>