"usbhid-ups" programing problem...

"usbhid-ups" programing problem...

[Michelle Konzack]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Hello,

after reading tonns of documentations I am puzzeling arround HOW
to implement the "usbhid-ups" in my Hardware...  Can anyone point
me into the right direction or to documents (with examples) how
to code such stuff?

Thanks, Greetings and nice Day
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: "usbhid-ups" programing problem...

[Andrew Lunn]

On Tue, Apr 29, 2008 at 08:19:22PM +0200, Michelle Konzack wrote:
> Hello,
> 
> after reading tonns of documentations I am puzzeling arround HOW
> to implement the "usbhid-ups" in my Hardware...  Can anyone point
> me into the right direction or to documents (with examples) how
> to code such stuff?

eCos is rather lacking in USB examples. Nobody contributes back there
USB class drivers.

What you can look at is the USB Ethernet code in packages/io/usb/eth
and the usb test programs in io/usb/slave/current/tests. These show
have the basic USB interface words.

     Andrew

Re: "usbhid-ups" programing problem...

[Frank Pagliughi]

Andrew Lunn wrote:
 > eCos is rather lacking in USB examples. Nobody contributes back there
 > USB class drivers.
 >
 >   
I'm actually going to be using eCos again pretty soon, and have been 
digging through some of my old stuff, including a nearly finished driver 
for the Philips/NXP ISP1181 chip, which I promised to submit two years 
ago. Maybe I can start with a few simple examples, like usb serial or a 
usb printer. Where would they go?

For that matter, the usb subsystem could use a bit of an upgrade to make 
drivers easier to write.

Frank Pagliughi

Re: "usbhid-ups" programing problem...

[Michelle Konzack]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Hello Frank,

Am 2008-05-01 11:38:19, schrieb Frank Pagliughi:
> I'm actually going to be using eCos again pretty soon, and have been 
> digging through some of my old stuff, including a nearly finished driver 
> for the Philips/NXP ISP1181 chip, which I promised to submit two years 
> ago. Maybe I can start with a few simple examples, like usb serial or a 
> usb printer. Where would they go?

Do you use the code from the Linux-Kernel or your own one?
Since the Linxkernel does not support very good this chip,

I have mixed it up with the code provided by NXP...

I am using Debian/ARM on the ARM922T CPU and for now it works.

Thanks, Greetings and nice Day
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: "usbhid-ups" programing problem...

[Andrew Lunn]

On Thu, May 01, 2008 at 11:17:19AM -0400, Frank Pagliughi wrote:
> Andrew Lunn wrote:
>> eCos is rather lacking in USB examples. Nobody contributes back there
>> USB class drivers.
>>
>>   
> I'm actually going to be using eCos again pretty soon, and have been  
> digging through some of my old stuff, including a nearly finished driver  
> for the Philips/NXP ISP1181 chip, which I promised to submit two years  
> ago.

It is probably worth looking at the assignments stuff. You will need
an FSF assignment before we can accept these contributions.

> Maybe I can start with a few simple examples, like usb serial or a  
> usb printer. Where would they go?

A CDC serial driver would be good. I would put it in

packages/io/usb/serial/slave/

> For that matter, the usb subsystem could use a bit of an upgrade to make  
> drivers easier to write.

Others have said that as well. But it needs somebody to actually do
it. A lot depends on the complexity of the driver. I recently wrote a
simple driver and a Linux kernel counterpart without too much effort.

        Andrew

Re: "usbhid-ups" programing problem...

[Gary Thomas]

Andrew Lunn wrote:
> On Thu, May 01, 2008 at 11:17:19AM -0400, Frank Pagliughi wrote:
>> Andrew Lunn wrote:
>>> eCos is rather lacking in USB examples. Nobody contributes back there
>>> USB class drivers.
>>>
>>>   
>> I'm actually going to be using eCos again pretty soon, and have been  
>> digging through some of my old stuff, including a nearly finished driver  
>> for the Philips/NXP ISP1181 chip, which I promised to submit two years  
>> ago.
> 
> It is probably worth looking at the assignments stuff. You will need
> an FSF assignment before we can accept these contributions.
> 
>> Maybe I can start with a few simple examples, like usb serial or a  
>> usb printer. Where would they go?
> 
> A CDC serial driver would be good. I would put it in
> 
> packages/io/usb/serial/slave/
> 
>> For that matter, the usb subsystem could use a bit of an upgrade to make  
>> drivers easier to write.
> 
> Others have said that as well. But it needs somebody to actually do
> it. A lot depends on the complexity of the driver. I recently wrote a
> simple driver and a Linux kernel counterpart without too much effort.

Perhaps you could share it as an example?


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: "usbhid-ups" programing problem...

[Andrew Lunn]

>> Others have said that as well. But it needs somebody to actually do
>> it. A lot depends on the complexity of the driver. I recently wrote a
>> simple driver and a Linux kernel counterpart without too much effort.
>
> Perhaps you could share it as an example?

Unfortunately it was done with my employee hat on, not my hobby hat.
Getting the O.K. to distribute it will not be easy...

        Andrew

Re: "usbhid-ups" programing problem...

[Frank Pagliughi]

>   
>> For that matter, the usb subsystem could use a bit of an upgrade to make  
>> drivers easier to write.
>>     
>
> Others have said that as well. But it needs somebody to actually do
> it. A lot depends on the complexity of the driver. I recently wrote a
> simple driver and a Linux kernel counterpart without too much effort.
>
>  
Yes, when the USBS framework was specified (ten years ago?) most USB 
chips were ugly beasts, with predefined endpoints, lots of limitations, 
and lots of bugs.

Most of the recent chips that I've seen appear to have a control 
endpoint and some number of fairly generic endpoints. Combining the 
usbs_rx_endpoint and usbs_tx_endpoint into a single thing 
(usbs_endpoint), adding an endpoint number and direction, and things 
like that would be helpful. I could make a list.

Many of the ideas could break the existing USBS drivers. Would this be OK?


But, if we wanted to get fancy, most of the events that a USBS driver 
respond to are the same:
- Respond to a bus reset
- Set the address
- Read an RX endpoint
- Fill a TX endpoint.
...

A common code base for USB drivers might be really helpful.   I could do 
this work, but would it be accepted?

Frank

Re: "usbhid-ups" programing problem...

[Andrew Lunn]

> Most of the recent chips that I've seen appear to have a control  
> endpoint and some number of fairly generic endpoints. Combining the  
> usbs_rx_endpoint and usbs_tx_endpoint into a single thing  
> (usbs_endpoint), adding an endpoint number and direction, and things  
> like that would be helpful. I could make a list.

The AT91 USB driver already does that to some extent.

> Many of the ideas could break the existing USBS drivers. Would this be OK?

Sorry, no. 

However you can add a new USB package parallel to the existing
one. That is the nice thing about the package system.

> A common code base for USB drivers might be really helpful.   I could do  
> this work, but would it be accepted?

Sure, so long as the assignment is in place so we can accept it.

      Andrew