Начиная с версии 1.10.5, программа FLProg позволяет объединять несколько плат Arduino в кольцевую UART сеть. Сначала рассмотрим, как это происходит. Платы соединяются между собой в соответствии со схемой, изображённой на заглавной иллюстрации. Предположим, что плата 1 отсылает через UART пакет данных содержащий идентификаторы платы, переменной, а так же значение переменной. Плата 2 принимает данный пакет и если данные из этой переменной ей не нужны, то просто отправляет этот пакет дальше. Если в соответствии с программой значение данной переменной необходимо контроллеру, то значение из пакета копируется во внутреннюю переменную, и пакет так же отправляется дальше по кольцу.
Когда таким образом пакет, пройдя всё кольцо, вернётся к плате, отправившей его, передача пакета прекратится.
Таким образом, данные из пакета доступны любой плате подключённой к кольцу, и инициатором отправки пакета так же может быть любая из плат.
Схема тестового стенда:
Логика работы следующая:
- Arduino №1 получает данные о температуре и влажности c датчиков.
- Arduino №2 отображает температуру с датчика DS18B20.
- Arduino №3 отображает температуру и влажность с датчика DHT-22.
Что бы избежать гневных комментариев о том, что такая логика не нужна и является бредом, уточню, что данный проект чисто учебный и предназначен для объяснения принципов передачи данных через информационное кольцо. Для этого внесём еще немного бреда в логику работы.
- Цифровое значение температуры от датчика DS18B20 ловит Arduino№3, затем преобразует его в строку и отправляет в кольцо. Эту строку ловит Arduino№2 и отображает на дисплее.
- Цифровое значение температуры от датчика DHT-22 ловит Arduino№2, затем преобразует его в строку и отправляет в кольцо. Эту строку ловит Arduino№3 и отображает на дисплее.
- Цифровое значение влажности от датчика DHT-22 ловит Arduino№3, затем преобразует его в строку и отображает на дисплее.
Итак, начнём.
Открываем программу FLProg и создаём проект для Arduino№1. На первую плату кидаем блок сканирования шины OneWire (библиотека элементов, папка «Разное»). Этот блок по переднему фронту на входе En производит сканирование шины OneWire и при нахождении на них датчиков складывает обнаруженные адреса в привязанные массивы. Для параметрирования блока вызываем редактор блока (двойной клик на блоке).
- Сначала создаём новую шину OneWire.
- Затем создаём массив. Поскольку датчик у нас на шине планируется один, создаём один массив.
Теперь организуем схему запуска этого блока один раз при старте программы. Для этого соберём такую схему.
R – Триггер находится в папке «Триггеры» библиотеки элементов. Он служит для выделения переднего фронта импульса подаваемого на вход. На его выходе будет импульс длительностью один цикл программе при переходе уровня на входе от низкого к высокому.
Затем создаём новую плату и перетаскиваем на неё датчик температуры DS18x2x (библиотека элементов, папка «Датчики»). Вызываем редактор блока и параметрируем датчик.
- Из выпадающего списка выбираем ранее созданную шину OneWire на пине 4
- Выбираем режим задания адреса «Массив»
- Выбираем ранее созданный массив «Датчик»
- Выставляем периодический режим опроса датчика, с частотой опроса раз в 1 сек.
Теперь полученное с датчика значение необходимо отправить в кольцо.
В программе FLProg подключить контроллер к кольцу можно двумя способами. В данном проекте для Arduino№1 рассмотрим первый способ – через блоки отправки переменной в кольцо.
Вытащим на плату блок «Отправка переменной в кольцо» (библиотека элементов, папка UART), и вызовем для него редактор блока.
- Сначала добавляем контроллер к кольцу.
В открывшемся окне необходимо выбрать порт подключения к кольцу, скорость порта, и задать имя устройства в кольце. Так же для удобства работы с проектом желательно создать файл списка переменных кольца, через который будут синхронизироваться все контроллеры, участвующие в нём.
- Затем создаем переменную, которая будет передаваться в кольцо
В окне создания переменной необходимо задать имя переменной и её тип.
- После этого задаём периодический режим отправки переменной, с периодом в 1 сек.
После параметрирования блока соединяем блоки датчика и отправки между собой и устанавливаем на входе En блока отправки переменной константу true.
Создаём новую плату и перетаскиваем на неё датчик DHT-22 (библиотека элементов, папка «Датчики»). Вызываем редактор блока и параметрируем датчик.
- Выбираем пин подключения датчика
- Выбираем тип датчика
- Задаём наличие выходов температуры и влажности
- Задаём периодический способ опроса датчика с периодичностью в 1 секунду
Затем перетащим на третью плату два блока отправки переменной в кольцо, в настройках блоков выберем существующее кольцо, и создадим в каждом из них по переменной.
Поле чего соединим блоки между собой, и поставим константы true на входы En блоков отправки переменных.
С проектом для Arduino№1 закончили. Должна получится такая схема:
Теперь создаём новый проект для Arduino№2.
Сразу подключаем плату к кольцу. Здесь воспользуемся вторым методом, через дерево проекта. Раскрываем дерево до ветки «Коммуникации» включительно и делаем клик правой кнопкой по пункту «Кольца». В появившемся контекстном меню выбираем пункт «Добавить кольцо».
Открывается уже известное нам окно параметров кольца. Нам опять необходимо ввести имя устройства в кольце и выбрать порт, через который устройство подключено к кольцу. Но теперь мы не создаем файл переменных кольца, а выбираем ранее созданный. При этом автоматически синхронизируются переменные между проектами.
Все параметры кольца можно изменить через дерево проекта, вызывая контекстное меню на соответствующих ветках.
Согласно алгоритму Arduino№2 ловит переменную о температуре от датчика DHT-22, превращает её значение в строку и отправляет в кольцо. Для этого перетащим на схему блок «Получение переменной из кольца» (библиотека элементов, папка «UART»)и вызовем для него редактор.
В редакторе выберем кольцо и соответствующую переменную.
Затем перетащим на схему блок «Преобразование строк» (библиотека элементов, папка «Конвертация типов») и соединим вход этого блока с выходом блока «Получение переменной из кольца»
После чего вызовем редактор для блока «Преобразование строк».
Поскольку на входе этого блока значение типа Float, у нас есть возможность задать количество знаков после запятой при преобразовании в строку. Я думаю, одного знака после запятой нам хватит.
Затем вытаскиваем на схему блок «Отправка переменной в кольцо» (библиотека элементов, папка UART), и помощью редактора выбираем кольцо, и создаем новую переменную, которая будет отправляться в кольцо. Так же выставляем периодический режим отправки, с периодом в 1 сек.
После чего соединяем блоки между собой и устанавливаем константу true на входе En блока отправки переменной.
Создадим новую плату и перетащим на неё блок «Получение переменной из кольца» (библиотека элементов, папка «UART»)и вызовем для него редактор. В редакторе выберем подключенное кольцо. Поскольку в соответствии с алгоритмом значение для отображения на дисплее нам готовит Arduino№3, создадим новую переменную, которую нам этот контроллер будет отправлять.
Теперь перетащим на схему блок «Дисплей на чипе HD44780» (библиотека элементов, папка «Дисплеи»), и вызовем для него редактор и запараметрируем его.
- Создадим новый дисплей
- Зададим подключение согласно схеме
- Зададим параметры дисплея
- Настроим отображение данных с входа блока
- Настроим отображение по центру первой строки
После этого соединим блоки и установив константу true на входе En блока дисплея.
С проектом для Arduino№2 закончили. Должна получится такая схема:
Создаем проект для Arduino№3.
Подключаем контроллер к кольцу любым из вышеуказанных способов. При подключении выбираем созданный ранее файл переменных кольца.
Согласно алгоритма, контроллер Arduino№3 ловит значение температуры с датчика DS18B20 от Arduino№1 и преобразует его в строку и отправляет эту строку в кольцо для Arduino№2. Все необходимые переменные для этого у нас уже существуют. Поэтому, аналогично Arduino№2. перетаскиваем на схему блоки «Получение переменной из кольца» (библиотека элементов, папка «UART»), «Преобразование строк» (библиотека элементов, папка «Конвертация типов») и блок «Отправка переменной в кольцо» (библиотека элементов, папка UART). После чего параметрируем их.
«Получение переменной из кольца»
«Преобразование строк»
«Отправка переменной в кольцо»
После этого собираем их в схему
Создаём новую плату для отображения температуры с датчика DHT-22. Так же аналогично Arduino№2 перетаскиваем «Получение переменной из кольца» (библиотека элементов, папка «UART») и «Дисплей на чипе HD44780» (библиотека элементов, папка «Дисплеи»). Параметрируем их.
«Получение переменной из кольца»
«Дисплей на чипе HD44780»
Соединяем между собой.
Создаём новую плату для отображения влажности.
Так же перетаскиваем на плату блок «Получение переменной из кольца» (библиотека элементов, папка «UART») и параметрируем.
Затем перетаскиваем блок «Преобразование строк» (библиотека элементов, папка «Конвертация типов»), соединяем его с блоком «Получение переменной из кольца» и то же параметрируем.
Ну и в последнюю очередь перетаскиваем блок «Дисплей на чипе HD44780» (библиотека элементов, папка «Дисплеи»). При параметрировании блока выбираем уже существующий дисплей и выводим значение влажности по центру второй строки.
Соединяем блоки между собой.
Создание программы для Arduino№3 законченно.
Конечный результат.
Спасибо за внимание.
Комментарии (46)
CrashLogger
09.03.2016 13:36+2Может быть полезно для распределенной сети контроллеров, каждый из которых работает со своими датчиками. Хотя и для этой цели на мой взгляд логичнее использовать I2C или SPI.
Camel
09.03.2016 13:44Аналог Token Ring, теперь на Arduino.
totuin
09.03.2016 13:52Если честно идея пришла из мира судовой навигации. Там оборудование где то похожим способом обменивается информацией по протоколу NMEA. В молодости работал с этим оборудованием.
stigory
10.03.2016 05:08А у меня создалось впечатление, что вы строите функционал, напоминающий мне тот, что появился в третьем КоДеСисе. Объединение в рамках одного проекта множества устройств с возможностью использования единого пространства переменных и состояний. И это, скажу вам, весьма круто. Хотя, пример в статье выбран довольно неудачный…
safari2012
10.03.2016 01:06Если одна из дуинок сдохнет, подозреваю, что сдохнет весь кластер. Токен ринг от таких неприятностей был вроде как защищен.
Mirn
09.03.2016 13:58-2есть очень опасный сложновыловимыми багами момент который упускают почти все железячники даже с опытом, не говоря про просто программистов или схемотехников и прочих любителей:
У всех ардуин будет У КАЖДОЙ СВОЯ ТАКТОВАЯ частота.
Более менее одинаковая но НЕ РАВНАЯ.
Обычно это 30ppm — 30 миллионых долей, а обычно в комнатных условиях даже менее 1-5 ppm.
И различаться она может как в плюс так и в минус, а так же плавать со временем.
А уарт тактируется от тактовой.
И у уарта скорость приёма и СКОРОСТЬ ПЕРЕДАЧИ МОЖЕТ РАЗЛИЧАТЬСЯ, т.к. приёмник умеет подстраиваться под скорость передатчика, а передатчик уарта просто шпарит деля тактовую на фиксированные 8*Х.
А раз тактовая меняется и различается то можно принять 100001 байт а передать уарт сможет 100000 байт.
___Один байт потеряется___.
Но
Eсли передатчик работает быстрее чем приёмник то всё ОК.
Если передача и приём не непрерывные а пакетами то тоже всё ОК.
Пожалуйста не забывайте что мы живём в реальном мире в котором ровно 8000000.00000000000Гц никогда не бывает.
Будьте инженерами ;)totuin
09.03.2016 14:02Честно говоря я ни разу не встречал ситуацию что бы какие то байты не проходили. Но конечно возможно всё, и если вдруг пакет будет неполный, то он просто не обработается, в программе реализована такая защита.
Mirn
09.03.2016 14:09да, работа с пакетами тоже хорошее решение — обычно есть обратная связь и повтор пакета по таймауту.
я встречался например когда делал АТС — фильтр в разрыв потока Е1. Там данные нонстоп шпарят и приходилось делать аппаратную подгонку частот приёмников и передатчиков на ПЛИС. И вообще суть Е1 потока в том что в отличии от TCP и езернета он не даёт задержки а пропускает данные от АЦП в ЦАП почти напрямую. А езернет даёт плавающую задержку с которой ещё больше проблем (вылазит эхо и прочие неприятности в войпе)
А так же недавно делал тестовый/прошивающий стенд из 4 отдельных приборов по схеме в верху статьи: два уарт микроамперметра развязанных, развяззанный модуль подъёма трубки, и развязанный источник тока. Так же пришлось реализовать протокол пакетов, благо у СТМ32 есть такой для уарта и обновления прошивки.
serafims
09.03.2016 14:39Так они же не синхронно работают, а для защиты просто надо добавить какой-нибудь контроль данных..
VT100
09.03.2016 22:54+1Более менее одинаковая но НЕ РАВНАЯ.
Отставить панику!
Берём в руки файл с документаций на ATmega328 (atmel.com/dyn/resources/prod_documents/doc8272.pdf, ЕМНИП это она в основной массе дуринок используется) и смотрим предельные отклонения частот передачи в разделе «19.9.3 Asynchronous Operational Range». Для 8 бит данных без чётности при нормальной (не удвоенной) скорости передачи — это ±2% и, насколько я разобрал формулы, уже отнесённые к тактовому генератору. В итоге мы получаем неимоверную величину в 2000 ppm, что даже для дешёвых кварцев — раз плюнуть. Atmel акцентирует внимание только на керамических резонаторах, имеющих более низкую точность от природы.
И у уарта скорость приёма и СКОРОСТЬ ПЕРЕДАЧИ МОЖЕТ РАЗЛИЧАТЬСЯ, т.к. приёмник умеет
подстраиваться под скорость передатчика, а передатчик уарта просто шпарит деля тактовую
на фиксированные 8*Х.
Вы что-то путаете насчёт подстройки. По крайней мере у AVR — её нет.Mirn
09.03.2016 23:25все неправильно поняли.
А что если первая ардуина имеет отклонение частоты +1%, а вторая -1%?
т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт, у нас же откланение всего 2%, в пределах документации и ошибок не будет — мы же её соблюдаем.
Но передать то вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
А если данные не будут останавливаться и просто идти без пауз даже в 1нс? Тогда разница будет накапливаться и как следствие внутренний буфер ардиуны переполнится и она потеряет часть данных рано или поздно.
Вот это я имел ввиду что приёмник уарта отвязан по реальной частоте данных от передатчика уарта.
В документации сказано что приёмник уарта может подстроиться +-2% А передатчик шпарит с фиксированной.Mirn
10.03.2016 08:27и не важно, 1% отклонения или 0.001%.
не важно, уарт с клоками или без.
даже не важно уарт это вообще или SPI или вообще видеоинтерфейс.
и не важно, какой источник тактовой частоты, да хоть точность тактовой 1ppm и ошибка выставления BOD равна 0.0000...%.
всё равно в случае непрерывных данных или длинных пакетов будут глюки из за этой разницы что принять может и больше чем отправить.
совсем недавно обратились люди, некое устройство типа тепловизора глючило — получало данные на стм32Ф4хх и отдавало в блекфин по SPI. А блекфин обрабатывал и формировал изображение на экранчике. При этом у стм32 SPI был ведущим — часть пикселей в конце кадра хронически отваливались и строки в кадре смещались по горизонтали. Как только они взяли тактовую из блекфинаи, выкинув из стм32 кварцевый резонатор затактировали стм32 тактовой блекфина — глюк пропал. Потому что тактовая у SPI стала строго равна тактовой развёртке блекфина.Mirn
10.03.2016 08:44это всё было сделано СТРОГО по даташитам, везде всё было точно сконфигурировано и ошибок как аппаратных так и программных не было. Все по отдельности работало идеально хоть неделю, хоть месяц. Проблемы возникали только когда они подключали всё вместе. Им не помогало ничего, ни минусование кармы, ни подключение спец генератора тактовой с точностью 1ppm и выше, ни переписывание с нуля по минимому, ни доскональная проверка оссцилографом, ни фильтры питания. Ничего не помогало. Это был тупик на стадии запуска серийного производства когда уже несколько сотен шт сделаны и каждая вторая так глючит.
sim31r
10.03.2016 14:50Возможно было переполнение буфера.
У меня сотни устройств работают по modbus rtu, никаких проблем, uart передатчика и приемника всегда сами синхронизируются между собой, данные не теряются, если и теряются (из-за помех на линии), данные проверяются CRC16. Точность более 2%, похоже, для UART не требуется, для каждого байта поток должен синхронизироваться по старт биту, стоп биту (лучше 2 стоп бита) и биту четности, надо не забывать его включать для таких тяжелых случаев.Mirn
10.03.2016 14:55ладно ладно, уговорили, сделаю нормальную статью на пальцах рассказывающую о чём речь с видео и гифками: никто не в курсе и мало кто понял, и стал давать совсем не из той области советы.
Я же говорил что никто не знает об этом.
Распишу в статье как реализовать свой уарт на плис и CPLD и какие подводные камни бывают и как организовать контроль качества канала даже если все данные всегда без ошибок идут но есть например завал фронтов, джитинг бод и тд.sim31r
10.03.2016 15:29Завал фронтов уже из другой оперы, это аналоговая часть. Аналоговую часть, согласование линии, мы вообще не рассматриваем. Я смотрел осцилографом аналоговый сигнал в линии RS485, там что-то страшное, шумоподобный сигнал, но приемник четко выделяет полезный сигнал.
Я вот тоже не уверен, что вы понимаете о чем речь, по моему всё смешали в одну кучу.
Вот может кому-то будет интересно
ссылка http://forum.easyelectronics.ru/viewtopic.php?f=17&t=23444&start=25&hilit=PWM&view=print
Кстати, обычный uart тоже может передавать самосинхронизирующийся код, если использовать для цифр 0-F не ASCII, а коды 08 0C 0E 0F 88 8C 8E 8F C8 CC CE CF E8 EC EE EF, останется только параллельно измерять частоту на rx и подстраивать baudrate
Вот тут интересная идея, надо над этим подумать, немного переделываем кодовую таблицу, убираем символы где может быть имитация старт-стоп бита в информционных битах и готов самосинхронизирующийся код.
sim31r
10.03.2016 16:04Вот еще обсуждение по тому же вопросу
http://www.530.ru/wwwboards/mcontrol/1509/messages/406244.shtml
VT100
10.03.2016 22:57т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт… вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
Теперь я понял Вашу тревогу. Это проблемы более высокого уровня интерфейса, чем УАРТ, а не "железного" приёмопередатчика.
Про СТМ и БлэкФин — странно, что сразу не поэкономили на лишнем кварце. А практически — было-бы интересно разобрать такой случай.
P.S. Кажется, подобная гипотетическая ошибка обсуждалась на одной из настоящих "желесных" конференций. Только вот не припомню ни где, ни с каким результатом.totuin
10.03.2016 23:10т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт… вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
Почему?
Вторая приняла 101 байт, распарсила пакет, посмотрела что ей нужно (если ей это нужно), собрала снова пакет и отправила дальше. При чем здесь разница в скоростях между первой и третьей? Причем пакеты идут не непрерывно. Автор пакета отправляет его периодически, и зазор по времени между ними есть.Mirn
10.03.2016 23:19у почти всех современных МК есть точный внутренний генератор. Но он даёт как раз эти 1% погрешности, и например на стм32 даже в случае небольших пакетов до 256 байт бывают сюрпризы если внешний кварец не поставили — последние байты могут потеряться, или весь пакет. Благо ДМА позволяет принимая следующий пакет передавать далее предыдущий. И люди сами того не зная делают такой код который непрерывно уже группу пакетов передаёт без пауз.
Вот перенесут Ваш код на другую ардуину на базе того же стм32 где дма незаметно для программиста работает и он не заработает.
И вообще работая с такой цепочкой устройств было бы неплохо знать её ограничения и чего делать нельзя.
Ну или мучайтесь неделю-месяц неверя глазам своим и недоверяя 10 строкам тривиального кода ;)
Mirn
10.03.2016 23:14ну хоть кто-то понял, спасибо! А то все упёрлись в ошибку, выставления BOD что допустима у аврок в 2% при неточном делителе частоты БОД который не удалось округлить до целого.
Часто это ошибка дизайна — люди часто забывают что кварцы даже из одной партии разные. Если действовать по уму то надо вводить обратную связь — подтверждать приём и его целостность и делать переотправку как в TCP или других простых протоколах. Ну или делать проще — чтоб следующие данные были не критичны к сбою где то в середине — признак начала строки кадра например помог бы типа чернее чёрного как в PAL/NTSC.
В случае нонстоп потока или больших кусков данных типа целого кадра 320х240 проблемы встают во весь рост. Но вся подстава что это выявляется как правило после сборки первой партии. Когда я сравнил их кварцы (дорогим и точным лекроем за лям рублей который у них был кстати), в первых отладочных вариантах то в всех трёх им везло — кварец блекфина перекосило в удачную сторону. А разница частот у сбойных плат была в 0.5 всего герца но уже перекошены в меньшую сторону.
А на кварце не сэкономили потому что они скопировали кусок из дискавери для стм32 и кусок из отладки блэкфина. Это кстати болезнь всех кто работает с железом: «Нам не нужен схемотехник и архитектор, всё это каждый сам делает как нибудь», и с этим я часто сталкиваюсь при аудите. Даже если они разрабатывают опасное медицинское оборудование (лазеры 100 — 1кВатт) или автоэлектронику / промышленные станки.VT100
11.03.2016 22:56И, всё-таки, считаю что где-то в логике был epic-fail. Нельзя так аппаратно забажить простой как два ниббла SPI (к тому-же — синхронный).
А по поводу УАРТа:
… например на стм32 даже в случае небольших пакетов до 256 байт бывают сюрпризы если внешний кварец не поставили — последние байты могут потеряться, или весь пакет. ...
тоже сомневаюсь. Ведь каждый отдельный байт синхронизируется по своему стартовому биту, а не от начала пакета. Вероятнее, что просто не успевают принимать данные из буфера УАРТа.Mirn
11.03.2016 23:02«Вероятнее, что просто не успевают принимать данные из буфера УАРТа.» да именно так — не успевает принятые отправить, в добавок ДМА всё усугубило.
cyberly
10.03.2016 10:00Из моего небольшого опыта общения с МК (AVR и Atmel'овские 51), эта проблема не является чем-то вот прям неожиданным и проявляется довольно быстро при тестировании. Понятно, что поскольку UART использует не самосинхронизирующийся код, с увеличением длинны последовательности байт растет вероятность, что начиная с n-го возникнет ошибка. Отправили, допустим 100 байт, приняли 50 нормально, остальное-мусор. И лечится это легко — можно просто отправлять данные короткими пакетами. А еще лучше сделать поверх UART какой-нибудь простенький протокол с проверкой целостности и запросом повторной отправки, может быть еще с подтверждениями (заодно продумать, как быть, если получатель или приемник зависнет или кабель выпадет).
sim31r
10.03.2016 14:37Лечится это паузой между данными "длинной" в один байт.
Лечится синхронизация передачей специального байта из одних единиц FFh, приемник там легко выделит стоповый бит.
Лечится это включением контроля четности, просто дописать Serial.Begin(9600, mark).
Контрольная сумма вообще хорошо.
sim31r
10.03.2016 14:32UART имеет стартовый бит, стоповый бит, можно разрешить бит контроля четности. Небольшие отклонения частоты, до 1-3% UART может компенсировать аппаратно. Тем более при наличии кварца. Стабилизация частоты нужна для того, чтобы интервалы не убежали за время приема одного байта. UART просто отследит по стоповому и стартовому биту начала следующего байта и подстроится под него, иначе зачем он нужен?
То о чем вы говорите имеет место быть в радиоканале, когда теряется стартовый бит и приемник (на момент включения приемника передача уже может давно идти), приемник ошибочно может принять что-то в данных за стоповый и стартовый биты (особенно без бита контроля четности). Но через некоторое время подстроится, если данные не формировать специально таким образом.
sav13
09.03.2016 16:50Может лучше общая шина чем кольцо?
Тот же RS485.
Микросхема копеечная, стандарт устоявшийся.
mitasamodel
09.03.2016 17:02В общей шине придётся следить за передачами чтобы избегать коллизий.
Здесь же физически этим можно пренебречь.
totuin
09.03.2016 16:57Поддержка Arduino как Modbus Slave через RS-485 в программе реализовано. С мастером пока посложнее. Работает пока медленно, но я работаю в этом направлении.
Cruzator
10.03.2016 07:27Доброго времени суток. Я с этой ВОЛШЕБНОЙ программой с первых выпусков! Сразу оговорюсь я не программист, электронщик или полноценный электрик — я моторист агрегатчик в спортивной команде. Но из за бюджетов и нынешнего курса -вместо забугорного железа, по двум нашим машинам, раскидано около 17 разных Ардуин. И объединение их именно в «кольцо» для нас просто благодать! Это создаст минимум веса (лишние провода и ...) и клон гоночного оборудования за 200К-300К рублей! Уважаемый Сергей Вы уже не первый раз нас выручаете! Спасибо БОЛЬШОЕ!
CRImier
11.03.2016 18:50Возьмите лучше RS485/CAN и нормальный код, так хоть помехозащищённость будет. Машины, надеюсь, без людей, ну или Ардуины ничем по факту не управляют?
Cruzator
12.03.2016 03:24Почему же? Очень даже управляют! На ардуинах почти 3й сезон едем и проблем с ними нет! А вот кольцо будет без управления и только для сбора данных и их вывода! дисплей по uart работает.
twsdwf
10.03.2016 22:00У атмег (и у 328p в том числе) есть аппаратный MPCM (Multi-processorCommunication Mode, есть в даташите целый раздел про эту штуку) для USART, который добавляет фильтрацию по адресу при приёме данных. И проводов данных всего два (общий RX и TX на все устройства на получившейся шине). Очень интересно почему не использовали, а сделали свою программную реализацию?
Prototik
Нет, правда, идея и реализация интересная, конечно, но нужно ли это вообще? Зачем брать 2-5 ардуин, если всё это можно запихнуть в один контроллер от другого производителя? (если не упрёмся в потолок по GPIO, конечно).
ay8910
Ну оговорились же, что проект чисто учебный…
Лично меня удивляет другое — зачем учиться программированию микроконтроллеров посредством этой вот "FLProg"? Ведь так или иначе, рано или поздно придётся перейти с ЭТОГО [...] на нормальный стандартный С с make-файлами.
Зато теперь по крайней мере не удивительно, откуда берутся вопросы типа "Как включить в проект на ATMega вот такой то С-файл".
totuin
Зачем, если нормальный С не потребуется для реализации своих проектов? Если "ЭТОГО" будет хватать. Не С единым существует DIY
stigory
Внимательно слежу за развитием «FLProg» и вот что заметил: буквально в каждой публикации я вижу комментарий в стиле — «зачем ЭТО?». Причем в тоне вопрошающего чаще звучит не искренне любопытство и желание узнать что-то новое, а высокомерие человека, убежденного, что он познал истину. Господа вопрошающие, искренне прошу вас, если вы по роду деятельности не имеете отношения к разработке и программированию АСУП, пройдите мимо молча. У всех своя специфика. Я знаком с программированием ардуинок в классическом стиле, но когда я скачал «FLProg», открыл и сходу за полминуты накидал проект из двух датчиков 18B20, завязанных на триггеры, которые привязал к компаратору, который щелкает выходом — я понял, что мыслить таким образом мне гораздо привычнее и проще. Пример, само собой, первый что тогда мне пришел в голову.
Проект «FLProg» явно на данном этапе проходит ранний период формирования. Нужен ли он? Судя по всему нужен многим. Нужен ли он вам? Решите это сами для себя, желательно не навязывая своего мнения. Этот способ программирования контроллеров никого не ограничивает. Само собой, чистый Си во многом предпочтительнее на определенной профессиональном уровне. Но, господа, почему-то все знают, что разработка на ассемблере еще лучше, но мало кто осмеливается дорасти до этого уровня.
FLProg это одна из многих дверей в мир ардуино. И эта дверь предназначена для автоматчиков. Другим через нее входить неудобно. Так входите через свои двери. Всё равно «место встречи изменить нельзя».
Hellsy22
А зачем вы навязываете кому-то свое мнение о том, что как и когда комментировать в рамках правил ресурса?
Знаете, демонстрация любой технологии начинается с решения задачи. Решение, описанное в статье — это чудовищно громоздкий и неудобный способ сделать тривиальную вещь. Вот вы "за полминуты" связали датчики, триггеры и компаратор? Замечательно! Напишите об этом статью, в которой это сделано реально за полминуты. А пока будут статьи типа "сейчас мы вам расскажем, как потратив три часа времени на войну с интерфейсом научиться мигать светодиодом" — будут и резонные вопросы об актуальности этого всего.
totuin
Именно для Вас я в начале статьи написал — "Это учебный пример"