Hi Chris
Chris Holgate wrote:
> John Dallaway wrote:
>
>> If you provide a new target record in pkgadd.db which matches the name
>> of an existing target record in ecos.db, the packages listed in the new
>> target record will be appended to the existing target record by
>> ecosadmin.tcl. So you
Hi John,
John Dallaway wrote:
> If you provide a new target record in pkgadd.db which matches the name
> of an existing target record in ecos.db, the packages listed in the new
> target record will be appended to the existing target record by
> ecosadmin.tcl. So you could do something like this i
Hi Chris
Chris Holgate wrote:
> John Dallaway wrote:
>>
>> I note that you've defined a new eCos target for "STM3210E-EVAL with
>> USB". This should not be necessary.
>
> That's there because I want the new package to be loadable against the
> 3.0 release using the package manager and I couldn
With the STM32 driver, it is possible to ...
I'll have a look at this new driver as soon as possible. Sounds interesting.
Hi John,
Sorry about the delay in getting back - I got distracted by the other
thread of this discussion...
John Dallaway wrote:
> Hi Chris
>
> Great to see more USB support for eCos.
>
> Chris Holgate wrote:
>
>> OK - I've now done a bit of tidying up which I hope won't have broken
>> it! Th
Frank Pagliughi wrote:
>
>> My main bugbear is the way in which class drivers currently access
>> device endpoints. At the moment you need to know which low level driver
>> is in use and the completely arbitrary names of the exported static
>> endpoint data structures. This should really be hidd
My main bugbear is the way in which class drivers currently access
device endpoints. At the moment you need to know which low level driver
is in use and the completely arbitrary names of the exported static
endpoint data structures. This should really be hidden behind a generic
API which is de
Frank Pagliughi wrote:
>
> Yeah, the USB subsystem for eCos was written at a time when USB chips
> were quite rigid - endpoints with fixed sizes and functions. Now, most
> chips are more flexible than not, with generic endpoints and
> configurable memory allocation. So the existing eCos infrastruc
Chris Holgate wrote:
Ethernet for the STM32? I'd considered having a stab at a driver for
one of the SPI based Ethernet chips (either the Micrel or Microchip) but
just don't have the time right now.
We don't have the possibility to add real ethernet to our platform,
using ethernet over USB co
Chris Holgate wrote:
Andrew Lunn wrote:
The AT91 USB driver has something similar to this. It can configure
the endpoints by looking at the USB descriptors.
I've just had a quick look back at the AT91, and while there's a certain
degree of flexibility there, it's still limited to the
Simon Kallweit wrote:
> Chris, do you have any example code using your driver?
There's the high-level driver for my application, but that's quite
involved and will probably obscure more than it illuminates...
> I may be working on USB serial and ethernet support.
Ethernet for the STM32? I'd c
Andrew Lunn wrote:
> The AT91 USB driver has something similar to this. It can configure
> the endpoints by looking at the USB descriptors.
>
I've just had a quick look back at the AT91, and while there's a certain
degree of flexibility there, it's still limited to the particular
configuration de
Andrew Lunn wrote:
There is a significant difference from the other USB drivers which I
should probably flag up (and document). The endpoint configuration is
generated dynamically from the USB descriptors. This gives a lot of
flexibility and potentially allows support for multiple configuration
Hi Chris
Great to see more USB support for eCos.
Chris Holgate wrote:
> OK - I've now done a bit of tidying up which I hope won't have broken
> it! The latest version of the package is here:
>
> http://www.zynaptic.com/ecos/packages/stm32-usb-20090519.epk
I note that you've defined a new eCos
> >> There is a significant difference from the other USB drivers which I
> >> should probably flag up (and document). The endpoint configuration is
> >> generated dynamically from the USB descriptors. This gives a lot of
> >> flexibility and potentially allows support for multiple configurations
Simon Kallweit wrote:
> Chris Holgate schrieb:
>>
>> It's stable in my application using my own Linux kernel driver (several
>> million bulk and interrupt transactions and counting!).
>>
> That sound's pretty stable to me :)
OK - I've now done a bit of tidying up which I hope won't have broken
16 matches
Mail list logo
