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. Regards Paul WB8TSL On Sun, Jan 15, 2012 at 11:07 AM, <ewkeh...@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, > mag...@rubidium.dyndns.org writes: > > On 01/15/2012 05:48 AM, Chris Albertson wrote: > > On Sat, Jan 14, 2012 at 4:32 AM,<ewkeh...@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
