Easyelectronics.ru

В одну или более. Правильное утверждение: если количество данных кратно размеру endpoint. И еще раз, не всем CDC драйверам нужен ZLP. Но по стандарту от должен быть даже в CDC ACM.

Eddy_Em, и как это понимание на хосте технически-то происходит? )

r2axz, а чем и как ты тестировал свою прошивку?

На всяких терминалах на Win, OS X, Linux, на передачу файлов на больших скоростях, еще с помощью Com Port Stress Test (хотя он и устарел малость), самописными скриптами на питоне. Смотрел обмен по USB. Смотрел чтобы notifications были правильными и ПО реагировало на изменение управляющих сигналов. В-общем, частично вручную, частично самописными тулами. Все как всегда.

Скорость сброса TXA измерял осциллографом.

Все очень просто: куча кэшей на разном уровне. Ядро вычитывает данные с USB и складывает в свой кэш. Если ты захочешь считать эти данные, ядро их тебе отдаст. Если не успел до переполнения буфера — буфер будет очищен (и об этом ты никогда не узнаешь) и станет заполняться заново. Обычно если открываешь устройство, которое давно работало, стоит сначала считать все содержимое этого буфера — там наверняка остался какой-то мусор.
Если пользоваться не операциями read/write, а прослойкой в виде stdio, то получится еще одна буферная зона.
P.S. А я когда CDC отлаживал, подключил к USART'у преобразователь USB<>serial и гонял на разных скоростях
И, кстати, вот не вспомню уже, но то ли с PL2303, то ли с CH340 наткнулся на проблемы со скоростью в три мегабита. Сначала пытался у себя баг найти, но потом оказалось, что сам преобразователь не тянул такие скорости…
Но фактически мне нафиг не нужен классический CDC: мне просто нужно "общение" МК с компьютером, и лучше, чем эмуляция PL2303, я ничего не придумал (крайне удобно для отладки: вообще ничего не нужно, кроме cat/echo, но я самопальный терминал написал, т.к. не нравится мне screen)!

А не пробовал со своими cdc эту прослойку в виде stdio? )

Я не понимаю смысла этого вопроса. Лично я нет, я не писал тесты на C которые использовали именно stdio. Почему? Да просто потому, что если все нормально работает с read/write, то и с stdio тоже будет прекрасно работать. Это всего лишь обёртка, ей сто лет и она отлажена уже донельзя.

Присоединяюсь к непониманию.
И да, если что, стандартный cat использует stdio и буферизует выводимые данные построчно! Так что, когда я делаю в скрипте

, то фактически работаю через stdio. И да, в некоторых моих утилитах тоже буферизую (чтобы поиском '\n' занималась stdio, а не я), читая при помощи getline и записывая при помощи printf.

r2axz, ладно пусть будет питон, на котором ты писал какие-то тесты
Типовой сценарий работы с ком портом - комп делает запрос девайсу и получает ответ
В питоне это write и read, read блокирующий с таймаутом если я правильно помню
Как это сделать если мк отправляет данные сразу сколько есть?

Да не делает компьютер никакого запроса: просто шлет себе IN пакеты, в надежде, что что-то в ответ придет...
Как пришло что-то, оно буферизуется, а там уж — может клиент это считает, а может, буфер просто уйдет в /dev/null...

Eddy_Em вам прекрасно ответил на ваш вопрос. Действительно, "лишние" данные сохраняются драйвером в буфера до тех пор, пока там есть место. Когда место кончается, драйвер может поступить по-разному в зависимости от реализации: может дропнуть буфер, а может просто перестать забирать данные из USB устройства, тогда оно дропнет в какой-то момент свой буфер. read никогда не вернет вам данных больше, чем вы попросили. Все, что вы не вычитаете, операционная система будет пытаться буферезировать сколько сможет. Это если не применяется flow control. А вот при использовании flow control, может быть совсем другая история: при критическом заполнении буферов можно опустить условный RTS и притормозить передачу с удаленной стороны. Тогда данные теряться не будут. Но только буферизация и несоответствие между длиной переданной read и размерами обмена между USB устройством и драйвером все равно остаются. Это не связанные вещи просто.

Данные становятся доступны для read/write только после окончания usb транзакции
В этом отличие виртуальных ком портов от настоящих, где сразу доступен каждый пришедший байтик
Драйвер cdc постоянно опрашивает in endpoint, и окончание транзакций практически всегда фиксируется из-за того что байтиков оказывается меньше размера endpoint
Всё становится похожим на настоящий ком порт, но это плохо на самом деле для приложений на пк, которые должны дёргаться на каждое такое событие

Отличная работа! Огромное спасибо автору проекта.
Недавно понадобилось логировать обмен на UART интерфейсе одного устройства, т.е. понадобилось два USB-UART адаптера одновременно.
Прошил плату BluePill прошивкой автора, установил драйвер (Win7 x64), запустил терминал. Всё работает отлично.
Кстати, на моей плате для энумерации USB установлен резистор 10 кОм, но несмотря на это всё работает. Позже заменю резистор на 1,5 кОм.

Спасибо, рад что пригодилось :)


Да, некоторым хостам по-барабану какой там резистор. Но некоторым другим - нет. Если под рукой таких неработающих хостов нет и нет планов втыкать устройство в рандомные компьютеры, то можно и не перепаивать. На работоспособность оно не влияет. Если определилось - дальше все будет хорошо.

Оформил в виде готового устройства:
-прикрутил светодиодную индикацию,
-добавил выбор напряжения логических уровней UART,
-добавил ESD защиту,
-состряпал платку вместо BluePill,
-запихнул в корпус.
Задействовал только линии RX/TX, т.к. остальные мне не понадобились.
Ссылка на статью

Попросил у ТС в личке продать одно устройство, вдруг лишнее окажется (бывает). Вот что ответил автор:
"Лишнего устройства нет, да и аккуратная сборка такого девайса занимает не один день...
В качестве альтернативы:
Если у жителей форума будет интерес к устройству, то возможно соберу складчину - скинемся всем форумом на платы, я закажу десяток штук, и потом разошлю участвующим."
Может быть кроме меня найдутся еще желающие приобрести устройство?
P.S. Плата это конечно хорошо, но я бы предпочел напаянный и прошитый МК на плате. Зрение уже не то, а STM мимо меня прошли...

"ТС" - наверное, в этой теме - я, а вот платы сделал уважаемый Zlodey, а я к ним никакого отношения не имею, но всячески одобряю их появление и вообще был приятно удивлен и обрадован.

Это я к тому, чтобы по поводу плат случайно ко мне не стали обращаться :) Платы - это не ко мне)

О, прошу прощения, ошибся. Конечно же речь шла о участнике форума с ником Zlodey.

Пожалуй надо заморочится и сделать универсальный девайс для снифа Modbus ^)

Зачем? Это говно только совсем невменяемые используют. Ему ж сто лет в обед!!! Отстойней модбаса трудно что-нибудь придумать... Разве что CANopen.

Это не ошибка? FlashMagic вроде ж только с NXP работает.

Промышленность во всём мире невменяемая.

Вот именно. Проверен временем на простоту, удобство и надёжность. Все его знают, поддерживают.

Ну так придумай! Документируй, напиши ОРС-серверы, библиотеки, эмуляторы, всё протестируй и отдай бесплатно.

Зачем его снифить? Есть немало утилит, показывающих "сырые" уходящие и приходящие данные. Не вижу смысла в таком девайсе.

Все уже придумано до нас! С CAN-шиной очень удобно работать. У меня на гитхабе найдешь исходники. Главное - не опускаться до идиотского canopen, и будет хорошо!

CANopen поддерживается многими производителями. Есть несколько бесплатных реализаций с необходимыми утилитами.
Если мне нужно работать, например, с датчиком по Модбас, то через пару щелчков мышкой он появится в ОРС-сервере, а значит и в любой СКАДА. С CANopen чуть больше щелчков. Со всеми самописными творениями для CAN ничего подобного не наблюдается. Вот ты, например, написал ОРС-сервер для своих девайсов, чтобы их можно было легко и быстро подключить к компу? А как ярый адепт Линукс передал в бесплатное пользование модуль для OpenSCADA.org? Нет? Тогда можешь плеваться и материться о Модбас сколько хочешь, но люди будут использовать его, а не твои девайсы потому, что кроме твоих программ с твоими девайсами никто не может работать также легко, как с девайсами, поддерживающими Модбас.

Нафиг мне эти ваши скады нужны? Они же в большинстве случаев анально огороженны, т.е. вообще не поддаются автоматизации!
Я сомневаюсь, что можно хотя бы по ssh подсоединиться к этому серваку и давать команды. А еще лучше - открыть сокет и читать/писать данные. С известным открытым протоколом!

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

Для работы с модбасом необходимо загрузить соответствующий модуль ядра, а потом уже писать свой софт аналогично разработке под RS-232 и любой другой последовательный порт.
Я бы не сказал, что это - легко. А учитывая то, какой тормозной это протокол, некоторые вещи вообще невозможно с модбасом делать (скажем, нужен тебе поток данных не меньше полумегабода, модбас так не умеет - из-за "железных" задержек).

P.S. Почитал я про этот OPC. Как и подозревал, это - почти полностью анально огороженная технология (более современные и открытые ответвления пока не популярны). В общем, совсем мимо!