[time-nuts] Controlling FEI 5680A

[EWKehren at aol.com]

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.