Hi all What would be a good choice for low-end embedded hardware (single board systems � la raspi, cubieboard) with good support for USB slave mode? As in there is USB hardware onboard that can be configured to run in USB device / slave mode and there is kernel support for it; as in gadget driver. I gather this mode or something like it was / is supported on the early RasPi models. Preferably on the software side there would be some bridge to userland so as not to have to meddle in kernel affairs in order to implement a device protocol. Any hints would be greatly appreciated. Thanks --Dietmar
embedded hardware choices with good usb slave support?
Started by ●January 19, 2016
Reply by ●January 19, 20162016-01-19
Dietmar Nowack wrote:> Hi all What would be a good choice for low-end embedded hardware > (single board systems � la raspi, cubieboard) with good support for > USB slave mode? As in there is USB hardware onboard that can be > configured to run in USB device / slave mode and there is kernel > support for it; as in gadget driver.Most will have a USB OTG ( On The Go ) port. https://en.wikipedia.org/wiki/USB_On-The-Go " Use of USB OTG allows those devices to switch back and forth between the roles of host and client." The USB OTG port is often used to reflash devices.> I gather this mode or something > like it was / is supported on the early RasPi models. Preferably on > the software side there would be some bridge to userland so as not 1to > have to meddle in kernel affairs in order to implement a device > protocol. Any hints would be greatly appreciated. Thanks --Dietmar >-- Les Cargill
Reply by ●January 20, 20162016-01-20
Thanks for your answer, Les. You're right, it seems that OTG is available pretty much on all systems, with the exception RaspberryPI B models, as far as I could make it out. And GadgetFS is what I was looking for in terms of implementing device protocols; I guess I'm all set. Cheers Dietmar> Most will have a USB OTG ( On The Go ) port. > > https://en.wikipedia.org/wiki/USB_On-The-Go > > " Use of USB OTG allows those devices to switch back and forth between > the roles of host and client." > > > The USB OTG port is often used to reflash devices. > > > I gather this mode or something > > like it was / is supported on the early RasPi models. Preferably on > > the software side there would be some bridge to userland so as not 1to > > have to meddle in kernel affairs in order to implement a device > > protocol. Any hints would be greatly appreciated. Thanks --Dietmar > > > -- > Les Cargill
Reply by ●January 20, 20162016-01-20
Dietmar Nowack wrote:> Thanks for your answer, Les. > You're right, it seems that OTG is available pretty much on all systems, with the exception RaspberryPI B models, as far as I could make it out. And GadgetFS is what I was looking for in terms of implementing device protocols; I guess I'm all set. > > Cheers > Dietmar >Don't relax just yet. Dig a little deeper and make sure there is software support for it to be used as you expect it to work. Unfortunately, this is a ragged process. Using the OTG to reflash is critical; other uses are not.>> Most will have a USB OTG ( On The Go ) port. >> >> https://en.wikipedia.org/wiki/USB_On-The-Go >> >> " Use of USB OTG allows those devices to switch back and forth between >> the roles of host and client." >> >> >> The USB OTG port is often used to reflash devices. >> >>> I gather this mode or something >>> like it was / is supported on the early RasPi models. Preferably on >>> the software side there would be some bridge to userland so as not 1to >>> have to meddle in kernel affairs in order to implement a device >>> protocol. Any hints would be greatly appreciated. Thanks --Dietmar >>> >> -- >> Les Cargill-- Les Cargill
Reply by ●January 20, 20162016-01-20
Devil's in the details, to be sure. That said I'm actually fairly confident now I can build upon the code examples accompanying the GadgetFS API [essentially a generic USB kernel driver that maps packet streams, descriptors and endpoint configuration to user space via the file system] in order to do what I want to do. Particularly so because my needs are more in the line of a simple FIFO rather than implementing the mass storage protocol implied by reflashing. Cheers, Dietmar> Don't relax just yet. > > Dig a little deeper and make sure there is software support for it > to be used as you expect it to work. Unfortunately, this is a > ragged process. > > Using the OTG to reflash is critical; other uses are not.
