[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[usb] Re: usb-digest V1 #228
Hi usb-digest£¡
I have simulated the DPLL state machine ,but when the input frequency (12M)-0.4% ,the data registered by the extracted clock will error .And the total number of receive bits lest than 8192.
Can tell me why ,my friends?
thanks
Best Regard
henry_xb
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡xxiaobin@263.net
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-20
======= 2003-02-14 06:01:00 in Your email£º=======
> usb@opencores.org usb-digest V1 #228
>
>
>----------------------------------------------------------------------
>From: "Ricky Nite" <ricky@hugletech.com>
>Date: Fri, 14 Feb 2003 11:47:03 +0800
>X-Virus: 6
>Subject: Re: [usb] USB-to-Bluetooth
>
>Hello Marc,
>
>I get your point, thanks - it really doesn't make sense to make the=20
>USB-to-Bluetooth adapter look like a hub. It just has to look like a=20
>typical USB device that communicates with the upper layers of=20
>the Bluetooth stack and application running on the PC/host.
>
>However, this would mean that I would have to define a separate
>USB bus for each peripheral device, because I cannot use the=20
>USB port of the device to make a similar Bluetooth Dongle=20
>connection as I did on the PC/host. I will have to reconfigure the=20
>Dongle as host, which, as I've been told, requires a lot of resources
>and is not supported by existing Dongles.
>
>Is there any other way to do this? Or maybe this is one of those=20
>applications that's just "not meant to be" :) In that case, I won't=20
>use the upstream USB port anymore - I'll just use the downstream=20
>USB port on my host/PC to attach the Dongle, and Bluetooth-enable=20
>all my peripherals...
>
>Ricky Nite
> ----- Original Message -----=20
> From: Marc Reinig=20
> To: usb@opencores.org=20
> Sent: Thursday, February 13, 2003 10:13 PM
> Subject: RE: [usb] USB-to-Bluetooth
>
>
> Because of the turn-around time (and some other issues), you cannot =
>just convert transmissions from the PC host and send them to the device =
>on the other side of the Bluetooth net (and vice versa) because the =
>Bluetooth protocol will not be able to respond in time for the USB =
>protocol requirements. So, the USB device must "dummy" up responses =
>from the remote Bluetooth device until actual responses are received. =
>This requires extra horsepower at the USB dongle end. Same issue for =
>the USB-to-Bluetooth adapter to act as a hub.
>
> In any case, the USB is just a bus to attach the Bluetooth adapter to =
>the PC Host, Bluetooth can already accept multiple connections, what =
>would be the function of trying to make the USB-to-Bluetooth adapter =
>look like a hub?
>
> Marc Reinig
> System Solutions
>
> -----Original Message-----
> From: owner-usb@opencores.org [mailto:owner-usb@opencores.org]On =
>Behalf Of Ricky Nite
> Sent: Wednesday, February 12, 2003 11:13 PM
> To: usb@opencores.org
> Subject: Re: [usb] USB-to-Bluetooth
>
>
> Hello Marc,
>
> Thanks for the reply - so a USB-to-Bluetooth Adapter=20
> is just another USB device as seen by the PC , but I'm=20
> still wondering what you meant with a "smart" USB=20
> device (?)=20
>
> I'm also trying to find out if it's possible for the PC-attached=20
> USB-to-Bluetooth adapter to emulate a hub, with the=20
> peripheral-attached adapters seen as slave devices (?)=20
>
> PC-->USB-BT adapter (hub)----->USB-BT adapters -->peripherals =
>(slaves)
>
>
> Rgds,
>
> Ricky Nite
>
> ----- Original Message -----=20
> From: Marc Reinig=20
> To: usb@opencores.org=20
> Sent: Thursday, February 13, 2003 12:31 PM
> Subject: RE: [usb] USB-to-Bluetooth
>
>
>
> -----Original Message-----
> From: owner-usb@opencores.org [mailto:owner-usb@opencores.org]On =
>Behalf Of Ricky Nite
> Sent: Wednesday, February 12, 2003 7:17 PM
> To: usb@opencores.org
> Subject: [usb] USB-to-Bluetooth
>
>
> > I need some clarification on Bluetooth-to-USB transmission. =20
> > As you know, some Bluetooth modules now have an on-chip
> > USB interface, used for device firmware upgrade and as HCI=20
> > transport. Future Bluetooth firmware upgrades will also =
>allow=20
> > you to change the USB descriptors in the module so you can
> > receive data over USB and transmit it over the air.
>
> > However, I was told that this will not allow me to layer =
>additional=20
> > firmware over the embedded Bluetooth stack to do an exact=20
> > USB cable replacement using a USB-to-Bluetooth adapter/dongle =
>
> > device, because:
>
> > (1) USB has strict timings which would be violated if the =
>adapter/
> > dongle had to transmit the request over the air and wait for =
>a=20
> > response.
>
> Correct, though this can be overcome with a "smart" device.
>
> > (2) The Bluetooth module is not capable of being a USB =
>master,
>
> > (3) The code doesn't fit on chip - USB is "normally" for PC =
>apps
> > where you have ample resources on the host. =20
>
> These are really part of the same issue. USB has a master/slave =
>concept. The logic/code to be a slave is relatively small compared to =
>that required to be a master.
>
> > As there are already a lot of USB-to-Bluetooth =
>adapters/dongles=20
> > available in the market, I was just wondering how these =
>devices=20
> > use USB for their applications. Can anybody shed some light
> > on this?
>
> They are devices and can be used, as you mentioned, for firmware =
>upload, the connecting bus to the PC, ... =20
>
> But in general, they are devices (slaves) not hosts (masters).
>
> Marc Reinig
> System Solutions
>
>
>----------------------------------------------------------------------
>End of usb-digest V1 #228
>-
>To unsubscribe from usb-digest mailing list please visit http://www.opencores.org/mailinglists.shtml
= = = = = = = = = = = = = = = = = = = =
--
To unsubscribe from usb mailing list please visit http://www.opencores.org/mailinglists.shtml