It looks like you're new here. If you want to get involved, click one of these buttons!
In my quest to repurpose a couple of older Macs to work with BlinkyTape, I'm in a similar situation to BlinkyTape not identifying as TTY device on Linux where the Mac detects the BlinkyTape but doesn't create the TTY. The following is on a PowerPC Mac running OS X 10.5.8 (Leopard).
The Mac equivalent of a Linux
Bus 027 Device 000: ID 1d50:605e 1d50 BlinkyTape
dmesg log shows:
0 0 AppleUSBCDCACMControl: start - Failed to find the CDC driver AppleUSBCDCACMData: start: InterfaceMappings dictionary not found for this device. Assume CDC Device... 0 0 AppleUSBCDCACMData: start - Find CDC driver failed
I found the same error for a Microchip MCP2200 controller. Here is some troubleshooting info with way-over-my-head-highly-technical-details on why it isn't working -- MCP2200 not recognized on a mac/OS X and MCP2200 CDC for Mac OS X and Linux.
The solution is described at Serial connection on Mac OS X and [Traumflug/Generation_7_Electronics/USB tool/](https://github.com/Traumflug/Generation_7_Electronics/tree/master/USB tool).
I modified [mcp2200-forwarder.c](https://github.com/Traumflug/Generation_7_Electronics/blob/master/USB tool/mcp2200-forwarder/mcp2200-forwarder.c) lines 49 and 50 to be the hardcoded BlinkyTape USB vendor:product ID's of 1d50:605e. (There are references to ATmega at the above links, and I know the BlinkyTape uses an Atmega 32u4. I'm hoping this means the code is close enough.)
When compiled and run with the highest verbose mode, I get:
$ ./mcp2200-forwarder -vvv -l /tmp/ACM0 device_added() Device added. find_interfaces() Scanning interfaces ... Interface 0x00001703. Interface class 2, subclass 2. Interface has 1 endpoints. PipeRef 1: direction in, transfer type interrupt, maxPacketSize 16. Choosing this interface as Interrupt. Interface 0x00001A03. Interface class 10, subclass 0. Interface has 2 endpoints. PipeRef 1: direction out, transfer type bulk, maxPacketSize 64. PipeRef 2: direction in, transfer type bulk, maxPacketSize 64. Choosing this interface as Bulk. ... interface scan done. send_bridge_setup() Failed to take down DTE & RTS. Ignoring. (e000404f) Failed to set baud rate & co. Ignoring. (e000404f) Failed to raise DTE & RTS. Ignoring. (e000404f) Unable to set up USB-UART bridge. (e000404f) close_interface() device_removed() pty_open() Terminal name: /dev/ttys002 Created symlink to /tmp/ACM0
When I start a second shell session and run Oskari Okko Ojala’s Perl Device::BlinkyTape example code pointing to
'dev' => '/tmp/ACM0', it sits there thinking for a few seconds and doesn't send anything to the screen (as expected), not even an error. And, the BlinkyTape just gives me a blank stare .
The first shell session running mcp2200-forwarder shows only one new line:
pty_read(), event 0x0002
I'm wondering if someone here who is familiar with the BlinkyTape USB hardware could look at [mcp2200-forwarder.c](https://github.com/Traumflug/Generation_7_Electronics/blob/master/USB tool/mcp2200-forwarder/mcp2200-forwarder.c) and tell me if, or what, needs changing? I know enough to change the hardcoded vendor:product ID but that's the limit of what I know about what mcp2200-forwarder.c is doing with the USB code.
If this isn't practical to get going and there's no longer much of a reason for my older Macs to justify their existence and electric bill, I'll quite understand, but I would appreciate knowing either way.