8051 with USB 2 High Speed 480Mbps variant ?

Hi,

Can anyone tell me who makes an 8051 with an on chip High Speed (480Mbps) USB 2 
UART ?  (Please don't tell me I don't need such a part, I do or I wouldn't be 
asking).

Thanks,

-- 
Boo

Boo wrote:
> Hi,
> 
> Can anyone tell me who makes an 8051 with an on chip High Speed 
> (480Mbps) USB 2 UART ?  (Please don't tell me I don't need such a part, 
> I do or I wouldn't be asking).

Can we tell you you need to use google ?

Try "8051 480MHz USB" and the first page
gives Cypress FX2 and Smsc devices as candidates.

The Cypress device is mature, proven, and widely deployed.

-jg

> Can anyone tell me who makes an 8051 with an on chip High Speed (480Mbps) 
> USB 2 UART ?  (Please don't tell me I don't need such a part, I do or I 
> wouldn't be asking).

You don't need such a part.

JJS

On Aug 13, 5:20 pm, Boo <reply_to_group_not_me@spam_me_no_spam.net>
wrote:
> Hi,
>
> Can anyone tell me who makes an 8051 with an on chip High Speed (480Mbps) USB 2
> UART ?  (Please don't tell me I don't need such a part, I do or I wouldn't be
> asking).

The cypress fx2 already mentioned.  However you should realize that
you can only fully leverage the USB2 transfer rates when the data goes
directly through the on-chip USB peripheral to or from an external
device; the wimpy 8051 core itself can't even remotely keep up if it
is in the data path.

 > the wimpy 8051 core itself can't even remotely keep up if it
> is in the data path.

I have small amounts if data that needs updating often so I need the higher 
message rates of USB 2 rather than the high throughput it also offers.

Thanks for the pointers so far,  any others gratefully received.

-- 
Boo

> > the wimpy 8051 core itself can't even remotely keep up if it
>> is in the data path.
>
> I have small amounts if data that needs updating often so I need the 
> higher message rates of USB 2 rather than the high throughput it also 
> offers.

So HS USB allows you to send messages at the microframe rate as opposed to 
the frame rate of FS and LS.  Keep in mind that USB doesn't generally 
guarantee delivery deadlines.  The choice of endpoint type will have an 
impact on the message transit times and, indirectly, message rate.  I think 
that if you don't have control over any other devices with which your device 
might be sharing the bus, you might lose come control of your "often" spec.

JJS

John Speth wrote:
>>> the wimpy 8051 core itself can't even remotely keep
>>> up if it is in the data path.
>> I have small amounts if data that needs updating often
>> so I need the higher message rates of USB 2 rather than
>> the high throughput it also offers.
> 
> So HS USB allows you to send messages at the microframe
> rate as opposed to the frame rate of FS and LS.  Keep in
> mind that USB doesn't generally guarantee delivery
> deadlines.

I'm not a USB 2.0 expert, but USB 1.0 provides a
mechanism to guarantee latency for interrupt and
isochronous endpoints. However, the granularity
is 1ms, which may or may not be sufficient depending
on your application. I assume the micro-frame rate
for USB 2.0 allows for a higher resolution with
the same ability to reserve time on the bus.

However, the most common use of USB uses bulk
endpoints which uses any time left over in the
schedule to transfer large amounts of data. Bulk
endpoints are generally used by serial-port adapters
and mass storage devices.


> The choice of endpoint type will have an impact on the
> message transit times and, indirectly, message rate.

Essentially.

> I think that if you don't have control over any other
> devices with which your device might be sharing the bus,
> you might lose come control of your "often" spec.

If your endpoint successfully enumerates, as interrupt
or isochronous, then you are ensured (by the USB spec)
those attributes that you stated as required in your
endpoint descriptor.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1

>>>> the wimpy 8051 core itself can't even remotely keep
>>>> up if it is in the data path.
>>> I have small amounts if data that needs updating often
>>> so I need the higher message rates of USB 2 rather than
>>> the high throughput it also offers.
>>
>> So HS USB allows you to send messages at the microframe
>> rate as opposed to the frame rate of FS and LS.  Keep in
>> mind that USB doesn't generally guarantee delivery
>> deadlines.
>
> I'm not a USB 2.0 expert, but USB 1.0 provides a
> mechanism to guarantee latency for interrupt and
> isochronous endpoints. However, the granularity
> is 1ms, which may or may not be sufficient depending
> on your application. I assume the micro-frame rate
> for USB 2.0 allows for a higher resolution with
> the same ability to reserve time on the bus.
>
> However, the most common use of USB uses bulk
> endpoints which uses any time left over in the
> schedule to transfer large amounts of data. Bulk
> endpoints are generally used by serial-port adapters
> and mass storage devices.
>
>
>> The choice of endpoint type will have an impact on the
>> message transit times and, indirectly, message rate.
>
> Essentially.
>
>> I think that if you don't have control over any other
>> devices with which your device might be sharing the bus,
>> you might lose come control of your "often" spec.
>
> If your endpoint successfully enumerates, as interrupt
> or isochronous, then you are ensured (by the USB spec)
> those attributes that you stated as required in your
> endpoint descriptor.

I agree.  My point is that other devices on the bus are also ensured the 
same deadlines if they enumerate those timing characteristics to the host. 
When those multiple devices have transfer deadlines that are coincidental in 
time, one of the deadlines will slip.  IOW, you've lost some response time 
despite what assurances the host has granted by virtue of successful 
enumeration.

It's not a hard money-back guarantee that the response deadlines will be met 
when the host ok's the device's enumeration.  It's simply an agreement by 
the host in which it says "I'll do my best".

If there's one device on the bus, no problem.  If two devices on the same 
bus are demanding rapid response, then there's a potential problem.

JJS

Yikes! What happened to the attributions in
this thread? Snipping attributions makes it
*very* difficult to tell who-said-what.

John Speth wrote:
> I agree.  My point is that other devices on the bus are 
> also ensured the same deadlines if they enumerate those 
> timing characteristics to the host.

Yes.

> When those multiple devices have transfer deadlines that
> are coincidental in time, one of the deadlines will slip.
> 
The USB scheduler is supposed to ensure that there are
no "coincidental" deadlines. Interrupt and isochronous
endpoints are serviced at the beginning of each frame,
and each is allocated a slot and bandwidth within every
frame such that if *all* allocations have transfers within
that frame *all* transfers have time to complete within
the frame. This of course assumes that there are no
physical layer errors induced.

> IOW, you've lost some response time despite what
> assurances the host has granted by virtue of successful
> enumeration.

That is not my understanding of how this should work.
If enumeration is successful for interrupt and isochronous
endpoints, they are ensured latency and bandwidth
from a bus perspective. Any failures of the host system
design (hardware/software) to meet these deadlines is
outside of the scope of the USB, but certainly possible
for *a* design to meet.

> It's not a hard money-back guarantee that the response 
> deadlines will be met when the host ok's the device's 
> enumeration.  It's simply an agreement by the host in 
> which it says "I'll do my best".

Again, that is the *intent* of the USB specication. Whether
or not a particular host *system* implemenation is capable
of achieving those guarantees is outside the scope of
the USB itself.

> If there's one device on the bus, no problem.

This is not true. It is certainly *possible* that the host
system is incapable of keeping up with a particular
device. For example:

1) The host processor may be too slow.
2) The host operating system may not be capable
of meeting the real time requirements of the USB.
3) A custom host controller implementation may be faulty.

> If two devices on the same bus are demanding rapid
> response, then there's a potential problem.

The same can be said about any number of devices, but
that does not make this a USB issue, this is a system
issue.

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1