Комментарии 46
Мы будем городить этажерки из Arduino, лишь бы не брать STM32 или любой другой мало-мальски годный контроллер.
Нет, правда, идея и реализация интересная, конечно, но нужно ли это вообще? Зачем брать 2-5 ардуин, если всё это можно запихнуть в один контроллер от другого производителя? (если не упрёмся в потолок по GPIO, конечно).
Ну оговорились же, что проект чисто учебный…
Лично меня удивляет другое — зачем учиться программированию микроконтроллеров посредством этой вот "FLProg"? Ведь так или иначе, рано или поздно придётся перейти с ЭТОГО [...] на нормальный стандартный С с make-файлами.
Зато теперь по крайней мере не удивительно, откуда берутся вопросы типа "Как включить в проект на ATMega вот такой то С-файл".
Лично меня удивляет другое — зачем учиться программированию микроконтроллеров посредством этой вот "FLProg"? Ведь так или иначе, рано или поздно придётся перейти с ЭТОГО [...] на нормальный стандартный С с make-файлами.
Зато теперь по крайней мере не удивительно, откуда берутся вопросы типа "Как включить в проект на ATMega вот такой то С-файл".
Зачем, если нормальный С не потребуется для реализации своих проектов? Если "ЭТОГО" будет хватать. Не С единым существует DIY
Внимательно слежу за развитием «FLProg» и вот что заметил: буквально в каждой публикации я вижу комментарий в стиле — «зачем ЭТО?». Причем в тоне вопрошающего чаще звучит не искренне любопытство и желание узнать что-то новое, а высокомерие человека, убежденного, что он познал истину. Господа вопрошающие, искренне прошу вас, если вы по роду деятельности не имеете отношения к разработке и программированию АСУП, пройдите мимо молча. У всех своя специфика. Я знаком с программированием ардуинок в классическом стиле, но когда я скачал «FLProg», открыл и сходу за полминуты накидал проект из двух датчиков 18B20, завязанных на триггеры, которые привязал к компаратору, который щелкает выходом — я понял, что мыслить таким образом мне гораздо привычнее и проще. Пример, само собой, первый что тогда мне пришел в голову.
Проект «FLProg» явно на данном этапе проходит ранний период формирования. Нужен ли он? Судя по всему нужен многим. Нужен ли он вам? Решите это сами для себя, желательно не навязывая своего мнения. Этот способ программирования контроллеров никого не ограничивает. Само собой, чистый Си во многом предпочтительнее на определенной профессиональном уровне. Но, господа, почему-то все знают, что разработка на ассемблере еще лучше, но мало кто осмеливается дорасти до этого уровня.
FLProg это одна из многих дверей в мир ардуино. И эта дверь предназначена для автоматчиков. Другим через нее входить неудобно. Так входите через свои двери. Всё равно «место встречи изменить нельзя».
Проект «FLProg» явно на данном этапе проходит ранний период формирования. Нужен ли он? Судя по всему нужен многим. Нужен ли он вам? Решите это сами для себя, желательно не навязывая своего мнения. Этот способ программирования контроллеров никого не ограничивает. Само собой, чистый Си во многом предпочтительнее на определенной профессиональном уровне. Но, господа, почему-то все знают, что разработка на ассемблере еще лучше, но мало кто осмеливается дорасти до этого уровня.
FLProg это одна из многих дверей в мир ардуино. И эта дверь предназначена для автоматчиков. Другим через нее входить неудобно. Так входите через свои двери. Всё равно «место встречи изменить нельзя».
А зачем вы навязываете кому-то свое мнение о том, что как и когда комментировать в рамках правил ресурса?
Знаете, демонстрация любой технологии начинается с решения задачи. Решение, описанное в статье — это чудовищно громоздкий и неудобный способ сделать тривиальную вещь. Вот вы "за полминуты" связали датчики, триггеры и компаратор? Замечательно! Напишите об этом статью, в которой это сделано реально за полминуты. А пока будут статьи типа "сейчас мы вам расскажем, как потратив три часа времени на войну с интерфейсом научиться мигать светодиодом" — будут и резонные вопросы об актуальности этого всего.
Знаете, демонстрация любой технологии начинается с решения задачи. Решение, описанное в статье — это чудовищно громоздкий и неудобный способ сделать тривиальную вещь. Вот вы "за полминуты" связали датчики, триггеры и компаратор? Замечательно! Напишите об этом статью, в которой это сделано реально за полминуты. А пока будут статьи типа "сейчас мы вам расскажем, как потратив три часа времени на войну с интерфейсом научиться мигать светодиодом" — будут и резонные вопросы об актуальности этого всего.
Может быть полезно для распределенной сети контроллеров, каждый из которых работает со своими датчиками. Хотя и для этой цели на мой взгляд логичнее использовать I2C или SPI.
Аналог Token Ring, теперь на Arduino.
Если честно идея пришла из мира судовой навигации. Там оборудование где то похожим способом обменивается информацией по протоколу NMEA. В молодости работал с этим оборудованием.
А у меня создалось впечатление, что вы строите функционал, напоминающий мне тот, что появился в третьем КоДеСисе. Объединение в рамках одного проекта множества устройств с возможностью использования единого пространства переменных и состояний. И это, скажу вам, весьма круто. Хотя, пример в статье выбран довольно неудачный…
Если одна из дуинок сдохнет, подозреваю, что сдохнет весь кластер. Токен ринг от таких неприятностей был вроде как защищен.
есть очень опасный сложновыловимыми багами момент который упускают почти все железячники даже с опытом, не говоря про просто программистов или схемотехников и прочих любителей:
У всех ардуин будет У КАЖДОЙ СВОЯ ТАКТОВАЯ частота.
Более менее одинаковая но НЕ РАВНАЯ.
Обычно это 30ppm — 30 миллионых долей, а обычно в комнатных условиях даже менее 1-5 ppm.
И различаться она может как в плюс так и в минус, а так же плавать со временем.
А уарт тактируется от тактовой.
И у уарта скорость приёма и СКОРОСТЬ ПЕРЕДАЧИ МОЖЕТ РАЗЛИЧАТЬСЯ, т.к. приёмник умеет подстраиваться под скорость передатчика, а передатчик уарта просто шпарит деля тактовую на фиксированные 8*Х.
А раз тактовая меняется и различается то можно принять 100001 байт а передать уарт сможет 100000 байт.
___Один байт потеряется___.
Но
Eсли передатчик работает быстрее чем приёмник то всё ОК.
Если передача и приём не непрерывные а пакетами то тоже всё ОК.
Пожалуйста не забывайте что мы живём в реальном мире в котором ровно 8000000.00000000000Гц никогда не бывает.
Будьте инженерами ;)
У всех ардуин будет У КАЖДОЙ СВОЯ ТАКТОВАЯ частота.
Более менее одинаковая но НЕ РАВНАЯ.
Обычно это 30ppm — 30 миллионых долей, а обычно в комнатных условиях даже менее 1-5 ppm.
И различаться она может как в плюс так и в минус, а так же плавать со временем.
А уарт тактируется от тактовой.
И у уарта скорость приёма и СКОРОСТЬ ПЕРЕДАЧИ МОЖЕТ РАЗЛИЧАТЬСЯ, т.к. приёмник умеет подстраиваться под скорость передатчика, а передатчик уарта просто шпарит деля тактовую на фиксированные 8*Х.
А раз тактовая меняется и различается то можно принять 100001 байт а передать уарт сможет 100000 байт.
___Один байт потеряется___.
Но
Eсли передатчик работает быстрее чем приёмник то всё ОК.
Если передача и приём не непрерывные а пакетами то тоже всё ОК.
Пожалуйста не забывайте что мы живём в реальном мире в котором ровно 8000000.00000000000Гц никогда не бывает.
Будьте инженерами ;)
Честно говоря я ни разу не встречал ситуацию что бы какие то байты не проходили. Но конечно возможно всё, и если вдруг пакет будет неполный, то он просто не обработается, в программе реализована такая защита.
да, работа с пакетами тоже хорошее решение — обычно есть обратная связь и повтор пакета по таймауту.
я встречался например когда делал АТС — фильтр в разрыв потока Е1. Там данные нонстоп шпарят и приходилось делать аппаратную подгонку частот приёмников и передатчиков на ПЛИС. И вообще суть Е1 потока в том что в отличии от TCP и езернета он не даёт задержки а пропускает данные от АЦП в ЦАП почти напрямую. А езернет даёт плавающую задержку с которой ещё больше проблем (вылазит эхо и прочие неприятности в войпе)
А так же недавно делал тестовый/прошивающий стенд из 4 отдельных приборов по схеме в верху статьи: два уарт микроамперметра развязанных, развяззанный модуль подъёма трубки, и развязанный источник тока. Так же пришлось реализовать протокол пакетов, благо у СТМ32 есть такой для уарта и обновления прошивки.
я встречался например когда делал АТС — фильтр в разрыв потока Е1. Там данные нонстоп шпарят и приходилось делать аппаратную подгонку частот приёмников и передатчиков на ПЛИС. И вообще суть Е1 потока в том что в отличии от TCP и езернета он не даёт задержки а пропускает данные от АЦП в ЦАП почти напрямую. А езернет даёт плавающую задержку с которой ещё больше проблем (вылазит эхо и прочие неприятности в войпе)
А так же недавно делал тестовый/прошивающий стенд из 4 отдельных приборов по схеме в верху статьи: два уарт микроамперметра развязанных, развяззанный модуль подъёма трубки, и развязанный источник тока. Так же пришлось реализовать протокол пакетов, благо у СТМ32 есть такой для уарта и обновления прошивки.
Так они же не синхронно работают, а для защиты просто надо добавить какой-нибудь контроль данных..
Более менее одинаковая но НЕ РАВНАЯ.
Отставить панику!
Берём в руки файл с документаций на ATmega328 (atmel.com/dyn/resources/prod_documents/doc8272.pdf, ЕМНИП это она в основной массе дуринок используется) и смотрим предельные отклонения частот передачи в разделе «19.9.3 Asynchronous Operational Range». Для 8 бит данных без чётности при нормальной (не удвоенной) скорости передачи — это ±2% и, насколько я разобрал формулы, уже отнесённые к тактовому генератору. В итоге мы получаем неимоверную величину в 2000 ppm, что даже для дешёвых кварцев — раз плюнуть. Atmel акцентирует внимание только на керамических резонаторах, имеющих более низкую точность от природы.
И у уарта скорость приёма и СКОРОСТЬ ПЕРЕДАЧИ МОЖЕТ РАЗЛИЧАТЬСЯ, т.к. приёмник умеет
подстраиваться под скорость передатчика, а передатчик уарта просто шпарит деля тактовую
на фиксированные 8*Х.
Вы что-то путаете насчёт подстройки. По крайней мере у AVR — её нет.
Отставить панику!
Берём в руки файл с документаций на ATmega328 (atmel.com/dyn/resources/prod_documents/doc8272.pdf, ЕМНИП это она в основной массе дуринок используется) и смотрим предельные отклонения частот передачи в разделе «19.9.3 Asynchronous Operational Range». Для 8 бит данных без чётности при нормальной (не удвоенной) скорости передачи — это ±2% и, насколько я разобрал формулы, уже отнесённые к тактовому генератору. В итоге мы получаем неимоверную величину в 2000 ppm, что даже для дешёвых кварцев — раз плюнуть. Atmel акцентирует внимание только на керамических резонаторах, имеющих более низкую точность от природы.
И у уарта скорость приёма и СКОРОСТЬ ПЕРЕДАЧИ МОЖЕТ РАЗЛИЧАТЬСЯ, т.к. приёмник умеет
подстраиваться под скорость передатчика, а передатчик уарта просто шпарит деля тактовую
на фиксированные 8*Х.
Вы что-то путаете насчёт подстройки. По крайней мере у AVR — её нет.
все неправильно поняли.
А что если первая ардуина имеет отклонение частоты +1%, а вторая -1%?
т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт, у нас же откланение всего 2%, в пределах документации и ошибок не будет — мы же её соблюдаем.
Но передать то вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
А если данные не будут останавливаться и просто идти без пауз даже в 1нс? Тогда разница будет накапливаться и как следствие внутренний буфер ардиуны переполнится и она потеряет часть данных рано или поздно.
Вот это я имел ввиду что приёмник уарта отвязан по реальной частоте данных от передатчика уарта.
В документации сказано что приёмник уарта может подстроиться +-2% А передатчик шпарит с фиксированной.
А что если первая ардуина имеет отклонение частоты +1%, а вторая -1%?
т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт, у нас же откланение всего 2%, в пределах документации и ошибок не будет — мы же её соблюдаем.
Но передать то вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
А если данные не будут останавливаться и просто идти без пауз даже в 1нс? Тогда разница будет накапливаться и как следствие внутренний буфер ардиуны переполнится и она потеряет часть данных рано или поздно.
Вот это я имел ввиду что приёмник уарта отвязан по реальной частоте данных от передатчика уарта.
В документации сказано что приёмник уарта может подстроиться +-2% А передатчик шпарит с фиксированной.
и не важно, 1% отклонения или 0.001%.
не важно, уарт с клоками или без.
даже не важно уарт это вообще или SPI или вообще видеоинтерфейс.
и не важно, какой источник тактовой частоты, да хоть точность тактовой 1ppm и ошибка выставления BOD равна 0.0000...%.
всё равно в случае непрерывных данных или длинных пакетов будут глюки из за этой разницы что принять может и больше чем отправить.
совсем недавно обратились люди, некое устройство типа тепловизора глючило — получало данные на стм32Ф4хх и отдавало в блекфин по SPI. А блекфин обрабатывал и формировал изображение на экранчике. При этом у стм32 SPI был ведущим — часть пикселей в конце кадра хронически отваливались и строки в кадре смещались по горизонтали. Как только они взяли тактовую из блекфинаи, выкинув из стм32 кварцевый резонатор затактировали стм32 тактовой блекфина — глюк пропал. Потому что тактовая у SPI стала строго равна тактовой развёртке блекфина.
не важно, уарт с клоками или без.
даже не важно уарт это вообще или SPI или вообще видеоинтерфейс.
и не важно, какой источник тактовой частоты, да хоть точность тактовой 1ppm и ошибка выставления BOD равна 0.0000...%.
всё равно в случае непрерывных данных или длинных пакетов будут глюки из за этой разницы что принять может и больше чем отправить.
совсем недавно обратились люди, некое устройство типа тепловизора глючило — получало данные на стм32Ф4хх и отдавало в блекфин по SPI. А блекфин обрабатывал и формировал изображение на экранчике. При этом у стм32 SPI был ведущим — часть пикселей в конце кадра хронически отваливались и строки в кадре смещались по горизонтали. Как только они взяли тактовую из блекфинаи, выкинув из стм32 кварцевый резонатор затактировали стм32 тактовой блекфина — глюк пропал. Потому что тактовая у SPI стала строго равна тактовой развёртке блекфина.
это всё было сделано СТРОГО по даташитам, везде всё было точно сконфигурировано и ошибок как аппаратных так и программных не было. Все по отдельности работало идеально хоть неделю, хоть месяц. Проблемы возникали только когда они подключали всё вместе. Им не помогало ничего, ни минусование кармы, ни подключение спец генератора тактовой с точностью 1ppm и выше, ни переписывание с нуля по минимому, ни доскональная проверка оссцилографом, ни фильтры питания. Ничего не помогало. Это был тупик на стадии запуска серийного производства когда уже несколько сотен шт сделаны и каждая вторая так глючит.
Возможно было переполнение буфера.
У меня сотни устройств работают по modbus rtu, никаких проблем, uart передатчика и приемника всегда сами синхронизируются между собой, данные не теряются, если и теряются (из-за помех на линии), данные проверяются CRC16. Точность более 2%, похоже, для UART не требуется, для каждого байта поток должен синхронизироваться по старт биту, стоп биту (лучше 2 стоп бита) и биту четности, надо не забывать его включать для таких тяжелых случаев.
У меня сотни устройств работают по modbus rtu, никаких проблем, uart передатчика и приемника всегда сами синхронизируются между собой, данные не теряются, если и теряются (из-за помех на линии), данные проверяются CRC16. Точность более 2%, похоже, для UART не требуется, для каждого байта поток должен синхронизироваться по старт биту, стоп биту (лучше 2 стоп бита) и биту четности, надо не забывать его включать для таких тяжелых случаев.
ладно ладно, уговорили, сделаю нормальную статью на пальцах рассказывающую о чём речь с видео и гифками: никто не в курсе и мало кто понял, и стал давать совсем не из той области советы.
Я же говорил что никто не знает об этом.
Распишу в статье как реализовать свой уарт на плис и CPLD и какие подводные камни бывают и как организовать контроль качества канала даже если все данные всегда без ошибок идут но есть например завал фронтов, джитинг бод и тд.
Я же говорил что никто не знает об этом.
Распишу в статье как реализовать свой уарт на плис и CPLD и какие подводные камни бывают и как организовать контроль качества канала даже если все данные всегда без ошибок идут но есть например завал фронтов, джитинг бод и тд.
Завал фронтов уже из другой оперы, это аналоговая часть. Аналоговую часть, согласование линии, мы вообще не рассматриваем. Я смотрел осцилографом аналоговый сигнал в линии RS485, там что-то страшное, шумоподобный сигнал, но приемник четко выделяет полезный сигнал.
Я вот тоже не уверен, что вы понимаете о чем речь, по моему всё смешали в одну кучу.
Вот может кому-то будет интересно
ссылка http://forum.easyelectronics.ru/viewtopic.php?f=17&t=23444&start=25&hilit=PWM&view=print
Вот тут интересная идея, надо над этим подумать, немного переделываем кодовую таблицу, убираем символы где может быть имитация старт-стоп бита в информционных битах и готов самосинхронизирующийся код.
Я вот тоже не уверен, что вы понимаете о чем речь, по моему всё смешали в одну кучу.
Вот может кому-то будет интересно
ссылка 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
Вот тут интересная идея, надо над этим подумать, немного переделываем кодовую таблицу, убираем символы где может быть имитация старт-стоп бита в информционных битах и готов самосинхронизирующийся код.
Вот еще обсуждение по тому же вопросу
http://www.530.ru/wwwboards/mcontrol/1509/messages/406244.shtml
http://www.530.ru/wwwboards/mcontrol/1509/messages/406244.shtml
т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт… вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
Теперь я понял Вашу тревогу. Это проблемы более высокого уровня интерфейса, чем УАРТ, а не "железного" приёмопередатчика.
Про СТМ и БлэкФин — странно, что сразу не поэкономили на лишнем кварце. А практически — было-бы интересно разобрать такой случай.
P.S. Кажется, подобная гипотетическая ошибка обсуждалась на одной из настоящих "желесных" конференций. Только вот не припомню ни где, ни с каким результатом.
т.е. первая передела 101 байт, а вторая как и полагается документации приняла эти 101 байт… вторая третьей за это же время, что и были переданы 101 байт сможет только 99 байт. т.е. на 2 байта меньше (разница в скорости эти 2%).
Почему?
Вторая приняла 101 байт, распарсила пакет, посмотрела что ей нужно (если ей это нужно), собрала снова пакет и отправила дальше. При чем здесь разница в скоростях между первой и третьей? Причем пакеты идут не непрерывно. Автор пакета отправляет его периодически, и зазор по времени между ними есть.
у почти всех современных МК есть точный внутренний генератор. Но он даёт как раз эти 1% погрешности, и например на стм32 даже в случае небольших пакетов до 256 байт бывают сюрпризы если внешний кварец не поставили — последние байты могут потеряться, или весь пакет. Благо ДМА позволяет принимая следующий пакет передавать далее предыдущий. И люди сами того не зная делают такой код который непрерывно уже группу пакетов передаёт без пауз.
Вот перенесут Ваш код на другую ардуину на базе того же стм32 где дма незаметно для программиста работает и он не заработает.
И вообще работая с такой цепочкой устройств было бы неплохо знать её ограничения и чего делать нельзя.
Ну или мучайтесь неделю-месяц неверя глазам своим и недоверяя 10 строкам тривиального кода ;)
Вот перенесут Ваш код на другую ардуину на базе того же стм32 где дма незаметно для программиста работает и он не заработает.
И вообще работая с такой цепочкой устройств было бы неплохо знать её ограничения и чего делать нельзя.
Ну или мучайтесь неделю-месяц неверя глазам своим и недоверяя 10 строкам тривиального кода ;)
ну хоть кто-то понял, спасибо! А то все упёрлись в ошибку, выставления BOD что допустима у аврок в 2% при неточном делителе частоты БОД который не удалось округлить до целого.
Часто это ошибка дизайна — люди часто забывают что кварцы даже из одной партии разные. Если действовать по уму то надо вводить обратную связь — подтверждать приём и его целостность и делать переотправку как в TCP или других простых протоколах. Ну или делать проще — чтоб следующие данные были не критичны к сбою где то в середине — признак начала строки кадра например помог бы типа чернее чёрного как в PAL/NTSC.
В случае нонстоп потока или больших кусков данных типа целого кадра 320х240 проблемы встают во весь рост. Но вся подстава что это выявляется как правило после сборки первой партии. Когда я сравнил их кварцы (дорогим и точным лекроем за лям рублей который у них был кстати), в первых отладочных вариантах то в всех трёх им везло — кварец блекфина перекосило в удачную сторону. А разница частот у сбойных плат была в 0.5 всего герца но уже перекошены в меньшую сторону.
А на кварце не сэкономили потому что они скопировали кусок из дискавери для стм32 и кусок из отладки блэкфина. Это кстати болезнь всех кто работает с железом: «Нам не нужен схемотехник и архитектор, всё это каждый сам делает как нибудь», и с этим я часто сталкиваюсь при аудите. Даже если они разрабатывают опасное медицинское оборудование (лазеры 100 — 1кВатт) или автоэлектронику / промышленные станки.
Часто это ошибка дизайна — люди часто забывают что кварцы даже из одной партии разные. Если действовать по уму то надо вводить обратную связь — подтверждать приём и его целостность и делать переотправку как в TCP или других простых протоколах. Ну или делать проще — чтоб следующие данные были не критичны к сбою где то в середине — признак начала строки кадра например помог бы типа чернее чёрного как в PAL/NTSC.
В случае нонстоп потока или больших кусков данных типа целого кадра 320х240 проблемы встают во весь рост. Но вся подстава что это выявляется как правило после сборки первой партии. Когда я сравнил их кварцы (дорогим и точным лекроем за лям рублей который у них был кстати), в первых отладочных вариантах то в всех трёх им везло — кварец блекфина перекосило в удачную сторону. А разница частот у сбойных плат была в 0.5 всего герца но уже перекошены в меньшую сторону.
А на кварце не сэкономили потому что они скопировали кусок из дискавери для стм32 и кусок из отладки блэкфина. Это кстати болезнь всех кто работает с железом: «Нам не нужен схемотехник и архитектор, всё это каждый сам делает как нибудь», и с этим я часто сталкиваюсь при аудите. Даже если они разрабатывают опасное медицинское оборудование (лазеры 100 — 1кВатт) или автоэлектронику / промышленные станки.
И, всё-таки, считаю что где-то в логике был epic-fail. Нельзя так аппаратно забажить простой как два ниббла SPI (к тому-же — синхронный).
А по поводу УАРТа:
тоже сомневаюсь. Ведь каждый отдельный байт синхронизируется по своему стартовому биту, а не от начала пакета. Вероятнее, что просто не успевают принимать данные из буфера УАРТа.
А по поводу УАРТа:
… например на стм32 даже в случае небольших пакетов до 256 байт бывают сюрпризы если внешний кварец не поставили — последние байты могут потеряться, или весь пакет. ...
тоже сомневаюсь. Ведь каждый отдельный байт синхронизируется по своему стартовому биту, а не от начала пакета. Вероятнее, что просто не успевают принимать данные из буфера УАРТа.
Из моего небольшого опыта общения с МК (AVR и Atmel'овские 51), эта проблема не является чем-то вот прям неожиданным и проявляется довольно быстро при тестировании. Понятно, что поскольку UART использует не самосинхронизирующийся код, с увеличением длинны последовательности байт растет вероятность, что начиная с n-го возникнет ошибка. Отправили, допустим 100 байт, приняли 50 нормально, остальное-мусор. И лечится это легко — можно просто отправлять данные короткими пакетами. А еще лучше сделать поверх UART какой-нибудь простенький протокол с проверкой целостности и запросом повторной отправки, может быть еще с подтверждениями (заодно продумать, как быть, если получатель или приемник зависнет или кабель выпадет).
UART имеет стартовый бит, стоповый бит, можно разрешить бит контроля четности. Небольшие отклонения частоты, до 1-3% UART может компенсировать аппаратно. Тем более при наличии кварца. Стабилизация частоты нужна для того, чтобы интервалы не убежали за время приема одного байта. UART просто отследит по стоповому и стартовому биту начала следующего байта и подстроится под него, иначе зачем он нужен?
То о чем вы говорите имеет место быть в радиоканале, когда теряется стартовый бит и приемник (на момент включения приемника передача уже может давно идти), приемник ошибочно может принять что-то в данных за стоповый и стартовый биты (особенно без бита контроля четности). Но через некоторое время подстроится, если данные не формировать специально таким образом.
То о чем вы говорите имеет место быть в радиоканале, когда теряется стартовый бит и приемник (на момент включения приемника передача уже может давно идти), приемник ошибочно может принять что-то в данных за стоповый и стартовый биты (особенно без бита контроля четности). Но через некоторое время подстроится, если данные не формировать специально таким образом.
Всё же, OneWire или OneWare? Я запутался…
Конечно же OneWire. Спасибо, сейчас поправлю
Может лучше общая шина чем кольцо?
Тот же RS485.
Микросхема копеечная, стандарт устоявшийся.
Тот же RS485.
Микросхема копеечная, стандарт устоявшийся.
Поддержка Arduino как Modbus Slave через RS-485 в программе реализовано. С мастером пока посложнее. Работает пока медленно, но я работаю в этом направлении.
А скетчи из стандартной среды как-то можно в FLProg добавлять?
Доброго времени суток. Я с этой ВОЛШЕБНОЙ программой с первых выпусков! Сразу оговорюсь я не программист, электронщик или полноценный электрик — я моторист агрегатчик в спортивной команде. Но из за бюджетов и нынешнего курса -вместо забугорного железа, по двум нашим машинам, раскидано около 17 разных Ардуин. И объединение их именно в «кольцо» для нас просто благодать! Это создаст минимум веса (лишние провода и ...) и клон гоночного оборудования за 200К-300К рублей! Уважаемый Сергей Вы уже не первый раз нас выручаете! Спасибо БОЛЬШОЕ!
У атмег (и у 328p в том числе) есть аппаратный MPCM (Multi-processorCommunication Mode, есть в даташите целый раздел про эту штуку) для USART, который добавляет фильтрацию по адресу при приёме данных. И проводов данных всего два (общий RX и TX на все устройства на получившейся шине). Очень интересно почему не использовали, а сделали свою программную реализацию?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FLProg — объединение плат Arduino в информационное кольцо