USB Observations and Questions: Part III (Host System Polling Rates)

LeafLabs Garden » Support » Maple Hardware Support

USB Observations and Questions: Part III (Host System Polling Rates)

(8 posts) (2 voices)

Started 4 years ago by StephenFromNYC
Latest reply from gbulmer

StephenFromNYC
Moderator

Hello-

[Note: Part II is simply a list of links to more USB resources]

I think my understanding of USB polling is improving. I will try to limit my observations and questions to full speed devices (such as the Maple). There are some differences with configuring and programming high speed USB devices, but I will not describe the differences, because it will only make things more confusing.

As stated in my earlier post (Part I) I still believe the host computer has the ability to split the attention it gives all the connected USB devices into 1 millisecond time slices. Each connected USB device specifies how frequently it wants the attention of the host (see below), but it is up to the host to poll the attached devices. Each device cannot say "I am ready now". Each device needs to be patient until it is polled by the host system.

The Lakeview Research web page (http://www.lvr.com/usbfaq.htm) says for "full-speed interrupt endpoints, the descriptor's bInterval value indicates the requested maximum number of milliseconds between transaction attempts".

If I understand this correctly, different devices on the USB chain can request different intervals. DeviceA may request the host system's attention every 5 milliseconds, while Device B may request the host system's attention every 20 milliseconds. In other words, the system does not poll all the USB devices every 1, 5, or 10 milliseconds. The rate of polling can be different for each device.

Maybe I am thinking too much about a single word, but I do not know why the Lakeview Research page says "maximum" time. Does this mean the polling may occur more frequently than the bInterval value? For example, if a device states (see below) that it wants the attention of the host every 10 milliseconds (100 times a second) is it possible the device might be occasionally polled every 5 milliseconds? To me an unpredictable polling can cause problems. For example, assume a USB device collects data for 6 milliseconds and then processes the data for 2 milliseconds, before waiting for the host to poll (win a 2 millisecond safety margin), before the data is sent. If the host polls occasionally after 5 milliseconds the device will not be ready to send the processed data, and the host-device synchronization will be confused. If the USB device is not ready to send, is the polling timer reset? Or is the polling timer reset only when the device responds to the host?

The information from http://www.beyondlogic.org/usbnutshell/usb5.shtml confirms that the smallest units for full speed devices are 1 millisecond frames. However, the beyondlogic.com information does not imply the polling may occur more frequently than the rate requested by a device.

I have been digging around in the files from "https://github.com/leaflabs/libmaple/blob/master/libmaple/usb/":

If I am correct, currently (March, 2011) the USB support on the Maple is limited to the SerialUSB functions. Is the polling interval used by SerialUSB specified indirectly somewhere else (and not directly by the bInterval value)?

I searched for variables whose names resembled "bInterval".

From the file "https://github.com/leaflabs/libmaple/blob/master/libmaple/usb/descriptors.c":

EP1_bInterval: 0xFF // for interrupt transfers
EP2_bInterval: 0x00 // for bulk transfers: DataOutEndPoint
EP3_bInterval: 0x00 // for bulk transfers: DataInEndPoint

I was expecting something in the range 1-5 (to request polling from the system in the range 1 to 5 milliseconds).

Am I missing something?

Second question (a repeated quested based on a calculation from my first USB post (Part I):

The USB data packet used with SerialUSB (which I think uses "interrupt transfer") is 64-bytes.

Is only a single data packet transmitted per 1 millisecond time slice (or can the system poll the same device multiple times in the same time slice)?

If the Maple bInterval is set to 1 milliseconds (and the system polls the Maple for USB communication every 1 milliseconds) does this mean that interrupt and bulk transfers are limited to 64,000 bytes per second?

This calculation cannot be correct, since USB thumb drives (which I think use bulk transfers) can transfer at a much higher rate.

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

[my current development system (old, but still working)]

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC - My reading of the http://www.beyondlogic.org/usbnutshell stuff is at each host->device polling 'event' a set of transactions between the host and device can exchange multiple packets of data

For example http://www.beyondlogic.org/usbnutshell/usb4.shtml#Control

The optional Data Stage consists of one or multiple IN or OUT transfers. The setup request indicates the amount of data to be transmitted in this stage. If it exceeds the maximum packet size, data will be sent in multiple transfers each being the maximum packet length except for the last packet.

So I believe this clearly states that data can be larger than a packet, and multiple IN or OUT transfers may be completed.

(full disclosure: I am not a LeafLabs staffer)

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

I may have found an answer to my question about the bInterval setting(s) used by the current implementation of USB on the Maple.

Apparently, the bInterval variable is ignore (not used) for bulk/control endpoints. This is stated in the table found at:

http://www.beyondlogic.org/usbnutshell/usb5.shtml#EndpointDescriptors

Does this mean Maple USB functions are implemented using bulk transfer endpoints? I had assumed the Maple used transfer endpoints for USB functions. The use of bulk transfers might be a partial explanation for the variation of rates which I and others have experienced. If the (Serial)USB functions are implemented using bulk endpoints then the host (which controls the bus) will transfer as much "bulk" data as possible in the time remaining in each interval (after the control and interrupt transfers). This allows spurts of activity. However, remember that bulk transfers are not guaranteed a specific size of each time interval. However, if a bulk transfer device (such as the Maple) gets the attention of the host, then at least 1216 bytes can be transferred (see below for reference).

The use of transfer endpoints (which to be clear I believe libmaple currently does not use) would limit the data transfer rates which is not desirable for some applications which need greater than 64,000 bytes/sec. I found a reference which agrees with my calculations that with interrupt endpoints a maximum rate of of 64,000 bytes/sec is possible with full speed devices. Here it it:

http://www.computer-solutions.co.uk/info/Embedded_tutorials/usb_tutorial.htm#Signals

Yes, I agree wth a conclusion by gbulmer about multiple control transfers per interval. At the bottom of the next link the descriptions seem to say control transfers can take up to 10% of the USB bandwidth:

http://www.beyondlogic.org/usbnutshell/usb4.shtml

Remember that user data is not transferred during the control transfer!

I hope this analysis helps!

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

[my current development system (old, but still working)]

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC - good stuff!

I think I either don't understand, or their is an error in your post. Maybe it is worth summarising a little bit, and then examine the details, identify the area which I think is different, and I'll add the things I don't yet understand.

As you have explained, all USB transfers are initiated by the host. The USB device is polled by the USB host, and must wait until the host interacts with it. On USB Full-Speed devices (12MBit/s) like Maple, this is supposed to happen at 1 milli second intervals.

There are only four possible types of transfer, which have different properties, these are the intended uses:
Control - primarily used by the host to query the device - max 832Kbyte/s
Interrupt - small data size 'events' from the device to host - max 64KByte/s
Bulk - large volumes of data, uses remaining bandwidth so unpredictable - max 1,216KBye/s
Isochronous - time constrained data, can reserve bandwidth, but packets may get lost - max 1,023Kbytes/s

Isochronous transfer type is potentially hard to use because data may be silently dropped, so if all the data must get through, which is usually the case, the Maple would have to layer more stuff on top, so IMHO that can't be the default transfer used by Maple.

Interrupt is intended for small units of data (the example is a HID device like a mouse), that IMHO it can't be the default either. But pjrc Teensy do use the HID device for a boot loader, so it is flexible.

So the only options for volume data are Control or Bulk transfers.

I believe that the all USB devices *must* use transfer endpoints in order to have working USB communicatiuon. Though I believe it is possible to have only one. So I assume the Msaple does use transfer endpoints.

My reading of the USB spec is that, when you define your own device, and produce your own host-side device drivers, you can do anything with these transfer types, BUT, the control transfers will be used by the host to figure out what the device is when it is plugged in, or at start up.

When trying to emulate an existing device, so that an existing host-side device driver will interact with the device, the device has to comply with the host drivers use of transfer types. I believe there is a 'chat' bwetween the host and device (using Control transfers), so there may be a bit of negotiation, but ultimately the host side driver constrains what can happen.

So, the host driver constrains the type of transfers that can be used on the types of endpoints.

I believe the Control transfers have to be to a specific endpoint, so that he protocol can 'bootstrap' itself, but I can't find a reference to that at this moment.

Looking at http://www.lvr.com/usb_virtual_com_port.htm which describes an example of a 'virtual serial port', there seems to be very little room for maneuver. It does explain that the USB device descriptor *must* set the maximum packet size to 64 bytes, or their will only be one packet transferred/transer, and hence less than 64 bytes/millli-second.

The example does use multiple bulk transfer endpoints. I assume it must use at least two end points to get concurrent bidirectional communication.

I do not know if the device can offer more than two bulk transfer endpoints, whether any of the host side 'virtual serial port' drivers on Windows, OS X, and Linux will use them, and whether it makes a lot of diference to the throughput.

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

First two questions which have been bothering me. If isochronous transfers, which are often used for streaming data transfers where the "timing" is critical do not allow resending of the data if a transmission error occurs, why do isochronous transfers have a CRC:

http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous

If an error occurs is the data discarded by the host or is the data send to the host application with the warning "use this data if you want, but it has errors"?

Second question: can a device use different types of endpoints? For example, can a single device be configured to simultaneously use interrupt transfers (eg for low volume data transfers where data integrity is necessary) and bulk transfers (where a large amount of data needs to be transferred, but the absolute accuracy is not needed). If this is possible to implement using a Maple board, would each of these endpoints appear as a different COM port (eg. COM7 for the interrupt transfers and COM8 for the bulk transfers)? I assume a combination scanner/FAX/printer uses bulk transfers for all three functions. My assumption is that separate endpoints are set up for each function. I do not have such a multifunction device, so I do not know how it appears if tested using a USB analyzer.

Reviewing and summarizing is a good strategy for clarification, especially when an early mistake may affect later statements. I am glad when others catch my mistakes or ask me to clarify unclear statements/questions. We all learn and everyone benefits.

gbulmer said:

On USB Full-Speed devices (12MBit/s) like Maple, this is supposed to happen at 1 milli second intervals

I believe this statement is largely correct, but not all the time. It is true that on full speed systems the smallest time frame is 1 milliseconds (in contrast to high speed USB where 125 microsecond microframes are allowed). I do not know the most common polling intervals used by full speed devices, but 1 millisecond intervals are not required. I believe interrupt and isochronous transfers use the bInterval variable to request polling by the host at a certain frequency. A bInterval setting of 5 would request a polling by the host at least every 5 millliseconds.

However, I believe the bInterval is the maximimum interval a device needs to wait, but that polling may occur more frequently if the bus is free (eg. if your Maple device is the only device connected to the port). In a previous post gbulmer appears to agree with this interpretation. I am trying to confirm this in the USB 2.0 specs (remember, it is 650 pages long). This may have implications for optimizing the libmaple implementation, which has a timeout value of 50 milliseconds, if a device wants to send a series of data packets which are smaller or the same size as the device buffer. A data packet which is not full may mean no more data will be generated at the moment. However, a data packet which is full may mean more data will be added to the device buffer after the transfer or by (bad) luck the data buffer is full and no more data will be added. I believe there is a parameter, possible the use of the zero-length packet (ZLP), in the communication protocols which helps the host/device determine if the latter (full buffer but no more immediate data) is true.

My reading of the USB literature agrees with gbulmer's short four line summary of the names/uses/speeds of Control, Interrupt, Bulk, and Isochronous transfers.

I agree that isochronous transfers cannot be the default type used (or the initial type developed) on the Maple, because data can be lost. However, for streaming video and music applications the guaranteed latency and the high data capacity of isochronous are required.

Yes, interrupt transfer configurations appear to be commonly used for peripherals such as mice and keyboards. I believe the bInterval setting for these HID (human interface devices) are approximately 5 (because a polling more frequently than 5 milliseconds seems like overkill). However, for some applications a data communication rate of 64,000 bytes/second (or even 57,000 bytes/second after overhead) may be more than enough. This can be achieved using an interrupt transfer type if bInterval is set to 1 milliseconds and a 64 byte data packet is used. 64,000 bytes/second is a lot and many things can be done with this amount data. Not quite 16-bit CD quality stereo audio, but close.

Up to this point our (gbulmer and mine) understandings do not vary too much. Our descriptions may vary a little, probably due to our desire to write succinctly.

However, in his most recent post gbulmer said:

So the only options for volume data are Control or Bulk transfers.

I believe that the all USB devices *must* use transfer endpoints in order to have working USB communicatiuon. Though I believe it is possible to have only one. So I assume the Msaple does use transfer endpoints.

gbulmer, are your quoting/paraphrasing me here? I think all USB devices *must* use CONTROL endpoints in order to have working USB communication (see below). Maybe I am confused here.

I think we both agree that for low amounts of data (less than a theoretical maximum of 64,000 bytes/sec) interrupt transfers can be theoretically used. I believe that most USB memory sticks (where large volumes of data may be transferred) use bulk transfers. However, I do not think control transfers are an option for data transfer. I do not think control transfers can be used to send any "user data" between the host and device. I think I tried saying this in my previous post. I do not know if I am more clear here.

Yes, I definitely agree that control transfers are used when a device is first connected to a host. This allows the host and device to talk to establish which protocols they will be using (eg. full speed vs high speed, polling interals, etc).

Next is a place where I believe we differ. I believe each and every (for redundant emphasis) time frame includes a control transfer between the host and the device. See the bottom of this page (in the "Bandwidth Management" section):

http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk

where it says "if you have a highly saturated bus with periodic transfers, the remaining 10% is left for control transfers and once those have been allocated, bulk transfers will get its slice of what is left."

Control frames are used every 1 milliseconds if polling is done using this bInterval setting.

I believe the Maple currently uses bulk transfers for data transfers (and of course control transfer for coordination of exchanges). Theoretically, this would allow high theoretical transfer rates. However, the unpredictable bandwidth problem can be "solved" by simply using the Maple as the only device connected to the USB port.

I agree, at the bottom of http://www.lvr.com/usb_virtual_com_port.htm there are a lot of good concepts, which I am still digesting, in the "Maximizing Performance" section.

I am looking forward to seeing how DMA is implemented in IDE 0.1.0 and if it works well with the SerialUSB functions.

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC - cracking questions!

why do isochronous transfers have a CRC ...

I had assumed that is to detect that complete payloads have arrived correctly, on the basis that there is a difference between:
a. dropping a packet
b. transfering a packet, but it got corrupted
c. transferring a packet, and it is complete and correct
But I really don't know if there is more, or less, to it than that.

Second question: can a device use different types of endpoints? For example, can a single device be configured to simultaneously use interrupt transfers (eg for low volume data transfers where data integrity is necessary) and bulk transfers (where a large amount of data needs to be transferred, but the absolute accuracy is not needed).

Yes, a USB device in general, *must* have multiple endpoints. (I believe I was told by someone who'd written a 'proper' USB CDC (virtual serial) device which worked with Windows, Linux, OS X, and Solaris, it should have 5 or 6, but lots of folks do it with one less.)
I'm not sure what is meant by "... configured to simultaneously use ...". Each endpoint is a physical resource in the USB peripheral hardware. I usually mean a software choice by "configured", maybe that isn't what you mean.

Also "and bulk transfers (..., but the absolute accuracy is not needed)" do you mean isochronous transfers? Bulk transfers should always provide accurate and complete data transfer, but isochronous transfers do not.

If this is possible to implement using a Maple board, would each of these endpoints appear as a different COM port

A single, simple device (like a USB CDC) is one device with it's set of one or more endpoints.

The LeafLabs folks have explained (sorry can't see link) that they tried to make a more complex device (serial+DFU), but it was hard to make portable across platforms, though they were implementing two different devices, rather than several instances of the same device.

I believe interrupt and isochronous transfers use the bInterval variable to request polling by the host at a certain frequency. A bInterval setting of 5 would request a polling by the host at least every 5 millliseconds.

Thanks for the clarification.
I had read the links as saying the device asks for bandwidth, so I had thought the bInterval was derived from the bandwidth request.

I think all USB devices *must* use CONTROL endpoints in order to have working USB communication

Yes, sorry, I missed out the word CONTROL, confusing.
The point I was trying to making is every USB device will always have a CONTROL endpoint, and may be other endpoints.
Further, for all comms. which need reliable delivery in volume, there is bulk transfer available. So IMHO, that is the key transfer type to implement properly and efficiently on Maple.

Yes, interrupt transfer configurations appear to be commonly used for peripherals such as mice and keyboards. I believe the bInterval setting for these HID (human interface devices) are approximately 5 (because a polling more frequently than 5 milliseconds seems like overkill). However, for some applications a data communication rate of 64,000 bytes/second (or even 57,000 bytes/second after overhead) may be more than enough. This can be achieved using an interrupt transfer type if bInterval is set to 1 milliseconds and a 64 byte data packet is used. 64,000 bytes/second is a lot and many things can be done with this amount data. Not quite 16-bit CD quality stereo audio, but close.

I'm not sure what you are planning, but CD is sampled at 44,100 Hz, in 16 bits, and stereo doubles that to get 176,000 bytes, quite a lot more than 57,000 bytes.

But that is only half the story. There needs to be a host-side driver which will use the transfer. If you're planning on writing your own host-side USB driver, then you can achieve a lot more. But we'd need to do some tests if the plan is to use existing drivers, and the USB spec's define the protocols, and hence which end points and transfer types are used.

Up to this point our (gbulmer and mine) understandings do not vary too much. Our descriptions may vary a little, probably due to our desire to write succinctly.

Yes, agreed.

Next is a place where I believe we differ. I believe each and every (for redundant emphasis) time frame includes a control transfer between the host and the device. See the bottom of this page (in the "Bandwidth Management" section):

http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk

where it says "if you have a highly saturated bus with periodic transfers, the remaining 10% is left for control transfers and once those have been allocated, bulk transfers will get its slice of what is left."

The linked text says "... allowing no more than 90% of any frame to be allocated for periodic transfers (Interrupt and Isochronous) on a full speed bus ..."
So that 90% does not include control transfers. My reading of them not being periodic is that they can't, by definition, be scheduled as regular transfers.

Then as you quote, 10% is left for control transfers and bulk transfers.
But it doesn't say there *MUST* be control transfers to every device in every frame.

You may be correct that every frame does have one or more control transfers for every device.
I have oscillated on this. I had assumed there must be a control transfer for every device, on every frame, but I haven't been able to confirm that. If you have spotted something which categorically confirms or denies that, please post a reference.

I believe the Maple currently uses bulk transfers for data transfers (and of course control transfer for coordination of exchanges).

I believe so too. Maple currently implements a USB CDC device and a USB DFU device, and hence must use the transfer types dictated by those USB specifications and host device driver implementations.

... Theoretically, this would allow high theoretical transfer rates. However, the unpredictable bandwidth problem can be "solved" by simply using the Maple as the only device connected to the USB port.

I am unsure about the later point about "solving" unpredictable bandwidth problem by using Maple as the only device connected to the USB port. A while ago (several years), I believe USB ports might be connected internally to a USB hub, and I believe that bandwidth might then be shared. I also vaguely recall that a low-speed device on a USB hub, constrained the whole hub. I believe this is a complex area, and I might be too out of date :-)

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

Let me open this post with a question. If the current (March 2011) USB implementation of libmaple uses bulk transfer endpoints (which guarantees data integrity, but not bandwidth access), what is the LeafLabs test to see that this is true? Would a simple loop of SerialUSB.println('A') which sends a gigabyte of data suffice? Of course, at the host/receiving end an application would have to test that all the characters received were capital As followed by the CR/newline.

gbulmer, I think we have unveiled many important questions about USB during our last few exchanges. We have answered many (of my) basic questions. Your observations have given me confidence that my growing knowledge is at least heading in the right direction.

After this post I may sit quietly about USB until I see what changes (eg. DMA) the LeafLabs team has planned for IDE 0.1.0. I may start a new topic related to how are functions (eg. USB) implemented by st.com on the chip in silicon and how does the libmaple (or software in general) access the hardware functions. The answers to these questions will determine how much further into USB I can dig.

However, as I edit this message I realize my understanding of endpoints (which we have not discussed very much) is beginning to solidify. Maybe I will start another topic on USB endpoints.

Back to USB transfer types. In one sentence I phrased a question poorly and also made a mistake (which was caught). Definitely not one of my best sentences. Previously, I said (including the mistakes):

For example, can a single device be configured to simultaneously use interrupt transfers (eg for low volume data transfers where data integrity is necessary) and bulk transfers (where a large amount of data needs to be transferred, but the absolute accuracy is not needed)?

Yes, I intended to say isochronous transfers. Of course, multiple communications cannot be simultaneous over a single wire, so a better way, fixing both mistakes, to phrase the previous sentence is:

For example, can a single device be configured to use both interrupt transfers (eg for low volume data transfers where data integrity is necessary) and isochronous transfers (eg where a large amount of data needs to be transferred, but the absolute accuracy is not needed)?

For example, can a USB device send some periodic low volume ADC measured information (eg. temperature) using interrupt transfer endpoints while it also "simultaneously" streams high volume audio (through isochronous transfers). Imagine yourself listening to music stored on a SD card connected to the Maple while you get the current temperature once every 5 seconds via a ADC temperature sensor.

Let me try to rephrase the question about assigning multiple COM ports to a single USB device. At the moment, my host system can communicate via USB with the Maple as COM7. However, in the Maple only bulk transfers are currently (March 2011) enabled. Is it theoretically possible (when interrupt transfers are enabled) to use both bulk transfers (COM7) and also interrupt transfers in the same Maple sketch? Will the host see the data arriving from the device as just COM7 or will another virtual COM port be enabled?

Another way to ask the question is this. The Maple currently (March 2011) use SerialUSB.print() to access bulk transfers. If the device can be setup to use for example, both bulk and interrupt transfers what print command will be used to distinguish between the bulk and interrupt transfers?

If two SD cards are connected to the Maple, can they be configured to appear as two separate hard drives? Does this require that both host (eg. a host USB driver) and device (eg. libmaple USB drivers) be written? I am not planning to do this; just trying to think of examples to explain what I originally meant by "simultaneouslt".

Is this all wrapped up in endpoints and possibly multiple endpoints?

Regarding interrupt vs isochronous:

I'm not sure what you are planning, but CD is sampled at 44,100 Hz, in 16 bits, and stereo doubles that to get 176,000 bytes, quite a lot more than 57,000 bytes.

I forgot that CD music is 16-bit (2 bytes), so in my mind I was comparing 88K to 57K. However, 176K is only three times 57K. I think we can agree that 64,000 bytes/second can be a lot of data (even to a 32-bit cpu), depending on how much it has to be processed before it is sent over the communication line.

gbulmer says:

But that is only half the story. There needs to be a host-side driver which will use the transfer. If you're planning on writing your own host-side USB driver, then you can achieve a lot more. But we'd need to do some tests if the plan is to use existing drivers, and the USB spec's define the protocols, and hence which end points and transfer types are used.

No, I do not plan to write a host-side USB driver, but maybe I set it as a very long term goal if I understand what is meant by "achieve a lot more". What else can be achieved using USB 2.0 which is not currently implemented using the current host-side USB drivers? I assumed the current host-side USB drivers permit the maximum data transfer rates permitted by the USB 2.0 full speed spec. I assumed that during enumeration, when the device is first connected, as many endpoints are created as are needed/requested by the device.

Regarding control transfers and time intervals.

But it doesn't say there *MUST* be control transfers to every device in every frame.

I think we now agree that another way to ask the question is if control transfers occur during each interval?

I am still looking for a link which says that control transfer occur during each time interval.

I assumed control transfers were used during each interval so the host could tell each of the connected devices when they could send and receive data during that interval. I assumed control transfers acted like traffic cops.

I think we now agree that devices can set during enumeration when they want to be polled by the host. Let's assume two devices (deviceA and deviceB) each want to send a full 1023 byte isochronous type data packet every 2 milliseconds. My assumption is that during a specific interval the control transfer would be used by the host to tell say which device (A or B) could send its data packet and (by default) which device had to wait.

To make the situation more complicated lets assume each isochronous device wants to be polled every millisecond and send a full 1023 packet. What will happen in this situation? Will half of each device's data packets simply not get sent/received? If deviceA is sending a continuous tone to the left headphone (but silence to the right headphone) and deviceB is sending a continuous tone to the right headphone (but silence to the left headphone) will the host system compromise and jump back and forth between deviceA and deviceB (resulting in sound alternating every millisecond between the left and right headphones)?

I think we agree that for the interrupt/bulk transfer data types which are used for data whose integrity is maintained asking the device to wait a few frames or asking the device to resend data is essential to data integrity (but does not guarantee when data is transferred). With interrupt/bulk transfers the devices wait until the host says the pipes are clear.

Regarding bandwidth I also said:

However, the unpredictable bandwidth problem can be "solved" by simply using the Maple as the only device connected to the USB port.

This is what I was thinking. Imagine a bulk transfer device (such as a USB drive). Bulk communication is done after the control/interrupt/isochronous communications are completed. Whatever is left of each time interval (1 millisecond for full speed devices) is distributed to the bulk devices. If there are few or zero other interrupt/isochronous devices connected, most of the time available is used for bulk devices.

So in the current (March 2011) Maple USB implementation the use of bulk transfer endpoints should not limit the speed much as long as the Maple is the primary USB peripheral.

I remember days when a slow IDE CD ROM drive configured on a two drive cable as the "sl_ve" (I always hated the expression) could slow down the second device on the cable (configured as the "m_aster"). Is the observation/memory of slow USB devices slowing down the whole USB chain related to the USB 1.0 spec? Or perhaps does a single USB 1.0 device on a USB 2.0 hub slow down all the traffic to the 1.0 speed?

Let me quickly return to an old question, which I think we have now answered (over the course of several exchanges). Do we agree that during a single 1 millisecond time interval a device can send a single packet?

Is this related to why the transfer types which are error free (control/interrupt/bulk) have small data packets? If during the transfer 64 bytes of data become corrupted, requesting a resend of the data is not a big challenge to the system. However, for isochronous data transfers if the data is transferred with errors then a choice needs to be made by the host to either use the partially corrupted data or to wait until the next frame.

I think I need to read more about USB endpoints. More questions later.

Those are my thoughts for now.

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC

For example, can a single device be configured to use both interrupt transfers (eg for low volume data transfers where data integrity is necessary) and isochronous transfers (eg where a large amount of data needs to be transferred, but the absolute accuracy is not needed)?

For example, can a USB device send some periodic low volume ADC measured information (eg. temperature) using interrupt transfer endpoints while it also "simultaneously" streams high volume audio (through isochronous transfers). Imagine yourself listening to music stored on a SD card connected to the Maple while you get the current temperature once every 5 seconds via a ADC temperature sensor.

Yes in theory I believe that is possible, but ...
... either you need to find an existing host-side device driver which will support this protocol (combination of use of transfers) which I think is unlikely, or you need to write a host-side driver, and figure out how to integrate it into the host-side USB infrastructure.

Let me try to rephrase the question about assigning multiple COM ports to a single USB device. At the moment, my host system can communicate via USB with the Maple as COM7. However, in the Maple only bulk transfers are currently (March 2011) enabled. Is it theoretically possible (when interrupt transfers are enabled) to use both bulk transfers (COM7) and also interrupt transfers in the same Maple sketch? Will the host see the data arriving from the device as just COM7 or will another virtual COM port be enabled?

No.
The host-side USB CDC driver is constrained to implement the USB CDC standard protocol. I do not believe that protocol has this option. So I don't believe the CDC protocol spec. would use the extra endpoint and transfer type.

Another way to ask the question is this. The Maple currently (March 2011) use SerialUSB.print() to access bulk transfers.

Yes.

If the device can be setup to use for example, both bulk and interrupt transfers

I don't believe the USB CDC spec. has this option, so even if the Maple were set up to use the endpoints and transfers the host-side driver won't use them, so nothing would happen.

what print command will be used to distinguish between the bulk and interrupt transfers?

It could be any name you would like. There is no 'standard', or constraints on names in Maple code. It won't cause any data to move unless the host-side driver uses the endpoint so I think it is irrelevant.

If two SD cards are connected to the Maple, can they be configured to appear as two separate hard drives?

SD cards can not be configured to be USB devices (in my use of the word configured).

Does this require that both host (eg. a host USB driver) and device (eg. libmaple USB drivers) be written?

Yes, that would do it, then the Maple-side USB driver would determine how the SD cards were presented. AFAIK, the usual USB Flash drive device looks like one volume, but if someone is writing the entire stack, it could look like anything.

I think we now agree that another way to ask the question is if control transfers occur during each interval?

I think we have got to a point where we think there are two units of 'activity', one is the frame, and the other is the systems scheduled response when asked for bInterval.
Which of these two do you mean when you say 'interval'?

I assumed control transfers were used during each interval so the host could tell each of the connected devices when they could send and receive data during that interval. I assumed control transfers acted like traffic cops.

Yes, if we agree it is either a frame or a bInterval, then I think we are assuming a very similar model.

I think we now agree that devices can set during enumeration when they want to be polled by the host.

Yes!-)

Let's assume two devices (deviceA and deviceB) each want to send a full 1023 byte isochronous type data packet every 2 milliseconds.

Okay. So that would be close to an aggregate throughput of one megabyte/second.
<>My assumption is that during a specific interval the control transfer would be used by the host to tell say which device (A or B) could send its data packet and (by default) which device had to wait.</>
I don't assume the control transfer needs to tell a device that it has to wait. Depending on the USB protocol, I assume the host can simply choose not to ask for the data. It doesn't need to say "I am not going to ask for your data". But I'd need to read all the USB device specs to confirm that is true.

To make the situation more complicated lets assume each isochronous device wants to be polled every millisecond and send a full 1023 packet. What will happen in this situation? Will half of each device's data packets simply not get sent/received?

My reading of the definition of isochronous transfers is the USB device requests an amount of bandwidth from the host during enumeration (in this case 1023 bytes/millisecond). The host will reserve that bandwidth, until a further USB device asks for an amount which exceeds the available bandwidth. The host will refuse that request. So it is up to the host to accept requests that it can honour.
Then the host has several alternatives to deal with the USB devices, which requested bandwidth, and use isochronous transfers, but try to exceed their allocated bandwidth. One is the approach you suggest of not transferring 1/2 of the data for each one, though I think that might have some other implications. I believe it is as valid for the host to starve one.

Let me quickly return to an old question, which I think we have now answered (over the course of several exchanges). Do we agree that during a single 1 millisecond time interval a device can send a single packet?

Definitely no.
Two reasons:
1. a single device may have more than one endpoint, and hence the device may do one or more transfers in each frame using each endpoint.
2. I believe that the bulk transfer packet size is a maximum of 64 bytes, but bulk transfer can move much larger chunks of data, and the only way that can happen is for the bulk transfer to support multiple packets.

I need to go read the spec. to respond to your other questions. I am a bit busy, so I may be slow (or forget).

Wonderful stuff StephenFromNYC, thank you. I am getting a better understanding of this than I had got from reading it alone.

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.