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.

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

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

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

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