Система из нескольких ардуино
- Войдите на сайт для отправки комментариев
Всем здравствуйте. В тему ардуино (и микроконтроллеров в целом) только начинаю вникать. Собираюсь сделать проект с несколькими связанными arduino. Вкратце: реализация в автомобиле дополнительных комфортных функций (выключение салоннго света в охране, управление подогревом сидений, климат контролем и еще очень много всего), дабы не тянуть через весь салон пучки по 15-20 проводов, хотельсь бы наладить систему, при которой каждая ардуино находится непосредственно рядом со скоплением источников вводных данных (проводка с управляющими сигналами, сенсоры и.т.д) и объектами, которыми нуобходимо управлять.
Со способами связи между ардуинами ознакомился. Здесь все более менее понятно. Открытым остался вопрос обновления кода (скетчей) на самих ардуинах, т.к. устройства будут спрятаны под общивками и каждый раз все разбирать - это не вариант. Возможно ли реализовать обновление через мастер устройство по i2c, RS485 и др.? Так же вопрос про ресет всей системы в случае зависания одного устройства или всей системы. Достаточно ли будет отключить напряжение на несколько секунд?
А чо не начал с программы запуска лунохода на Марс? Все попроще будет...
Интересует принципиальная возвожность реализации моей идеи, ЕСЛИ ЧО. Если это возможно, будут приобретаться одни компоненты. Если нет, то другие. Прекрасно понимаю, что проект не самый простой для новичка. Но и постоить его одним махом не планирую. Буду познавать все в процессе.
Заранее спасибо.
А чо не начал с программы запуска лунохода на Марс? Все попроще будет...
https://www.youtube.com/watch?v=fOznjQJ7d6s
а нафига их обновлять ?
сделайте так чтобы никаких обновлений.
Для изменения алгоритмов работы системы, для согласования работы новых компонентов с уже имеющимися, для устранения возможных багов.
Если вкратце, что бы реализовать ваши хотелки, нужно менять бутлоадер на дуинах, а этим врятли кто будет заниматься бесплатно. Есть вариант более топорный, но проще, нужно придумать что то вроде джамперов, которыми будете отключать все дуины кроме той, которую хотите прошивать. А насчет перезапуска, то отключения питания будет достаточно
Накупить юсб проводов, вывести в доступное место от каждой ардуины для обновления ПО. Связать ардуины кан шиной, т.к. она проще к освоению для новичка.
А вообще гораздо проще провода протянуть. В чем проблема, не вижу
В машине все протоколы уже придуманы и это не i2c. Датчики и исполнительные механизмы уже живут в этой сети.
Если бы была возможность реализации через can, так и было бы сделано. Подробнейшим образом изучил штатную реализацию каждой функции, алгоритм работы которых хочу модифицировать. По итогу: этими функциями нет возможности управлять через can. Т.к. они подключены либо силовым методом, либо через аналоговое реле, с аналоговым управлением (не от МК).
А использовать существующий can как транспорт для новых функций - если чесно, страшно. Хотя и хотелось бы. Страшно из за тех же практически промышленных устройств, can-bus адаптеров для китайских андройд магнитол, после подключения этих can-bus'ов в машине некоторые важные функции переставали работать корректно или совсем. Из за кривой реализации и того мусора который адаптер шлет в шину.
а дальше
вы уж разберитесь нужна ли вам сеть ардуин или нет. Естественно я говорил про организацию своей can шины при помощи китайскийх модулей . Лезть в штатную шину не стОит. Ну разве только если из неё считывать информацию, но для этого нужно знать принцип протокола, а у всех производителей они разные.
А если не использовать штатную can шину, то какая разница как связывать ардуины? В чем у can преимущество перед i2c в условиях авто?
Ну я бы не стал что-то по CAN свое передавать, мало ли что. Слушать да. Но для передачи не стоит её использовать.
CAN идеологически ближе к RS485, чем к i2c. Т.е. более защишена от помех, и передача возможна на большие расстояния. i2c все-таки рассчитан был на обмен между микросхемами в пределах одного устройства.
Но я бы рекомендовал использовать RS485, его реализация дешевле CAN, микросхемы MAX485 стоят копейки
1) http://s.aliexpress.com/QZnUnuam
2) http://s.aliexpress.com/aUNRNfiY
3) http://s.aliexpress.com/YFBZfyme
В других проектах видел только такой как по 3 ссылке. Поэтому воник вопрос: для слушания автомобильной can шины и для возможности посылать впо ней комманды подойдет любой из этих адаптеров? И какие преимущества у 2 перед 1 и 3 перед 2?
Имхо, 2 и 3 одно и то же - мост CAN - SPI, просто разный форм фактор. 1 - мост CAN - UART. Используя 2 или 3 вы не сможите использовать программирование контроллера по SPI не изымая его из схемы. Используя 1 и повесив его на основной UART не сможите программировать не снимая через UART (штатно для среды ардуино).
Имхо, 2 и 3 одно и то же - мост CAN - SPI, просто разный форм фактор. 1 - мост CAN - UART. Используя 2 или 3 вы не сможите использовать программирование контроллера по SPI не изымая его из схемы. Используя 1 и повесив его на основной UART не сможите программировать не снимая через UART (штатно для среды ардуино).
про 2 и 3 правильно написано. Брать лучше который дешевле, шилд нафиг не нужен. 1 - как мост CAN- UART вряд ли получится, т.к. это просто трансивер шины CAN без контроллера CAN шины. Этот трансивер используется для физического согласования с шиной кан. (Ну типа как микросхема мах485 в сети RS485). Только даже если и получится использовать этот трансивер CAN-UART, то смысл использования кан шины теряется, т.к. все преимущества отстутсвуют. Преимущества использования нормального модуля (там где есть и контроллер КАН и трансивер) в том, что здесь борьба с коллизиями и весь арбитраж сети лежит аппаратно на микросхеме, а не на программисте. Вы сразу работаете с сообщениями, причем любой МК может когда хочет "говорить", т.е. система мультимастерная, а на RS485 придётся это всё самому городить программно. Немного переплатить за CAN модуль считаю будет оправдано, чтоб не парится со стабильностью шины, и направить свою энергию сразу на реализацию задуманного.
1 - вообще для вас не вариант. Этот вариант годится когда в МК (ну например возмем ардуино) уже есть встроенный контроллер КАН шины (т.е. имею ввиду ардуино DUE).
2. Оптимальный вариант. по функциям полностью соответствует варианту 3. Дешевле
3. Лишние навороты. по функциям как вариант 2 только дороже.
Как вариант, есть готовое, называется avr-etherboot, понимает bin файл выкладываемый по tftp. Но потребуется всё подключать через Ethernet свитч.
Преимущества использования нормального модуля (там где есть и контроллер КАН и трансивер) в том, что здесь борьба с коллизиями и весь арбитраж сети лежит аппаратно на микросхеме, а не на программисте. Вы сразу работаете с сообщениями, причем любой МК может когда хочет "говорить", т.е. система мультимастерная, а на RS485 придётся это всё самому городить программно. Немного переплатить за CAN модуль считаю будет оправдано, чтоб не парится со стабильностью шины, и направить свою энергию сразу на реализацию задуманного.
В принципе да, если нужна "мультимастерная" система, то при самостоятельной реализации придется поиграться. Но если в системе один "мастер", то все достаточно тривиально и можно делать на MAX485.
На варианте 2 кварц на 8 кгц, на варианте 3 - 16кгц. Есть ли разница?
Возможно ли к одной arduino подключить 2 моста CAN - SPI?
На варианте 2 кварц на 8 кгц, на варианте 3 - 16кгц. Есть ли разница?
Возможно ли к одной arduino подключить 2 моста CAN - SPI?
Естественно. Советую почитать что такое SPI. И как оно работает.
На варианте 2 кварц на 8 кгц, на варианте 3 - 16кгц. Есть ли разница?
Возможно ли к одной arduino подключить 2 моста CAN - SPI?
Ошибся, МГц конечно же.
Что скажете про такой вариант:
В каждом "узле" связка arduino mini pro + can-spi + hc05. По can-spi реализовать шину между узлами. По bluetooth заливать скетчи. Для всех hc05 отдельная линия питания. Давать напряжение на эту линию только когда требуется обновление скетчей.
небольшая разница есть - для маленького модуля нужно использовать библиотеку, поддерживающую 8 Мгц
да, я так пробовал - работает, т.е. к одной ардуино можно подключать несколько CAN шин.
[quote=MaksVV]
небольшая разница есть - для маленького модуля нужно использовать библиотеку, поддерживающую 8 Мгц
Если заменить кварц на 16мгц - устройство будет работать так же, как большой модуль? Т.е. различие на схематическом уровне только в номинале кварца?
да я менял кварц на 16. все работает
На варианте 2 кварц на 8 кгц, на варианте 3 - 16кгц. Есть ли разница?
Возможно ли к одной arduino подключить 2 моста CAN - SPI?
А еще на варианте 1 - питание 1,8в;на 2ом-3,3В , а на 3-ем -все 5. Будет работать под катушкой зажигания с 12-ти вольтового ИЖ с тремя цилиндрами при температуре масла в коробке заднего моста радиатора +127С или нет?
Админы! Снимите бан с Клапауция хотя бы на неделю!
Ребятки, а почему никто не предложил самый очевидный вариант?
Если у вас множество ардуин, которыми нужно централизованно управлять и удобно перепрошивать - используйте штатный usb в связке с микрокомпьютером. Купите какой-нибудь фруктовый Пи* (Raspberry Pi, Orange Pi, Banana Pi - по вкусу, лично я бы апельсинку воткнул), возьмите сколько нужно arduino nano (дешевый и малогабаритный вариант с usb) и все ардуины через необходимое количество usb-хабов (хабы располагаются где угодно, лучше всего - в местах скопления ардуин) подключите к Пи. К той же Пи - небольшой сенсорный экранчик для контроля и управления.
Нюанс - если система будет потреблять много энергии, то некоторые из хабов должны предусматривать дополнительное питание.
Минус - надо ориентироваться в линуксе. Для виндузятников придется вместо дешевых Pi взять какую-нибудь малогабаритную машинку на intel atom. Атомный комп существенно дороже - около сотни вечнозеленых, других противопоказаний нет.
Ребятки, а почему никто не предложил самый очевидный вариант?
А у ТС все ардуины и так не могут найти общего языка. А вы тут малину на линухе , апельсину - на ХР и банан - на бананОС предлагаете. Он даже блинк еще не пробывал залить в ардуину.
Ну так в том и суть, чтобы всю сложную логику переложить на компьютер, с которым ТС наверняка имел дело. Можно без ограничений выбирать языки программирования (в т.ч. задачу первому попавшемуся IT-студенту поставить), нет строгих ограничений на использование памяти и т.п. А ардуино остаются фактически как интерфейсы между датчиками и компьютером - на них только простейший код. Собственно, если логистика (в смысле - расположение датчиков и длина кабелей) позволяет, то к фруктовым пи цифровые датчики и напрямую можно подключать, в отличие от микродесктопов на атоме.
А еще на варианте 1 - питание 1,8в;на 2ом-3,3В , а на 3-ем -все 5.
Это не правда.
CAN идеологически ближе к RS485, чем к i2c. Т.е. более защишена от помех, и передача возможна на большие расстояния. i2c все-таки рассчитан был на обмен между микросхемами в пределах одного устройства.
Но я бы рекомендовал использовать RS485, его реализация дешевле CAN, микросхемы MAX485 стоят копейки
Ребята сделали нам комплекс на i2c, в пределах стола у них все прекрасно работало, но когда разместили на объекте через 10-30 метровые кабеля работало страшно нестабильно.
Если все же есть желание по шине i2c то поищите i2c-extender, я применил p82b715. Пока никто не жалуется.
говорю же CAN шина тут нужна, никакие не i2c и тем более малины апельсины
Заказал 3 комплекта pro mini, can-spi (mpc2515), hc05. И на всякий случай usb-ttl пару. Хотя можно и мегой шить. После праздников начну пытать мегу)
вот как собрать анализатор кан шины (сниффер), делов на 5 мин. Вещь крайне необходимая при работе с шиной CAN, этим сниффером можно автомобильный CAN сканировать, записывать трейс сообщений, воспроизводить и т.д.