[time-nuts] Controlling FEI 5680A

paul swed paulswedb at gmail.com
Sun Jan 15 11:27:27 EST 2012

I have been watching for a bit now. Its more interesting now that my
FE5680s working quite well. I have noticed on numbers of threads the
conversation dramatically shifts from reasonably implemented low cost
solutions to the ultimate FPGA.
FPGAs are generally intended for the mass market with a steep learning
curve. Though they can be pressed into whats of interest to time-nuts it
simply seems like a overly complicated technology and method for a non-mass
market solution.

The tools that are available in any of the $2 micros these days are very
good and you have a wide choice of tools and languages to develop in. I
have several FPGA dev kits and have to say have never turned anything much
out with them.

On the flip side I have several of the dev kits for PIC and I get pretty
much everything I want to done in those. Just simple, stupid, dumb stuff at
a cost of a few dollars.

Though it may have been lost in the thread. I think it started as a how do
you control the 5680 with a GPS engine to lock it. It had hovered around
filters and evolved to long counters and D/A converters. Still all
reasonable approaches.

If I build anything it would be along those lines. FPGA simply won't happen.

On Sun, Jan 15, 2012 at 11:07 AM, <EWKehren at aol.com> wrote:

> Magnus   I agree,
> I can not se how any one can simplify this approach. A $2 gate array in a
> 0.5 $ socket that is solderable, a $ 2 14 pin DIP uP what ever brand, a
> clock generator, a RS232 interface, a 3.3 V regulator and two single gate
> 14's
> what more do you want. If communication is limited to the 5680 a 74AC14
> could be  used eliminating the RS232 chip and any SMD.
> The counter on the G/A has been increased to 21 bits.
> With all this working, some group may want to tackle it on a FPGA.
> Bert Kehren
> In a message dated 1/15/2012 10:46:42 A.M. Eastern Standard Time,
> magnus at rubidium.dyndns.org writes:
> On  01/15/2012 05:48 AM, Chris Albertson wrote:
> > On Sat, Jan 14, 2012 at  4:32 AM,<EWKehren at aol.com>  wrote:
> >> I have no expertise  when it comes to filter design or programming PIC's
> or
> >> other micro  controllers. But I know what works for me. For 11 years I
> have
> >>  been  using Shera controllers with very good results. (I still have
> some  new
> >> assembled  extra A&A boards, if any one is  interested, please contact
> me
> >> off list) Over  the years I  have made hardware work around's and made
> my own
> >> boards ending  up  with 120 and 240 samples and 100 MHz clock in stead
> of 24
> >>  MHz. Over time chips  are harder to get. The solution is an Altera MAX
> 3000
> >> gate array and that input  circuit can be implemented on  a $ 2  100 MHz
> >> version or $ 5   200  MHz  version using either a 100 MHz or 200 MHz
> clock. That
> >> circuit  works with the  present Shera PIC but that is a 28 pin $ 4
> device.
> >> Since in  this application the controller does not  have  to be all
> things
> >> for all  devices it would make  sense to use a PIC16F688  or any other
> 14 pin
> >>  device.
> >
> > Have you thought about putting the PIC  _INSIDE_  the Altera FPGA?
> >
> > It's a common trick to implement a  microcontroller in the FPGA and you
> > can get the code for just about  any CPU core online.  Here is an
> > example of "virtual  PIC":
> > http://www.embeddedtronics.com/pic_core.html
> > If the PIC  fits inside then that is one less chip on the PCB.   The
> >  example above found that could run the virtual PIC a little faster
> >  than a real pic so you don't give up any performance
> A short notice on  embedded CPU/MPUs into FPGAs. Using PIC or AVR might
> be tempting, but I  consider any clone "dirty" from a rights perspective,
> MIPS for instance  have been very protective on their side, so has ARM.
> So far has the SPARC  been the only big one being accepted in their
> LEON-x variants that I know  of. We be sad to see the cotton industry
> level being smashed by the big  firm lawyers.
> So, either using the OpenRISC variants or similar. There  is loads of
> CPUs on the OpenCores website, but just because they are there  do not
> think they are free to use if they are clones of commercial  stuff.
> I would either use one of the FPGA vendors CPUs and then write  the core
> in C, or use a free CPU.
> I could also roll my own CPU, as  I have already done before, but
> building a tool-chain including GCC is a  bit of home-work. For my
> application I haven't bothered, but it is  tempting to get C capabilities.
> Then again, if someone could show that  the PIC and/or AVR is free to
> clone in FGPA, by showing a clear statement  from the respective
> technology holders, then that would be a way  forward.
> I've done this analysis before, and so far I have not seen any
> comprehensive open analysis covering these aspects.
> I fear that  this is way off topic for this list, so I propose that this
> aspects is  continued on another list, such as the FPGA-Synth list, which
> faces  essentially the same  problems.
> Cheers,
> Magnus
> _______________________________________________
> time-nuts  mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the  instructions there.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list