我正在使用支持高速USB的32位AVR微控制器（AT32UC3A3256）。我想定期从我的PC向设备传输数据（不承认数据），所以就像USB音频接口一样，除了我要发送的数据不是音频。这样的界面在这里描述：http://www.edn.com/design/consumer/4376143/Fundamentals-of-USB-Audio。
我对USB 等时传输感到有点困惑。我了解单次转帐的工作原理，但 是下一次后续转帐的计划？我想要一个提前计算的连续数据流，但是流量最小，延迟时间短，没有中断（偶尔会有一些数据丢失）。根据我的理解，Windows不是实时操作系统，所以我认为传输不应该每隔x毫秒计划一次，而是使用中断/事件？或者可能需要使用尽可能多的数据连续填充缓冲区？
我认为我的问题仍然是关于USB的概念而不是与代码相关，但如果有人想看我的代码，我正在测试和修改Atmel Studio的ASF框架中的“USB Vendor Class”示例，包含AVR的固件源以及Windows EXE的源。 Windows示例程序使用libusb和提供的驱动程序。
答案 0 :(得分：1)
斯蒂芬 -
你说“完全像USB音频”;但要注意！ USB Audio类非常非常复杂，因为它实现了闭环伺服系统，以在PC和音频设备之间建立长期同步。您可能不需要在应用程序中使用所有这些内容。
更多地了解长期同步：一端的音频编解码器（例如USB耳机）可以以标称的48KHz采样率运行，而另一端的音频文件（例如PC）可能是旨在提供每秒48,000个样本，但PC和耳机永远不会以完全相同的速度运行。迟早会出现缓冲区溢出或欠载。因此USB音频类实现了控制管道以及音频管道。控制管道用于协商一端的轻微加速或减速，通常是设备端（例如耳机），以避免数据丢失。这就是音频设备类产品的USB描述符非常复杂的原因。
如果您的应用程序可以容忍数据从PC传送到AVR的速度有轻微错误，则可以省去闭环伺服。这使得事情变得更加简单。
在使用等时管道传输数据时，您绝对正确地需要长期缓冲。单个等时传输毫无意义 - 您也可以使用散装管道。等时管道的全部原因是处理数据流。所以必须像你说的那样设置很多前瞻缓冲。
我在产品特定的应用程序中使用LibUsbK进行iso传输，这些应用程序不适合任何先入为主的USB类。在libusbk上有关于iso传输的相当好的文档。简而言之 - 您可以确定每个数据包的字节数和每次传输的数据包数。你决定预先填充多少个缓冲区（我用五个），然后提供libusbk驱动程序来开始工作。然后你得到回调，因为每个缓冲区都被驱动程序清空，所以你可以用新数据填充它们。虽然我有尴尬的采样率来处理，但它对我来说效果很好。在我的情况下，我设置了一堆二十一个数据包，其中二十个携带40个字节，第二十一个携带44个字节！
希望有所帮助 - 托尼