Mathieu Daëron

> Hey, I tried to include the ulab library (written for micropython) in this fork. > I always get this error: > `error: conflicting type qualifiers for 'ulab_user_cmodule' mp_obj_module_t ulab_user_cmodule`...

I second both options (upstream or standalone module). It would be really nice to have access to more that DAC.write().

> I think making it easier for `mpremote` to find a connected board on macOS is a good suggestion. > > You _can_ however, get somewhere towards this via the...

> You could do: `mpremote connect /dev/cu.usbmodem*` - I use that as an alias. This seems to break the ability to automatically find the first free device. If I connect...

#9140 aims to fix this issue.

This PR corrects a bug on macOS, where `cu.Bluetooth-Incoming-Port` is considered an eligible port for mpremote auto connect (#8485). The fix is perhaps brittle (check `sys.platform`), and could need to...

> I don't think that PR is a good idea. Since the docs say "This command automatically detects and connects to the first available serial device" and Macs for some...

+1 for this feature. Easy anchor links to headers would be so useful! Is there any chance to eventually implement this?

> Note that a board with a WCH chip like the CH340/CH9102 (a common replacement for CP210x these days), using the official driver (which is required to work properly, at...

I've tried to look into this again: * When installing `mpremote` from PyPI in a clean environment, I get version 0.4.0 and it treats `/dev/cu.Bluetooth-Incoming-Port` as a valid port. *...