Re: Polymorphic devices
Iain Hibbert writes: > On Fri, 5 Jan 2024, Brad Spencer wrote: > >> I see a few options for doing this, such as simply matching all of the >> possible children and using sysctl to enable the one you want. Probably >> followed by a rescan call. That seems ugly, however. The use of >> 'drvctl -r -a ' seemed to hold promise. It seems like a >> better idea to require the detachment of whatever followed by the rescan >> with the attribute indicating which sort of thing you wanted to attach >> (detach ucom in favor of i2c, for example). But I do not completely >> understand if this sort of thing is possible. > > I don't see why it shouldn't be.. you attach your main driver as a bus, > then send it a message as to what configuration you need, then it > essentially rescans and finds and attaches or detaches sub-drivers as > appropriate. > > I did this sort of thing in software with bthub(4) > > iain Thanks for that. bthub(4) appears to be close to the idea I need. I will look at it in detail. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Polymorphic devices
Brad Spencer writes: > I don't know just yet, but there might be unwanted device reset the "use > the one you open" technique. That is, you might have to reset the chip > to change mode and if you support say, I2C and GPIO at the same time > (which is possible), but then change to just GPIO the chip has to be > reset and that will disrupt any setting you might have set (I think, I > am am still working out what needs to happen with the mode switches). > This may not matter in the bigger picture and it wouldn't matter as much > if the mode switch was a sysctl, which one can say will reset the chip > anyway. Interesting complexity, but I'd say state the user has asked for should live in the driver and if it has to write that again on mode switch so be it. Generally if you open a device and close it you don't have much grounds to expect things you did to persist to the next session, but devices have device-specific semantics anyway.
Re: Polymorphic devices
m...@goathill.org (MLH) writes: > Brad Spencer wrote : > >> It has a built in UART which is a separate USB device and then >> a USB device that can be programmed to provide I2C, Hello... > What are you using to flash these devices? No flashing of anything is needed to use the I2C mode. All you need to do is send the proper control commands down the USB bus and have the I2C bus glue in place to make a bus. The MPSSE mode uses all of the same USB endpoints as the UART mode, just with a different protocol. You can do a lot of this today from userland with pyftdi (a pure Python solution), libmpsse and libftdi, all of which are open source based upon reverse engineering the FTDI USB protocol. Or.. you can download the closed source FTDI userland library and work with the chip with that, but that is only available for some systems, of course. What I want is a proper NetBSD i2c bus, which should be possible. > I have been using several I2C devices such as servomotor controllers, > i/o extenders, relay controllers, displays, etc. with arduino > controllers (waiting on some esp32 boards now) and most of the > non-standard arduino boards require flashing (via usb) of some sort > to set what you want to use, as I will have to so with the esp32s. > > I am having to use a 10-yr-old windows laptop to flash and program > these things. I wish we had the Arduino IDE ported to NetBSD as it > is a very nice tools for this but waiting for 10 minutes for the > thing to come up under windows is tiring. Once they are up, many > of these controllers have bluetooth, ethernet and wifi support > where I can control them directly from NetBSD but getting them > there and programming them is archaic on windows. Ya, I thought that the Ardunio compiler was in pkgsrc, which I think is just gcc. > Yes, there are the basic programmers in pkgsrc but the arduino ide > can easily program a complete package linked to a git repository > into these devices very nicely (once you have it up and running) > and runs on linux. Ya, I do some Ardunio stuff from time to time and use the graphically IDE for that. > Having I2C devices directly accessible sounds interesting though. I think so as well,, which is mostly why I am trying to get this working. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Polymorphic devices
On Fri, 5 Jan 2024, Brad Spencer wrote: > I see a few options for doing this, such as simply matching all of the > possible children and using sysctl to enable the one you want. Probably > followed by a rescan call. That seems ugly, however. The use of > 'drvctl -r -a ' seemed to hold promise. It seems like a > better idea to require the detachment of whatever followed by the rescan > with the attribute indicating which sort of thing you wanted to attach > (detach ucom in favor of i2c, for example). But I do not completely > understand if this sort of thing is possible. I don't see why it shouldn't be.. you attach your main driver as a bus, then send it a message as to what configuration you need, then it essentially rescans and finds and attaches or detaches sub-drivers as appropriate. I did this sort of thing in software with bthub(4) iain
Re: Polymorphic devices
Brad Spencer wrote : > It has a built in UART which is a separate USB device and then > a USB device that can be programmed to provide I2C, What are you using to flash these devices? I have been using several I2C devices such as servomotor controllers, i/o extenders, relay controllers, displays, etc. with arduino controllers (waiting on some esp32 boards now) and most of the non-standard arduino boards require flashing (via usb) of some sort to set what you want to use, as I will have to so with the esp32s. I am having to use a 10-yr-old windows laptop to flash and program these things. I wish we had the Arduino IDE ported to NetBSD as it is a very nice tools for this but waiting for 10 minutes for the thing to come up under windows is tiring. Once they are up, many of these controllers have bluetooth, ethernet and wifi support where I can control them directly from NetBSD but getting them there and programming them is archaic on windows. Yes, there are the basic programmers in pkgsrc but the arduino ide can easily program a complete package linked to a git repository into these devices very nicely (once you have it up and running) and runs on linux. Having I2C devices directly accessible sounds interesting though.
Re: Polymorphic devices
Greg Troxel writes: > Brad Spencer writes: > >> The first is enhancements to ufdti to support the MPSSE engine that some >> of the FTDI chip variants have. This engine allows the chip to be a I2C >> bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, >> as well as the normal USB UART. It is not possible to use all of the >> modes at the same time. That is, these are not separate devices, but >> modes within one device. Or another way, depending on the mode of the >> chip you get different child devices attached to it. I am curious on >> what the thoughts are on how this might be modeled. > > My reaction without much thought is to attach them all and to have the > non-selected one return ENXIO or similar. And to have another device on > which you call the ioctl to choose which device to enable. > > Or perhaps, to let you open any of them, flipping the mode, and to fail > the 2nd simultaenous open. Those techniques and models have occured to be too, except I probably would still elect to use use a sysctl instead of another device with a ioctl. I don't know just yet, but there might be unwanted device reset the "use the one you open" technique. That is, you might have to reset the chip to change mode and if you support say, I2C and GPIO at the same time (which is possible), but then change to just GPIO the chip has to be reset and that will disrupt any setting you might have set (I think, I am am still working out what needs to happen with the mode switches). This may not matter in the bigger picture and it wouldn't matter as much if the mode switch was a sysctl, which one can say will reset the chip anyway. In any case, thanks for the comments... -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Polymorphic devices
Brad Spencer writes: > The first is enhancements to ufdti to support the MPSSE engine that some > of the FTDI chip variants have. This engine allows the chip to be a I2C > bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, > as well as the normal USB UART. It is not possible to use all of the > modes at the same time. That is, these are not separate devices, but > modes within one device. Or another way, depending on the mode of the > chip you get different child devices attached to it. I am curious on > what the thoughts are on how this might be modeled. My reaction without much thought is to attach them all and to have the non-selected one return ENXIO or similar. And to have another device on which you call the ioctl to choose which device to enable. Or perhaps, to let you open any of them, flipping the mode, and to fail the 2nd simultaenous open.
Polymorphic devices
Hello I am in need of some advise and guidance. I am working slowly on device support for a couple of USB chips that have multiple, but somewhat mutually exclusive, behaviors. The first is enhancements to ufdti to support the MPSSE engine that some of the FTDI chip variants have. This engine allows the chip to be a I2C bus, SPI bus and provides some simple GPIO, and a bunch of other stuff, as well as the normal USB UART. It is not possible to use all of the modes at the same time. That is, these are not separate devices, but modes within one device. Or another way, depending on the mode of the chip you get different child devices attached to it. I am curious on what the thoughts are on how this might be modeled. I see a few options for doing this, such as simply matching all of the possible children and using sysctl to enable the one you want. Probably followed by a rescan call. That seems ugly, however. The use of 'drvctl -r -a ' seemed to hold promise. It seems like a better idea to require the detachment of whatever followed by the rescan with the attribute indicating which sort of thing you wanted to attach (detach ucom in favor of i2c, for example). But I do not completely understand if this sort of thing is possible. The second chip is the MCP2221 which provides some of the same features as the FTDI MPSSE engine. It has a built in UART which is a separate USB device and then a USB device that can be programmed to provide I2C, GPIO, some DAC a bit of ADC (low number of bits in both of those cases, but still interesting enough). You can probably always just provide the I2C bus and then flip the behaviors of the GPIO pins by setting their alt settings. This chip may be a bit simpler to deal with with the using gpio alt settings and such, but I also have not looked at this one as much. If I can get these to work, the end result will be that any system with USB, including virtual systems with USB devices presented to it in some way, can have I2C, simple GPIO and maybe SPI ... and this is the place I want to end up for my own needs. I have looked around the tree for other devices that do this sort of thing and didn't really find any that tried to deal with this sort of situation, but I will admit I looked mostly at the MI devices. Any thoughts would be appreciated, -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org