[BYTE_1_SIGNED, 1, 10, 20, 04,01][0] 1 й датчик температуры
[BYTE_1_SIGNED, 1, 10, 20, 04,01][1] 2 й датчик температуры
[BYTE_1_SIGNED, 1, 10, 20, 04,01][2] 3 й датчик температуры
[BYTE_1, 1, 10, 20, 04,03][3] 1 й датчик влажности
Точно, не внимательно посмотрел в первый раз. Так можно попробовать. Тогда не придётся лишние пустые ячейки в массиве занимать. Будут только те, которые присутствуют на узле. Как то так:
тип парам. номер тип данных значение посл.знач. адрес 1-го узла адрес 2-го узла
[BYTE_1_SIGNED, 1, 10, 20, 04,01][0] 1 й датчик температуры
[BYTE_1_SIGNED, 1, 10, 20, 04,01][1] 2 й датчик температуры
[BYTE_1_SIGNED, 1, 10, 20, 04,01][2] 3 й датчик температуры
[BYTE_1, 1, 10, 20, 04,03][3] 1 й датчик влажности
Точно, не внимательно посмотрел в первый раз. Так можно попробовать. Тогда не придётся лишние пустые ячейки в массиве занимать. Будут только те, которые присутствуют на узле. Как то так:
тип парам. номер тип данных значение посл.знач. адрес 1-го узла адрес 2-го узла
Ок. Я просто думал по твоему ответу что логика жестко зашита.
Тогда все в порядке. Массив заполняеется как порядковый № устрйства на изделии, тип устройства, № устройства такого то типа, куда отправлять 1, куда отправлять 2, его переменные параметры.
Красиво - понятно.
Иницирующие параметры в eprom
Например адрес 50-54 первое устройство, 55-59 второе и т.д.
При запуске читаем епром, иницируем массив, начинаем читать переменные с датчиков.
Потом любой блок может к массиву обратиться для считывания и записи переменных параметров, а если подумать то можно как с ID CAn параметры настроечные формировать. Не x,y,z,a,b,c а xyzabc
В итоге будет не
[BYTE_1_SIGNED, 1, 10, 20, 04,01][0]
а
[SS][xyzabc, VV, RR] SS порядковый номер, xyzabc - Разбираемый ID в котором тип, № и куда отправлять1 и 2, VV - сам параметр RR - последнее значение параметра (причем RR спорный параметр, см. выше)
Да немного сложнее разбирать и формировать (но опыт то по разбору CAN ID), но думаю памяти сожрет меньше
а лучше вообще по максимуму к структуре ID привести, это я например накидал.
сделал версию 18. Сейчас присутсвует действительно тип параметра и номер датчика. Ответ параметра будет такой (добавился только байт номера датчика).
В поле данных запроса параметра теперь байты означают не тип параметра , а номер датчика.
Т.е. за один запрос мы можем запросить только один из типов параметра, но несколько номеров датчиков.
Пример ответа параметра смостри выше по ссылке (будет такой). Пример запроса параметра вот:
13040B01 56 01 03 02
т.е. узел 04 запросил у узла 0B тип параметра 01 датчики № 01, 03 и 02. Наблюдать ответ в канхакере нужно делая, трейс данных, т.к. ID одинаковый будет у одного типа параметра но разных датчиков - то мы не успеем увидеть все ответы, а в трейсе данных все фреймы записывыаются как на магнитофонную ленту - просмотреть можно.
Загрузка ОЗУ МЕГИ 15% UNO 65%. Неплохо получилось.
сделал версию 18. Сейчас присутсвует действительно тип параметра и номер датчика. Ответ параметра будет такой (добавился только байт номера датчика).
В поле данных запроса параметра теперь байты означают не тип параметра , а номер датчика.
Т.е. за один запрос мы можем запросить только один из типов параметра, но несколько номеров датчиков.
Пример ответа параметра смостри выше по ссылке (будет такой). Пример запроса параметра вот:
13040B01 56 01 03 02
т.е. узел 04 запросил у узла 0B тип параметра 01 датчики № 01, 03 и 02. Наблюдать ответ в канхакере нужно делая, трейс данных, т.к. ID одинаковый будет у одного типа параметра но разных датчиков - то мы не успеем увидеть все ответы, а в трейсе данных все фреймы записывыаются как на магнитофонную ленту - просмотреть можно.
Загрузка ОЗУ МЕГИ 15% UNO 65%. Неплохо получилось.
Супер! Вечером залью. Кстати заливка упростилась на порядок, мастер слейв по USB и скрипт для заливки однотипной прошивки!
После привязки к епром массива параметров будет еще проще
В общем я думаю разобрался почему были глюки. Я в библиотеке отключил DEBUG. И вот видимо этий милисекунд которые тратились на вывод в сериал не хватало на переинициализацию. + Начил отлавливать на нескольких mcp2515 аппаратные глюки и ошибки инициализации. Их просто нужно поменять.
может делать внешний вочдог ардуине с помощью ESP?, т.е. еспшка будет периодически проверять Дуню на предмет жив или мертв, и, в случае чего, посылать сигнал на ногу РЕСЕТ ардуино. У тебя что залито в ESP?
может делать внешний вочдог ардуине с помощью ESP?, т.е. еспшка будет периодически проверять Дуню на предмет жив или мертв, и, в случае чего, посылать сигнал на ногу РЕСЕТ ардуино. У тебя что залито в ESP?
MaksVV пишет:
может делать внешний вочдог ардуине с помощью ESP?, т.е. еспшка будет периодически проверять Дуню на предмет жив или мертв, и, в случае чего, посылать сигнал на ногу РЕСЕТ ардуино. У тебя что залито в ESP?
Умеет дать ресет по Web, MQTT, REST,SLIP путем выдачи c GPIO ESP на ресет меги + може передать комадну по сериал.
Саму ESP тоже можно отдельно от меги ресетить и переливат прошивку. Она может быть как клиентом точки доступа так и сама точкой доступа.
2. Считаю что нужно разделить ресеты на уровни
Во первых разделить ресет МК и обвязки в т.ч. MCP2515 и ESP
Вот что у нас есть
- Watchdog (это пред последний уровень защиты ситемы, после нее только ресет питания с помощью реле, а дельше только руками) https://habr.com/post/189744/ постоянный вызов в loop - wdt_reset();
пока вызываетcz , контроллер не сбросится. Как только система зависнет и эта функция вызываться перестанет, то по истечении заданного периода произойдет перезагрузка.
- Добавил, чтобы одним запросом можно было запросить все датчики одного типа параметра. (№ датчика при этом нужно запрашивать со значением 0. )
- изменены названия типов сообщений, а то я всё время путался.
- В отладку добавлена функция проверки правильности конфигурации массива параметров. Если забить датчики с одинаковым номером на один и тот же тип параметра - будет выдавать ошибку.
И всё таки, ты подключал на ночь канхаер? Ловит ли он глюкавые сообщения? или же эти глюки возникают непосредственно на узлах, а не на всей шине?
у меня функция Print начинается с большой буквы. А везде используется с маленькой. Так что проблем нет.
У меня конфликтует с библиотекой Ethernet.h и без переименоввывания в 50 местах ф-и Print ничего не работает. Так что далее я не в состоянии без того чтобы тратить час времени на переименование использовать код. Процесс опять сильно занянестся.
MaksVV пишет:
И всё таки, ты подключал на ночь канхаер? Ловит ли он глюкавые сообщения? или же эти глюки возникают непосредственно на узлах, а не на всей шине?
шилд примерно такой. Часть пинов на меге вниз припаевается (показано желтым), остальные вверх. Т.е. мега насаживается на шилд, на котором MCP2515 и ESP.
шилд примерно такой. Часть пинов на меге вниз припаевается (показано желтым), остальные вверх. Т.е. мега насаживается на шилд, на котором MCP2515 и ESP.
А где платы печать будешь? В китае? Я тоже штук 20 таких шилдов бы заказал, сразу в сборе.
Если Gerber и Э3 пришлешь бeду благодарен. Самому просто сил нет трассировку делать.
P.S. Ты по механике как крепить MCP2515 к шилду собираешься? Отверстий или поодержек не увидел. Или на разъеме все держаться будет? Жескости тогда хватит?
плата сделана в layout 6 . На скорую руку. Но в гербер вроде как можно экспортировать. Изготавливать собираюсь ЛУТом, у меня немного узлов. MCP в шилд скорее всего припаивать придётся, либо садить на более низкую кроватку, чем мега. 3д модель не делал, не умею.
плата сделана в layout 6 . На скорую руку. Но в гербер вроде как можно экспортировать. Изготавливать собираюсь ЛУТом, у меня немного узлов. MCP в шилд скорее всего припаивать придётся, либо садить на более низкую кроватку, чем мега. 3д модель не делал, не умею.
Спасибо! А принципиальную схему рисовал (Э3)? Там же обвязка к ESP. Резисторы по 10к и пр веселье. И ругается на отсутствие подложки Mega.bmp
подложку *.bmp можешь удалить (опции/загрузить шаблон/ удалить). Она нужна была когда рисовал отверстия под мегу. Схему не рисовал. ESP я так подключал, у меня работало. Я у тебя схему чё раньше и просил, как ты есп подключаешь. Эту или подбную статью читал. Давно хотел найти время научиться платы рисовать в pcb и в китае заказывать, но пока не дошёл ещё до этого. Понятно, что там качество огонь, к тому же две стороны. Ценник норм, единственное ждать нужно. Также перед заказом обязательно надо самому прототип за лутить, а то косяки всегда бывают, пока не сделаешь плату - не выявишь. А то закажешь опт, а там косяки.
На счёт разъема, с таким конкретно я не сталкивался, но подобные обжимал. В принципе размер норм для обжатия без спец обжимок - даже кусачками. Но имхо d-sub везде есть, быстрее найти, паять тоже быстрее чем обжимать. тем более d-sub в навесном варианте можно использовать. Хотя разъем на плате конечно это лучше, но такой вариант только для заводской платы подходит, т.к. трассировать двухрядные разъемы на односторонней плате это шляпа, тем более у меги тоже по два ряда пины.
На счёт 10К резисторов, они в общем то и не нужны, без них работает все. Я так понимаю они от ошибок, чтоб КЗ не устроить.
в общем собрал шилд. Если оба ряда пинов меги полностью припаивать, то MCP совсем чуть чуть не вмещается, буквально доли милиметра. Вернее мега потом не лезет, т.к. контакты распирает.
Но если есть дремель , проблема решается за пару сек.
Но, собственно, это совсем не нужно, т.к. все ряды можно не запаивать. В одном ряду нужно всего 4 пина, в другом чуть больше, тогда нормально MCP лезет без подпиливания:
MCP я попробовал ставить на более низкую кроватку, но т.к. один ряд - держется очень шатко, контакт плохой может быть, к тому же по высоте в мегу уже упирается, поэтому МСП лучше запаивать, уперев ее до кварца, держится очень крепко:
Получается такой будерброд. На неиспользуемые в шилде контакты меги можно вверх пины припаять (предпочтительно) или пустыми оставить, чтобы проводки припаять (имхо это не очень):
ЕСП шка тут:
Понятно, что это колхоз. На двусторонней плате заводского исполнения бы получилось и опторазвязки сделать и разъем двухрядный поставить, не увеличивая размеры платы.
На счет разъёма, можно так сделать, взяв шлейф от флоппаря:
шилд примерно такой. Часть пинов на меге вниз припаевается (показано желтым), остальные вверх. Т.е. мега насаживается на шилд, на котором MCP2515 и ESP.
Чтобы антенна (модуля ESP-12) правильно работала, она должна "висеть в воздухе". Под ней не должно быть ни дорожек, ни даже просто стеклотекстолита без меди.
Если под антенной стеклотекстолит без дорожек, то дальность связи снизится раза в 2-3. Если стеклотекстолит с дорожками - то раз в 10, или вообще работать не будет.
С такой разводкой надо поднять модуль над платой примерно на сантиметр или более,
у меня валяется два кан трансивера. Не поленюсь подключу к уарт. Посмотрим, долетят ли байты от одного МК до другого. Что то я сомневаюсь, если честно.
А почему сомневаетесь, если не секрет? Что особенного есть в контроллере CAN, из-за чего байты, отправленные им, непременно доходят до другого МК? И какой волшебной субстанции не хватает обычному UART, чтобы достичь того же результата?
подключил два транссивера на софтсериал Tx и Rx двух ардуин. Залил стандартный скетч примера софтсериал. Ничего НЕ передается и НЕ принимается. Менял местами TX и RX в скетче, бесполезно. Резистор тоже пробовал убирать, не помогает. Не работает ваша схема гибрида uart и can
подключил два транссивера на софтсериал Tx и Rx двух ардуин. Залил стандартный скетч примера софтсериал. Ничего НЕ передается и НЕ принимается. Менял местами TX и RX в скетче, бесполезно. Резистор тоже пробовал убирать, не помогает. Не работает ваша схема гибрида uart и can
Увидел вашу тему)) И если кому интересна модульная система для например системы умный дом могу выложить сюда фото ссылки на корпуса и платы которые я делал под свою систему домашней автоматики но там все они общаются по MODBUS. Уже платы запилины под заводские недорогие корпуса фирмы меандр и т.д. Так что если кому интересно то найду время и выложу все.
Увидел вашу тему)) И если кому интересна модульная система для например системы умный дом могу выложить сюда фото ссылки на корпуса и платы которые я делал под свою систему домашней автоматики но там все они общаются по MODBUS. Уже платы запилины под заводские недорогие корпуса фирмы меандр и т.д. Так что если кому интересно то найду время и выложу все.
Ну так вот затравочка. Че на данный момент собрано. Основной модуль ПЛК как бы + модуль расширительный на дискретные ввод с гальванической развякой + 2а модуля приемники 433. Почему два да просто один модуль у меня для опроса Орегоновских датчиков 4 штуки второй для всех ост альных датчиков на 433 охранных. Вот пока фоточки для затравочки) Та кже пример опроса по модбасс модуля на орегоновские датчики 12 регистров по 3и регистра на каждый датчик. Привязка к ID датчика автоматическая и т.д.
подключил два транссивера на софтсериал Tx и Rx двух ардуин. Залил стандартный скетч примера софтсериал. Ничего НЕ передается и НЕ принимается. Менял местами TX и RX в скетче, бесполезно. Резистор тоже пробовал убирать, не помогает. Не работает ваша схема гибрида uart и can
А если напрямую соединить TX-RX, RX-TX, без модулей CAN, неужто работает? Что-то сомневаюсь.
1. Вы поставили нестандартную бодовую скорость 125000, хотя SoftwareSerial больше 57600 не тянет. А в примере у них 4800 стоит.
2. Если исправить бодовую на 4800, то напрямую будет работать, а через модули CAN - опять не будет. Потому что в этих фиолетовых модулях стоят микросхемы TJA1051, у которых стоит защита (тайм-аут) от постоянного доминантного уровня. Если на вход подать "0", то через 0.3...5мс выход передатчика автоматически выключится. То есть, на скоростях ниже 30 кбит/сек они могут портить передаваемые символы. Они годятся для скоростей 50 кбит/сек и выше.
Попробуйте не фиолетовые китайские модули, а синенькие. Там стоит SN65HVD230, у него нет тайм-аута, он на любых скоростях может работать.
Однако MCP2551 требует питания 5В, а вы его запитали от 3.3В. "Чудес не бывает" (с)
Да, в этом и было дело. Подтверждаю, теперь работает ваша схема. Только не знаю зачем я ее проверял, так для любопытства. Проверял на 115200 и 9600, обе работают.
взялся посадить на плату основной МК в моей модульной системе. А то так и работает на "соплях" уже три года. На эту мотню из проводов смотреть страшно. Купил распр щиток, рисую плату, положу всё туда.
Основной МК у меня отвечает в основном за коммуникацию (SIM900 и ESP wi-fi), а также
тиканием часов DS3231 , контролем t DS18B20 , контролем сети 220В (ток, напряжение, мощность, кВт*часы) PZEM004T, оповещением при помощи mp3 Df Player mini и усилка PAM8403, вывод кое каких данных на LCD 20_4 для контроля, пищалкой buzzer при внештатных ситуациях,
Пока такой вариант платы, пилим дальше. файл layout
на вырост. плату разведу. Пока одна шина, соответственно здесь один MCP2515. Просто стандарт CAN шины звездой не позволяет топологию делать, я так понял. Тем более у тебя вон как не стабильно много МК работают, и до сих пор хз почему. Если понадобится делать ответвления, то лучи у меня пойдут от этого МК и каждый луч будет своя шина, а данный МК будет шлюзом между ними.
CAN это мульти мастер, каждый узел может начать передачу данных с арбитражем шины, а 485 это моно мастер, где один узел опрашивает остальные. Если использовать контроллеры для событий реального времени то будет существенная задержка. Сработал датчик движения а свет загорелся через 1-2 секунды.
Это не совсем правда) у меня все на шине 485 и включение моментальное 1 сек и то если учесть что через ESP еще передача на сервер валит))) Просто крупные производители автоматики промышленной и домашней не с проста выбрали данный интерейс) Ну тут дело каждого. ПРосто тема про умный дом и поэтому я и спросил в рамках этого проекта. В таких системах в основном один мастер. В машине же иначе все поэтому там выгоднее кан например. Ну в целом я понял вашу логику. А по функционалу вы что планируете сделать? Все что вы описали выше делает один мастер вроде как.
А зачем их все хранить?
Нужно определить что нужно хранить а что можно перезапросить.
Все климатические параметры хранить нет смысла. Состояние ламп вкл/выкл спорно можно и опросить,
Бузусловно нужно хранить например количество людей в помещении да и то нужно определить где хранить на light или main. А вот все остальное зачем?
а если CAN лёг , мы в автономный режим переходим. откуда брать эти не хранящиеся параметры? замерять каждый раз когда они требуются?
А почему нет. Давай не путать протокол обмена и внутренняя логика работы. Опять смотри на логику построения умной теплицы. Он все классно расписал.
Если блочно
1. Блок работы с CAN (задача передачи приема команд и параметров)
2. Блок работы с ИУ (с возможностью ДУ) работает под управлением блока автомномной логики с возможностью ДУ
3. Блок работы с датчиками выдает параметры в блок автономной логики и в CAN
4. Блок автономной логики принимает решения на управляющие воздействия с возможностью ДУ
Это упрощенно
См. #1008
Кстати я поэтому и говорил в начале про функции с параметрами.
Функцию пыполнения чего то может вызвать как RX в CASE так и в LOOP (но лучше отдельная секция) по таймерами или событиям.
В общем давай я алгоритм нарисую.
А нельзя как я выше писал
Точно, не внимательно посмотрел в первый раз. Так можно попробовать. Тогда не придётся лишние пустые ячейки в массиве занимать. Будут только те, которые присутствуют на узле. Как то так:
А нельзя как я выше писал
Точно, не внимательно посмотрел в первый раз. Так можно попробовать. Тогда не придётся лишние пустые ячейки в массиве занимать. Будут только те, которые присутствуют на узле. Как то так:
Ок. Я просто думал по твоему ответу что логика жестко зашита.
Тогда все в порядке. Массив заполняеется как порядковый № устрйства на изделии, тип устройства, № устройства такого то типа, куда отправлять 1, куда отправлять 2, его переменные параметры.
Красиво - понятно.
Иницирующие параметры в eprom
Например адрес 50-54 первое устройство, 55-59 второе и т.д.
При запуске читаем епром, иницируем массив, начинаем читать переменные с датчиков.
Потом любой блок может к массиву обратиться для считывания и записи переменных параметров, а если подумать то можно как с ID CAn параметры настроечные формировать. Не x,y,z,a,b,c а xyzabc
В итоге будет не
[BYTE_1_SIGNED, 1, 10, 20, 04,01][0]
а
[SS][xyzabc, VV, RR] SS порядковый номер, xyzabc - Разбираемый ID в котором тип, № и куда отправлять1 и 2, VV - сам параметр RR - последнее значение параметра (причем RR спорный параметр, см. выше)
Да немного сложнее разбирать и формировать (но опыт то по разбору CAN ID), но думаю памяти сожрет меньше
а лучше вообще по максимуму к структуре ID привести, это я например накидал.
сделал версию 18. Сейчас присутсвует действительно тип параметра и номер датчика. Ответ параметра будет такой (добавился только байт номера датчика).
В поле данных запроса параметра теперь байты означают не тип параметра , а номер датчика.
Т.е. за один запрос мы можем запросить только один из типов параметра, но несколько номеров датчиков.
Пример ответа параметра смостри выше по ссылке (будет такой). Пример запроса параметра вот:
13040B01 56 01 03 02
т.е. узел 04 запросил у узла 0B тип параметра 01 датчики № 01, 03 и 02. Наблюдать ответ в канхакере нужно делая, трейс данных, т.к. ID одинаковый будет у одного типа параметра но разных датчиков - то мы не успеем увидеть все ответы, а в трейсе данных все фреймы записывыаются как на магнитофонную ленту - просмотреть можно.
Загрузка ОЗУ МЕГИ 15% UNO 65%. Неплохо получилось.
сделал версию 18. Сейчас присутсвует действительно тип параметра и номер датчика. Ответ параметра будет такой (добавился только байт номера датчика).
В поле данных запроса параметра теперь байты означают не тип параметра , а номер датчика.
Т.е. за один запрос мы можем запросить только один из типов параметра, но несколько номеров датчиков.
Пример ответа параметра смостри выше по ссылке (будет такой). Пример запроса параметра вот:
13040B01 56 01 03 02
т.е. узел 04 запросил у узла 0B тип параметра 01 датчики № 01, 03 и 02. Наблюдать ответ в канхакере нужно делая, трейс данных, т.к. ID одинаковый будет у одного типа параметра но разных датчиков - то мы не успеем увидеть все ответы, а в трейсе данных все фреймы записывыаются как на магнитофонную ленту - просмотреть можно.
Загрузка ОЗУ МЕГИ 15% UNO 65%. Неплохо получилось.
Супер! Вечером залью. Кстати заливка упростилась на порядок, мастер слейв по USB и скрипт для заливки однотипной прошивки!
После привязки к епром массива параметров будет еще проще
ну как со стабильностью? я думаю должен был помочь delay (5). Если всё равно глюки есть , ты заливал простой скетч?
В общем я думаю разобрался почему были глюки. Я в библиотеке отключил DEBUG. И вот видимо этий милисекунд которые тратились на вывод в сериал не хватало на переинициализацию. + Начил отлавливать на нескольких mcp2515 аппаратные глюки и ошибки инициализации. Их просто нужно поменять.
Вот так получается стабильная перезагрузка
01
00:11:40:00
02
NODES CAN COMMUNICATION:
03
node_5_Net_center_Due2 OK!!!
04
node_6_Hallway_net_center OK!!!
05
node_7_Hallway_main OK!!!
06
node_8_Hallway_light OK!!!
07
node_9_Kitchen_net_center OK!!!
08
node_10_Kitchen_main OK!!!
09
node_11_Kitchen_light OK!!!
10
node_12_WC_main OK!!!
11
node_13_WC_waterleak OK!!!
12
node_14_Bathroom_main OK!!!
13
node_15_Boxroom_main OK!!!
14
node_16_Balcony_meteo FAIL!!!
15
node_18_Loggia_recuperator OK!!!
16
node_19_Livingroom_main OK!!!
17
node_20_Bedroom_main OK!!!
18
node_21_Cabinet_main OK!!!
19
20
00:11:40:08 Принято из CAN: Неизвестное сообщение От Кого: node_9_Kitchen_net_center - ID 9E090400 00 00 00 00 00 00 00 00
21
Entering Configuration Mode Successful!
22
Setting Baudrate Successful!
23
Starting to Set Mask!
24
Setting Mask Successful!
25
Starting to Set Filter!
26
Setting Filter Successfull!
27
Starting to Set Filter!
28
Setting Filter Successfull!
29
Starting to Set Mask!
30
Setting Mask Successful!
31
Starting to Set Filter!
32
Setting Filter Successfull!
33
Starting to Set Filter!
34
Setting Filter Successfull!
35
Starting to Set Filter!
36
Setting Filter Successfull!
37
Starting to Set Filter!
38
Setting Filter Successfull!
39
MCP2515 Initialized Successfully!
40
41
РЕСТАРТ MCP2515
42
43
00:11:40:30
44
NODES CAN COMMUNICATION:
45
node_5_Net_center_Due2 OK!!!
46
node_6_Hallway_net_center OK!!!
47
node_7_Hallway_main OK!!!
48
node_8_Hallway_light OK!!!
49
node_9_Kitchen_net_center OK!!!
50
node_10_Kitchen_main OK!!!
51
node_11_Kitchen_light OK!!!
52
node_12_WC_main OK!!!
53
node_13_WC_waterleak OK!!!
54
node_14_Bathroom_main OK!!!
55
node_15_Boxroom_main OK!!!
56
node_16_Balcony_meteo FAIL!!!
57
node_18_Loggia_recuperator OK!!!
58
node_19_Livingroom_main OK!!!
59
node_20_Bedroom_main OK!!!
60
node_21_Cabinet_main OK!!!
Теперь нужно ватчдог от зависания МК, софт ресет МК, аппаратный ресет MCP через GPIO и можно переходить уже к алгоритмам работы.
может делать внешний вочдог ардуине с помощью ESP?, т.е. еспшка будет периодически проверять Дуню на предмет жив или мертв, и, в случае чего, посылать сигнал на ногу РЕСЕТ ардуино. У тебя что залито в ESP?
может делать внешний вочдог ардуине с помощью ESP?, т.е. еспшка будет периодически проверять Дуню на предмет жив или мертв, и, в случае чего, посылать сигнал на ногу РЕСЕТ ардуино. У тебя что залито в ESP?
+ може передать комадну по сериал.
Так тоже можно, но лезть в код готового изделия типа ESP-LINK не охота. Он есть в исходниках. Но поставляется прошивкой для ESP
Контроль можно осуществлять Majordomo
И еще просьба поменяй название функции в debug.h с print на print1, онаиспользуется в куче классов библиотек.
Вообще поосторожнее с именами функций которые кажутся очевидными.
у меня функция Print начинается с большой буквы. А везде используется с маленькой. Так что проблем нет.
В скетче, рядом с номером версии, теперь буду писать - что изменилось, добавилось и т.д.
Версия 19.
- Добавил, чтобы одним запросом можно было запросить все датчики одного типа параметра. (№ датчика при этом нужно запрашивать со значением 0. )
- изменены названия типов сообщений, а то я всё время путался.
- В отладку добавлена функция проверки правильности конфигурации массива параметров. Если забить датчики с одинаковым номером на один и тот же тип параметра - будет выдавать ошибку.
И всё таки, ты подключал на ночь канхаер? Ловит ли он глюкавые сообщения? или же эти глюки возникают непосредственно на узлах, а не на всей шине?
у меня функция Print начинается с большой буквы. А везде используется с маленькой. Так что проблем нет.
У меня конфликтует с библиотекой Ethernet.h и без переименоввывания в 50 местах ф-и Print ничего не работает. Так что далее я не в состоянии без того чтобы тратить час времени на переименование использовать код. Процесс опять сильно занянестся.
И всё таки, ты подключал на ночь канхаер? Ловит ли он глюкавые сообщения? или же эти глюки возникают непосредственно на узлах, а не на всей шине?
Сообщения проскакивают но не много.
ок, в след. редакции поменяю
шилд примерно такой. Часть пинов на меге вниз припаевается (показано желтым), остальные вверх. Т.е. мега насаживается на шилд, на котором MCP2515 и ESP.
шилд примерно такой. Часть пинов на меге вниз припаевается (показано желтым), остальные вверх. Т.е. мега насаживается на шилд, на котором MCP2515 и ESP.
А где платы печать будешь? В китае? Я тоже штук 20 таких шилдов бы заказал, сразу в сборе.
Если Gerber и Э3 пришлешь бeду благодарен. Самому просто сил нет трассировку делать.
P.S. Ты по механике как крепить MCP2515 к шилду собираешься? Отверстий или поодержек не увидел. Или на разъеме все держаться будет? Жескости тогда хватит?
В какой программе трасировку делал?
3D модель делал?
плата сделана в layout 6 . На скорую руку. Но в гербер вроде как можно экспортировать. Изготавливать собираюсь ЛУТом, у меня немного узлов. MCP в шилд скорее всего припаивать придётся, либо садить на более низкую кроватку, чем мега. 3д модель не делал, не умею.
можешь потом к меге проводочки припаивать в GPIO и далее разъем D-SUB 25, в корпусе которого можно монтировать оптопары.
плата сделана в layout 6 . На скорую руку. Но в гербер вроде как можно экспортировать. Изготавливать собираюсь ЛУТом, у меня немного узлов. MCP в шилд скорее всего припаивать придётся, либо садить на более низкую кроватку, чем мега. 3д модель не делал, не умею.
Спасибо! А принципиальную схему рисовал (Э3)? Там же обвязка к ESP. Резисторы по 10к и пр веселье. И ругается на отсутствие подложки Mega.bmp
можешь потом к меге проводочки припаивать в GPIO и далее разъем D-SUB 25, в корпусе которого можно монтировать оптопары.
Я вот на такой разъем запал DJ7120XR-1.2 http://pke1.ru/catalog/razemy/avt-soediniteli/94892
Что скажешь по нему. Тебе эта тематика ближе.
3д модель не делал, не умею.
Если в альтиуме делать то там сразу полный комплект. Э3, 3D деталей, Gerber
Вот глянь https://mysku.ru/blog/taobao/34130.html
Такая плата как у тебя будет аж рублей 500 за 10 шт стоить.
подложку *.bmp можешь удалить (опции/загрузить шаблон/ удалить). Она нужна была когда рисовал отверстия под мегу. Схему не рисовал. ESP я так подключал, у меня работало. Я у тебя схему чё раньше и просил, как ты есп подключаешь. Эту или подбную статью читал. Давно хотел найти время научиться платы рисовать в pcb и в китае заказывать, но пока не дошёл ещё до этого. Понятно, что там качество огонь, к тому же две стороны. Ценник норм, единственное ждать нужно. Также перед заказом обязательно надо самому прототип за лутить, а то косяки всегда бывают, пока не сделаешь плату - не выявишь. А то закажешь опт, а там косяки.
На счёт разъема, с таким конкретно я не сталкивался, но подобные обжимал. В принципе размер норм для обжатия без спец обжимок - даже кусачками. Но имхо d-sub везде есть, быстрее найти, паять тоже быстрее чем обжимать. тем более d-sub в навесном варианте можно использовать. Хотя разъем на плате конечно это лучше, но такой вариант только для заводской платы подходит, т.к. трассировать двухрядные разъемы на односторонней плате это шляпа, тем более у меги тоже по два ряда пины.
ты не знаешь, в таком варианте китайцы примут плату к изготовлению? Хочу заказать у китайцев платки канхакера на стм.
Я у тебя схему чё раньше и просил, как ты есп подключаешь.
Извини видимо упустил
вот пайка и схема, я ее упростил, ресет мне не нужен прошиваю припаяв перемычку.
ты не знаешь, в таком варианте китайцы примут плату к изготовлению? Хочу заказать у китайцев платки канхакера на стм.
Это у тебя выгрузка из альтиум, как раз был pcb экспортированный в pdf, попробуй отправить может примут.
В альтиум не загрузить в лоб. Может есть тулзы обратного преобразования но я не знаю.
На счёт 10К резисторов, они в общем то и не нужны, без них работает все. Я так понимаю они от ошибок, чтоб КЗ не устроить.
в общем собрал шилд. Если оба ряда пинов меги полностью припаивать, то MCP совсем чуть чуть не вмещается, буквально доли милиметра. Вернее мега потом не лезет, т.к. контакты распирает.
Но если есть дремель , проблема решается за пару сек.
Но, собственно, это совсем не нужно, т.к. все ряды можно не запаивать. В одном ряду нужно всего 4 пина, в другом чуть больше, тогда нормально MCP лезет без подпиливания:
MCP я попробовал ставить на более низкую кроватку, но т.к. один ряд - держется очень шатко, контакт плохой может быть, к тому же по высоте в мегу уже упирается, поэтому МСП лучше запаивать, уперев ее до кварца, держится очень крепко:
Получается такой будерброд. На неиспользуемые в шилде контакты меги можно вверх пины припаять (предпочтительно) или пустыми оставить, чтобы проводки припаять (имхо это не очень):
ЕСП шка тут:
Понятно, что это колхоз. На двусторонней плате заводского исполнения бы получилось и опторазвязки сделать и разъем двухрядный поставить, не увеличивая размеры платы.
На счет разъёма, можно так сделать, взяв шлейф от флоппаря:
шилд примерно такой. Часть пинов на меге вниз припаевается (показано желтым), остальные вверх. Т.е. мега насаживается на шилд, на котором MCP2515 и ESP.
Чтобы антенна (модуля ESP-12) правильно работала, она должна "висеть в воздухе". Под ней не должно быть ни дорожек, ни даже просто стеклотекстолита без меди.
Если под антенной стеклотекстолит без дорожек, то дальность связи снизится раза в 2-3. Если стеклотекстолит с дорожками - то раз в 10, или вообще работать не будет.
С такой разводкой надо поднять модуль над платой примерно на сантиметр или более,
планируется использовать ESP-07 c выносной антенной.
На фотографии - ESP-12 со встроенной антенной.
Керамический конденсатор 0.1 мкФ на ножки питания модуля не забудьте припаять. И желательно иметь 470 мкФ электролит в питании.
esp07 не пришел просто ещё. Кондеры да, подрисую в следующем шилде.
у меня валяется два кан трансивера. Не поленюсь подключу к уарт. Посмотрим, долетят ли байты от одного МК до другого. Что то я сомневаюсь, если честно.
А почему сомневаетесь, если не секрет? Что особенного есть в контроллере CAN, из-за чего байты, отправленные им, непременно доходят до другого МК? И какой волшебной субстанции не хватает обычному UART, чтобы достичь того же результата?
подключил два транссивера на софтсериал Tx и Rx двух ардуин. Залил стандартный скетч примера софтсериал. Ничего НЕ передается и НЕ принимается. Менял местами TX и RX в скетче, бесполезно. Резистор тоже пробовал убирать, не помогает. Не работает ваша схема гибрида uart и can
схема
скетч
01
#include <SoftwareSerial.h>
02
03
SoftwareSerial mySerial(10, 11);
// RX, TX
04
05
void
setup
() {
06
// Open serial communications and wait for port to open:
07
Serial
.begin(57600);
08
while
(!
Serial
) {
09
}
10
11
12
Serial
.println(
"Goodnight moon!"
);
13
14
15
mySerial.begin(125000);
16
mySerial.println(
"Hello, world?"
);
17
}
18
19
void
loop
() {
// run over and over
20
if
(mySerial.available()) {
21
Serial
.write(mySerial.read());
22
}
23
if
(
Serial
.available()) {
24
mySerial.write(
Serial
.read());
25
}
26
}
подключил два транссивера на софтсериал Tx и Rx двух ардуин. Залил стандартный скетч примера софтсериал. Ничего НЕ передается и НЕ принимается. Менял местами TX и RX в скетче, бесполезно. Резистор тоже пробовал убирать, не помогает. Не работает ваша схема гибрида uart и can
А осцилографом смотрел что на шине CAN?
Увидел вашу тему)) И если кому интересна модульная система для например системы умный дом могу выложить сюда фото ссылки на корпуса и платы которые я делал под свою систему домашней автоматики но там все они общаются по MODBUS. Уже платы запилины под заводские недорогие корпуса фирмы меандр и т.д. Так что если кому интересно то найду время и выложу все.
Увидел вашу тему)) И если кому интересна модульная система для например системы умный дом могу выложить сюда фото ссылки на корпуса и платы которые я делал под свою систему домашней автоматики но там все они общаются по MODBUS. Уже платы запилины под заводские недорогие корпуса фирмы меандр и т.д. Так что если кому интересно то найду время и выложу все.
Очень интересно. Буду крайне признателен.
P.S.
Сам присматривался к этим корпусам https://www.meandr.ru/plastikovye-korpusa
Ну так вот затравочка. Че на данный момент собрано. Основной модуль ПЛК как бы + модуль расширительный на дискретные ввод с гальванической развякой + 2а модуля приемники 433. Почему два да просто один модуль у меня для опроса Орегоновских датчиков 4 штуки второй для всех ост альных датчиков на 433 охранных. Вот пока фоточки для затравочки) Та кже пример опроса по модбасс модуля на орегоновские датчики 12 регистров по 3и регистра на каждый датчик. Привязка к ID датчика автоматическая и т.д.




подключил два транссивера на софтсериал Tx и Rx двух ардуин. Залил стандартный скетч примера софтсериал. Ничего НЕ передается и НЕ принимается. Менял местами TX и RX в скетче, бесполезно. Резистор тоже пробовал убирать, не помогает. Не работает ваша схема гибрида uart и can
А если напрямую соединить TX-RX, RX-TX, без модулей CAN, неужто работает? Что-то сомневаюсь.
1. Вы поставили нестандартную бодовую скорость 125000, хотя SoftwareSerial больше 57600 не тянет. А в примере у них 4800 стоит.
2. Если исправить бодовую на 4800, то напрямую будет работать, а через модули CAN - опять не будет. Потому что в этих фиолетовых модулях стоят микросхемы TJA1051, у которых стоит защита (тайм-аут) от постоянного доминантного уровня. Если на вход подать "0", то через 0.3...5мс выход передатчика автоматически выключится. То есть, на скоростях ниже 30 кбит/сек они могут портить передаваемые символы. Они годятся для скоростей 50 кбит/сек и выше.
Попробуйте не фиолетовые китайские модули, а синенькие. Там стоит SN65HVD230, у него нет тайм-аута, он на любых скоростях может работать.
у меня в модулях стоит mcp2551, скорости пробовал разные.
У MCP2551 тайм-аут 1.25 мс. Что дает минимальную скорость 9600. Однако MCP2551 требует питания 5В, а вы его запитали от 3.3В. "Чудес не бывает" (с)
Напрямую пробовали соединять? Работает?
Однако MCP2551 требует питания 5В, а вы его запитали от 3.3В. "Чудес не бывает" (с)
Да, в этом и было дело. Подтверждаю, теперь работает ваша схема. Только не знаю зачем я ее проверял, так для любопытства. Проверял на 115200 и 9600, обе работают.
скетч
01
#include <SoftwareSerial.h>
02
byte
vata;
03
SoftwareSerial mySerial(10, 11);
// RX, TX
04
uint32_t prev = 0;
05
void
setup
() {
06
07
Serial
.begin(57600);
08
while
(!
Serial
) {
09
}
10
11
12
Serial
.println(
"Goodnight moon!"
);
13
14
15
mySerial.begin(115200);
16
mySerial.println(
"Hello, world?"
);
17
}
18
19
void
loop
() {
// run over and over
20
if
(mySerial.available()) {
21
Serial
.write(mySerial.read());
22
}
23
if
(
Serial
.available()) {
24
mySerial.write(
Serial
.read());
25
}
26
27
if
(millis()- prev >1000) {
28
vata++;
29
mySerial.println(vata);
30
31
prev = millis();
32
}
33
34
35
}
как там дела у моего коллеги? Наладил свою кан шину?
Пока все забросил. То отпуск то ремонт.
взялся посадить на плату основной МК в моей модульной системе. А то так и работает на "соплях" уже три года. На эту мотню из проводов смотреть страшно. Купил распр щиток, рисую плату, положу всё туда.
Основной МК у меня отвечает в основном за коммуникацию (SIM900 и ESP wi-fi), а также
тиканием часов DS3231 , контролем t DS18B20 , контролем сети 220В (ток, напряжение, мощность, кВт*часы) PZEM004T, оповещением при помощи mp3 Df Player mini и усилка PAM8403, вывод кое каких данных на LCD 20_4 для контроля, пищалкой buzzer при внештатных ситуациях,
Пока такой вариант платы, пилим дальше. файл layout
А какой смысл в 3х MCP2515?
на вырост. плату разведу. Пока одна шина, соответственно здесь один MCP2515. Просто стандарт CAN шины звездой не позволяет топологию делать, я так понял. Тем более у тебя вон как не стабильно много МК работают, и до сих пор хз почему. Если понадобится делать ответвления, то лучи у меня пойдут от этого МК и каждый луч будет своя шина, а данный МК будет шлюзом между ними.
А почему выбрали CAN интерфейс? Почему не RS485?
CAN это мульти мастер, каждый узел может начать передачу данных с арбитражем шины, а 485 это моно мастер, где один узел опрашивает остальные. Если использовать контроллеры для событий реального времени то будет существенная задержка. Сработал датчик движения а свет загорелся через 1-2 секунды.
Это не совсем правда) у меня все на шине 485 и включение моментальное 1 сек и то если учесть что через ESP еще передача на сервер валит))) Просто крупные производители автоматики промышленной и домашней не с проста выбрали данный интерейс) Ну тут дело каждого. ПРосто тема про умный дом и поэтому я и спросил в рамках этого проекта. В таких системах в основном один мастер. В машине же иначе все поэтому там выгоднее кан например. Ну в целом я понял вашу логику. А по функционалу вы что планируете сделать? Все что вы описали выше делает один мастер вроде как.
#179 посмотрите схему. Примерно такой функционал.
Просто крупные производители автоматики промышленной и домашней не с проста выбрали данный интерейс) .
Также же крупные производители не спроста выбрают и CAN интерфейс. Просто он позже появился, поэтому более современный и имеет свои плюшки.
основные причины выбора мной CAN - более простое программирование и быстрота работы шины.