Честно говоря, я не понимаю, как мы можем «потерять» (или мы должны сбросить, сбросить или перезаписать) байты при передаче или получении через USB.

А USB Communication основана на «пакетах» где управление RX/TX выполняется через подтверждение связи (ACK/NACK/STALL PACKETS), где размеры пакетов для управления передачами (например, команда и статус) размером от 8 до 64 байтов, и Размер пакета полезной нагрузки максимум 1024 байта (фактически 8, 16, 32, 64, 512, 1023 или 1024 на основе типа передачи).

Не существует больших размеров пакетов, afaik (пожалуйста, поправьте меня).

Когда мы устанавливаем буфер RX на буфер 1024 и TX на 1024 (совершенно возможные размеры для любого STM32) мы не должны отбрасывать/сбрасывать/перезаписать каких -либо байтов, и поэтому мы не можем терять байты при выполнении TX или RX через USB..

[Пито - Пн, 14 августа 2017 г. 5:57 утра] - Честно говоря, я не понимаю, как мы можем «потерять» (или мы должны сбросить, сбросить или перезаписать) байты при передаче или получении через USB.

А USB Communication основана на «пакетах» где управление RX/TX выполняется через подтверждение связи (ACK/NACK/STALL PACKETS), где размеры пакетов для управления передачами (например, команда и статус) размером от 8 до 64 байтов, и Размер пакета полезной нагрузки максимум 1024 байта (фактически 8, 16, 32, 64, 512, 1023 или 1024 на основе типа передачи).

Не существует больших размеров пакетов, afaik (пожалуйста, поправьте меня).

Когда мы устанавливаем буфер RX на буфер 1024 и TX на 1024 (совершенно возможные размеры для любого STM32) мы не должны отбрасывать/сбрасывать/перезаписать каких -либо байтов, и поэтому мы не можем терять байты при выполнении TX или RX через USB..

Вы правы, пито, но так это должно работать, но не всегда так реализовано. В общем ядре каждый пакет, который отправляется хост, заполняется незаметно, даже если он не подходит в буфере. Поэтому, если пакет не подходит, он остается в оперативной памяти USB -устройства, чтобы быть перезаписанным следующим пакетом, отправленным хостом.
Libmaple F1 остановит вклейки пакетов, когда буфер будет заполнен, поэтому хост должен выдержать. В Libmaple F4 Serialusb, который не является на самом деле Libmaple, поскольку он был добавлен Aeroquad из стандартной периферийной библиотеки, каждый пакет заполняется независимо от того, подходит ли он в буфере или нет.
Я уже изменил это (Libmaple F4), так что он не ACK, когда буфер заполнен, и, как только буфер имеет емкость для еще 1 пакета, он заставляет предыдущий, и хост может продолжать отправлять.

TX во всех ядрах (Libmaple F1, F4 и Generic) имеет тайм -аут, если передача не может быть завершена в пределах X MS, она возвращает. Но поведение тоже зависит от этого. Мне нужно подтвердить, но я считаю, что это как следует:
Libmaple F1 & F4: возвращает количество байтов правильно в очереди для отправки.
Общий F4: возвращает 0, даже если некоторые байты были очередями. Кроме того, у него есть переменная «передачи», которая, поскольку я не могу понять, что именно предназначено для. Я думаю, что намерение состоит в том, чтобы указать, сколько байтов в буфере, ожидающем отправки, но это скорее следует рассчитать с помощью головы и хвоста очереди. Также я не уверен, что переменная передачи получает правильное значение в зависимости от того пути, который берет код. Но это может быть, я не понимаю это правильно, хотя ваше подтверждение того, что TX искажено, и отсутствует байты, я думаю, это подтверждение, которое не работает правильно.

Учитывая, что общее ядро ​​основано в HAL, может быть хорошей идеей заменить код SerialusB на то, что от STM.

Кто -нибудь на самом деле пытался просто подготовить тайм -аут с миллисекундов до секунд?
Замените код serialusb на то, что от STM Serialusb находится поверх всего кода STM.
И код CDC STM не имеет буферизованных записей (CDC_TRANSTIMER_FS () немедленно отправляется, что было первоначальной проблемой), поэтому мне пришлось взломать USBSerial_tx_handler в код CDC STM, поэтому, когда теку Больше вещей, которые нужно отправить и отправлять его из USB -прерывания, вместо serialusbclass :: write (и serialusbclass :: write не отправит его, если он знает, что есть передача Ongoin (переменная передачи)))).

[Даниэфф - Вторник 15 августа 2017 г. 6:21] - Кто -нибудь на самом деле пытался просто подготовить тайм -аут с миллисекундов до секунд?
Замените код serialusb на то, что от STM Serialusb находится поверх всего кода STM.
И код CDC STM не имеет буферизованных записей (CDC_TRANSTIMER_FS () немедленно отправляется, что было первоначальной проблемой), поэтому мне пришлось взломать USBSerial_tx_handler в код CDC STM, поэтому, когда теку Больше вещей, которые нужно отправить и отправлять его из USB -прерывания, вместо serialusbclass :: write (и serialusbclass :: write не отправит его, если он знает, что есть передача Ongoin (переменная передачи)))).

Разве мы не можем использовать головку и хвост, чтобы определить, есть ли в буфере больше, а не переменную передачи?
Если у нас есть только 1 данные о вытягивании функции (TX_HANDLER) и 1 функция, добавляя данные (serialusb :: write), и мы не позволяем головке ударить хвост, тогда мы всегда можем знать, что сейчас находится в буфере, даже если это мы прерываться и еще много чего.


О коде, я не знал, что это использует STM, так как он показывает Vassilis в качестве автора, я думал, что STM написал свой собственный.

Все в этой теме, можем ли мы сначала согласиться с тем, каково желаемое поведение для USB TX и RX в случае заполнения буферов?
Мое предпочтение:
Для TX должен вернуться сразу же, и возвратное значение указывает на то, сколько байтов он может стоять в очереди. Если 0 байтов, верните 0. Для x байтов вернуть x. (Итак, это вызывает увольнение тайм -аута, оставьте тайм -аут или повторение для приложения).

Для RX, если буфер заполнен, NAK The Last Host Packet, так что он не отправляет еще один. После того, как в буфере будет достаточно емкости, чтобы получить как минимум на 1 пакет, выпустите ACK для предыдущего пакета, чтобы хост мог отправить новый. Если приложение начинает читать байты из буфера RX в точке, он получает достаточно места для другого пакета, затем выпустите NAK и продолжайте.

Выше, как я изменил код Стива F4 RX для работы (не TX на данный момент).

[victor_pv - Ср 16 августа 2017 г., 16:46] - Все в этой теме, можем ли мы сначала согласиться с тем, каково желаемое поведение для USB TX и RX в случае заполнения буферов?
Мое предпочтение:
Для TX должен вернуться сразу же, и возвратное значение указывает на то, сколько байтов он может стоять в очереди. Если 0 байтов, верните 0. Для x байтов вернуть x. (Итак, это вызывает увольнение тайм -аута, оставьте тайм -аут или повторение для приложения).

Возвратные значения в порядке, но там должен быть небольшой тайм -аут. Никто никогда не будет делать повторения с серийным.Печать/написать (...).

[victor_pv - Ср 16 августа 2017 г., 16:46] - Для RX, если буфер заполнен, NAK The Last Host Packet, так что он не отправляет еще один. После того, как в буфере будет достаточно емкости, чтобы получить как минимум на 1 пакет, выпустите ACK для предыдущего пакета, чтобы хост мог отправить новый. Если приложение начинает читать байты из буфера RX в точке, он получает достаточно места для другого пакета, затем выпустите NAK и продолжайте.

Выше, как я изменил код Стива F4 RX для работы (не TX на данный момент).

Вы можете попытаться сделать это, но это глубоко внутри кода CDC STM. (Я думаю. Я на самом деле не проверял)

Что касается данных, наконец, я смог настроить тест, чтобы я действительно мог увидеть проблему. (Используя `for (i = 0; i < TXCHARS; i ++) сериал.Напишите ('0' + (i % 10)); `плюс Teraterm, мне не нужно регистрировать, и я могу видеть 0123456789.)
Кстати, проблема сохраняется, даже если я комментирую тайм -аут, так что не так.

Следующий код: // USBSERIAL TX PROBLEM DEMONSTRATION // Pito 7/2017 #include "Arduino.h" void setup() { Serial.begin(115200); delay(3000); } #define TXCHARS 1000000 void loop() { uint32_t i; uint32_t elapsed = micros(); for (i = 0; i < TXCHARS; i++) { Serial.write('0' + (i % 10)); } elapsed = micros() - elapsed; Serial.println("***"); Serial.print("USB TX speed = "); Serial.print((1000.0 * TXCHARS) / elapsed, 2); Serial.println(" KBytes/sec"); delay(5000); }

Различные приложения могут вытащить пакеты RX с разными скоростями от буфера -хоста, поэтому возможно, что они могут заполняться при использовании Teraterm, а затем код TX будет падать байты, и Arduino IDE может тянуть их быстрее и никогда не допустить. Буфер TX заполняет.
Мы можем добавить немного флага в код TX, чтобы увидеть, заполнится ли когда -нибудь буфер.

При использовании Arduino IDE, вы когда -нибудь видели байтовые последовательности вне порядка? (Вероятно, просто заменить 0123456789 для "" "или" ok "и посмотреть, что у вас осталось)

Это не о буфере TX. Следующий код обходит весь класс serialusb, без сериала.xxx звонок вообще: #include "Arduino.h" char buffer[200]; #define TX 1000 void setup() { Serial.begin(115200); delay(3000); memset(buffer, '.', sizeof(buffer)); for(int i=0; iTxState != 0); // Wait for USB transfer to finish } delay(5000); }

Я также согласен, что никто никогда не попытается повторно отправить данные при выходе через серийный.
То есть я думаю, что отправка сериала должна быть как можно простая, поэтому либо блокировать, либо не блокировать.

Последовательный USB F4 был первоначально настроен на неблокирование, но я изменил это, потому что я пропустил некоторые данные со стороны хоста. После смены этого приема на стороне хоста было в порядке.

Чип должен отправлять данные как можно быстрее.
Кроме того, хост должен прочитать эти данные как можно быстрее. Неспособность сделать это, конечно, будет результатом потери данных.
Если хотя бы одно приложение для хоста способно читать все данные, это означает, что чип работает нормально.

Похоже, у Teraterm есть проблемы с Win10?

Commecho тоже теряет данные (см. Выше из моего win7_64bit).
Не могли бы вы примерить свои машины - Commecho - вернет ли он 1 мил chars ok, plz?

Обновлять:
С последним Libmaple F1 я получаю 1 мили ChARS от Teraterm при входе в файл (217 кб/с, когда не зарегистрирован, 102KB/S при регистрации в файл).
С последним Libmaple F4 я получаю 1 мили ChARS от Teraterm при входе в файл (170 КБ/с, когда не зарегистрирован, 102KB/S при регистрации в файл).

Проблема с блокировкой TX заключается в том, что в последовательном порте, если в другом конце нет ничего, есть конечная сумма, которую потребуется для отправки данных и установленного уровня бода, а затем вернется, так что не будет Блок постоянно.
Но в USB, если другой конец не получает его. Так больше или меньше, но я думаю, что необходимо некоторое время ожидания. Мы могли бы установить тайм -аут как множество времени на байт для определенной минимальной скорости, поэтому время ожидания не одинаково при отправке 1 байт, как при отправке 1000. Это будет больше напоминать, что будет делать драйвер UART.

С другой стороны, с тайм -аутом, если хост медленно получает данные, мы можем потерять байты. Но я думаю, что любой, кто не хочет потерять байты, должен проверить возвращенное значение, чтобы подтвердить, что оно было отправлено. Если это не критично, игнорируют возврат.
Например, если мы решим использовать тайм -аут для имитации минимальной скорости 100 КБ/с, то это будет 10us за байт. Если хост медленнее, чем этот (или отключен), то трансмиссии могут тайм -аут, но если хост сохраняет хотя.

Но на RX, если мы не перестанем отправлять Acks на хост, пока не появится места в буфере, очень возможно, что данные будут потеряны, не имеет значения, что делает приложение, поскольку хост потенциально намного быстрее.
Ядро F1 делает это, и в Libmaple F4 я изменяю его локально, я отправлю PR, чтобы больше людей могли проверить, что RX.

На общем TX я постараюсь повторить некоторые тесты, которые проделал Пито, и посмотреть, есть ли какая -то разница, но я не убежден, что это просто терратерм.

http: // www.за пределами сложности.org/usbnutshell/usb1.SHTML
Ведущий отвечает за управление полосой пропускной способности автобуса. Это делается при перечислении при настройке изохронных и прерывающих конечных точек и на протяжении всей работы шины.

Да, но продолжайте читать:
http: // www.за пределами сложности.org/usbnutshell/ ... Сохронный
OUT: Когда хост хочет отправить функцию массовым пакетом данных, он выдает токен Out, за которым следует пакет данных, содержащий объемные данные. Если какая -либо часть токена или пакета данных повреждена, то функция игнорирует пакет. Если буфер конечной точки функции был пуст, и он включил данные в буфер конечной точки, он выпустит ACK, информируя об хосте, который он успешно получил данные. Если буфер конечной точки не пуст из -за обработки предыдущего пакета, то функция возвращает NAK. Однако, если у конечной точки была ошибка, и ее бит остановки был установлен, она возвращает стойло. Также я думаю, что важно отметить: Объемные переводы
Используется для передачи больших взрывающих данных.
Обнаружение ошибок через CRC, с гарантией доставки.
Нет гарантии пропускной способности или минимальной задержки.
Потоковая труба - однонаправленная
Полный & Только режимы высокой скорости. Мы должны гарантировать доставку с помощью рукопожатия, но нет никакой гарантии пропускной способности, поэтому мы не должны сбрасывать пакеты только потому, что приложение на хосте или MCU не так быстро.

Мое наивное «Пользовательское» наблюдение (на основе вышеуказанных результатов с Libmaple F1 и F4) следующее:

USB TX в Libmaple «понял команды (хост -хост) Teraterm (хост), так как он перенес 1 мил ok с 102 кб/с как для F1, так и для F4, в то время как TT вошел в данные в файл.

Очевидно, что TX Libmaple был организован хостом, так как общая достигнутая скорость TX одинакова для F1 и F4 (скорость пакета такая же, потому что USB -часы одинаковы, но накладные F4/F1 сделала бы Разница в общей скорости TX, когда пакеты не были синхронизированы хостом).

С помощью TX Daniel мы можем достичь более высоких скоростей NX (с большими размерами буферов CDC), но мы теряем, скажем, 70% данных - таким образом, кажется, что STM32Generic TX игнорирует команды рукопожатия TT ​​-хоста..

Серийный монитор Arduino, возможно, намного быстрее, чем TT, поэтому он захватывает 1 мил ChARS без надлежащего поручения, или он использует другую модель ручной работы, STM32GENERIERENEREN TX понимает лучше..

У Libmaple есть код, который проверяет один из сигналов рукоятки (я думаю, DTR), и если он не может отправить данные на хост, то код «блоки» в функции write ()

Было отмечено, что это отличается от того, что, похоже, не проверяет, готов ли хост для данных

@Pito, я в значительной степени согласен с вами в этой теории.

[Rogerclark - Сб 19 августа 2017 г. 1:09] - У Libmaple есть код, который проверяет один из сигналов рукоятки (я думаю, DTR), и если он не может отправить данные на хост, то код «блоки» в функции write ()

Было отмечено, что это отличается от того, что, похоже, не проверяет, готов ли хост для данных

Роджер, я много посмотрел на код F1 при написании Readbytes, чтобы попытаться достичь максимальной скорости. Libmaple F1 будет работать с хозяином с ACK и NACK в TX и RX, поэтому, когда буфер на одной стороне будет заполнен, другая сторона будет удерживать дальнейшие пакеты. Когда буфер получает место, ACK отправляется на другой конец, и продолжает передачу, пока буфер не заполнится, и этот конец снова не отправит Нэк.
Что касается того, что я видел с DTR, используется только для обнаружения сброса волшебного слова, но для обычного рукопожатия, но ручная задача с ACK и NACK - это то, что должно произойти, и, кажется, является хорошей реализацией.

У F4 в RX этого не было. Он всегда отправлял ACK, даже если буфер был заполнен. Я изменил это и сейчас работает довольно хорошо. Я могу получить 500 КБ/с, аналогично F1 (MCU быстрее, но код основан на SPL, более накладных расходов, чем Libmaple).
F4 TX действительно работал в моих тестах, и я не внес никаких изменений в это.

У меня не было возможности копать глубоко в той, что используется общим ядром, чтобы увидеть, что именно это делает, но я подозреваю, что рукопожатие не так, как подозревает Пито.

Лично я думаю, что реализация, которая теряет байты в любом направлении, просто бессмысленная. Если я захочу отправить что -то в одну сторону, потому что я хочу получить это в другом конце.
Я понимаю, что для распыления последовательных отчетов здесь и там не иметь большого значения, но для передачи изображений, таблиц, данных датчиков, что -либо еще отправлено, я бы не хотел терять ни одного байта, если ссылка не упадет или один конец не Отвечая слишком долго.
Я бы предпочел иметь без потерь 100 КБ/с, которые 500 КБ с проигрышами.

Я не программист, просто любопытный, это то, что я мог найти: ... CDC_Transmit_FS(&tx_buffer.buffer[tx_buffer.iTail], transmitting); //Set buffer and begin tranmission ...

Libmaple Lasting от Repo, Maple Mini, Log Teraterm, тестовый код из первого сообщения (GCC 6-2017-Q1-Update), USB, по-видимому, отбрасывает данные (все *** должны быть на одном столбце):

Teraterm3.PNG (48.29 киб) просмотрено 664 раза

Хм, то, что я сделал сегодня утром - Установлен Wireshark - бесплатный открытый сетевой анализатор, который включает в себя анализатор "USB Packet Capture".

https: // www.Wireshark.орг/

Тестирование с помощью цикла отправляет «u» (0x55) Teraterm (Win7_64b), от Black F407:

Libmaple F4 - пакеты данных, идентифицированные как «5555» и Ethernet II - «« Уродственный пакет », всегда протокол пакета данных« 5555 »с некоторыми данными заголовков, а затем содержащим 2048x« U »и небольшой тип протокола Ethernet». «28 Urb -объем в уродливых», содержащий 1x u, между ними, не видно рукопожатия (если не уродство не является пакетом рукопожатия)

32GENERIERC - пакеты данных, идентифицированные как 5555 или «Ethernet II», один пакет, содержащий 16-100 "U" S, не видно рукопожатия

В качестве доказательства это как -то работает, я пробовал для развлечения:
Я сохранил файл с UUUS в Corsair Flash Drive и прочитал его в редактор.
Это другое устройство (массовое хранилище), но - все пакеты данных, назначенные «хорошими», до 65535 больших, с рукопожатием (2 <-> Транзакции между Host A Device) между пакетами данных. Протоколы пакетов были связаны с USB.

Libmaple:

Libmaple USB захват.JPG (194.53 киб) просмотрено 649 раз

Пито, очень интересный.
Libmaple F4 USB CDC основан на SPL на основе SPL.
Не могли бы вы проверить Libmaple F1?

Libmaple F1 - Похоже на 32 GENEREN, но гораздо больше UUS внутри пакета:

Libmaple F1 захват.JPG (227.8 киб) просмотрено 371 раз

Libmaple F1 против гипертерминализации (227 КБ/с)

Libmaple F1 против гиперподронала.JPG (245.55 киб) просмотрено 350 раз

Если последний пакет не заполнен, может быть, попробуйте это ?
Интересно, что отправка пакетов все на 1 байт ниже максимального размера что -то изменит ?
SRP

К вашему сведению: загрузить через DFU (Maple_Loader v0.1, хост, от Словера) в Maplemini (разработчик 2.39.0) - Пакеты полезной нагрузки (1052bytes) с некоторым рукопожатием (только небольшая часть показанных данных, до конца нет аномалий, все чистые, только 2 необработанных пакета из ~ 60 во время фазы переключения/init):

Maplemini dfu bin загрузка.JPG (240.49 киб) просмотрено 328 раз

Ребята, со всеми ядрами в настоящее время есть тайм -аут TX, если хост не тянет пакеты так быстро, как MCU может отправить их.

Это одна из причин, по которой я изменил эскиз для тестирования PITO, чтобы отправить блоки, а не 1 байт, поэтому я делал большие транзакции, а не многие очень маленькие.

Я думаю, что для тестирования мы могли бы прокомментировать тайм -аут проверки на TX, поэтому мы знаем, что это не фактор, влияющий на какое -либо падение пакета.

РЕДАКТИРОВАТЬ:
Я также подтвердил, что общий код RX будет сбрасывать байты, если эскиз не будет читать их как та же скорость, что и хост отправляет. Он признает каждый пакет обратно к хосту, несмотря ни на что.

Легкий тест:
Откройте порт сериалом.начинать();
Тогда Loop никогда не читая из порта.
Затем отправьте от хоста в хост, хост никогда не будет блокировать, потому что MCU подтвердит все пакеты, даже если не читать их.

Вы также можете проверить, открыв порт с серийным.начинать().
Затем задерживайте достаточно долгое время.
Затем распечатайте то, что читается.
Затем с хоста отправьте все больше, чем общий размер буфера. Хозяин будет вести себя так, как будто все было отправлено, но MCU будет печатать только то, что подходит в размере буфера. Все остальное после этого было сброшено без знания хозяина.

Если вы пытаетесь отправить что -то большое, например, изображение, как можно быстрее, вполне вероятно, что вы потеряете данные, если вы наброски можете обработать его быстрее, чем хост может отправить.

С моей точки зрения это нежелательно, поскольку на хосте скорость последовательного порта не влияет на то, как быстро приложение будет пытаться отправить данные, либо вы реализуете некоторые изделия в свои приложения (в MCU и на компьютере), либо или или Вы никогда не знаете, когда буфер может быть заполнен и сбрасывает данные.

Edit2:
Я изменил код, чтобы вести себя как Libmaple F1, в котором, если буфер заполнен, он не подтвердит пакеты обратно на хост. Это в этой ветви. Синхронизируется с Даниэлем, кроме этих изменений.
https: // github.com/Victorpv/stm32generi ... имизации

Мне все еще нужно сделать дальнейший тест, чтобы подтвердить, что нигде нет коррупции с данными, но я подтвердил, что, если эскиз делает что -то, делая что -то, и не вытаскивает данные из буфера, он сделает паузу хоста, когда он будет заполнен, и возобновить, когда у него есть емкость.

TX: Что если сериал.Напишите (и друзья) проверят, не является ли хост, и это таймауты при возвращении 0 ??

[Пито - Сб 19 августа 2017 г. 18:32] - TX: Что если сериал.Напишите (и друзья) проверят, не является ли хост, и это таймауты при возвращении 0 ??

Вы имеете в виду без буферизации, даже если в буфере есть емкость?

Таким образом, код TX в настоящее время должен ждать NAK, прежде чем получить больше данных из буфера TX и отправить его. И функция write (), как она записывает в буфер, а не USB Peripheral, вернется 0, если буфер будет заполнен, но не до этого момента.
Работает ли этот IR правильно, или период времени ожидания достаточно длинный, это готово для дебатов.
Я бы предпочел тайм -аут, который пропорционален тому, что приложение пытается отправить. Не то же самое ожидание буферного пространства на 1 байт, чем для 30 или 300.

С точки зрения пользователя я не вижу каких -либо буферов (внутренних в ядре STM или в хосте), и мне не волнует, какие буферы находятся внутри черного ящика (ES) ».

У меня есть хост, который может быть не в состоянии быстро (по любой причине).
Я делаю сериал.Что -то (1byte или 1kb или 1 МБ) из моего эскиза.

Когда сериал.что -то возвращает 0 или возвращает число, которое меньше, чем сумма, которую пользователь намеревался отправить, это означает, что для пользователя данные не были «получены» хостом (другая сторона не приняла их все или приняли только только часть этого).
Я - пользователь - мне нужно заботиться на уровне своего эскиза, что должно произойти в такой ситуации.
Таким образом, вы не можете потерять какие -либо данные TXED.

Представьте, что вы собираетесь загрузить изображение из вашего массива 100 КБ (массив в вашем эскизе, user_array) через USB -сериал на хост ПК. Он должен работать так, когда хост компьютера сможет получать, скажем, 1 кб в минуту через USB, вы загрузите этот user_array за 100 минут успешно на хост без каких -либо потерянных данных..

Но тогда у вас есть другие люди, думающие по -другому:
ViewTopic.PHP?F = 51&t = 2354&начало = 30#p33133

Как я это вижу, у нас есть два варианта:
1.- Гарантированная доставка с блокировкой.
2.- Не гарантированная доставка, после определенного тайм -аута не отправляет и не возвращает количество байтов, которые были успешно отправлены (или буферизации)

Но, похоже, мы не можем остановиться на одном из других.
Мой Opcion 2, и приложение проверить возвратное значение. Это будет напоминать то, что происходит с физическим USART. Код не будет блокировать и просто выводить данные по данной ставке.

Кроме того, в качестве более продвинутой функции мы могли бы использовать параметр бод, который мы в настоящее время игнорируем, чтобы управлять тайм -аутом.
Так что, если мы сделаем сериал.Начните (115200), тогда тайм -аут должен составлять около 70us за байт.
Таким образом, если у вас есть медленное приложение, в которое вам нужно отправлять не более быстрее, чем на 57 кбит / с, вы можете установить на это скорость передачи данных, и функция записи USB будет блокировать только для этого скорости и вернуться с номером байтов фактически отправлены, если это займет больше времени, чем это.

Seemy Post здесь: ViewTopic.PHP?f = 3&P = 33241#P33241

Сериал.Исторически что-то происходит из серийного коммуникации UART, подобного RS232, где рукопожатие с хозяином управляется RTS/CTS, DTR/DSR и т. Д., или через xon/xoff, или сделано на уровне приложения через Xyzmodem/Kermit и т. Д.
Без такого рукоятки это может прийти к потере данных с RX/TX. Но это рукопожатие обычно не используется с Duinos. Так серийный.что -то может потерять данные, когда внутренние кольцевые бакаферы заполняют или медленно читают их, или что -то в этом роде.

Serialusb использует сложный USB -протокол, который по своей природе включает в себя рукоятки. Итак, на уровне рук на «пакетах» есть уровень. Это необходимо использовать, а затем вы не можете «потерять» какую -либо информацию, пока RX/TX.
Люди могут обсудить, что должно произойти, когда мы используем USB -слой для «серийной» эмуляции - будем ли мы распространять RT/CTS или такие типы сигналов и т. Д. То, что я видел в различных дискуссиях по этой теме - даже они говорят, что USB CDC включает в себя такого рода флаги (команда out 0x22 (set_control_line_state) rts/dtr bits в cdc_acm) - это не обязательно с USB, как вы можете сказать другим сторона «Перестань посылать, я не могу читать новый пакет».

К вашему сведению: аналогичное обсуждение на форуме Pauls - .Sketch и Python Script для тестирования и мониторинга сериала CDC..
https: // форум.PJRC.com/threads/33167-us ... -обнаружение
Может, мы сможем как -то повторно использовать это.

О накинге в/из USB -пакетов:
http: // nuttx.org/doku.PHP?id = wiki: nxint ... SBOUT-NAK

К вашему сведению - вот как «Usblyzer» (не бесплатно, 33D Eval) показывает передачу между Mmini и Teraterm (Libmaple F1).
Usblyzer предоставляет огромное количество информации, поэтому мне пришлось отрезать только небольшую часть, которая подходит как привязанность.
Вы можете увидеть полезную нагрузку UUUU Данные фрагментированы на 1-16/414-426Bytes большие куски. Не знаю, что означает "4096 Buffer".
Транзакции отмечены успешными.

Usblyzer 3.JPG (136.28 киб) просмотрено 563 раза

@Pito, вы пробовали это с "замазкой" вместо Teraterm?

Pito Драйвер Windows определенно делает буферизацию на своем конце, так как объемный перевод только для 64 -битов, жестко кодируется в драйвере Libmaple.
Интересно, что 4096 - это некоторая информация, которую хост отправляет на доску, чтобы указать, сколько буферных пространств у него в настоящее время имеет.

@Rick: я попробовал с гиперподроналом (тот же результат - см. Выше) и с Minicom (Ubuntu в VirtualBox). С Minicom я не сделал никаких захватов.

@VICTOR: «Буфер 4096B» может быть некоторым неверным истолкованием данных USBLYZER или рукопожатие..
Обновление: кажется USBSER.SYS запросы 4 КБ объем в..

Сек. Числа всегда обращаются к пакетам, например, 128-127, где 127 был пакетом «4096B Buffer», чтобы это мог быть 128-й пакет, отвеченный на 127-й..

Что интересно, так это результат - размеры кусков полезной нагрузки - похожи на то, что я получил от Wireshark.
Он отправляет ~ 1 мс (период пакета) ~ 16 или ~ 420bytes ("случайный размер"). Это то, что нужно понять.

При выполнении серийного.Напишите ('u') в цикле, который вы заполняете в буферах быстро, поэтому я ожидаю, что исходящие пакеты полезной нагрузки всегда будут содержать количество Uuus, равное размеру самого низкого уровня слоя.

Обновление: Mmini Libmaple против Putty (Win7_64b) - те же результаты, что и выше, с Wireshark и Usblyzer.

Замазка.JPG (226.03 киб) просмотрено 525 раз

Это с Mmini, Libmaple F1, с этим модом vitor_boss из моего эскиза (сериал.написать (buf..): void loop() { uint32_t i; uint8_t x = 85; uint32_t elapsed = micros(); uint8_t buf[bufsize]; for (i = 0; i < bufsize; i++) { buf[i] = x; } elapsed = micros(); for (i = 0; i < TXCHARS; i+=bufsize) { Serial.write(buf, bufsize); } elapsed = micros() - elapsed;

Проблема: STM32GERIERIER с CDC_BUF 128 и BUFSIZE = 256 (скорость ???)
3 секунды между пакетами

STM32Generic CDC_BUFF 128 BUFSIZE 256.JPG (134.05 киб) просмотрено 488 раз

Почему вы отметили это как проблему? Проблема: STM32GERIERIER с CDC_BUF 128 и BUFSIZE = 256 (скорость ???)
3 секунды между пакетами

Из -за 3 секунды между пакетами, когда Bufsize в эскизе составляет 256 баллов (или 512, 1024 и т. Д.)..
Это даже видно в TT, поскольку куски 4 КБ всегда вздремните 3 секунды..

Другой тест - подсчет байтов - вошел в файл TT.
Чтобы сделать это просто, я txed 1.280.000 байтов #define bufsize 64 #define TXCHARS bufsize*20000

[Пито - Вторник 22 августа 2017 г. 16:48] - Libmaple F1, Bufsize 64 в эскизе, зарегистрировано 1.280.000 байтов -> ХОРОШО.

Моя проблема в том, что я делать Получите потери с помощью Libmaple Maple Mini Teraterm (4.95 (SVN# 6761) 31 мая 2017 г. 20:25:51) (Win10, USBSER.Sys 10.0.14393.0). Данные, полученные в файле журнала с 1272912 до 1279552.

Изменить: если я запускаю другую интенсивную программу процессора одновременно (https: // www.Мерсенн.орг/скачать/), проблема исчезает, и я получаю все данные из приведенного выше теста.

@Daniel: Интересно! Моя гипотеза: под управлением вышеуказанного теста (стресс -тест на процессор Mersenne) вы нагреваете внутреннюю температуру в своей коробке, такая ваша USB -подсистема работает лучше (то есть USB -часы??, напряжения??).

Используя этот код https: // Stackoverflow.com/a/6037377/834966, с большим `buffer [1024]`
* Оригинальный плотный цикл: все полученные данные
* `Sleep (10/100/1000)` В цикле: потеря того же Amout (!) данных. (Тайм -аут TX в коде Arduino прокомментируется, блокируя весь путь!)

Код из первого сообщения на 3 Tennsy 3.5 в Teraterm: потеря некоторых данных.

Я начинаю подозревать, что это USBSER.система. Есть ли альтернативные драйверы? Мне нужно будет запустить живой компакт -диск Linux на этой машине.

(Я также получаю проблему 128/256 буфера 3 секунды, но это будет что -то еще полностью.)

В дискуссии я видел, что они рекомендуют Winusb вместо USBSER.система..