Answer

No, the driver does not close the connection when Windows enters sleep. The application is always responsible for closing the connection.

Furthermore, failing to close a connection before calling SI_Open() will cause SI_Open() to be unsuccessful.

Answer

Here's the steps to perform an eeprom write and read using the evaluation tool.

1) Make sure that Chip Select is set to 2 for the eeprom.

2) Write of one byte 06 to enable a write (this will need to be repeated for every write).

06

3) Write of 4 bytes. First byte the write command (0x02), next is address (0x00), and next is 2 bytes of data (0x03 and 0x07).

02 00 03 07

4) WriteRead of 4 bytes. First byte the read command (0x03), next is address (0x00), and next is 2 dummy bytes to get the read data (0x00 and 0x00).

03 00 00 00

At this point the receive data window displays:

03 07

Answer

The option to write to RAM has been deprecated in the CP21xx Customization Utility because there are several config parameters that cannot be changed by writing to RAM. For example, the clocking options are only applied when coming out of reset and resetting the part will clear the RAM. So there is no way to test clocking options by writing to RAM. Writing configurations to OTP is the best way to test all configuration options.

Answer

The short answer is no, but understanding why this is the case requires some background.

Foremost, we need to know what kind of power delivery capabilities are supported by the different versions of USB. This is not as clear cut as it might seem.

The USB specifications define power in terms of unit loads.  A unit load as defined by the USB 1.1 and 2.0 specifications is 100 mA, and a maximum of 5 unit loads (500 mA) can be drawn from a powered root hub port. For USB 3.0, a unit load is 150 mA, and the maximum current draw is 6 unit loads (900 mA).

At first blush, these numbers might seem suspiciously low. After all, a variety of portable electronic devices come with chargers capable of delivering 1 A, 2 A, or more. This differs substantially from the maximums specified in terms of unit loads.

Key to this, of course, is that these are chargers, and the maximum current that can be provided by a USB charger is governed by the USB Battery Charging Specification. Depending on the type of charging port, as defined in the specification, current draw up to 5 A can be supported, although not necessarily with concurrent data transmission (as is the case with USB 3.0). Regardless, the USB device needs to be able to detect the type of charging port to which it is connected in order to determine how much current it can draw, and this is something that the CP2110, CP2114, and CP2130 cannot do.

So, how does a host know how much current a connected device can draw? Like everything else involving USB capabilities, the host figures out what a device can do during enumeration.

When a connected device enumerates, it transmits an overview of its capabilities packaged in a series of descriptors to the host. Two fields in two of these descriptors are relevant to knowing how much current a USB device reports that it can/will draw.

The first of these is the bcdUSB field in the device descriptor. This is just a binary coded decimal representation of the version of the USB specification with which the device is compliant: 0x0110, 0x0200, and 0x0300 for USB 1.1, 2.0, and 3.0, respectively. The devices referenced in this article report as:

While this does not immediately tell how much current a USB device can draw, it implicitly sets the maximum per the definition of unit loads above. Actual current draw is reported by a device using the MaxPower field in its configuration descriptor.

For most devices, the 8-bit MaxPower value is multiplied by 2 mA to get the reported current draw, thus a maximum of 250 (0xFA), which equates to 500 mA, is allowed. However, for USB 3.0 devices operating in SuperSpeed (5 Gbps) mode, the MaxPower multiplier is 8 mA, for a maximum of 112 (0x70) equating to 900 mA.

So, in the case of the CP2110, CP2114, and CP2130, while MaxPower can be customized, it is still interpreted relative to the 2 mA multiplier for USB 1.1 and USB 2.0 devices and thus subject to a maximum value of 0xFA (250 x 2 mA = 500 mA) even when plugged into a USB 3.0 port.

Answer

The maximum data throughput you can achieve with a CP210x device depends on the maximum allowable baud rate of that device and on the amount of USB traffic on the system.  Because the CP210x device utilize Bulk USB transfers, delivery is guaranteed but latency is not, so while the data will eventually be sent over the interface, there is no guarantee of the delivery time.

That being said, the maximum realizable throughput is capped at the maximum allowable baud rate of the device.  For instance, the CP2102 maximum baud rate is listed as 921600 bps (see CP2102 datasheet, page 1). Assuming the largest frame size you can select for the device of 11 bits (8 data bits, 1 start bit, 2 stop bits), the theoretical maximum throughput of the device with these settings is 921600 bps / 11 bits per byte = 83781 bytes/sec = 83.781 kB/sec.  This is not a guaranteed throughput because of the uncertainty of the USB delivery, but serves as a theoretical ceiling on the CP2102 throughput.  Thus, the maximum throughput is also less than the total number of bits sent due to overhead of the UART protocol (see figure below). 

The theoretical maximum throughput of all of the CP210x devices (non-HID USB) can be calculated in a similar manner by first locating their maximum baud rate from the device datasheet and accounting for the overhead of the protocol you are using.