a) Asymmetric communication
RS232C is symmetric communication, when TX and RX are connected each other on host and device. Device can notify to host any time device requires.
In USB transfer, device cannot notify to host unless host polls device. Moreover, device should prepare data before host polls device.
Therefore, most of USB communication sequence is as follows.
- host sends a command to a device (sometimes cut down on continuous transfer)
- the device prepares data according to the command
- host reads the answer from the device
If a device requires quick response, host should poll the device frequently.


b) Transfer speed is not fixed.
In RS232C communication, baudrate determines the transfer speed.
In USB bulk transfer, transfer speed is affected by many factors, such as
- Activity of other devices connected to the same bus tree
- Retry caused by communication error, such as noise
- Performance of device core processor
- Other processes and background services on PC
- Performance of low level driver for PC mother board/chip set
You can usually expect at least 300-400 KByte/sec in "full speed" transfer when only a single device is connected to the USB bus.

Even in USB interrupt transfer, which is "scheduled" transfer, the theoretical maximum speed is not always achieved owing to error-retry or performance issue of low level driver.
You can expect at least ~30 KByte/sec in "full speed" transfer.

To handle fluctuation of transfer speed, following methods are often used.
- Transfer buffers (or equivalent) on the both ends
- Timeout


c) "transfer" and "transaction" / host application and firmware
A "transfer" consists of multiple "transactions". The host application issues "transfer" to the device driver. This "transfer" is split into multiple "transactions"- "packets" in the device driver, and the firmware replies to each "transactions"- "packets". Therefore, the firmware should gather packets to reconstruct a stream of data on OUT (from host to device) transfer. Or it should split a stream of data to multiple packets on IN (from device to host) transfer. A single "transfer" of the host application corresponds multiple "packets" on the firmware.


d) Start with fiddling bulk or interrupt transfer routines
USB firmware programming is a little complicated than RS232C but not so much after all.
Surely, USB protocol has a complicated enumeration process, but it is handled by established code or libraries provided by the device manufacturer. What you need is modifying several parameters. Most of reference books, including Axelson's, start with explanation of protocol and enumeration process, but pass through it first.
Instead, start with fiddling transfer routine of bulk or interrupt example of your device. You can find a simple bulk and interrupt protocol explanation in
"USB in a NutShell" http://www.beyondlogic.org/usbnutshell/usb4.htm

Tsuneo