Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!

Hi Jon,

Re CPLD vs FPGA: I guess I was sort of thinking one chip per channel,
but you're right of course, putting 3 or 4 channels in one FPGA is more
cost effective for our application. You've clearly given this much more
thought than I have.

I don't think I asked the "product to sell vs open source project"
question too clearly. I'll try again. What I was trying get at was how
nosey I should be. If your plan is to publish the design for all to see,
GPL style, that's one thing. If you're working on a proprietary design
that you or your client plan to sell as a package, that's a whole other
sort of deal. It may be that I just got in late on this discussion, but
so far I'm not sure which sort of project you're talking about. I just
wandered in here and I don't want to step on any toes. Should I stay out
of the way, offer to help, take this off list, or what?

Re parallel port chips: From what little I've seen the Intel south
bridge chips are one case, the VIAs are another, and then there are
various PCI parallel port add on cards. It's all rather ugly. There are
clues lurking in various Linux driver code.

Jeff

On Wed, 30 Aug 2000 00:43:29 -0500, Jon Elson wrote:

>
>One very small correction here, but thanks much for the support. It is
>hard to get
>heard for all the PIC for everything people out there. A CPLD, which is
>very nice for
>a lot of simple things is just too small to hold the encoder counters,
>or the timing
>generator. It just has too many flip flops. If you have a 24-bit
>counter, and a 24-bit
>count holding register for each channel, plus one 24-bit word assembly
>register, pretty soon
>you have 216 flip flops on the chip, not counting any protocol state
>machines and or
>whatever else is needed. The CPLD I'm using on the DAC card is under
>$10. The
>more capable Spartan chip (about 5000 gate equivalent) is $18, and you
>need a $4
>serial prom to hold the program for it.
>
>> Jon, are you doing this as a product design to sell, or is it an "open
>>
>> source" type project?
>
>Both, I guess. What I'm trying to eventually get to, is where I can
>supply an entire
>package, with EMC software, just about any computer, and several boards
>that
>plug into a backplane to do encoders, servos or steppers, servo amps,
>digital
>I/O for auxilliary stuff, and eventually a dedicated control panel for
>EMC.
>
>> Also, I read about you doing battle with the EPP
>> fast transfer protocol. How many different parallel port chips have
>> you
>> tested with. Some don't play nice at all.
>
>Well, 2 so far. I never got EPP mode to work right. But, I did get one
>system
>set to ECP mode, and then configured that back to the EPP subset, and
>that
>DID work as advertised. I have to go back and try the first machine
>again with
>the new knowledge I've acquired, and the code that now works on one.
>The ECP seems to be more strictly specified in hardware, where the EPP
>definition left a lot up to the designers, as the only locked-down
>interface
>definition is the BIOS routines.
>
>For a number of reasons, USB can not be used safely.
>
>Jon