Комментарии 36
простого и законченного решения в сети я так и не нашёл. Под простым и законченным решением я подразумеваю дуэт микроконтроллера (далее МК) с компьютером (далее ПК)
Да неужели? Во всем интернете не нашлось информации как работать с COM-портом (ПК) и UART (МК)?
Лучше бы конечно автору написать причины, почему он решил работать с морально устаревшим МК, когда на рынке есть куда более современные и дешевые (даже не смотря на ковид) и доступные кристаллы, с куда более простой возможностью реализации USB VCP.
А так, AVR очень приятные контроллеры. :) Я их тоже очень люблю.
Все верно, за исключением одного - я прекрасно понимаю, что мир обо всем уже давно знает, и моя задача была не в открытии Америки, а резюмировать изученное и поделиться опытом с такими же новичками, как я :) А контроллер я выбрал этот только потому, что он использовался в катушке тесла и я с ним знаком.
Так если мир знает уже, может стоило более лучше гуглить? Я когда писал свою программу для управления ардуинкой с компа, почему-то за час нашёл и как передавать в порт команды и как получать и как прошивать ардуино прямо через ПО. Как говорится, было бы желание и голова на плечах, а заново изобретать колесо и переоткрывать америку, ну так себе занятие.
Почему никто никогда в таких руководствах не добавляет контрольную сумму? Где гарантия что последовательность байт не пришла искаженной? Особенно при использовании дешевых преобразователей. А контроль длинны сообщения? А проверку, что оба девайса на линии не начали передавать одновременно?
Берём at-протокол. Тоже самое. Нет контрольной суммы. Тот же вопрос…
с одной стороны - внутри чипа нет смысла, с другой - протокол асинхронный
А коллизии быть не должно по причине разных линий tx/rx
ps на RS485 у меня всё есть)
Пишу комменты с перерывах с кодом. Кто-то наоборот максимально сосредоточен - это не я. Сколько раз таким образом смотрел на ошибку в упор. А вот если сгонять в творческую командировку на кухню или в окно тлен браузера, то внезапно можно что то обнаружить)
Это к тому, что каждый раз порываюсь в любом комменте развернуть switch/case на все случаи, но понимаю, что всё равно ровно же столько раз всё равно предложат описанное:)
так что да)
Если переходник usb-uart стоит рядом с МК, то на помехи на линию как правило можно смело забить. Внешняя линия там USB и там контроль целостности данных есть из коробки прозрачно для пользовательских данных.
Что вы хотите от человека который впервые прикрутил МК к компу через uart?
Автору, если чуть умерить пыл, можно было обойтись режимом HID. Наверняка в сети полно примеров под нужный МК. Возможно даже от микрочипа.
Почему никто никогда в таких руководствах не добавляет контрольную сумму? Где гарантия что последовательность байт не пришла искаженной? Особенно при использовании дешевых преобразователей. А контроль длинны сообщения?
Для начинающих типичная ошибка :) Кстати можно автора отправить почитать про nmea 0183 например.
А проверку, что оба девайса на линии не начали передавать одновременно?
Это ж 232, он дуплексный, ничего страшного не произойдет.
Да, контрольную сумму я обязательно добавлю, и не только её. Это ведь только заготовка проекта. Спасибо за обратную связь.
Тут в комментариях правильно ответили, что у UART есть бит чётности (опциональный) и контроль фрейма по старт и стоп битам, а в протоколе USB есть своя контрольная сумма. Однако на самом деле контрольная сумма в устройствах с таким UART<->USB интерфейсом не нужна потому, что шина данных от МК до преобразователя UART-USB находится внутри устройства, её параметры хорошо контролируется схемотехнически и она достаточно коротка для того, чтобы на неё что-то навелось. Если на этой шине вдруг возникают ошибки, то решать это надо не контрольной суммой, а переделкой схемотехники.
swprintf(portName, sizeof(portName)>>1, L«COM%d», comnum);
COM-порт с номером от 10 адресуется иначе. А именно,"\\\\.\\COM%d" вместо «COM%d».
нужны PID (Product ID) и VID (Vendor ID), за которые сегодня надо заплатить, на секундочку, 3500$
А вы возьмите для своего устройства такие идентификаторы:
VENDOR_ID 0x0c45
PRODUCT_ID 0x7401
Они соответствуют тепловизору Flir One Gen 2. И к компьютеру его, обычно, не подключают (официально — точно нет, поэтому драйвер от производителя никогда не появится в Windows или Linux). Правда, тут появится проблемы накатать драйвер и подписать его. Но, возможно, у вас получится. :)
Потом это прочтет ушлый теле-журналюга и возникнет очередная сесация про российских детей сделавших изобретение века. 🙁
Предвидя вопрос типа «В чём смысл этого топика?», отвечу, что простого и законченного решения в сети я так и не нашёл. Под простым и законченным решением я подразумеваю дуэт микроконтроллера (далее МК) с компьютером (далее ПК) и заготовки кода с функцией автоматического коннекта, а также мега-функцией «поморгать светодиодом».Так в чем смысл топика-то? Информации по подключению контроллера к компьютеру море. Хоть по устаревшему LPT-порту, хоть по чуть менее замшелому COM, хоть по современному USB. Даже по bluetooth, ethernet, wifi народ подключает.
Собственно сам МК (я взял Atmega328, т. к. она используется в моём проекте).Вот с этого стоило начать, потому что я долго пытался угадать что же за контроллер вы изучаете и какой же извращенный способ подключения реализуете (потому что обычные проблем не представляют, см.выше).
микросхема по кличке CP2102Классическое решение, но о проблемах предупредить стоит. Это только переходник USB-UART, соответственно ничего кроме COM-порта вы не получите. Ни аудиоканала, ни HID. Невозможно (в некоторых переходниках таки возможно, но не очень-то поможет) настроить VID:PID, manufacturer/product/serial. То есть если у вас несколько таких переходников, друг от друга вы их программно не отличите.
Возьму библиотеки типа V-USB и libusb, подключу МК напрямую к USB-разъему, быстренько найду готовый пример кода и будет мне счастье. Но «быстренько» не получилось. Оказывается, там много заморочек — например, дополнительная библиотека кушает ресурсы МК, а моя прошивка предполагается довольно ёмкой.vusb занимает всего около 2 кБ флеша. У вас ATmega328 — целых 32кБ! Я бы еще понял если бы не хватало скорости, софтовый USB действительно здорово нагружает ядро. Но только пока идет передача. Если вам надо поменять какую-то настройку примерно раз в вечность, средняя нагрузка будет совсем незначительной. Зато можно изобразить не COM-порт, а HID-устройство, то есть однозначно себя идентифицировать по VID, PID, manufacturer, product, serial и в некоторых случаях даже вывести эти самые manufacturer, product в список оборудования.
BYTE byteReceive() //Ждет и возвращает данные от хоста
{
while (!(UCSR0A & (1 << RXC0)));
return UDR0;
}
Так делать не стоит. А вдруг провод выскочит или переходник сломается? Так и будете висеть в ожидании. Работать с UART стоит по прерываниям или хотя бы по методу опроса.
if(UCSR0A & (1<RXC0)){/*читаем UDR0, обрабатываем и т.д.*/}else{/*ничего не пришло, выполняем основной код*/}Рабочая частота МК подойдет не абы какая, а та, что задал автор библиотеки.Вы хоть видели список доступных частот? 12, 12.8, 15, 16, 16.5, 18 и 20 МГц. Вы от чего вообще тактируетесь, что ничего из этого не подходит?
для моего устройства нужны PID (Product ID) и VID (Vendor ID)Если вы собираете устройство со стандартным функционалом (COM-порты, аудио, HID и т.п.), то есть не пытаетесь обрабатывать низкоуровневые запросы, то можно взять VID:PID от чужого устройства с более-менее похожим. Я обычно пользуюсь парой от vusb (16C0:05DF).
Задача VID:PID в том чтобы производитель железа мог реализовать любой извращенный алгоритм, не вписывающийся в стандарты USB, написать под него драйвер и потом применять его к любому устройству с данной парой VID:PID. Ну и прописать свои инициалы в системе. Мол все, что с этой парой идентификаторов — МОЁ.
Это действительно больная тема, была для меня 10 лет назад)
Создать с нуля систему мк - порт связи - комп действительно сложно, а готового решения из коробочки не найти, в лучшем случае можно приспособить под себя чтото похожее.
Я когда начинал изучать мк, остановился на примере бутлоадера - по сути взял готовый протокол с контрольной суммой, автоопределения скорости и командами чтения/записи ром и епром. Добавил команды работы с рам и вобщемто довольно неплохо получилось. Работает всё такжэ как у автора через усб-уарт и блютуз-уарт, поддерживается много контроллерная система по RS422. Всё работает в полудуплексном режиме, с компа запрос, с мк ответ. Единственно что познее добавил широковещательную команду синхронизацыи времени RTC, на нее никто не отвечает.
С начала работал в терминале и он долгое время оставался запасным вариантом при отладке. С програмкой на комп всё было сложнее, помог колега, какраз разрабатывая по для стенда. Рисование графиков для переменных я уже потом сам добавил поискав примеры в тырнете.
В интернете можно найти всего около 100500 примеров подключения атмег к компьютеру - катастрофически мало. И Вы решили добавить еще один :)
Последний пункт я не стал раскрывать в рамках этой статьи, потому что бесконечную простыню текста и картинок читать утомительно. Оставлю материал для будущей статьи, если тема окажется интересной.
Вот тут интрига. Обычно "драйвер" для такого преобразователя представляет из себя просто .inf-файл.
Можно установить девайсу PID/VID стандартного USB-COM, тогда в системе он и будет виден как стандартный, и драйвера винда подтянет стандартные.
Можно установить девайсу PID/VID от какого-нить существующего USB-COM устройства и установить соответствующий драйвер, тогда в системе девайс будет виден как это устройство.
Можно установить девайсу свои наобум взятые PID/VID, взять .inf от какого-то существующего USB-COM устройства, заменить в нем PID/VID на те, что установили девайсу (заменив заодно и описание на свое), и установить этот .inf как драйвер. Тогда в системе девайс будет виден под своим именем. Но тогда встанет проблема с тем, что драйвер не подписан и винда откажется устанавливать его без бубна.
Неужели есть еще какой-то способ?
Вот тут интрига. Обычно «драйвер» для такого преобразователя представляет из себя просто .inf-файл.
Можно установить девайсу свои наобум взятые PID/VID, взять .inf от какого-то существующего USB-COM устройства, заменить в нем PID/VID на те, что установили девайсу (заменив заодно и описание на свое), и установить этот .inf как драйвер. Тогда в системе девайс будет виден под своим именем. Но тогда встанет проблема с тем, что драйвер не подписан и винда откажется устанавливать его без бубна.
inf-файл — это не драйвер. Драйвер это набор устанавливаемых в систему dll, которые указаны в inf-файле. И вот эти-то dll написать не так уж просто.
Про написание собственных бинарников драйверов и их подписание я даже не заикаюсь, такой уровень сложности автору явно не по плечу, поэтому вряд ли он имел в виду этот путь.
Но некоторым устройствам достаточно только этого файла,
Так это когда в системе уже есть драйвер нужного класса устройств.
и их подписание
Но, к слову, в XP подписание не требуется. А в системах выше его можно обойти. :)
написание собственных бинарников драйверов
Кстати, в DDK есть примеры готовых драйверов для разных устройств. Весьма вероятно что автору подойдёт что-то готовое с незначительной модификацией.
Так это когда в системе уже есть драйвер нужного класса устройств.
Стандартный usbcom.sys есть в стандартном комплекте винды еще с версии XP точно, а может и раньше :)
Но, к слову, в XP подписание не требуется.
Не буду утверждать точно, но по-моему требуется, по крайней мере в SP3. Но там это достаточно просто отключить. В семерке - уже сложнее, в десятке - надо быть продвинутым пользователем :) Я со своими девайсами пошел изначально по этому пути еще когда XP был самым распространенным. С появлением семерки пользователи уровня "Я тут нажал кнопку и выскочило какое-то окошко" уже начали остро чувствовать эту проблему. А с появлением десятки я взял себя в руки и переделал все на HID - и никаких проблем даже с самыми "тук-тук-войдите" пользователями :)
Кстати, в DDK есть примеры готовых драйверов для разных устройств. Весьма вероятно что автору подойдёт что-то готовое с незначительной модификацией.
Установить и настроить DDK - тот еще квест сам по себе, и все равно придется подписывать полученный драйвер :)
Не буду утверждать точно, но по-моему требуется, по крайней мере в SP3.
Не требуется и в SP3. :)
Установить и настроить DDK — тот еще квест сам по себе, и все равно придется подписывать полученный драйвер :)
Я бы так не сказал. Ставится DDK очень просто. А вот разобраться в примерах — вот будет квест. :) Ну а подпись… ну что ж делать…
Статья хорошая, не реклама чужого... Автор показал свой уровень и понятным языком дал вход в тему.
Вы хоть видели список доступных частот? 12, 12.8, 15, 16, 16.5, 18 и 20 МГц. Вы от чего вообще тактируетесь, что ничего из этого не подходит?
By default, the Internal RC Oscillator provides an 8.0MHz clock. Though voltage and temperature dependent, this clock can be very accurately calibrated by the user.
Не предмет статьи. 99% примеров в сети на 8 мнz. Можно и здесь провести испытания, только зачем?
А еще есть преобразователи Ethernet-RS232 или Ethernet-RS485. Мне кажется с ними было бы интереснее, проще, надежнее может быть. Но это несколько дороже
Берём stm и собираем проект VirtualComPort. Устанавливаем свои VID, PID и имя устройства. Теперь в программе с ПК можно опрашивать устройства и подключаться только к тем чьи VID, PID и имена совпадают с нужными.
Если вы пишете программу, взаимодействующую с устройством, не обязательно реализовывать usb-cdc, можно собрать хоть кастомное устройство и напрямую слать пакеты в конечные точки.
Если же вы делаете именно CDC, то, скорее всего, чтобы с ним могла взаимодействовать не только специальная программа, но и какие-то другие.
Еще интереснее когда устройство составное и прикидывается несколькими COM-портами.
В таком случае идентификация по VID:PID не работает. Проще прописать строковые идентификаторы manufacturer, product и отдельных интерфейсов. Например, в одном из моих устройств реализованы CDC интерфейсы с именами "DBG", "STFLASH" и "LOG" — при желании можно догадаться для чего они нужны. Так вот, чтобы не путаться между кучей одинаковых COM-портов, достаточно написать три строчки в конфиге (если кому интересно, они есть по ссылке), и отображение меняется на /dev/tty_DBG_0, /dev/tty_STFLASH_0 и /dev/tty_LOG_0. А уже их можно скармливать хоть самописной проге, хоть stm32flash, хоть screen или другому эмулятору терминала. Более старая поделка, на основе CustomHID. Чтобы ее отличать от подобных, воспользовался строками manufacturer и product. Правда, есть побочный эффект: программа, предназначенная для взаимодействия с ним, начинает замусоривать лог wireshark другого vusb устройства запросами этих строк.
В общем, в дескрипторах USB есть гораздо более гибкие способы идентификации, чем просто VID:PID.
Ну так напишите в корневой ветке свою вариацию видения и развития проекта. Мне зачем это? Я коротко написал и подсказал автору как я реализую подобные связки. У меня всё работает. Клиенты довольны.
Я не понимаю зачем нужно использовать устройство с другими программами, если оно разрабатывалось как уникальное и должно работать только с определённой, такой же как оно уникальной программой.
Посмотрел Вашу статью про программатор и хочу сказать что можно было сделать всё гораздо проще, чем вы описали. Эта информация не в тему здесь, но на Вашем сайте нет возможности оставить комментарий.
Здесь далеко не самое активное обсуждение, заинтересованный человек вполне прочитает все комментарии.
Посмотрел Вашу статью про программатор и хочу сказать что можно было сделать всё гораздо проще, чем вы описали. Эта информация не в тему здесь, но на Вашем сайте нет возможности оставить комментарий.
Если действительно хотите помочь, можно написать здесь в личку.
github pages, где расположена та статья, насколько я понимаю, все же не предназначены для создания форумов или обсуждений. А может, это я с ним не разобрался.
Микроконтроллер + компьютер + своё программное обеспечение