--device is hardcoded for a specific playdate on Unix

[kettle11]

This line is hardcoded for a specific playdate number so it won't work unless you're lucky enough to have that exact playdate.:

crank/src/main.rs

Line 370 in 6ac4323

let modem_path = Path::new("/dev/cu.usbmodemPDU1_Y0005491");

[rtsuk]

I think #23 provides a work-around. I'll make the default work better in the future.

[rtsuk]

Since the modem appears and disappears as the device is mounted as a disk, I don't think there is a way to make a good default. I think an environmental variable is the best we can do.

[kettle11]

Since the modem appears and disappears as the device is mounted as a disk, I don't think there is a way to make a good default. I think an environmental variable is the best we can do.

I think a way to make it work would be to check for a modem with the correct prefix, if it exists use that. If it doesn't exist check for the PLAYDATE volume and eject it then search for the modem again.

[rtsuk]

So long as there's some code to handle the no playdate plugged in at all case that seems good to me.

[rtsuk]

Something like ioreg -p IOUSB | grep Playdate would work on Mac. lsusb for Linux, and maybe Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^USB' } | Select-String Playdate on Windows?

[tjkirch]

I think a way to make it work would be to check for a modem with the correct prefix, if it exists use that
lsusb for Linux

At least with lsusb 015, it only shows CDC ACM capability info, not the device path, at least not directly. Since other devices (like my keyboard) have the capability as well, that alone isn't enough to find the device. Here's how that section of the Playdate's information shows up:

  iManufacturer           1 Panic Inc
  iProduct                2 Playdate
  iSerial                 3 PDU1-Y999999
...
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
...
    Interface Descriptor:
      bInterfaceClass        10 CDC Data
...

However, I found that the kernel (or udev) creates a very useful symlink to the ttyACM device:

/dev/serial/by-id/usb-Panic_Inc_Playdate_PDU1-Y999999-if00 -> ../../ttyACM1

The pieces of the symlink name come from the manufacturer, product, and serial from lsusb, so we could probably reconstruct the exact name and therefore find the link, but I think it'd be fine to wildcard /dev/serial/by-id/usb-Panic_Inc_Playdate_PDU1-* and use the result. We'd use the link target if found, and fall back to the current logic if not. If someone has two Playdates connected, they would set $PLAYDATE_SERIAL_DEVICE, as they would today.

What do you think? I could write that for the Linux case.

[rtsuk]

Worth a shot. I'm not sure when I'll have the time to do the Mac side of the work, but that's no reason not to make it better for Linux.