* STM32 USB support [not found] ` <4A11E5DF.2000403@intefo.ch> @ 2009-05-19 11:47 ` Chris Holgate 2009-05-19 12:00 ` Andrew Lunn 2009-05-19 13:33 ` John Dallaway 0 siblings, 2 replies; 16+ messages in thread From: Chris Holgate @ 2009-05-19 11:47 UTC (permalink / raw) To: Simon Kallweit, ecos-devel 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 it! The latest version of the package is here: http://www.zynaptic.com/ecos/packages/stm32-usb-20090519.epk There are a couple of minor TODO's which I need to revisit before a proper release, but nothing significant. >> However, I've not had much luck getting it working with the standard >> eCos test framework - although I now suspect thats a Linux usbfs issue >> rather than my driver. I also need to sort out some proper >> documentation! > > Well, I could do some testing too and see where I get. That would be very helpful, although I think that the standard host-side tests have only ever been run on a pretty old version of Linux. I'd have more confidence in testing against some standard drivers like a virtual serial port or a 'memory stick' device. >> 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 >> (untested!). However, the downside is that I had to leave out devtab >> support since the devtab entries need to be set statically. >> > Don't you think it's possible to have both options? I haven't looked at > the USB subsystem or any drivers, but I think a public driver should > behave as the subsystem intends. Maybe the subsystem could be extended > for more dynamic usage though. The official docs say "To support this the device driver can provide a devtab entry for each endpoint". I took that to mean that devtab support was optional - and the dynamic endpoint configuration is a much more useful feature IMHO. Previously supported hardware has had fixed endpoint configurations which makes the static devtab entries easy to implement. However, with dynamic endpoint configuration, the low-level driver doesn't know a-priori what endpoints to generate devtab entries for - and nor should it! Copied to the list, since I'm sure there are other people who would like to comment... Chris. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 11:47 ` STM32 USB support Chris Holgate @ 2009-05-19 12:00 ` Andrew Lunn 2009-05-19 15:17 ` Simon Kallweit 2009-05-19 15:44 ` Chris Holgate 2009-05-19 13:33 ` John Dallaway 1 sibling, 2 replies; 16+ messages in thread From: Andrew Lunn @ 2009-05-19 12:00 UTC (permalink / raw) To: Chris Holgate; +Cc: Simon Kallweit, ecos-devel > >> 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 > >> (untested!). However, the downside is that I had to leave out devtab > >> support since the devtab entries need to be set statically. > >> > > Don't you think it's possible to have both options? I haven't looked at > > the USB subsystem or any drivers, but I think a public driver should > > behave as the subsystem intends. Maybe the subsystem could be extended > > for more dynamic usage though. > > The official docs say "To support this the device driver can provide a > devtab entry for each endpoint". I took that to mean that devtab > support was optional - and the dynamic endpoint configuration is a much > more useful feature IMHO. > > Previously supported hardware has had fixed endpoint configurations > which makes the static devtab entries easy to implement. However, with > dynamic endpoint configuration, the low-level driver doesn't know > a-priori what endpoints to generate devtab entries for - and nor should it! The AT91 USB driver has something similar to this. It can configure the endpoints by looking at the USB descriptors. I don't remember how it works with respect to devtab entries. Andrew ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 12:00 ` Andrew Lunn @ 2009-05-19 15:17 ` Simon Kallweit 2009-05-19 16:28 ` Chris Holgate 2009-05-19 15:44 ` Chris Holgate 1 sibling, 1 reply; 16+ messages in thread From: Simon Kallweit @ 2009-05-19 15:17 UTC (permalink / raw) To: Andrew Lunn; +Cc: Chris Holgate, ecos-devel 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 configurations >>>> (untested!). However, the downside is that I had to leave out devtab >>>> support since the devtab entries need to be set statically. >>>> >>> Don't you think it's possible to have both options? I haven't looked at >>> the USB subsystem or any drivers, but I think a public driver should >>> behave as the subsystem intends. Maybe the subsystem could be extended >>> for more dynamic usage though. >> The official docs say "To support this the device driver can provide a >> devtab entry for each endpoint". I took that to mean that devtab >> support was optional - and the dynamic endpoint configuration is a much >> more useful feature IMHO. >> >> Previously supported hardware has had fixed endpoint configurations >> which makes the static devtab entries easy to implement. However, with >> dynamic endpoint configuration, the low-level driver doesn't know >> a-priori what endpoints to generate devtab entries for - and nor should it! > > The AT91 USB driver has something similar to this. It can configure > the endpoints by looking at the USB descriptors. > > I don't remember how it works with respect to devtab entries. Chris, do you have any example code using your driver? I was wondering if your approach to dynamically set the endpoint configurations should be offered as an official alternative to the devtab entries (or we may even get rid of the devtab entries). I may be working on USB serial and ethernet support. The USB serial driver at least seems to be tailored for the AT91 driver right now and cannot be used generically yet. We could change that to use dynamic setup of endpoints, which I think would be a great idea. Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 15:17 ` Simon Kallweit @ 2009-05-19 16:28 ` Chris Holgate 2009-05-20 8:20 ` Simon Kallweit 0 siblings, 1 reply; 16+ messages in thread From: Chris Holgate @ 2009-05-19 16:28 UTC (permalink / raw) To: Simon Kallweit; +Cc: Andrew Lunn, ecos-devel 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 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. > The USB serial driver at least seems to be tailored > for the AT91 driver right now and cannot be used generically yet. We > could change that to use dynamic setup of endpoints, which I think would > be a great idea. I've just had a look at the code and it shouldn't be too hard. The key change is that in order to obtain a handle on the endpoint data structures you need to wait for endpoint configuration to complete (which the serial driver does anyway): // -------------------------------------------------------------------------- // Block the calling thread until the USB is configured. void usbs_serial_wait_until_configured(void) { cyg_mutex_lock(&usbs_serial_lock); while (usbs_serial_state != USBS_STATE_CONFIGURED) cyg_cond_wait(&usbs_serial_state_cond); cyg_mutex_unlock(&usbs_serial_lock); } Then you can get a handle on the endpoint data structures by calling one of the following functions (see the STM32 USB header). cyg_usbs_cortexm_stm32_tx_endpoint (...) cyg_usbs_cortexm_stm32_rx_endpoint (...) This replaces the static way of doing it, where the following lines from the USB serial driver specify the statically allocated endpoint data structures: extern usbs_tx_endpoint CYGDAT_IO_USB_SLAVE_SERIAL_TX_EP; extern usbs_rx_endpoint CYGDAT_IO_USB_SLAVE_SERIAL_RX_EP; And these are hooked directly into the following static data structure: usbs_serial usbs_ser0 = { tx_ep: TX_EP, rx_ep: RX_EP, tx_result: 0, rx_result: 0, }; Everything else looks fine. The STM32 driver should automatically parse the device descriptors so that it looks like the 'standard' serial device. If you don't have any luck with it I might have time to play with it at the weekend. Chris. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 16:28 ` Chris Holgate @ 2009-05-20 8:20 ` Simon Kallweit 0 siblings, 0 replies; 16+ messages in thread From: Simon Kallweit @ 2009-05-20 8:20 UTC (permalink / raw) To: Chris Holgate; +Cc: Andrew Lunn, ecos-devel 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 could be a nice solution for device configuration (http server). >> The USB serial driver at least seems to be tailored >> for the AT91 driver right now and cannot be used generically yet. We >> could change that to use dynamic setup of endpoints, which I think would >> be a great idea. > > I've just had a look at the code and it shouldn't be too hard. The key > change is that in order to obtain a handle on the endpoint data > structures you need to wait for endpoint configuration to complete > (which the serial driver does anyway): I see. Should be easy to get around. I'll see if I can change the serial driver in a way so it's still usable with the other slave drivers. Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 12:00 ` Andrew Lunn 2009-05-19 15:17 ` Simon Kallweit @ 2009-05-19 15:44 ` Chris Holgate 2009-05-20 3:09 ` Frank Pagliughi 1 sibling, 1 reply; 16+ messages in thread From: Chris Holgate @ 2009-05-19 15:44 UTC (permalink / raw) To: Andrew Lunn; +Cc: Simon Kallweit, ecos-devel 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 decreed by Atmel as far as buffer sizes, endpoint number etc. is concerned. With the STM32, ST seem to have taken the opposite approach - you have a chunk of buffer memory and 8 endpoint state machines. Beyond that you've got complete flexibility to choose how many endpoints you want - input or output (or bidirectional[1] if you don't need double buffering). You can also choose an arbitrary set of logical (ie visible to the host) endpoint IDs and buffer sizes. Given this flexibility, it seemed to be a bit of a waste to define a fixed standard configuration similar to the Atmel device. Instead, when the host sends the configuration select to the STM32 EP0 I intercept it and scan the descriptor data structures for a corresponding configuration. Using the descriptor configuration I can then set up the buffer memory and endpoint state machines 'on the fly' to correspond directly to the configuration requested by the host. All this gives the application specific driver layered on top of the STM32 driver complete freedom to specify one or more supported endpoint configurations. > I don't remember how it works with respect to devtab entries. Since the Atmel and other USB drivers have fixed endpoint configurations, it's reasonable to statically allocate and configure the devtab entries during the device init sequence. Unfortunately, this has obvious problems when using the dynamic configuration scheme described above. Chris. [1] I used the bidirectional mode for the control endpoint, but otherwise decided it was more bother than it was worth! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 15:44 ` Chris Holgate @ 2009-05-20 3:09 ` Frank Pagliughi 2009-05-20 10:19 ` Chris Holgate 0 siblings, 1 reply; 16+ messages in thread From: Frank Pagliughi @ 2009-05-20 3:09 UTC (permalink / raw) To: Chris Holgate; +Cc: Andrew Lunn, Simon Kallweit, ecos-devel 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 particular > configuration decreed by Atmel as far as buffer sizes, endpoint number > etc. is concerned. > > With the STM32, ST seem to have taken the opposite approach - you have a > chunk of buffer memory and 8 endpoint state machines. Beyond that > you've got complete flexibility to choose how many endpoints you want - > input or output (or bidirectional[1] if you don't need double > buffering). You can also choose an arbitrary set of logical (ie visible > to the host) endpoint IDs and buffer sizes. > > Given this flexibility, it seemed to be a bit of a waste to define a > fixed standard configuration similar to the Atmel device. Instead, when > the host sends the configuration select to the STM32 EP0 I intercept it > and scan the descriptor data structures for a corresponding > configuration. Using the descriptor configuration I can then set up the > buffer memory and endpoint state machines 'on the fly' to correspond > directly to the configuration requested by the host. > > All this gives the application specific driver layered on top of the > STM32 driver complete freedom to specify one or more supported endpoint > configurations. > > >> I don't remember how it works with respect to devtab entries. >> > > Since the Atmel and other USB drivers have fixed endpoint > configurations, it's reasonable to statically allocate and configure the > devtab entries during the device init sequence. Unfortunately, this has > obvious problems when using the dynamic configuration scheme described > above. > > Chris. > > [1] I used the bidirectional mode for the control endpoint, but > otherwise decided it was more bother than it was worth! > > 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 infrastructure is showing it's age. So each new driver is hitting this same problem and trying to solve it in a new and different way. A search of this mailing list and 'ecos-devel' will show a couple different complaints and suggestions that I and a few other people made a while back. I haven't used eCos all year, but am close to jumping back in for a bit, and would need to refresh my own memory with the details. IIRC, at the time I had fairly convinced myself that what was needed was an entirely new USB subsystem that would: - make it much easier to work with the flexible new chips - handle much more of the device enumeration - provide a very specific callbacks structure (like read/write an endpoint, respond to a bus reset, set the chips' address, etc) - handle more of the buffering In general, make it much easier to knock out USB drivers. Maybe now it's time to start considering this in earnest? Count me in. Frank ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-20 3:09 ` Frank Pagliughi @ 2009-05-20 10:19 ` Chris Holgate 2009-05-20 14:54 ` Frank Pagliughi 0 siblings, 1 reply; 16+ messages in thread From: Chris Holgate @ 2009-05-20 10:19 UTC (permalink / raw) To: Frank Pagliughi; +Cc: Andrew Lunn, Simon Kallweit, ecos-devel 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 infrastructure is > showing it's age. So each new driver is hitting this same problem and > trying to solve it in a new and different way. My thoughts are that the current infrastructure is still pretty usable and that the main limitations are the use of static devtab entries (which are optional anyway) and the drivers themselves. More specifically, there isn't a good example of how to use the infrastructure to write drivers for these more configurable USB devices. 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 defined by usbs.h. I think that this would be an easy change and would require mimimal additions to the existing drivers. Existing drivers could add the endpoint 'getter' functions and still export their static endpoint data structures for legacy class drivers. > IIRC, at the time I had fairly convinced myself that what was needed was > an entirely new USB subsystem that would: > - make it much easier to work with the flexible new chips > - handle much more of the device enumeration There's quite a bit of code in the STM32 driver which addresses these issues within the existing framework. Maybe the thing to do would be to factor it out into a device driver utility library which can be used alongside the existing framework. > - provide a very specific callbacks structure (like read/write an > endpoint, respond to a bus reset, set the chips' address, etc) > - handle more of the buffering While the existing callback setup may not be the easiest to use, it does provide all the required information. As for buffering, this is something which I think should be a matter for the class driver writer. Again, this could all be made easier by better documentation and a possible class driver utility library. > In general, make it much easier to knock out USB drivers. It's never going to be really easy though! Chris. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-20 10:19 ` Chris Holgate @ 2009-05-20 14:54 ` Frank Pagliughi 2009-05-20 16:06 ` Chris Holgate 0 siblings, 1 reply; 16+ messages in thread From: Frank Pagliughi @ 2009-05-20 14:54 UTC (permalink / raw) To: Chris Holgate; +Cc: Andrew Lunn, Simon Kallweit, ecos-devel > 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 defined by usbs.h. I think that this would be an easy > change and would require mimimal additions to the existing drivers. > Existing drivers could add the endpoint 'getter' functions and still > export their static endpoint data structures for legacy class drivers. > In addition, it's difficult to specify endpoints which can be used for either direction. I believe several drivers specify that all their generic endpoints are "rx endpoints" and if you want to use one to transmit data you must overlay a "tx endpoint" on top of it. That's not a big problem, but it's confusing. In addition, then rx/tx data structures lack a few fields to completely (easily) handle a generic endpoint, like the endpoint number, and maybe some intermediate buffer pointers to handle a single transfer. So each driver has to add this functionality in one way or another. >> IIRC, at the time I had fairly convinced myself that what was needed was >> an entirely new USB subsystem that would: >> - make it much easier to work with the flexible new chips >> - handle much more of the device enumeration >> > > There's quite a bit of code in the STM32 driver which addresses these > issues within the existing framework. Maybe the thing to do would be to > factor it out into a device driver utility library which can be used > alongside the existing framework. > Agreed that this is actually more realistic. And, keep in mind, there are a few additional tricky issues to which the driver writer is exposed, which can be delegated out to a common package. I don't think any of the drivers properly deal with the state change callback - most appear to emit a "current/new state" enumerated value (USBS_STATE_xxx) rather than a state change value (USBS_STATE_CHANGE_xxx). And the way in which transfers for bulk and interrupt endpoints need to be ended - in regard to short and zero packets - can get a little messy, but is common to all devices. With a more complete, common endpoint structure, this decision making could be handed off to a single, common set of routines. >> - provide a very specific callbacks structure (like read/write an >> endpoint, respond to a bus reset, set the chips' address, etc) >> - handle more of the buffering >> > > While the existing callback setup may not be the easiest to use, it does > provide all the required information. As for buffering, this is > something which I think should be a matter for the class driver writer. > Again, this could all be made easier by better documentation and a > possible class driver utility library. > True, though I worry that even the existing drivers have a number of bugs and deficiencies, especially since they're left to handle some common control messages on their own. And, since each new driver is written using an old one as a template, the bugs are perpetuated. But no one - my self included - wants to fix the old drivers since they're mostly for chips that are obsolete or no longer viable. Frank ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-20 14:54 ` Frank Pagliughi @ 2009-05-20 16:06 ` Chris Holgate 2009-05-20 22:31 ` Frank Pagliughi 0 siblings, 1 reply; 16+ messages in thread From: Chris Holgate @ 2009-05-20 16:06 UTC (permalink / raw) To: Frank Pagliughi; +Cc: Andrew Lunn, Simon Kallweit, ecos-devel 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 hidden behind a generic >> API which is defined by usbs.h. >> > In addition, it's difficult to specify endpoints which can be used for > either direction. I believe several drivers specify that all their > generic endpoints are "rx endpoints" and if you want to use one to > transmit data you must overlay a "tx endpoint" on top of it. That's not > a big problem, but it's confusing. It does make a bit of a mockery of type safety, though. To the user, Tx and Rx endpoints are fundamentally different things and it's good to try and prevent Tx calls to Rx endpoints and vice versa. If the driver writer feels they must use the same data structure for each, then this should be hidden from the user. With the STM32 driver, it is possible to have Tx and Rx endpoints with the same logical endpoint ID but they will be implemented on different physical endpoints[1]. The user doesn't need to know this - they just tell the tx or rx endpoint getter function the logical endpoint number they want and the corresponding, correctly typed data structure is returned. > And the way in which transfers for bulk and interrupt endpoints need to > be ended - in regard to short and zero packets - can get a little messy, > but is common to all devices. With a more complete, common endpoint > structure, this decision making could be handed off to a single, common > set of routines. Yeah - that would have saved me from a lot of pain! Chris. [1] The distinction being that logical endpoints are the endpoint numbers seen by the host and physical endpoints are the actual endpoint state machines on the chip. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-20 16:06 ` Chris Holgate @ 2009-05-20 22:31 ` Frank Pagliughi 0 siblings, 0 replies; 16+ messages in thread From: Frank Pagliughi @ 2009-05-20 22:31 UTC (permalink / raw) To: Chris Holgate; +Cc: Andrew Lunn, Simon Kallweit, ecos-devel > With the STM32 driver, it is possible to ... I'll have a look at this new driver as soon as possible. Sounds interesting. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 11:47 ` STM32 USB support Chris Holgate 2009-05-19 12:00 ` Andrew Lunn @ 2009-05-19 13:33 ` John Dallaway 2009-05-20 21:22 ` Chris Holgate 1 sibling, 1 reply; 16+ messages in thread From: John Dallaway @ 2009-05-19 13:33 UTC (permalink / raw) To: Chris Holgate; +Cc: ecos-devel 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 target for "STM3210E-EVAL with USB". This should not be necessary. If you take a look at one of the other targets with USB support (eg "assabet") there's a CDL option which controls compilation of the USB hardware driver source code. In the case of assabet, this is the CYGFUN_DEVS_USB_SA11X0_EP0 option. This option is controlled by the CYGINT_IO_USB_SLAVE_CLIENTS interface. The intention is that other packages implement this interface to indicate that the USB hardware driver is required. Can you do something similar for your own target to eliminate the need for an extra target definition in ecos.db? The assabet target is old and may not offer the best example. John Dallaway ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-19 13:33 ` John Dallaway @ 2009-05-20 21:22 ` Chris Holgate 2009-05-21 7:27 ` John Dallaway 0 siblings, 1 reply; 16+ messages in thread From: Chris Holgate @ 2009-05-20 21:22 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-devel 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! 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 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't see a way of adding in new hardware packages to a platform without creating a new target. When we're all happy that the driver is up to scratch for a CVS commit I'll modify the existing target as you suggested. However, this raises another question for the maintainers. I'm now developing against 3.0 for production purposes and would rather add in things like this USB driver as stable 3.0 packages rather than pulling a potentially unstable CVS tree. Is there an 'official' place where all such additional 3.0 packages could be located? Chris. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-20 21:22 ` Chris Holgate @ 2009-05-21 7:27 ` John Dallaway 2009-05-31 15:01 ` Chris Holgate 0 siblings, 1 reply; 16+ messages in thread From: John Dallaway @ 2009-05-21 7:27 UTC (permalink / raw) To: Chris Holgate; +Cc: ecos-devel 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't see a way of adding > in new hardware packages to a platform without creating a new target. 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 in your pkgadd.db: target stm3210e_eval { packages { CYGPKG_IO_USB CYGPKG_IO_USB_SLAVE CYGPKG_DEVS_USB_CORTEXM_STM32 } } > When we're all happy that the driver is up to scratch for a CVS commit > I'll modify the existing target as you suggested. OK, but you _will_ need to provide a mechanism for disabling the compilation of the driver source code as I outlined in my previous e-mail. > However, this raises another question for the maintainers. I'm now > developing against 3.0 for production purposes and would rather add in > things like this USB driver as stable 3.0 packages rather than pulling a > potentially unstable CVS tree. Is there an 'official' place where all > such additional 3.0 packages could be located? We have tended to avoid doing this in the past. If we did this for all new packages we would end up with quite a number of .epk files over the lifetime of an eCos release. These files might also require updating if bugs are found and fixed. The maintainers focus their efforts on the CVS repository between releases. If developers want the very latest packages we advise them to use CVS. John Dallaway ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-21 7:27 ` John Dallaway @ 2009-05-31 15:01 ` Chris Holgate 2009-05-31 15:46 ` John Dallaway 0 siblings, 1 reply; 16+ messages in thread From: Chris Holgate @ 2009-05-31 15:01 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-devel 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 in your pkgadd.db: > > target stm3210e_eval { > packages { > CYGPKG_IO_USB > CYGPKG_IO_USB_SLAVE > CYGPKG_DEVS_USB_CORTEXM_STM32 > } > } I tried this and while it works for adding in a new package, I found that it has the unfortunate side effect of causing the entire STM3210E target to be removed when removing the USB package. Subsequently re-adding the USB package then just adds in this truncated target definition which results in ecos.db becoming unloadable. On balance, I think I'll probably stick with adding in a completely new target for the time being since this seems to be more robust. The other changes you suggested have now gone in and should allow the USB driver to be added to the standard target in CVS. Chris. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STM32 USB support 2009-05-31 15:01 ` Chris Holgate @ 2009-05-31 15:46 ` John Dallaway 0 siblings, 0 replies; 16+ messages in thread From: John Dallaway @ 2009-05-31 15:46 UTC (permalink / raw) To: Chris Holgate; +Cc: ecos-devel 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 could do something like this in your pkgadd.db: >> >> target stm3210e_eval { >> packages { >> CYGPKG_IO_USB >> CYGPKG_IO_USB_SLAVE >> CYGPKG_DEVS_USB_CORTEXM_STM32 >> } >> } > > I tried this and while it works for adding in a new package, I found > that it has the unfortunate side effect of causing the entire STM3210E > target to be removed when removing the USB package. Subsequently > re-adding the USB package then just adds in this truncated target > definition which results in ecos.db becoming unloadable. The following (undocumented) incantation: ./ecosadmin.tcl --keep_targets remove CYGPKG_DEVS_USB_CORTEXM_STM32 should allow you to remove the driver package without deleting the targets which use it. Perhaps this should become the default behaviour when removing packages so that people are less likely to remove target records inadvertently. Anyway, working with ecosadmin.tcl is certainly more elegant and more scalable than adding a new target just to accommodate a new driver. > The other > changes you suggested have now gone in and should allow the USB driver > to be added to the standard target in CVS. That's great. John Dallaway ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-05-31 15:46 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <4A11CAAA.8040900@intefo.ch> [not found] ` <4A11D861.8090206@zynaptic.com> [not found] ` <4A11E5DF.2000403@intefo.ch> 2009-05-19 11:47 ` STM32 USB support Chris Holgate 2009-05-19 12:00 ` Andrew Lunn 2009-05-19 15:17 ` Simon Kallweit 2009-05-19 16:28 ` Chris Holgate 2009-05-20 8:20 ` Simon Kallweit 2009-05-19 15:44 ` Chris Holgate 2009-05-20 3:09 ` Frank Pagliughi 2009-05-20 10:19 ` Chris Holgate 2009-05-20 14:54 ` Frank Pagliughi 2009-05-20 16:06 ` Chris Holgate 2009-05-20 22:31 ` Frank Pagliughi 2009-05-19 13:33 ` John Dallaway 2009-05-20 21:22 ` Chris Holgate 2009-05-21 7:27 ` John Dallaway 2009-05-31 15:01 ` Chris Holgate 2009-05-31 15:46 ` John Dallaway
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).