Tony Duell wrote:
IIRC, the interface to a CF card is essentially
IDE, so you could use
non-rotating memory if you wanted to.
Sorry, I would use sd-flash. much easier to deal with, less I/O.
So would I (is that thw oen with an SPI-like interface?). But another
list member mentioned making a device using IDE hard disks, and I was
commenting that if such a device was created, it could also use CF cards
with little, if any, modification.
Yes, that's the problem. Most of the
traditional HPIB interface chips
have long beend discontinued. And ehile you might be able to fet them for
repair purposed, I'd rahter not such a device in a new design.
Here I would put an cpld/fpga on it. Only newer chips available are PCI.
Bit-Banging the GP-IB is doable, but why ?
Why would you want to use a CPLD/FPGA here? It's another chip, it's
another chip that has to be programmed (and for which you need the
development tools [1] and a machine to run them on), and it doesn't give
you anyting. Using just about any microcontroller, you can bit-bang the
HPIB handshake plenty fast enough.
[1] And unlike most microcontroollers, you have to use the proprietary
tools, you can't write your own.
I suspect that with a sensible choice of microcntroller, it could be
built in 4 or 5 chips (microcontroller, a couple of HPIB buffers, the
minimal logic needed to support a banged HPIB handshake and maybe buffers
to the flash memroy device).
Now if I was designing this for myself, I can assure you I'd use a
microprocessor, separate ROM and RAM, some kind of HPIB controller chip
(HP used the Intel 8291 in most of their drive units), and whatever chips
were needed to link up the flash memory device. And of course a pile of
TTL for clocks, reset, address decoding, etc. The reason is that it would
be easier for me to debug the firmware in a setup like that (I could use
an EPROM emulaotr, I could also use a logic analyser to trace the code as
it was running). Problem is, nobody would want to build that, so I feel a
single-chip miocrocontroller + buffers is probably the most senible solution.
[75160/xxx]
Definitely I would use them. No reason to make a real project out of
this, and suffer, because somebody put 200 devices on it.
If you do it, do it right (tm)
Indeed...
(DIL CPUs, whatever)
Here I'm
disagreeing, Probably even BGA, but who cares ?
There more interesting chips are BGA, and I'm not thinking about
replacing the CPU anyway.
The problem with BGAs is that they're alomost impossible to prototype
with, and not many people have the setup to solder them onto a PCB
anyway (I don't). So who is going to be able to actually build the thing?
Oh yes, I'd want to solder the PCBs myself. That way I know they're
soldeed with 'real' solder...
[...]
That would be my approach, to put everything in one
chip, but the
drivers ;-)
My (serious) approach too. One chip + buffers (to HPIB) + the flash
memory device. And since you really need that chip to be a processor (you
try doing the CS/80 protocol in random logic ;-)),, it makes more sense
to use a microcontroller than an FPGA here (yes, I know you _can_ make a
processor in an FPGA, I've done it, but it's not the sensible thing to
use hree).
-tony