It's a MOS KIM-1 6502 front panel. I'd assume you can emulate the whole processor in an AVR. See http://en.wikipedia.org/wiki/KIM-1. I'd also guess that U4 is an SPI flash for tiny basic or whatever they called it.
Well, the official arduino ethernet shield is an add on board and will not run "standalone" either. The wiznet chip uses SPI to the AVR on the arduino. I think the wiznet chip had a bit more internal protocol smarts than the enc28j60 chip. The issue with the tiny ebay enc28j60 boards is that you have to figure out how to connect SPI to the arduino and get the one of the libraries to work.
Note that the enc28j60 has 5V tolerant inputs but may need level translation to get good edges going back to the AVR. The wiznet shield has a 74something125 on board as level translation.
I don't actually use real arduinos, I use the adafruit boarduino instead. It will fit on normally spaced pin headers and you can change out the voltage regulator for a 3.3V one and interface with modern chips with no level translation. It's cheaper too.
As for hardware, I haven't tried the olimex board. I've used the cheapest one on ebay: "enc28j60 module" (sort by price) and it seems to work fine. It's the one that uses the SOIC version of the chip. I've also used one that's the size of an ethernet jack with a BGA enc28j60 on the bottom. Search for "enc28j60 smallest" to see it. That one does NOT have mounting holes which is an issue if you put it in a case. It will fit on a solderless breadboard, unlike the cheap one.
I've used the enc28j60 boards that are all over flebay for around $5 with the arduino. You have to use a different library which I think is a bit heavier than the stock "Ethernet" lib. Seems to work fine.
Some EIDE (PATA) hard drives used a serial interface to access the diagnostic mode, mostly used in data recovery operations. Very proprietary stuff. So yes, you could use a BP to talk to some desktop hard drives. But you don't want to. I've actually used a BP with flashrom to copy an SPI flash memory chip on an EIDE interface board inside a hard drive but I'm having unpleasant flashbacks and won't say anything else about it.
As far as I can tell, the prologix 4.2 unit uses the atmel avr109/butterfly boot loader through the ftdi usb/serial bridge. The pc board also has a standard (unpopulated) ISP (2x3). So I'd assume that the device could be trivially cloned in much the same way as the Saleae Logic or the USBee has been cloned by chinese ebay sellers. You'd still be stuck with the prologix software as-is since it's not open source. I suppose that there might be some sort of serial number in the eeprom that might prevent the software running on a cloned device, but I have no idea.
The real issue is what you want on the PC end of the interface. Prologix gives you a serial port interface with a command set you use to talk to the GPIB device. Any program on a PC that wants to talk on the GPIB bus must use that prologix protocol, which is unique to the prologix device. That is its fatal flaw.
That's why that chinese device on ebay implements the Agilent 82357B protocol on the USB side of the device. It makes it useful for existing programs that actually use gpib devices. That protocol is also supported by the linux-gpib package.
GPIB isn't very complicated at the hardware level. I have a listener (an HP 59306A relay actuator) that is implemented with just 74xx TTL logic; no microcontroller. It's that final interface that's exposed to the client on the PC that's hard.
If I were going to start from scratch, I'd just build a shield with a GPIB connector for either an arduino/borduino/teensy or atmega32u4-breakout and go from there. Reading a value from a multimeter should be easy. (famous last words. as we say in the software world it's just a SMOP, Simple Matter Of Programming!).
It's a 24 position Centronics micro-ribbon connector. Both digikey and mouser stock them, check under interconnects, centronics and select 24 positions. Depending on what you're doing, it may be cheaper to ebay a cable and chop it.
I have a prologix gpib-usb 4.2 (old version). Internally, it's an AVR atmega164p and a ftdi ft245rl. The software upgrade package has a HEX file and avrdude so it's pretty clear what's going on inside. The AVR connects directly to the GPIB, no buffers or drivers.
There is no hacker demand for these interfaces so they tend to be quite pricey. I got mine used simply because I couldn't find a reasonable open-source solution. Even the PCI cards are going for $125 or so on flebay. Labs that can afford NI stuff are willing to pay $350 for an interface so it really drives the prices up.
The fun begins once you try to get devices talking. Most things that speak GPIB were pretty old school microprocessor based test equipment that didn't have room for error messages.
Kinda old thread, but I'll kick in some ideas anyway.
I just took apart my DLC5, and it uses a motorola MC74HC125A. Digging into the datasheets and you'll find that this chip only allows input at Vcc+0.5V max. So if you power the DLC5 from 3.3V, the inputs from the parallel port are too high. Turns out that there are a LOT of different 74125 chips in various families out there. A good reference is from TI: http://www.ti.com/litv/pdf/scea035a about level translation. One possibility is the 74LV125A where Vcc is 2v-5v and inputs from -.5 upto 7v.
But that moves the problem to the parallel port end. It uses TTL levels, and from the same TI ap note, min Vin-hi for 5v-TTL is 2.0V and min Vout-hi for 3.3V-TTL is 2.4V. This means that the PC parallel port should see the right logic levels as long as the slew rate of the driver gets the output level above 2.0V fast enough for the JTAG data rate. Slew for the 74LV125A is 100ns/V. So lets say 1 MHz, but 2 MHz might work (remember you have to slew both ways and have bit valid time too).
So my theory (awaiting a digikey order) is that replacing the exiting buffer chips in the DLC5 with the 74LV125A should allow it to work with the coolrunner-ii and FPGAs that JTAG at 3.3V (CR-II jtag max is 4.0V, that's why xilinx says you can't use it for the cr-ii: http://www.xilinx.com/support/answers/3596.htm) when the DLC5 is powered from 3.3V.
I had always thought of the 74HC125 as an OK 5v-3.3v buffer (it's listed that way on the adafruit partfinder) but it turns out you have to pick the right one or you violate it's datasheet specs.
I poked around throught the xilinx datasheets on the dlc9g and dlc10, the primary difference seems to be that the dlc9g uses an unspecified CPLD for the I/O and the dlc10 uses a spartan-3a. It also has an extra I/O line (HALT_INT_WP), and an internal unique serial number. The dlc9g manual doesn't say if there is an SN.
It looks like the available timings and voltages are the same.
Both manuals say that IMPACT will program the adapter microcontroller and upgrade the internal CPLD/FPGA as necessary so I guess that if the hardware is properly cloned then the software takes care of itself.
Where did you get the hardware info on the xilinx platform cable? Is it public?
I only have a dlc5, which xilinx says not to use on any chips that fry on 5V, like the CR-II and the spartans. It looks the the issue is that they used 74125s that can't be driven above Vcc so the parallel port frys the interface when Vcc==3.3V. So my digilent board is stuck in windows due to their built in AVR based USB programmer. (or use my BP).
ebay is now loaded with various clones of that cable, who knows if they work. Search for "xilinx usb platform cable" and you'll see them starting at $37, buy-it-now. They even have the trademarked logo and the part number DLC9G.
Of course, it depends on what you're doing. The CUI modules are UL approved and generate quite a bit of power. $14.40/1 isn't that bad, although for a product demo you may as well use a wall-wart.
The target market for the FSAR001B is different. Consider trying to get a microcontroller and a few other chips powered up in something like a lightbulb base or inside an extension cord. The typical solution involved an approved capacitor that's 25x15x8mm (I'm looking at an X2 0.47uF on the bench) and a few other tricky components and unless your power budget is exact, it wastes power and heats up.
It's a pretty specific chip and it took a LONG time to hit (useful) distribution.
Picked up a Tektronix 1502 TDR (Time Domain Reflectometer). Flea-bay, $25. Broken, of course. Picture shows it repaired, TDRing a random piece of 50 ohm coax, unterminated. [attachment=0]
and hooked up the bus pirate according to the wiki page for PiratePICprog. You then run into the same problem when using pirate-loader on the web platform. The hex files generated by mplabx, and the bootloader dp-wp-bootloader.v0a.hex have addresses outside the range of the flash memory. For the boot loader, it has:
which writes a bunch of config stuff at starting address 0x01f0 0000. A brief poke at the data sheet shows that this is a lot like the fuse bits on the AVR. Deleting this from the HEX file allows piratePICprog to flash the bootloader and lets us continue development.
In the long run, manually hacking HEX files is not a good thing. Now, I don't really know enough about the PIC to understand what the right thing to do here is. The code that reads HEX files in piratePICprog does NOT do the right thing here since it assumes that the address space of the HEX file is contiguous and this out-of-band data is far away from the valid flash addresses. HEX files generated by mplabx are full of these references to 0x01f0 0000, and they are scattered within the file (unlike the boot loader where it's at the end).
Has anyone hacked up the linux BP tool pirate-loader to upload firmware for the web platform? It seems like a vast overkill to install mono just to run the ds30 GUI; all it's really doing is shoving a HEX file across a serial port. Clearly pirate-loader has been hand-hacked specifically for the BP, but isn't the protocol the same?
When pirate-loader is pointed at the web platform and run it says:
compute% pirate-loader --dev=/dev/webplatform --hello +++++++++++++++++++++++++++++++++++++++++++ + Pirate-Loader for BP with Bootloader v4 + +++++++++++++++++++++++++++++++++++++++++++
Opening serial device /dev/webplatform...OK Configuring serial port settings...OK Sending Hello to the Bootloader...OK
Device ID: UNKNOWN [ab] Bootloader version: 1,02 Unsupported device (ab:UNKNOWN), only 0xD4 PIC24FJ64GA002 is supported
After a quick look at the pirate-loader.c code, it looks like some careful crafting of the defines might make it work but I'm an AVR dude and know nothing about PICs.