USB 2.0 High Speed


For our products we have the have the power of a PC for internet connectivity. I realize that the focus right now is on IoT, and we are still working on the G400D based design so this is down the road somewhat.

But I would be interested in the USB client (using WinUSB as the Windows device driver) capabilities of the Cortex M7 processor(s) selected for SITCore, specifically if USB 2.0 High Speed, and how many end points are available. Ideally having two end points for bulk transfers, and one or two end points for interrupt transfers would be required.

My plan B is to use a Cypress USB chip to meet these requirements, the down side there is the USB FIFO buffers expect a 8 or 16 bit access as one would get if interfaced on to the processor bus. Possibly a 16 or 32 bit SPI interface to an FPGA FIFO which would then be connected to the Cypress USB FIFOs, would give use something closer to the high speed rates, and many times better then full speed.

P.S. This is low priority question but mainly just wanted to set the scope of SITCore products.

We have the option to support 480mbps on USB but this is a long term plan honestly and we may not support it if there is not about interest. The problem here is that you will lose about 15 pins to add 480mhz ulpi. So before we get into this, why do you need it? We need to make sure this will solve a serious need.

So please share more details on what you are trying to accomplish and then we can decide what is the best answer.

@Gus_Issa thanks for the update, I was thinking there was USB 2.0 high speed build into the SITCore processor, like the G400 SoC. Having to expose the ulpi does require a lot of resources if there is not much of a customer requirement for high speed.

You asked about our requirements, three main features come to mind. While we don’t require the 40 x speedup, we could use something between 4 to 6 x improvement. Mainly to handle the extensive logging from three USB clients (2 - G400D). Secondly, we have a message passing interface running on USB, for most commands / responses the 64 byte packets works fine, however synchronization issues of the host to client and client to host become a simpler / more deterministic if we could use the USB 2.0 high speed maximum packet size. Lastly it seems to be typical that a USB 2.0 high speed serial interface engine has more end points, ideally we would use two for bulk transfers (IN/OUT) and at least one but two would be better for Interrupt transfers (IN/OUT).

To achieve these requirements, I believe that USB 2.0 high speed signaling is a therefor a requirement.

Possibly adding a Cypress USB controller to our next hardware design might be the way to go.


1 Like

Are we overthinking the details? Let’s look at it from the results needed. How much data are you transferring and how fast you need it done?

@Gus_Issa, yes this is quite forward looking for us. The bulk of the data we moving is trace logs from three satellite processors to the PC, which are quite extensive, and currently un-optimized for size. On the G400D with the wall clock time set for every run of 1 hour there are times we see as much as 5 or 6 seconds delay in the timestamps when the satellite processor(s) trace log appears with the PC trace log. Workable but only if something has gone wrong with the run. There is a camera, several barcode readers, USB to Ethernet dongle, and three external USB ports that may have things like wireless keyboard/mouse, Flash drive, and UPS so USB traffic is bursty and un-deterministic.

It would have been nice to have the USB 2.0 features, but we are managing now, and any significant change to the instrument architecture is clearly years ways. But I am planning that road map now, with my personal free time permitting, and was planning some experimentation.

Thanks for responding and the insight to SITCore USB capabilities.

More to the point of this NDA ,I am planning to modify our adapter to work with the SC20260D that talks SPI to the pressure sensors (3) and six solenoid valves. I believe there is a picture that I have previously posted.

Best Regards

I am impressed and would love to have more details from you to post on our website, if your company allows of course.

What can we do to help you transition? Just let is know please.

I check if there is anything I can share publicly but very likely not at this time.

I will let you know as I progress with that part of our planning.


I heard back from our marketing team, they are open to your request, with a final approval on the exact content GHI Electronics would share publically. It is now up to Product Development team to decide what details if any details we can share. This would be high level for sure.


No rush. We need this for the new website coming in a month.