AdaFruit and Haiku USB

Something of a disappointment… Being so far behind the curve, I decided it was time to start playing with a microcontroller or two. I got all motivated when I saw an article (in IEEE Spectrum) that mentioned the latest AdaFruit boards with built in Python! The blurb says that they just present a pseudo disk drive to USB, with a ‘main.py’ on it that one can edit. So I gleefully ordered a “Trinket M0”. Should work with any OS [they said…]

Unfortunately not. When I try to mount (on my usual year or so old hrev) I get “General OS Error”! I switched to a rather newer version (still not all that recent) and rather than posting an error panel it just freezes and probably KDLs. At some point I’ll update the kernel again, but I’m not hopeful.

On the earlier hrev, SerialConnect works fine with the Python REPL provided, but not in the newer one! A stream of garbage pours out.

Of course it’s all as advertised in Linux. I looked at the mount parameters of the Trinket and a simple USB stick and they’re identical, so I’ve no idea what’s foiling Haiku. Shame – I was hoping to work from there.

As you guess, Haiku USB or mass storage support over USB have still some bugs.
Could you retry to connect your AdaFruit to a a recent hrev of Haiku and grab the syslog (after reboot if it crash), there should be some valuable USB errors that could help us to find what’s wrong?
Filing a bug on dev.haiku-os.org with these attachment will be very helpful.

Regarding SerialConnect, I suspect there is a usb mode switch required to turn the Trinket from usb mass storage device to a ACM device. Some udev on linux should do it by default, but not on Haiku.

If you can connect to it, then it is already in serial mode and published a device in /dev/ports/usb0. So it is unlikely that a mode switch would help.

A “listusb -v” would be useful, to see if it is a standard ACM device or one of the custom ones (FTDI, Prolific, …). ACM looks more probable as there is no external USB serial converter on-board. But it’s quite possible our driver has a problem with the particular configuration (maybe it just uses the wrong endpoints). Maybe it’s possible to fix the problem on that side just by looking at the output of listusb and the usb serial driver.

For the mass storage part we will indeed need a syslog or KDL backtrace.

Thanks for your responses, Philippe and Adrien. I’m somewhat occupied with other things right now (that Trinket, for example :slight_smile:) but I’ll try to dig out some debugging info later. I’ll need to update a partition first, though.

[I’ll confess I have great reluctance to updating these days. Every time I do, something else breaks, but my 2-yearold hrev is fine for e.g. MusicWeaver and Csound (and the browsers at least work) so I’m not going to move away from that except for experimenting. As an example of breakage, the latest I have – hrev50559 – clobbers two of my USB ports! Yes, I should investigate and submit a ticket, but motivation is low.]

The more you wait before creating tickets, the harder it becomes to solve them. Because devs forget what they were working on, they moved to other things, etc. Going through 2 years of change to find when exactly the problems started happening is not going to be fun.