8051 with USB 2 High Speed 480Mbps variant ?

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

You don't need such a part.

JJS

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.

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

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

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.

Essentially.

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

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:

Yes.

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.

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.

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.

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.

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