Да, смотрел его. На мой взгляд его реализация немного геморройная — нужно мерять таймауты между символами, значит нужно кроме UART задействовать еще и таймер. А со стороны ПК вообще нет поддержки ни ModBus ни RS485. Поэтому применение — только в сети МК.
Именно, поэтому и работа в пакетном режиме должна быть аппаратной, раз такая возможность есть. Если бы был модуль, который реализует всю грязную работу по пакетному обмену — я бы им пользовался. Для CAN и USB это делается средствами периферии аппаратно.
Вообще я предвидел, что основной спор будет на тему — UART vs HID :) типа «чем вам не угодил простой UART».
Так вот — каждый пользуется тем, что ему больше нравится. Я люблю комфорт и функциональность. Всем, кому это интересно, я предложил попробовать с минимальными усилиями. Если вам не нужно — пользуйтесь UART
Пакета с конкретным ID да, но идентификаторов может быть сотни, на каждый тип используемого пакета. А можете задать пакет максимального используемого размера сделать поле с идентификатором своего типа пакета, который позволит рассматривать его как нужного формата структуру.
При использовании последовательного порта — сильно сложнее. Вообще говоря программа нелинейная, поэтому по приходу каждого байта нужно анализировать не только его, но и байты до него, уже находящиеся в буфере, а также вводить машину состояний — принимаем пакет, ждем пакет, ждем поле длины пакета, ждем контрольную сумму, ой, пропустили из-за того, что кабель выдрали и снова вставили или питание девайса моргнуло и теперь мы принимаем с середины пакета. Я в свое время занимался разработкой системы телеметрии и телеуправления Ташметрополитена и у меня было 13 географически распределенных стоек с оборудованием, связанных модемами USRCourier. Кабельные линиии были не лучшего качества, помехи, возможные потери байт, а тайминг на весь цикл опроса станций и ответа — не более 4с. Вместе с повторами.
Сейчас такое легко встречается при наличии помех по питанию, наводок от моторов рядом (управление станком ЧПУ, например) и т.п.
В академическом случае на столе все работает хорошо. Но протокол должен быть надежным и если часть этой работы можно выполнить аппаратно, лучше делать ее аппаратно. К тому же это проще и удобнее.
Кстати, комментарии для того и нужны, чтобы учиться друг у друга и обсуждать.
Если можете посоветовать набор библитек для пакетной связи через COM порт для Delphi + C/C++ на ПК + С/С++ на МК, чтобы обмен был бинарным, с задаваемым размером пакета и передать было достаточно указатель на буфер и размера буфера, остальное библиотека должна сделать сама. По приему пакета она должна вызвать мою функцию для обработки принятого пакета. Если будут функции, сигнализирующие об ошибках на линии — отлично.
Остаток совы за вас уже нарисован :) Так что осталось именно два кружочка нарисовать. Хотите разобраться во всем самостоятельно — вам не в статью для начинающих, но проект тоже может быть полезен для изучения.
Под потоковый обмен написано всего много, но почему то как доходит до дела, выясняется, что либо слишком тяжелая библиотека, либо не компилируется совместно с другим софтом, либо не умеет чего-то, либо работает без DMA, а надо с ним, либо неудобна в работе, либо лицензия не та. Проходили. В итоге все равно приходится изобретать велосипед. Каждый раз.
Нет, вы не понимаете. Речь вовсе не о том, что несколько устройств на одной шине.
Кроме того — текстовый протокол в обмене между устройствами я считаю глупостью. Я его все равно читать не буду, а для девайса экономнее и быстрее использовать двоичный протокол.
Большинство проектов для МК вообще не включают реализацию обработки строк. Если от устройства не требуется выводить текст для человека, то это лишний расход ОЗУ, flash памяти и процессорного времени.
К тому же алгоритм обработки текста всегда более неуклюж чем для бинарных данных.
Я никого не призываю поступать именно так. Нравится вам заниматься половину времени над проектом всякой посторонней работой, не влияющей на результат — на здоровье, пишите протоколы и обработку потоков.
Я их уже написал для себя, но все равно использовать не люблю — родная поддержка пакетного обмена куда как элегантнее. Точно так же как не люблю дрыганье ножками для реализации протоколов типа SPI, I2C, и программный UART. У них всегда есть неудобства и программные ограничения, которые рано или поздно вылезают боком.
VendorID нужен в любом случае, особенно если вы делаете коммерческое устройство. Но есть приличное количество VID и PID которые безопасно можно использовать. Главное, чтобы устройство с такими идентификаторами не было.
Выявление в потоке пакета — это дополнительная задача, требующая буферизации, выявления начала и конца пакета, проверки на целостность, введения доп. символов в поток для надежного определения заголовка. Все это надо программировать, это ест ОЗУ, ресурсы МК и время программиста. Если вы всего этого не делаете — обмен нельзя считать надежным. Пакетный обмен в USB все это делает прозрачно для программиста. Все данные уже разложены по нужны полям пакета, просто рассматриваешь полученный пакет как struct. Это ОЧЕНЬ удобно. При отправке то же самое — достаточно записать данные в поля структуры простым присваиванием и отправить буфер одной командой. Об остальном позаботится модуль USB. Причем буферы у него аппаратные.
Если вам это непонятно, то либо вы не делаете всего этого, что вообще-то странно, либо вам нравится каждый раз изобретать велосипед.
При работе с пакетами переменной длины в потоке нужно вводить какие-то идентификаторы длины пакета, выяснять считан ли весь пакет, не пропали ли байты и т.п.
При работе же с пакетами в USB достаточно определить какие поля нужны и какого размера. Это вся подготовка к работе.
Я не говорил, что COM порт хорош. я говорю о том, что у него много приверженцев. Ну нравится он людям, что тут поделать. Я не очень любли потоки. Предпочитаю пакеты. Но у меня для этого свои причны.
>3 метра или 5 метров — это локально или уже удалённо?
Тут все определяется стандартами. 5 метров для USB — допустимо, но кабель нужно очень качественный. Да и питание по нему подавать уже нежелательно. Вообще же граничные случаи на то и граничные, чтобы рассматривать их более внимательно и с учетом остальных факторов.
Виртуальный комп порт имеет недостаток — он работает в таком же пакетном режиме, а не в потоковом, как реальный COM порт, соответсвенно те же скорости и задержки. Но ко всему прочему потребует драйвер скорее всего. Под стандартный драйвер не видел реализаций.
На мой взгляд с HID работать гораздо приятнее и удобнее — никаких номеров портов, каждый девайс можно автоматически подцеплять при подключении к компу. Не нужно сканить порты на появление и исчезновение, не нужно пытаться аккуратно закрыть порт при отключении девайса. Можно подключать столько прог к одному девайсу, сколько нужно. Девайс сам поставляет данные по мере их наличия (прерываниями заниматся USB шина) а не приходится опрашивать по таймеру, в итоге получается, что софтина на ПК занята только обработкой полезных данных и ровно тогда, когда они появляются, а не по таймеру, пытаясь угадать как же часто нужно опрашивать устройство, чтобы скорость реакции была приличная и нагрузка не слишком возросла.
На мой взгляд для связи ПК-МК последовательный порт крайне редко бывает оправдан.
Поэтому я никак не могу понять этой инерции мышления — любой интерфейс превращать в убогую трубу с байтами, даже когда возможностей куда больше.
В данном примере вы ошибаетесь — наблюдая за тем, как каждый новый фотограф с примерно одинаковыми обработками фотографий приходит на форум и ждет одобрения и отзывов, посылает фотографии всем знакомым, я как раз задумывался о таком сервисе, но реализовать его был не в состоянии. А раз идея пришла больше чем в одну голову, значит в ней есть смысл, она не уникальна и спрос в воздухе витал, нужно его было просто увидеть. Другой дело, что частенько спроса и правда нет, а изобретатель думает, что это нужно всем, потому что просто нравится ему. Попытка экстраполировать свои желания на всех и реальное видение спроса — это разные вещи.
есть у меня такой. Еще не возился с ним. Но я говорю в статье об элегантном способе взаимодействия с ПК. Без дополнительных микросхем, конвертеров и лишних задержек. Максимально нативный интерфейс для современного компьютера. К тому же МК с поддержкой USB экстремально дешевы.
TCP/IP нельзя назвать ни простым ни дешевым ни быстрым протоколом. Особенно в вариации со всякими промежуточными конвертерами.
Для специфических случаев, когда нужно передавать данные удаленно — это то, что нужно. А при локальном подключении — удобнее USB. Никакой возни с сетевыми адресами, все прозрачно и автоматически. Для пользователя — жутко удобно. А для промышленного применения вообще лучше CAN. Но там без CAN трансивера не обойтись.
То, что он выводит список файлов в две панели не делает его альтернативой. У меня он установлен. По функционалу и удобству даже близко не сравним с TC. Это весьма простой файловый менеджер.
Меня вот уже несколько лет совершенно не интересуют ни железки ни операционки как таковые. Фокус сместился на их применение — если они дают что-то новое к моим увлечениям и интересам — хорошо. Нет — неинтересно. ОС как таковая ничего не дает. Это лишь платформа для софта. Хорошая платформа почти незаметна в работе. Плохая торчит из всех дыр арматурой.
Для меня идеалом была бы одна единственная универсальная операционная система из модулей — какие надо, такие включил.
Что касается вашего оптимизма — я рад за вас, но сильно сомневаюсь в том, что компании будут что-то делать из Linux, учитывая, что из собственного UNIX не смогли — HP UX, Solaris тому пример. У этих монстров другие задачи.
Я в целом считаю, что платное или бесплатное ПО разницы особой нет, важно, чтобы оно решало задачи. А для этого нужны талантливые программисты, объединенные общей задачей. в мире СПО чаще всего ситуация лебедя рака и щуки. Все делается долго, часто бросается посреди дороги, а если заинтересованных в результате не сотни тысяч, то шансов, что получится нужный продукт мало — только если автор в одиночку сделает.
От спектра лампы, конечно, зависит. Поэтому для слайд-проекторов используются специальные лампы, а не какие попало.
«Художника каждый может обидеть» :) На деле прикрывать безвкусие фразой «я так вижу» довольно модно. К сожалению, некоторое право на это они имеют — нет стандарта и параметров понятия «красиво» — оно сугубо субъективно. Ориентироваться на массы тоже смысла нет. Но вот халтуру от произведения искусства чаще всего отличить можно. Хоть и не всегда.
Во-первых, я говорил про фотографов без кавычек. Грамотных и технически в том числе. Фототехника — обязательный курс.
Картинка на пленке отличается цветопередачей. Например слайдовая пленка Fuji Velvia50 отличается значительно более широким цветовым охватом в красных цветах. Это заметно. Но только при просмотрел слайдов через проектор. При печати на бумагу или сканировании большая часть преимуществ бесследно исчезнет.
Шумы и прочее — дело вкуса. Сейчас модно искать себя и персонализировать все на свете. Когда больше нечем выделиться, начинают искать красоту шума и боке, которые есть всего лишь инструменты фотографа. Хотя основная красота вовсе не в них. Они могут лишь подчеркнуть и поставить нужный акцент, не более.
Вообще я предвидел, что основной спор будет на тему — UART vs HID :) типа «чем вам не угодил простой UART».
Так вот — каждый пользуется тем, что ему больше нравится. Я люблю комфорт и функциональность. Всем, кому это интересно, я предложил попробовать с минимальными усилиями. Если вам не нужно — пользуйтесь UART
При использовании последовательного порта — сильно сложнее. Вообще говоря программа нелинейная, поэтому по приходу каждого байта нужно анализировать не только его, но и байты до него, уже находящиеся в буфере, а также вводить машину состояний — принимаем пакет, ждем пакет, ждем поле длины пакета, ждем контрольную сумму, ой, пропустили из-за того, что кабель выдрали и снова вставили или питание девайса моргнуло и теперь мы принимаем с середины пакета. Я в свое время занимался разработкой системы телеметрии и телеуправления Ташметрополитена и у меня было 13 географически распределенных стоек с оборудованием, связанных модемами USRCourier. Кабельные линиии были не лучшего качества, помехи, возможные потери байт, а тайминг на весь цикл опроса станций и ответа — не более 4с. Вместе с повторами.
Сейчас такое легко встречается при наличии помех по питанию, наводок от моторов рядом (управление станком ЧПУ, например) и т.п.
В академическом случае на столе все работает хорошо. Но протокол должен быть надежным и если часть этой работы можно выполнить аппаратно, лучше делать ее аппаратно. К тому же это проще и удобнее.
Кстати, комментарии для того и нужны, чтобы учиться друг у друга и обсуждать.
Если можете посоветовать набор библитек для пакетной связи через COM порт для Delphi + C/C++ на ПК + С/С++ на МК, чтобы обмен был бинарным, с задаваемым размером пакета и передать было достаточно указатель на буфер и размера буфера, остальное библиотека должна сделать сама. По приему пакета она должна вызвать мою функцию для обработки принятого пакета. Если будут функции, сигнализирующие об ошибках на линии — отлично.
Под потоковый обмен написано всего много, но почему то как доходит до дела, выясняется, что либо слишком тяжелая библиотека, либо не компилируется совместно с другим софтом, либо не умеет чего-то, либо работает без DMA, а надо с ним, либо неудобна в работе, либо лицензия не та. Проходили. В итоге все равно приходится изобретать велосипед. Каждый раз.
Кроме того — текстовый протокол в обмене между устройствами я считаю глупостью. Я его все равно читать не буду, а для девайса экономнее и быстрее использовать двоичный протокол.
Большинство проектов для МК вообще не включают реализацию обработки строк. Если от устройства не требуется выводить текст для человека, то это лишний расход ОЗУ, flash памяти и процессорного времени.
К тому же алгоритм обработки текста всегда более неуклюж чем для бинарных данных.
Я никого не призываю поступать именно так. Нравится вам заниматься половину времени над проектом всякой посторонней работой, не влияющей на результат — на здоровье, пишите протоколы и обработку потоков.
Я их уже написал для себя, но все равно использовать не люблю — родная поддержка пакетного обмена куда как элегантнее. Точно так же как не люблю дрыганье ножками для реализации протоколов типа SPI, I2C, и программный UART. У них всегда есть неудобства и программные ограничения, которые рано или поздно вылезают боком.
Если вам это непонятно, то либо вы не делаете всего этого, что вообще-то странно, либо вам нравится каждый раз изобретать велосипед.
При работе с пакетами переменной длины в потоке нужно вводить какие-то идентификаторы длины пакета, выяснять считан ли весь пакет, не пропали ли байты и т.п.
При работе же с пакетами в USB достаточно определить какие поля нужны и какого размера. Это вся подготовка к работе.
>3 метра или 5 метров — это локально или уже удалённо?
Тут все определяется стандартами. 5 метров для USB — допустимо, но кабель нужно очень качественный. Да и питание по нему подавать уже нежелательно. Вообще же граничные случаи на то и граничные, чтобы рассматривать их более внимательно и с учетом остальных факторов.
На мой взгляд с HID работать гораздо приятнее и удобнее — никаких номеров портов, каждый девайс можно автоматически подцеплять при подключении к компу. Не нужно сканить порты на появление и исчезновение, не нужно пытаться аккуратно закрыть порт при отключении девайса. Можно подключать столько прог к одному девайсу, сколько нужно. Девайс сам поставляет данные по мере их наличия (прерываниями заниматся USB шина) а не приходится опрашивать по таймеру, в итоге получается, что софтина на ПК занята только обработкой полезных данных и ровно тогда, когда они появляются, а не по таймеру, пытаясь угадать как же часто нужно опрашивать устройство, чтобы скорость реакции была приличная и нагрузка не слишком возросла.
На мой взгляд для связи ПК-МК последовательный порт крайне редко бывает оправдан.
Поэтому я никак не могу понять этой инерции мышления — любой интерфейс превращать в убогую трубу с байтами, даже когда возможностей куда больше.
TCP/IP нельзя назвать ни простым ни дешевым ни быстрым протоколом. Особенно в вариации со всякими промежуточными конвертерами.
Для специфических случаев, когда нужно передавать данные удаленно — это то, что нужно. А при локальном подключении — удобнее USB. Никакой возни с сетевыми адресами, все прозрачно и автоматически. Для пользователя — жутко удобно. А для промышленного применения вообще лучше CAN. Но там без CAN трансивера не обойтись.
Надеюсь будет полезна.
Для меня идеалом была бы одна единственная универсальная операционная система из модулей — какие надо, такие включил.
Что касается вашего оптимизма — я рад за вас, но сильно сомневаюсь в том, что компании будут что-то делать из Linux, учитывая, что из собственного UNIX не смогли — HP UX, Solaris тому пример. У этих монстров другие задачи.
Я в целом считаю, что платное или бесплатное ПО разницы особой нет, важно, чтобы оно решало задачи. А для этого нужны талантливые программисты, объединенные общей задачей. в мире СПО чаще всего ситуация лебедя рака и щуки. Все делается долго, часто бросается посреди дороги, а если заинтересованных в результате не сотни тысяч, то шансов, что получится нужный продукт мало — только если автор в одиночку сделает.
«Художника каждый может обидеть» :) На деле прикрывать безвкусие фразой «я так вижу» довольно модно. К сожалению, некоторое право на это они имеют — нет стандарта и параметров понятия «красиво» — оно сугубо субъективно. Ориентироваться на массы тоже смысла нет. Но вот халтуру от произведения искусства чаще всего отличить можно. Хоть и не всегда.
Картинка на пленке отличается цветопередачей. Например слайдовая пленка Fuji Velvia50 отличается значительно более широким цветовым охватом в красных цветах. Это заметно. Но только при просмотрел слайдов через проектор. При печати на бумагу или сканировании большая часть преимуществ бесследно исчезнет.
Шумы и прочее — дело вкуса. Сейчас модно искать себя и персонализировать все на свете. Когда больше нечем выделиться, начинают искать красоту шума и боке, которые есть всего лишь инструменты фотографа. Хотя основная красота вовсе не в них. Они могут лишь подчеркнуть и поставить нужный акцент, не более.