devices firmware to load them as a libgpiod driver.

[adminy]

I'm not sure if this is possible, but I was wondering if these usb dongles can be used as linux gpio pins via the libgpiod device manager.

So they can show up as: /dev/gpiochipN where N is the current tinyMH plugged in.

Micronucleus is a bootloader over usb. Is there anything else needed for this to be detected as a device in gpioinfo ?

[SpenceKonde]

You want to make the tinies a USB device for function other that uploading? You're not gonna be happy.

Micronucleus only works as a bootloader because it was DOING NOTHING ELSE. because it needs to CONSTANTLY POLL THE USB LINEs. There was in the past a dream that interrupt-driven VUSB was posible, and that you would be able to create USB devices in arduino sketches and interact over USB. It is early grade school map to add up clocks it takes to get in and out of interrupts and see that you easilly blow the timing requirements.Digispark bent over backwards to try to make this work, and you canstill only make a very restricticted and constrained set of cases work;

On something newer like an AVR128DB64 extended temp range, overclocked at 48 MHz (twice spec) and with the ability to elevate the priority of the USB interrupt, that would have hope to bitbang USB in interrupt driven mode I suspect.

However I do not advise working on any bitbang USB solutions for modern AVRs however with the DU's so close. Once the DU's are available, and looking at microchip pricing trends. there will simply be no reason to do anything with a classic AVR either m32u4 or tiny with flaky fiddly VUSB. DU's will be priced below m32u4 and around vusb part prices if looking at historical at-release prices for modern AVRs (there's a big table of it over in DxCore docs, "AboutDxSeries" or something, near the bottom)

The DU's are upon release going to instantly become the only rational choice for an AVR developer looking for native USB. My guy on the inside tells me, it could be by the end of the year. But technically, he didn't specify which yeah. and this wouldn't be the first time that they have answered something like "Second quarter" and while it did come out in the second quarter of a year, I wasn't the one that one would have expected.... So I would advise you play with some of the new DD/DB series and modern tinyAVRs (see my other two cores) to get ready for the momentous release of the much anticipated DU-series 16/32k 14 and 20 pins, 16/32/64k 28 and 32 pins (basically it's a DD using MVIO to do the level shifting to USB levels, with the TCD and PLL was sacrificed at the alter of USB as well.,

With VUSB, you have a long road ahead,, which may not actually go all the way to what you want, and you need a lot of work to get it running at all.

With DU's real USB, barring unexpectedly severe bungling and errata. the road head should be more or less straight, wide and within a few months of technical briefs, practically paved for you.

[adminy]

libgpiod just encapsulates the ioctl calls and data structures behind a straightforward API. I don't really need it to be a full usb implementation, just as long as the pins can be set according to the signals coming from the usb and it would be nice if the usb was able to read pins also, but a bare minimum if it was possible to do outputting. If I can't even use them as bit shift registers then what good is this hardware? My intended use was simply to just take 2 pins and turn them into 15 pins. surely that should be possible with this ... I ran out of pins on the Pi and I wanted to use the tiny88 as a gpio extender. Turn the tiny88 into 16-channel 5V USB Serial Port Control Switch

[SpenceKonde]

Yeah, exactly - that's what I was talking about, you want to have a sketch running that uses VUSB to pretend to be some sort of USB device and communicate over USB, to provide access to it's GPIO pins.

That's what I'm talking about. It cannot work in an Arduino sketch context. The timing constraints are such that you cannot get something that approximates a USB device without throwing basically everything else overboard. You're writing straight C and probably assembly in time critical part. I attempted to make VUSB client devices work from the arduino context years ago, nothing fucking worked, it was a total shitshow, and and I worked off and on for a year or so - and then I finally pinned down someone who knew wtf he was talking about (Yeah, I found someone like that - it was a momentous occasion - people were dancing in the streets, setting off fireworks and popping champagne in celebration - until they heard what he had to say, and then they all put away the fireworks, chugged their champagne to dull the pain of the news, and shuffled sadly home because they wanted to make Arduino VUSB client devices too). Once I learned what the problem was, and through mathematics satisfied myself that on a classic AVR, it's never going to work well and working at all would require painful sacrifices. The timing constraints are just too demanding, AVRs The only way it would ever have a snowballs chance in hell is if you gunned serial, millis, and anything else that used interrupts and wrote it like they wrote micronucleus in terms of polling. And that's the the treasure at the end of the rainbow? Really?

I decided that directing further resources towards attempting anything other than a bootloader with VUSB, in light of the still-dismal best case scenario on a VUSB device, and the impending arrival of the DU-series (you'll be able to get 32-pin ones.... Of those pins, assuming you want both reset and UPDI, which most people do, those'll give you up to 23 gpio pins (and you can run the DU at any voltage between 1.8 and 5.5v while USB runs at 3.3v making interfacing with different voltages easy) and they run up to 24 MHz regardless of voltage, with a temperature range that (waterproofing issues aside) would be in spec if the board was sitting in a pot of boiling water (and that's not even the extended temp range parts - they're rated up to 125C. Same max clocks and all). That's the rated speed too to be clear - if the other Dx-series are a guide, you can probably overclock the bejeezus out of them too.

So yeah I've concluded that the quality of the best case results did not warrant the compromises and development resources to support acting as a VUSB device except for the bootloader. I came to that conclusion before I saw the DU-series product brief and became aware that there was an all new ass-whooping part on the way with native USB and tinyAVR-like pincounts.

DU-series is 14/20/28/32 pins)16/32k on the small pincounts 16/32/64k on the big ones, Dx-like SRAM progression (2k, 4k, 8k). I expect to see the 16k parts launch not far north of a buck, with 64k parts not more than $2 for the cheapest package of a given pincount (just my predictions). That these parts feature a dual USART raises the possibility of a 14-pin DU being used as a dual serial adapter. But even a single serial adapter based around an AVR has some magic, because AVRs can do things normal serial adapters can't, such as running in single wire mode, or sync mode (the S in USART, which nobody in their right mind uses), or 9-bit mode (which is such a nightmare that even the people who are out of their mind have the sense to avoid it). But yeah - with something like that coming (likely the next family of AVRs to be released - though I am not placing any bets on that, not since 16EB headers showed up in an ATpack first - though the EB is tiny-like, and headers for those have always come out further ahead of release than the Dx-like parts), with those specs, and with that kind of expected pricing (just based on what their new products have been launching at), I would have to be out of my mind to waste time (and this would be a BFD to attempt, with success uncertain) jury rig some way to make VUSB kind-of-work on these aging parts, unless I was being paid by the hour.