From: Chris Holgate <chris@zynaptic.com>
To: Simon Kallweit <simon.kallweit@intefo.ch>
Cc: Andrew Lunn <andrew@lunn.ch>, ecos-devel@sourceware.org
Subject: Re: STM32 USB support
Date: Tue, 19 May 2009 16:28:00 -0000 [thread overview]
Message-ID: <4A12DE12.7020504@zynaptic.com> (raw)
In-Reply-To: <4A12CD5F.20901@intefo.ch>
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.
next prev parent reply other threads:[~2009-05-19 16:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A11CAAA.8040900@intefo.ch>
[not found] ` <4A11D861.8090206@zynaptic.com>
[not found] ` <4A11E5DF.2000403@intefo.ch>
2009-05-19 11:47 ` Chris Holgate
2009-05-19 12:00 ` Andrew Lunn
2009-05-19 15:17 ` Simon Kallweit
2009-05-19 16:28 ` Chris Holgate [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A12DE12.7020504@zynaptic.com \
--to=chris@zynaptic.com \
--cc=andrew@lunn.ch \
--cc=ecos-devel@sourceware.org \
--cc=simon.kallweit@intefo.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).