5 ms·

This is a cool hack, but I think the article would benefit from a deeper explanation of why "USB to serial" worked and "USB to parallel" would not.

by jpm_sd 10y ago

tyingq 10y ago
>> "USB to serial" worked Somewhat. The combination of vendors sunsetting older chipsets (Prolific HX), and their reaction to counterfeit chips makes the USB-to-Serial world a huge pain in the ass. I'm hopeful the CH340 chipset eases the pain of supporting non-tech end users with these things.
- janekm 10y ago
  CH340 has no practical Mac support last I tried. Try CP2102, works great and cheap too.
  - voltagex_ 10y ago
    Oh boy - looks like the same kinds of problems that happened when Microsoft started enforcing driver signing. https://tzapu.com/making-ch340-ch341-serial-adapters-work-under-el-capitan-os-x/ https://tzapu.com/making-ch340-ch341-serial-adapters-work-un... How difficult would it be to write a driver for these adapters from scratch?
  - tyingq 10y ago
    Signed drivers for OSX do exist now: http://blog.sengotta.net/signed-mac-os-driver-for-winchiphead-ch340-serial-bridge/ http://blog.sengotta.net/signed-mac-os-driver-for-winchiphea... But...I'll check out CP2102.
kirrent 10y ago
USB to serial worked because he could do larger transfers of data to the AVR which would then do low latency byte by byte writes to the device when polled.
VLM 10y ago
Here comes a mostly true simplification. Printers speak an extremely low level protocol of "Once the printer ready pin indicates the printer is ready, load up one byte of data across 8 pins, smack a pulse out that says yo here is another valid byte, wait a bit, then repeat until you run out of data in the buffer to print". This is actually not too far from how parallel port hardware and port driver OS software worked. In practice the hardware ends up as something like 10 general purpose TTL IO ports, in fact in the REALLY old days our NON-integrated parallel printer ports used actual 8 bit latches like you'd see on memory busses from S-100 cards and stuff. Not the abstract concept of a latch but an actual TTL DIP chip like a 74LS373 or whatever printers use (I don't remember inverting or not or whatever) Newer hardware is way more complicated and "automated" and "buffered" but at some level the original PC compatible API locked down how low level it had to be and you have to be able to at least pretend you're GPIO to be "IBM PC Compatible". Standards being a great idea there are of course at least four SPP, EPP, and some others that spec'ed slightly more advanced but whatever. So the high level protocol PLUS industry monopoly compatibility meant if you sell it as "IBM PC compatible" its gotta be able to speak at a 10+ pins of general purpose IO level. The USB replacements do something different and appear to be printers and can no longer implement general purpose IO they implement "print a character" at the USB level not bit fiddling. I've not written a USB driver for a printer (on either side) so I'm a little fuzzy but what I've heard second hand is the USB level lives at an abstraction of "here's a packets worth of UTF-8 stream" Note that there were weird situations for RS-232 serial where you'd synthesize signals by weird pulsing of DTR leads or CTS or whatever that can be pretty well messed up by transitioning to a USB implementation of "heres a bit stream". I guess another way to look at it, is its easier to maintain compatibility across hardware generations for a single stream of bits so serial has it easy, whereas parallel was always a mismatch of high level byte transfer vs GPIO in the same system. The USB emulators only mass market making a printer work, not concerned about providing 10 or so pins of GPIO. There is other fun... to a first approximation (aka its untrue) no one implemented multipoint networks on parallel ports. So latency was approximately zilch and much hardware hacking relied on that. USB of course is shared and totally non-deterministic and just maintains a long term average bandwidth. So trying to synthesize a beautiful sine wave works fine on actual hardware, not so well over a jittery USB. Its very much like the technical challenge of output sound to a local sound card vs stream VOIP across the public internet, which is really hard.

This is a cool hack, but I think the article would benefit from a deeper explanation of why "USB to serial" worked and "USB to parallel" would not.

by jpm_sd 10y ago

This is a cool hack, but I think the article would benefit from a deeper explanation of why "USB to serial" worked and "USB to parallel" would not.

tyingq 10y ago

>> "USB to serial" worked Somewhat. The combination of vendors sunsetting older chipsets (Prolific HX), and their reaction to counterfeit chips makes the USB-to-Serial world a huge pain in the ass. I'm hopeful the CH340 chipset eases the pain of supporting non-tech end users with these things.

janekm 10y ago
CH340 has no practical Mac support last I tried. Try CP2102, works great and cheap too.
- voltagex_ 10y ago
  Oh boy - looks like the same kinds of problems that happened when Microsoft started enforcing driver signing. https://tzapu.com/making-ch340-ch341-serial-adapters-work-under-el-capitan-os-x/ https://tzapu.com/making-ch340-ch341-serial-adapters-work-un... How difficult would it be to write a driver for these adapters from scratch?
- tyingq 10y ago
  Signed drivers for OSX do exist now: http://blog.sengotta.net/signed-mac-os-driver-for-winchiphead-ch340-serial-bridge/ http://blog.sengotta.net/signed-mac-os-driver-for-winchiphea... But...I'll check out CP2102.

kirrent 10y ago

USB to serial worked because he could do larger transfers of data to the AVR which would then do low latency byte by byte writes to the device when polled.

VLM 10y ago

Here comes a mostly true simplification. Printers speak an extremely low level protocol of "Once the printer ready pin indicates the printer is ready, load up one byte of data across 8 pins, smack a pulse out that says yo here is another valid byte, wait a bit, then repeat until you run out of data in the buffer to print". This is actually not too far from how parallel port hardware and port driver OS software worked. In practice the hardware ends up as something like 10 general purpose TTL IO ports, in fact in the REALLY old days our NON-integrated parallel printer ports used actual 8 bit latches like you'd see on memory busses from S-100 cards and stuff. Not the abstract concept of a latch but an actual TTL DIP chip like a 74LS373 or whatever printers use (I don't remember inverting or not or whatever) Newer hardware is way more complicated and "automated" and "buffered" but at some level the original PC compatible API locked down how low level it had to be and you have to be able to at least pretend you're GPIO to be "IBM PC Compatible". Standards being a great idea there are of course at least four SPP, EPP, and some others that spec'ed slightly more advanced but whatever. So the high level protocol PLUS industry monopoly compatibility meant if you sell it as "IBM PC compatible" its gotta be able to speak at a 10+ pins of general purpose IO level. The USB replacements do something different and appear to be printers and can no longer implement general purpose IO they implement "print a character" at the USB level not bit fiddling. I've not written a USB driver for a printer (on either side) so I'm a little fuzzy but what I've heard second hand is the USB level lives at an abstraction of "here's a packets worth of UTF-8 stream" Note that there were weird situations for RS-232 serial where you'd synthesize signals by weird pulsing of DTR leads or CTS or whatever that can be pretty well messed up by transitioning to a USB implementation of "heres a bit stream". I guess another way to look at it, is its easier to maintain compatibility across hardware generations for a single stream of bits so serial has it easy, whereas parallel was always a mismatch of high level byte transfer vs GPIO in the same system. The USB emulators only mass market making a printer work, not concerned about providing 10 or so pins of GPIO. There is other fun... to a first approximation (aka its untrue) no one implemented multipoint networks on parallel ports. So latency was approximately zilch and much hardware hacking relied on that. USB of course is shared and totally non-deterministic and just maintains a long term average bandwidth. So trying to synthesize a beautiful sine wave works fine on actual hardware, not so well over a jittery USB. Its very much like the technical challenge of output sound to a local sound card vs stream VOIP across the public internet, which is really hard.