toggle quoted messageShow quoted text
It’s possible that an off the shelf FTDI dongle might do it, as long as it has a bunch of pins broken out. Their chips (like FT232R) have a buffered parallel bit-bang mode. You get 8 I/O lines that you can drive and sample at an arbitrary speed. You could probably use one or two lines and a clever drive pattern to do charge pumping to generate signals above 5V or below 0V.
An AVR will have no problem sampling at whatever async frequency, because you can use DMA and a timer to capture a raw bit steam off a port, as well as send out a bitstream from RAM. It’s a byte per sample, but those chips have enough ram to make that work. So you won’t have any interrupt overheads.
I could probably whip out some Arduino code and a software test bench to check it out, if there’s interest.
14 dec. 2019 kl. 5:12 em skrev Chris Hanson <cmhanson@...>:
On Dec 12, 2019, at 10:24 AM, Dave via Groups.Io <dfnr2@...> wrote:
I think the USB to HIL interface would probably be the easiest and cheapest option.
I’ve looked into building a HP-HIL to USB interface a bit and it’s going to be a little bit of work:
Sourcing the connectors and cabling for HIL is difficult. And the connectors are rare enough that taking things apart to use their HIL connectors isn’t really a good idea. (Except maybe ID boxes.) At least the “HIL extender” systems use DB-15 on one side so you can use that as an endpoint without dismantling anything.
II. Hardware Interfacing
I recall the voltage levels involved in HIL being slightly different than TTL, which means building custom level shifters out of transistors. At least getting transistors that cleanly switch at 200+ KHz shouldn’t be difficult.
III. Low-level protocol
The low-level protocol for HIL is trivial—it’s basically just bidirectional serial with a start bit, stop bit, and parity—but you can’t get off-the-shelf hardware to speak it because it’s an un-clocked 100kbps protocol with 15-bit packets and pretty strict timing requirements. So you’re looking at making your own UART either with bit-banging or logic. This gives, for example, a 16MHz Arduino approximately 160 clock cycles per bit—which doesn’t give it time for much else, especially since you need to be able to both transmit and receive.
IV. High-level protocol
Once you get packets going back and forth, this part is easy; there are plenty of examples in NetBSD et al, in addition to what’s in the HP-HIL protocol reference. Building an API to talk to devices and translate them to something modern should be straightforward if everything else is taken care of.
The approach that I’ve planned to take whenever I try this again is to use an AVR or two solely as a custom UART since 160 cycles/bit should easily be sufficient for a polled/bit-banged software UART implementation, with room enough to implement a couple of registers and buffers accessible by the actual host device, which would be something more like a Cortex M series that implements the high-level protocol and USB HID.
In other words:
USB HID <—> Cortex (HID/HIL) <—> AVR (custom UART) <—> DB-15 HIL