под словом игрушки надо понимать китайскую ардуину и наш говнокод? Проведу аналогию с автомобилем - мы не собираемся подушками безопасности управлять или ABS. Максимум магнитолой, климатом, оповещением об опасности.
А выглядит, как будто замахнулись на ЭБУ. Однажды вы поймете, что "электроника это наука о контактах".
triac пишет:
Полная чушь. C-bus - это синхронный канал и CSMA/CA. В каждом сегменте сети всегда есть узел, который дает импульс синхронизации каждые 2 мс. Коллизии избегаются на битовом уровне.
Учи матчасть:) C-bus это всего лишь синхронный протокол, такой же как CAN или Ethernet. А канал передачи данных асинхронный. В синхронных каналах нет и не может быть коллизий по определению.
triac пишет:
То есть, логика: "в огороде-бузина, в Киеве - дядька".
Есть несколько способов что-то сделать. Какой бы способ я ни выбрал, вылезет Andy и скажет, что этот способ не годится, потому что "есть другие способы сделать то же самое".
До тех пор пока есть межпакетный интервал глупо изобретать еще какие-то способы идентификации начала пакетов. Но ты-то начитался литературы посвященной "умным домам". Несешь, несвойственную этому ресурсу, пургу "производитель-потребитель", был бы прогером использовал бы "мастер-слейв", был бы разработчиком на ардуино не запал бы. По всему выходит, что ты и в программировании, и в схемотехнике ноль.
triac пишет:
CAN сложно и неудобно использовать.
Не сложнее, чем твой "велосипед". Одни сложности заканчиваются на канальном уровне, другие на сетевом. На уровне приложения уже фиолетово, каким образом передаются данные.
А выглядит, как будто замахнулись на ЭБУ. Однажды вы поймете, что "электроника это наука о контактах".
Работаю 10 лет автоэлектриком и уж это знаю не по наслышке.
На счёт ЭБУ может быть. В принципе у меня то уже два месяца как работает система, понятно, что в гораздо более простом виде, чем мы сейчас тут городим. Но без сбоев в плане линии CAN, от слова совсем. Не знаю, что сложного в этом протоколе нашёл triac. Используя библиотеку даже такой дилетант как я разобрался. Два года назад ты мне как раз первый и ответил, собственно с этого и началось изучение ардуино и программирования. Респект однако.
У моего коллеги проблемы скорее всего в топологии или выборе кабеля / терминаторов / скорости, т.к. узлов много. А может и действительно контакт где нибудь плохой.
кстати фунция mcp2515_reset(); находится внутри функции инита, так что смысла особого не было её до инита делать. Получается она два раза выполнится и всё. ну сделали и пофиг , пусть два раза ресетится. А вот зачем ты несколько раз инит вызываешь не очень понятно.
кстати фунция mcp2515_reset(); находится внутри функции инита, так что смысла особого не было её до инита делать. Получается она два раза выполнится и всё. ну сделали и пофиг , пусть два раза ресетится. А вот зачем ты несколько раз инит вызываешь не очень понятно.
Если посмотришь структуру INT8U MCP_CAN::mcp2515_init то она возвращает нам CAN_OK не по факту ресета, поэтому мне было проще дать ресет а потом еще раз инит.
По хорошему нужно внимательно либу изучить на предмет работы с MCP2515
Да и главное понять причину и найти путь, а лекарство потом допилим.
У моего коллеги проблемы скорее всего в топологии или выборе кабеля / терминаторов / скорости, т.к. узлов много. А может и действительно контакт где нибудь плохой.
Это мне тоже ясно, но! и это самое главное, сейчас допиливается механизм который спасет сеть от сошедшего с ума контроллера, новых подключений в сеть и пр.
Важно что появится самодиагностирующий механизм который не сбрасывая МК ресетит MCP и восстанавливает работу сети.
согласен, костылём это быть перестанет, когда найдем причину такого поведения узлов и костыль превратиться просто в подстраховочный элемент. Главное сейчас понять, помогает ли этот костыль при глюке.
Учи матчасть:) C-bus это всего лишь синхронный протокол, такой же как CAN или Ethernet. А канал передачи данных асинхронный. В синхронных каналах нет и не может быть коллизий по определению.
Матчасть:
АСИНХРОННЫЙ КАНАЛ
Канал передачи данных, использование которого не требует синхронизации работы отправителя и получателя данных
СИНХРОННЫЙ КАНАЛ
Синхронный канал - канал, обеспечивающий синхронизацию процесса передачи данных.
Из определений видно, что синхронность/асинхронность к коллизиям относится фиолетово, а канал обмена C-bus - синхронный. И если CAN кто-то считает синхронным, а кто-то асинхронным https://www.quora.com/Is-CAN-communication-synchronous-or-asynchronous , то для C-bus никаких разночтений нет: все узлы в сегменте полностью синхронизированы, и это никак от протокола не зависит.
Азы надо знать, а не выковыривать из носа всякую невежественную чушь.
Andy пишет:
До тех пор пока есть межпакетный интервал глупо изобретать еще какие-то способы идентификации начала пакетов.
То есть, все, кто использует SLIP, COBS, WAKE - дураки, один Andy умный и образованный: услышал про межпакетный интервал , подумал что на свете ничего лучше нет и быть не может и теперь бегает по форумам и всем навязывает свое "глубоко обоснованное" мнение.
Andy пишет:
Но ты-то начитался литературы посвященной "умным домам". Несешь, несвойственную этому ресурсу, пургу "производитель-потребитель", был бы прогером использовал бы "мастер-слейв"
Просто я знаю, чем "мастер-слэйв" отличается от "производитель-потребитель".
ну, судя по всему прилетает в момент глюка ID 0x000, а байты поля данных отсутствуют, значит DLC = 0. Жопа какая то. Скорость попробуй до 20kbit/s уронить.
если топология/терминаторы/кабель подобраны неверно, то ведь низкая скорость шины должна решить проблему. Ещё есть такой момент как какие то фронты, они как то должны настраиваться. Это тоже из оперы скорости , терминаторов, отражения сигнала и т.д.
С питанием МК и MCP точно всё хорошо? Земли узлов ты объёдинял?
ну, судя по всему прилетает в момент глюка ID 0x000, а байты поля данных отсутствуют, значит DLC = 0. Жопа какая то. Скорость попробуй до 20kbit/s уронить.
Тут уже вопрос принципа, что же так вешает контроллер что его не ресетнуть.
если топология/терминаторы/кабель подобраны неверно, то ведь низкая скорость шины должна решить проблему. Ещё есть такой момент как какие то фронты, они как то должны настраиваться. Это тоже из оперы скорости , терминаторов, отражения сигнала и т.д.
С питанием МК и MCP точно всё хорошо? Земли узлов ты объёдинял?
Скорости ронял до 50 и еще хуже было быстрее сыпались.
С терминаторами буду в выходные биться.
Питание у меня единое, по одной паре из центра 12В по другой CAN
питание сделай сдвоенное - соедини проводники пар - одна пара +12В, вторая пара GND. Т.к. Провод если utp5e сечение маловато у него . Неужели не найдём косяк? Попробуй опять тот упрощённый скетч залить, но с фильтрами.
И я не знаю как фильтром закрыть 0 ID.
Не охото доводить до хардового ресета MCP. Но ты говорил кстати помогает перезагрузка дуни? Странно это, ведь в этом случае питание MCP не перебрасывается...
Услышал звон, да не знаешь где он. Подумай на досуге, в чем разница между UART и USART, между коммутацией каналов и коммутацией пакетов, между SDH и IP, между синхронными и асинхронными сетями, между синхронным и асинхронным протоколами. А-то так и будешь нести бред. Хотя, тебе не поможет, ты же ноль во всех смыслах.
triac пишет:
для C-bus никаких разночтений нет: все узлы в сегменте полностью синхронизированы
В синхронных сетях все узлы одновременно и синхронно передают данные. В C-bus поочередно. Вся синхронизация не более, чем преамбула в ethernet. Так что никаких разночтений нет. Канал передачи асинхронный.
triac пишет:
То есть, все, кто использует SLIP, COBS, WAKE - дураки
Устаревший протокол и высокая избыточность. Этим все сказано. Да, дураки его используют и ты. Можешь и дальше тешить свое самолюбие.
triac пишет:
Просто я знаю, чем "мастер-слэйв" отличается от "производитель-потребитель".
Держи это при себе. Производителей бреда здесь и без тебя хватает.
Твоя идея с CAN на UARTе в этой теме уже озвучивалась. Лично я ничего против неё не имею.
Надоело мне тебя лечить. Сам факт твоего намерения разрабатывать систему жизнеобеспечения из говна и палок уже говорит о твоем скудоумии.
питание сделай сдвоенное - соедини проводники пар - одна пара +12В, вторая пара GND. Т.к. Провод если utp5e сечение маловато у него . Неужели не найдём косяк? Попробуй опять тот упрощённый скетч залить, но с фильтрами.
И я не знаю как фильтром закрыть 0 ID.
Не охото доводить до хардового ресета MCP. Но ты говорил кстати помогает перезагрузка дуни? Странно это, ведь в этом случае питание MCP не перебрасывается...
Кабель тот, что я на фото тебе показывал в прошлом году. В кабеле всего 2 пары. Одна под питание вторая под CAN. Сечение достаточное, падение напряженния минимальное.
Вот и меня смущает, что мы не можем сделать MCP без ресета ардуино.
И в чем инкапсуляция, полиформизм и наследование помогут нам выловить проблему которую нужно решань наооборот не на C++ а на С работой с контроллером. Работая с регистрами?
Ведь проблема не в том что контроллер сбоит из-за сбоев сети, а в том сто мы его нормально по SPI переинициализировать не можем, причем после непонятной ошибки.
И кстати повторю свои слова которые написал для triac.
Это форум самодельщиков, которые что то ваяют на ардуино.
Я могу взять PLC прикрутить к ним свои промореле и получу то-же самое. Цена будет той же, даже дешевле т.к не буду столько времени на это тратить.
Подумай на досуге, в чем разница между UART и USART, между коммутацией каналов и коммутацией пакетов, между SDH и IP, между синхронными и асинхронными сетями, между синхронным и асинхронным протоколами.
синхронных сетях все узлы одновременно и синхронно передают данные. В C-bus поочередно. Вся синхронизация не более, чем преамбула в ethernet. Так что никаких разночтений нет. Канал передачи асинхронный.
Andy стал на лету подменять понятия и давать свои собственные определения, извиваясь как червяк под сапогом. В явном отчаянии даже коммутацию каналов и пакетов приплел ни к селу ни к городу. Якобы для него кроме SONET на свете никаких синхронных интерфейсов нет, все остальное он одним махом назвал "протоколами". Сейчас он еще SPI назовет "асинхронным".
Дружок, с C-bus ты сел в лужу, продемонстрировал свое невежество и глупость. Он абсолютно синхронный во всех смыслах, сколько бы ты ни старался пeреврать общеизвестные понятия. Ты еще про атомные часы в SONET скажи, что это то же самое, что преамбула, повесели нас.
Не пыжься, xамло невежественное. B каждом сообщении ты лажался и нес ахинею, а порой просто врал и был на том ловлен с поличными. Раз уж не знаешь ничего - не лезь спорить, сопляк, сиди и слушай, что старшие ребята говорят, вникай и благодари за науку.
Andy пишет:
Устаревший протокол и высокая избыточность.
COBS новей чем CAN, а UART с байт-стаффингом менее избыточен чем CAN, но ты этого по невежеству не знаешь. Твои любимые межпакетные паузы используются в древнем Модбасе, гораздо более древнем чем SLIP, но при этом использование канала ничуть не лучше, чем с байт-стаффингом, а реализация сложнее. Так что опять ты глупость сморозил.
Кабель тот, что я на фото тебе показывал в прошлом году. В кабеле всего 2 пары. Одна под питание вторая под CAN. Сечение достаточное, падение напряженния минимальное.
точно, ты же говорил что такой кабель. Блин, дак он вообще норм - лучше чем обычная витуха utp5e. Может у тебя всё таки звезданутая топология? Ну всмысле отводы большие. Какое в результате у тебя омическое сопротивление между CAN-H и CAN-L?
Не могу найти как настраивается длительность фронтов трансивера.
ПС. закажи себе штук 20 RS485 трансиверов, не дорого в принципе. На них твою сеть проверим
У меня терминаторов даже больше. Топология у меня смешанная, шина с подключенными к ней звездами.
раз такое дело, если есть бухта utp, протяни навесу, и сделай именно шину, с небольшими отростками на узлы, а лучше узлы вообще в разрыв. Думаю, что проблема уйдёт.
У меня терминаторов даже больше. Топология у меня смешанная, шина с подключенными к ней звездами.
раз такое дело, если есть бухта utp, протяни навесу, и сделай именно шину, с небольшими отростками на узлы, а лучше узлы вообще в разрыв. Думаю, что проблема уйдёт.
Ребята, снижайте скорость обмена. 500 kbps для этой задачи - перебор, достаточно 19.2 кbps. Только проверьте даташиты на трансиверы, у многих есть встроенная защита от долгих доминантных уровней на уровне 0.3 мс. С такими трансиверами придется скорость поднять до 38.4 kbps
Ребята, снижайте скорость обмена. 500 kbps для этой задачи - перебор, достаточно 19.2 кbps. Только проверьте даташиты на трансиверы, у многих есть встроенная защита от долгих доминантных уровней на уровне 0.3 мс. С такими трансиверами придется скорость поднять до 38.4 kbps
Как я уже писал основная проблема почему мы не можем ресетнуть MCP2515 без ресета 2556 и в чем причина его зависания.
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
У меня терминаторов даже больше. Топология у меня смешанная, шина с подключенными к ней звездами.
раз такое дело, если есть бухта utp, протяни навесу, и сделай именно шину, с небольшими отростками на узлы, а лучше узлы вообще в разрыв. Думаю, что проблема уйдёт.
Попробую, но все же мне не дает покоя невозможность ресета отдельно MCP2515. Попробую сегодня setmode
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
На низких скоростях согласование может быть частичным. Достаточно поставить один терминатор примерно в центре. Если интересно, можете поискать у Velbus, у них в открытом доступе было руководство по произвольной топологии кабелей до 1 км, это при том что Velbus - это CAN bus.
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
На низких скоростях согласование может быть частичным. Достаточно поставить один терминатор примерно в центре. Если интересно, можете поискать у Velbus, у них в открытом доступе было руководство по произвольной топологии кабелей до 1 км, это при том что Velbus - это CAN bus.
Хочу присоединиться к вам, и к разработке тоже, но все таки задачи у нас немного разные ... я собираюсь собрать все на одной плате на базе atmega328 (к примеру) ну и распаять MCP2551, вот только пока не понимаю нужен ли мне MCP2515 или действительно MCP2551 заведется по urart
По Поводу вашей проблемы, зависания, если таки дело в кабеле, то нужно терминатор с подтягивающим резистором ставить, и если в кан также как и 485 то и шунт тоже нужен, и общее сопротивление на линии не должно превышать 150 ом... ( по памяти, нужно гуглить) не забывая закон ома. =) ну если поможет...
По поводу ваших наработок, к сожалению у меня нет доступа к ядиску, не хотели бы выложиться на github или bitbucket ? там можно удобно работать коллективно и коммитить и мержить изменения, на крайняк ветки делать.. Например , то что работает, коммитим в мастер, что то новое разрабатываем в стейджинг, когда готово, фичу мержим с мастер и пулим, и все видят новую версию ... На крайняк форкнуть можно код... также и откаты и ревизии, итд ... ну вы должны знать это ?
или хотя бы пришлите код ваш, хочу посмотреть ) спасибо .
Читал долго, и все таки кажется много лишнего у вас в протоколе, статус на получение статуса ? ... ну я бы для выключателя бы отправля бы статус, причем сразу в запросе указывал бы, нужен мне статус о выполнении или нет ?Для смены индикатора например.
А для димера зачем статус ? димер каждое значение должен отправить как можно быстрее, , а если 2 потеряются , это норма, или для датчика температуры ? отправил - хорошо, не отправил - есть сервер который мониторит все и логирует , он же PC , где на это можно вешать обработку, что датчик температуры с комнаты уже 2 часа молчит... Ну для тревожных понятное статус тоже нужен ... Пока читал пришла такая идея..
Типов у вас тоже много ... не понимаю зачем... я бы просто выделил пару байт на серийный номер устройства, а путем некоторых комбинаций, программировали бы на реле коды кнопок, и сохранял бы в пзу. но это мое мнение.. ваш код я еще не видел, и CAN только заказал, еще не щупал ...
зато с rs485 игрался уже, и у меня там возникла похожая проблема , только не зависало, а приходила ерунда =) А все потому, что кан что 485 должны сидеть на общей шине, без больших ответвлений, а у меня вышло топология звезда которая соединена с другой звездой по общей шине ))
Хочу присоединиться к вам, и к разработке тоже, но все таки задачи у нас немного разные ... я собираюсь собрать все на одной плате на базе atmega328 (к примеру) ну и распаять MCP2551, вот только пока не понимаю нужен ли мне MCP2515 или действительно MCP2551 заведется по urart
Добро пожаловать.
Тут как говориться на вкус и цвет.... Просто я пока не готов на этом этапе Э3 и Т5М делать. Проще взять готовый контроллер, с его ценой 200 руб, если надо потом нарисовать готовую плату с разу с МК и CAN.
tosic пишет:
По Поводу вашей проблемы, зависания, если таки дело в кабеле, то нужно терминатор с подтягивающим резистором ставить, и если в кан также как и 485 то и шунт тоже нужен, и общее сопротивление на линии не должно превышать 150 ом... ( по памяти, нужно гуглить) не забывая закон ома. =) ну если поможет...
Почему сбоит не главная проблема, это я сам разгребу. Важно что нам не удается после сбоя MCP сделать ему ресет без ресета МК. MCP сглючивает и по SPI начинает сыпать 0x000 с DLC 0 в МК. Попытка его перинициализации разными способами приводит либо к зависанию МК либо невозможности его проинициализировать.
tosic пишет:
По поводу ваших наработок, к сожалению у меня нет доступа к ядиску, не хотели бы выложиться на github или bitbucket ? там можно удобно работать коллективно и коммитить и мержить изменения, на крайняк ветки делать.. Например , то что работает, коммитим в мастер, что то новое разрабатываем в стейджинг, когда готово, фичу мержим с мастер и пулим, и все видят новую версию ... На крайняк форкнуть можно код... также и откаты и ревизии, итд ... ну вы должны знать это ?
или хотя бы пришлите код ваш, хочу посмотреть ) спасибо .
Систем контроля версий много, у меня на работе аппаратчики ипользуют mercurial, программисты тоже на CVS по моему сидят.
Тут нужно MaksVV убеждать, он на этом этапе сейчас главный гразработчик, а я скорее тестировщик.
Читал долго, и все таки кажется много лишнего у вас в протоколе, статус на получение статуса ? ... ну я бы для выключателя бы отправля бы статус, причем сразу в запросе указывал бы, нужен мне статус о выполнении или нет ?Для смены индикатора например.
А для димера зачем статус ? димер каждое значение должен отправить как можно быстрее, , а если 2 потеряются , это норма, или для датчика температуры ? отправил - хорошо, не отправил - есть сервер который мониторит все и логирует , он же PC , где на это можно вешать обработку, что датчик температуры с комнаты уже 2 часа молчит... Ну для тревожных понятное статус тоже нужен ... Пока читал пришла такая идея..
Типов у вас тоже много ... не понимаю зачем... я бы просто выделил пару байт на серийный номер устройства, а путем некоторых комбинаций, программировали бы на реле коды кнопок, и сохранял бы в пзу. но это мое мнение.. ваш код я еще не видел, и CAN только заказал, еще не щупал ...
Статус на статус это только при обмене контроллеров, если мастер рассылает бродкастом свой статус то все живые должны ответить. Это нужно для контроля сети в целом.
Статус подключеных ИУ мы не опрашиваем.
Типов как раз мало, проще получив тип сразу понимать как его обрабатывать, нежели разбираться что за устройство тебе прислало данные.
я собираюсь собрать все на одной плате на базе atmega328 (к примеру) ну и распаять MCP2551, вот только пока не понимаю нужен ли мне MCP2515 или действительно MCP2551 заведется по urart
Статус на статус это только при обмене контроллеров, если мастер рассылает бродкастом свой статус то все живые должны ответить. Это нужно для контроля сети в целом.
и для синхронизации процессов в сети. В широковещательном статусе мастера содержится время. Узлы могут выполнять какие либо действия, засинхронизировавшись относительно чего то общего - статуса мастера.
Например, периодическую отправку своих параметров выполняют в "своё" время. Чтобы не накладывалось много сообщений в один момент в шине.
Ты, недоумок, не в состоянии понять разницу между сетями, каналами и протоколами. C-bus синхронный протокол, а не канал. Тебе просто этого не дано понять. Ты же читатель, думать это не твоё.
triac пишет:
B каждом сообщении ты лажался и нес ахинею, а порой просто врал и был на том ловлен с поличными
Напомни мне где я врал и на чем был ловлен с поличными... А то из твоего поноса трудно понять, где твои фантазии, где бред, а где копипаст из литературы про умные дома.
Ты же дятел и в программировании и в схемотехнике. О чем с тобой разговаривать. Не иначе ты влез в тему в надежде, что за тебя напишут код и разработают железку... Ты послан. Можешь не отвечать.
riv пишет:
И в чем инкапсуляция, полиформизм и наследование помогут нам выловить проблему которую нужно решань наооборот не на C++ а на С работой с контроллером. Работая с регистрами?
Помогут не инкапсуляция и полиморфизм, а структурное программирование.
riv пишет:
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
Чем ниже частота, тем проще согласование. Скорость распространения сигнала должна быть на порядок больше скорости изменения сигнала - тогда согласование не нужно в принципе. Снижайте скорость до 9600. Её более, чем достаточно для вашей задачи. DALI вообще на 1200 передает и не заморачивается на витую пару и согласование.
riv пишет:
невозможность ресета отдельно MCP2515
У неё же вывод reset есть. Не задействован что ли?
riv пишет:
человек на базе mcp_can нарисовал свою библиотеку Velbus для MCP2515
вот вспомнил, есть интересный проект умной теплицы уважаемого коллеги по форуму DIYMan. Много чего можно взять на заметку. Например идея конфигуратора это гуд. Но не в моих силах к сож. Автор гораздо опытнее в программировании, меня точно.
Помогут не инкапсуляция и полиморфизм, а структурное программирование.
RIV заливал простейший скетч пинг понга, всё равно часа через три начинаются ошибки, откуда берётся мусор в шине, не понятно. Имхо прошивка тут не причём. У меня на трех МК разнесённых на 20м FTP 5e кабелем работает без сбоев.
Andy пишет:
У неё же вывод reset есть. Не задействован что ли?
Помогут не инкапсуляция и полиморфизм, а структурное программирование.
Так что же нам поможет ;-)
Парадигма объектно-ориентированного программиования со своими основными понятиями инкапсуляция, полиформизм и наследование ( Классы там всякие со всойствами методами и событиями)
ИЛИ
Парадигма структурного программирования с принципами обеспечивающими читаемость програмыи избавлением от SC. (Ну просто логичный структурированыый код)
Тот же вопрос про легкость согласования длинноволновых линий связи. Утверждение основано на опыте или теории?
Добавил строки для ресета, проверяю
Есть несколько способов что-то сделать. Какой бы способ я ни выбрал, вылезет Andy и скажет, что этот способ не годится, потому что "есть другие способы сделать то же самое".
Сработал переинит MCP2515
Я перестраховался и поставил все варианты
01{02MCP5515_RST();03Serial.println("Reset MCP2515");04delay(1000);05MCP2515_Init ();06Serial.println("Init 1");07delay(1000);08MCP2515_Init ();09Serial.println("Init 2");10delay(1000);11Serial.println("Запуск 2");12}Где
1voidMCP5515_RST()2{3can.mcp2515_reset();4}Да и старайся быть осторожнее с именами функций. В библиотеке есть
1INT8U MCP_CAN::mcp2515_init(constINT8U canIDMode,constINT8U canSpeed,constINT8U canClock)хорошо что она в private:
Работаю 10 лет автоэлектриком и уж это знаю не по наслышке.
На счёт ЭБУ может быть. В принципе у меня то уже два месяца как работает система, понятно, что в гораздо более простом виде, чем мы сейчас тут городим. Но без сбоев в плане линии CAN, от слова совсем. Не знаю, что сложного в этом протоколе нашёл triac. Используя библиотеку даже такой дилетант как я разобрался. Два года назад ты мне как раз первый и ответил, собственно с этого и началось изучение ардуино и программирования. Респект однако.
У моего коллеги проблемы скорее всего в топологии или выборе кабеля / терминаторов / скорости, т.к. узлов много. А может и действительно контакт где нибудь плохой.
ну ведь я большими буквами фукнцию написал)) а так да, попасть можно. Я так сделал
01// в can_struct.h вверху0203#ifdef ARD_UNO04#define can CAN005#define csPIN 1006#endif07#ifdef ARD_MEGA08#define can CAN009#define csPIN 5310#endif11#ifdef ARD_DUE12#define can CAN313#define csPIN 5214#endif1516MCP_CAN can(csPIN);17181920voidMCP2515_Init () {2122SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));23digitalWrite(csPIN, LOW);24SPI.transfer(0xC0);25digitalWrite(csPIN, HIGH);26SPI.endTransaction();27delay (100);28boolcan_ok = 0;29if(can.begin(MCP_STDEXT, CAN_500KBPS, MCP_8MHZ) == CAN_OK) can_ok = 1;30can.init_Mask(0,1,0x0000FF00);// Init first mask...31can.init_Filt(0,1,(node_address & 0xFFFFFFFF)<<8);// Init first filter...32can.init_Filt(1,1,0x00000000);// Init second filter...33can.init_Mask(1,0,0xFFFFFFFF);// Init second mask... запрещает все стандартные ID , кроме 0х0003435#ifdef debug36if(!Setup)Serial.begin(115200);37if(can_ok)Serial.println(F("MCP2515 Initialized Successfully!"));38else39Serial.println(F("Error Initializing MCP2515..."));4041Serial.println();Serial.print(F("Мой адрес в сети CAN: ")); Print (node_address, ADDR);42#ifdef type_node_master43Serial.println (F(" MASTER!"));44#endif45Serial.println();46if(!Setup) timeoutsConfigControl ();47#endif48can.setMode(MCP_NORMAL);49}кстати фунция mcp2515_reset(); находится внутри функции инита, так что смысла особого не было её до инита делать. Получается она два раза выполнится и всё. ну сделали и пофиг , пусть два раза ресетится. А вот зачем ты несколько раз инит вызываешь не очень понятно.
кстати фунция mcp2515_reset(); находится внутри функции инита, так что смысла особого не было её до инита делать. Получается она два раза выполнится и всё. ну сделали и пофиг , пусть два раза ресетится. А вот зачем ты несколько раз инит вызываешь не очень понятно.
Если посмотришь структуру INT8U MCP_CAN::mcp2515_init то она возвращает нам CAN_OK не по факту ресета, поэтому мне было проще дать ресет а потом еще раз инит.
По хорошему нужно внимательно либу изучить на предмет работы с MCP2515
Да и главное понять причину и найти путь, а лекарство потом допилим.
У моего коллеги проблемы скорее всего в топологии или выборе кабеля / терминаторов / скорости, т.к. узлов много. А может и действительно контакт где нибудь плохой.
Это мне тоже ясно, но! и это самое главное, сейчас допиливается механизм который спасет сеть от сошедшего с ума контроллера, новых подключений в сеть и пр.
Важно что появится самодиагностирующий механизм который не сбрасывая МК ресетит MCP и восстанавливает работу сети.
согласен, костылём это быть перестанет, когда найдем причину такого поведения узлов и костыль превратиться просто в подстраховочный элемент. Главное сейчас понять, помогает ли этот костыль при глюке.
Еще вопрос ты в двух местах закинул инит для перестраховки или был смысл?
здесь
if (direction ==0 && msg_type ==0 && dev_addr == 0 && rem_addr == 0 && dev_type == 0) { MCP2515_Init (); return;}
и здесь
И еще вопрос
Между двумя выводами статусов c OK на все узлы , появляется сообщение о аварии, это нормально?
01NODES CAN COMMUNICATION:02node_5_Net_center_Due2 OK!!!03node_6_Hallway_net_center OK!!!04node_7_Hallway_main OK!!!05node_8_Hallway_light OK!!!06node_9_Kitchen_net_center OK!!!07node_10_Kitchen_main OK!!!08node_11_Kitchen_light OK!!!09node_12_WC_main OK!!!10node_13_WC_waterleak OK!!!11node_14_Bathroom_main OK!!!12node_15_Boxroom_main OK!!!13node_17_Loggia_main OK!!!14node_18_Loggia_recuperator OK!!!15node_19_Livingroom_main OK!!!16node_20_Bedroom_main OK!!!17node_21_Cabinet_main OK!!!1819Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 8A040113 04202100:00:10:0022NODES CAN COMMUNICATION:23node_5_Net_center_Due2 OK!!!24node_6_Hallway_net_center OK!!!25node_7_Hallway_main OK!!!26node_8_Hallway_light OK!!!27node_9_Kitchen_net_center OK!!!28node_10_Kitchen_main OK!!!29node_11_Kitchen_light OK!!!30node_12_WC_main OK!!!31node_13_WC_waterleak OK!!!32node_14_Bathroom_main OK!!!33node_15_Boxroom_main OK!!!34node_17_Loggia_main OK!!!35node_18_Loggia_recuperator OK!!!36node_19_Livingroom_main OK!!!37node_20_Bedroom_main OK!!!38node_21_Cabinet_main OK!!!Учи матчасть:) C-bus это всего лишь синхронный протокол, такой же как CAN или Ethernet. А канал передачи данных асинхронный. В синхронных каналах нет и не может быть коллизий по определению.
Матчасть:
АСИНХРОННЫЙ КАНАЛ
Канал передачи данных, использование которого не требует синхронизации работы отправителя и получателя данных
СИНХРОННЫЙ КАНАЛ
Синхронный канал - канал, обеспечивающий синхронизацию процесса передачи данных.
Из определений видно, что синхронность/асинхронность к коллизиям относится фиолетово, а канал обмена C-bus - синхронный. И если CAN кто-то считает синхронным, а кто-то асинхронным https://www.quora.com/Is-CAN-communication-synchronous-or-asynchronous , то для C-bus никаких разночтений нет: все узлы в сегменте полностью синхронизированы, и это никак от протокола не зависит.
Азы надо знать, а не выковыривать из носа всякую невежественную чушь.
До тех пор пока есть межпакетный интервал глупо изобретать еще какие-то способы идентификации начала пакетов.
То есть, все, кто использует SLIP, COBS, WAKE - дураки, один Andy умный и образованный: услышал про межпакетный интервал , подумал что на свете ничего лучше нет и быть не может и теперь бегает по форумам и всем навязывает свое "глубоко обоснованное" мнение.
Но ты-то начитался литературы посвященной "умным домам". Несешь, несвойственную этому ресурсу, пургу "производитель-потребитель", был бы прогером использовал бы "мастер-слейв"
Просто я знаю, чем "мастер-слэйв" отличается от "производитель-потребитель".
Еще вопрос ты в двух местах закинул инит для перестраховки или был смысл?
был смысл, и ты же сам ответил, один сброс для вообще 0-вого ID. Второй - если тип сообщения отличен от нашего енума.
конечно так быть не должно. Нужно смотреть что получает в момент косяка узел. судя по логу мастера см. лог узла минуту от 9ой до 10ой.
конечно так быть не должно. Нужно смотреть что получает в момент косяка узел. судя по логу мастера см. лог узла 19, минуту от 9ой до 10ой.
Пробую сразу несколько вариантов reset
1. Вызовом функции
2. Через SPI (из библиотеки)
3. Через SETMODE
Потом придется лезть в SPI напрямую через SPI.h (У тебя механизм ресета по SPI отличается от библиотечной почему?)
Кстатит сразу вопрос
в библиотеке CAN ресет такой
#define MCP_RESET 0xC0
В описании контроллера пишут что такой
#define RESET 0b11000000 // Сброс MCP2515
У тебя механизм ресета по SPI отличается от библиотечной почему?)
я просто убрал дефайны
В описании контроллера пишут что такой #define RESET 0b11000000 // Сброс MCP2515
это одно и то же. Просто первое HEX, второе BIN
И всё же, что получают узлы в момент глюка (какой ID, поле данных)? никак от тебя не могу добиться этой информации.
У тебя механизм ресета по SPI отличается от библиотечной почему?)
1voidMCP_CAN::mcp2515_reset(void)2{3SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));4MCP2515_SELECT();5spi_readwrite(MCP_RESET);6MCP2515_UNSELECT();7SPI.endTransaction();8delayMicroseconds(10);9}а у тебя
1SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));2digitalWrite(csPIN, LOW);3SPI.transfer(0xC0);4digitalWrite(csPIN, HIGH);5SPI.endTransaction();6delay (100);И всё же, что получают узлы в момент глюка (какой ID, поле данных)? никак от тебя не могу добиться этой информации.
А как мне их снять? Canhacker у меня глючит а в дебаге Отправлено в CAN без деталей.
Сейчавс с дебагом покручу.
я же поменял дебаг, теперь там показывает ID и поле данных. См. видос который я выкладывал как там отладка идёт мастера и узла.
На счет функции ресет говорю же просто убрал дефайны, смотри внимательнее библиотеку, это одно и тоже.
я же поменял дебаг, теперь там показывает ID и поле данных. См. видос который я выкладывал как там отладка идёт мастера и узла.
На счет функции ресет говорю же просто убрал дефайны, смотри внимательнее библиотеку, это одно и тоже.
С отправкой раз в секунду у меня буферв на ночь не хватит лог собирать.
Я просто тупо добавил в default
01Serial.println();02if(rem_addr == node_address)Serial.println(F("-------CAN MESSAGE RX ADRRESSED TO ME-------"));03elseif(rem_addr == 0)Serial.println(F("----------CAN BROADCAST MESSAGE RX----------"));04elseSerial.println(F("----------------CAN MESSAGE RX--------------"));05Serial.print (F(" ID "));Serial.println(rxId_can, HEX);0607Serial.print(F(" type_msg - ")); Print (msg_type, TypeMES);Serial.println ();08Serial.print(F(" node_addr - ")); Print (dev_addr, ADDR);Serial.println ();09Serial.print(F(" Rem_addr - ")); Print (rem_addr, ADDR);Serial.println ();10Serial.print(F(" Dev_type - ")); Print (dev_type, TypeDEV);Serial.println ();11Serial.print(F("DATA FRAME "));Serial.print (" ");12if(!can_frame_type){if(len_can!=0) {for(inti=0; i<len_can; i++) {13if(rxBuf_can[i]<=0x0F)Serial.print (F("0"));14Serial.print (rxBuf_can[i], HEX);Serial.print (F(" ")); }}}15elseSerial.println (F("NOT DATA, BECAUSE REMOTE FRAME"));16Serial.println();Serial.println(F("--------------------------------------------"));17Serial.println();Вот прямо сейчас глюк вылетел, кстати контроллер подвисает
0100:00:10:3002NODES CAN COMMUNICATION:03node_5_Net_center_Due2 OK!!!04node_6_Hallway_net_center OK!!!05node_7_Hallway_main OK!!!06node_8_Hallway_light OK!!!07node_9_Kitchen_net_center OK!!!08node_10_Kitchen_main OK!!!09node_11_Kitchen_light OK!!!10node_12_WC_main OK!!!11node_13_WC_waterleak OK!!!12node_14_Bathroom_main OK!!!13node_15_Boxroom_main OK!!!14node_18_Loggia_recuperator OK!!!15node_19_Livingroom_main OK!!!16node_20_Bedroom_main OK!!!17node_21_Cabinet_main OK!!!1819----------CAN BROADCAST MESSAGE RX----------20ID 021type_msg - NULL_C22node_addr - ШИРОКОВЕЩАТЕЛЬНО23Rem_addr - ШИРОКОВЕЩАТЕЛЬНО24Dev_type - NULL DEVICE25DATA FRAME26--------------------------------------------2728Error Initializing MCP2515...2930Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!3132Init 133Reset1 MCP251534Reset2 MCP251535Error Initializing MCP2515...3637Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!3839Init 240msg_id<>0ну, судя по всему прилетает в момент глюка ID 0x000, а байты поля данных отсутствуют, значит DLC = 0. Жопа какая то. Скорость попробуй до 20kbit/s уронить.
если топология/терминаторы/кабель подобраны неверно, то ведь низкая скорость шины должна решить проблему. Ещё есть такой момент как какие то фронты, они как то должны настраиваться. Это тоже из оперы скорости , терминаторов, отражения сигнала и т.д.
С питанием МК и MCP точно всё хорошо? Земли узлов ты объёдинял?
ну, судя по всему прилетает в момент глюка ID 0x000, а байты поля данных отсутствуют, значит DLC = 0. Жопа какая то. Скорость попробуй до 20kbit/s уронить.
Тут уже вопрос принципа, что же так вешает контроллер что его не ресетнуть.
Надо добивать.
И кстати может фильтром все эе закрыть ID 0x000?
если топология/терминаторы/кабель подобраны неверно, то ведь низкая скорость шины должна решить проблему. Ещё есть такой момент как какие то фронты, они как то должны настраиваться. Это тоже из оперы скорости , терминаторов, отражения сигнала и т.д.
С питанием МК и MCP точно всё хорошо? Земли узлов ты объёдинял?
Скорости ронял до 50 и еще хуже было быстрее сыпались.
С терминаторами буду в выходные биться.
Питание у меня единое, по одной паре из центра 12В по другой CAN
питание сделай сдвоенное - соедини проводники пар - одна пара +12В, вторая пара GND. Т.к. Провод если utp5e сечение маловато у него . Неужели не найдём косяк? Попробуй опять тот упрощённый скетч залить, но с фильтрами.
И я не знаю как фильтром закрыть 0 ID.
Не охото доводить до хардового ресета MCP. Но ты говорил кстати помогает перезагрузка дуни? Странно это, ведь в этом случае питание MCP не перебрасывается...
Твоя идея с CAN на UARTе в этой теме уже озвучивалась. Лично я ничего против неё не имею.
Надоело мне тебя лечить. Сам факт твоего намерения разрабатывать систему жизнеобеспечения из говна и палок уже говорит о твоем скудоумии.
питание сделай сдвоенное - соедини проводники пар - одна пара +12В, вторая пара GND. Т.к. Провод если utp5e сечение маловато у него . Неужели не найдём косяк? Попробуй опять тот упрощённый скетч залить, но с фильтрами.
И я не знаю как фильтром закрыть 0 ID.
Не охото доводить до хардового ресета MCP. Но ты говорил кстати помогает перезагрузка дуни? Странно это, ведь в этом случае питание MCP не перебрасывается...
Кабель тот, что я на фото тебе показывал в прошлом году. В кабеле всего 2 пары. Одна под питание вторая под CAN. Сечение достаточное, падение напряженния минимальное.
Вот и меня смущает, что мы не можем сделать MCP без ресета ардуино.
Можно поиграть с can.setMode(MCP_LOOPBACK); затем NORMAL. В общем нужно код библиотеки просмотреть на тему включения и иницииализации и его посторить. Или уже букварь изучать подробно http://microsin.net/adminstuff/hardware/mcp2515-stand-alone-can-controller-with-spi-interface.html
Парни, пора переходить на ООП.
И в чем инкапсуляция, полиформизм и наследование помогут нам выловить проблему которую нужно решань наооборот не на C++ а на С работой с контроллером. Работая с регистрами?
Ведь проблема не в том что контроллер сбоит из-за сбоев сети, а в том сто мы его нормально по SPI переинициализировать не можем, причем после непонятной ошибки.
И кстати повторю свои слова которые написал для triac.
Это форум самодельщиков, которые что то ваяют на ардуино.
Я могу взять PLC прикрутить к ним свои промореле и получу то-же самое. Цена будет той же, даже дешевле т.к не буду столько времени на это тратить.
Но это хобби, и этим все сказано.
Подумай на досуге, в чем разница между UART и USART, между коммутацией каналов и коммутацией пакетов, между SDH и IP, между синхронными и асинхронными сетями, между синхронным и асинхронным протоколами.
синхронных сетях все узлы одновременно и синхронно передают данные. В C-bus поочередно. Вся синхронизация не более, чем преамбула в ethernet. Так что никаких разночтений нет. Канал передачи асинхронный.
Andy стал на лету подменять понятия и давать свои собственные определения, извиваясь как червяк под сапогом. В явном отчаянии даже коммутацию каналов и пакетов приплел ни к селу ни к городу. Якобы для него кроме SONET на свете никаких синхронных интерфейсов нет, все остальное он одним махом назвал "протоколами". Сейчас он еще SPI назовет "асинхронным".
Дружок, с C-bus ты сел в лужу, продемонстрировал свое невежество и глупость. Он абсолютно синхронный во всех смыслах, сколько бы ты ни старался пeреврать общеизвестные понятия. Ты еще про атомные часы в SONET скажи, что это то же самое, что преамбула, повесели нас.
Не пыжься, xамло невежественное. B каждом сообщении ты лажался и нес ахинею, а порой просто врал и был на том ловлен с поличными. Раз уж не знаешь ничего - не лезь спорить, сопляк, сиди и слушай, что старшие ребята говорят, вникай и благодари за науку.
Устаревший протокол и высокая избыточность.
COBS новей чем CAN, а UART с байт-стаффингом менее избыточен чем CAN, но ты этого по невежеству не знаешь. Твои любимые межпакетные паузы используются в древнем Модбасе, гораздо более древнем чем SLIP, но при этом использование канала ничуть не лучше, чем с байт-стаффингом, а реализация сложнее. Так что опять ты глупость сморозил.
Кабель тот, что я на фото тебе показывал в прошлом году. В кабеле всего 2 пары. Одна под питание вторая под CAN. Сечение достаточное, падение напряженния минимальное.
точно, ты же говорил что такой кабель. Блин, дак он вообще норм - лучше чем обычная витуха utp5e. Может у тебя всё таки звезданутая топология? Ну всмысле отводы большие. Какое в результате у тебя омическое сопротивление между CAN-H и CAN-L?
Не могу найти как настраивается длительность фронтов трансивера.
ПС. закажи себе штук 20 RS485 трансиверов, не дорого в принципе. На них твою сеть проверим
Да кстати интересное наблюдение. На DUE
void MCP2515_Init () с включением
1SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));2digitalWrite(csPIN, LOW);3SPI.transfer(0xC0);4digitalWrite(csPIN, HIGH);5SPI.endTransaction();6delay (100);не работает при первом запуске. НИчего не выводит в консоль.
Да и при сбое (получении 0х000 МК просто зависает)
рекомендую заменить DUE на мегу. Вот когда всё отладится, будешь уже DUE мучить.
Ну это только к выходным
У меня терминаторов даже больше. Топология у меня смешанная, шина с подключенными к ней звездами.
раз такое дело, если есть бухта utp, протяни навесу, и сделай именно шину, с небольшими отростками на узлы, а лучше узлы вообще в разрыв. Думаю, что проблема уйдёт.
У меня терминаторов даже больше. Топология у меня смешанная, шина с подключенными к ней звездами.
раз такое дело, если есть бухта utp, протяни навесу, и сделай именно шину, с небольшими отростками на узлы, а лучше узлы вообще в разрыв. Думаю, что проблема уйдёт.
Ребята, снижайте скорость обмена. 500 kbps для этой задачи - перебор, достаточно 19.2 кbps. Только проверьте даташиты на трансиверы, у многих есть встроенная защита от долгих доминантных уровней на уровне 0.3 мс. С такими трансиверами придется скорость поднять до 38.4 kbps
Ребята, снижайте скорость обмена. 500 kbps для этой задачи - перебор, достаточно 19.2 кbps. Только проверьте даташиты на трансиверы, у многих есть встроенная защита от долгих доминантных уровней на уровне 0.3 мс. С такими трансиверами придется скорость поднять до 38.4 kbps
Как я уже писал основная проблема почему мы не можем ресетнуть MCP2515 без ресета 2556 и в чем причина его зависания.
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
У меня терминаторов даже больше. Топология у меня смешанная, шина с подключенными к ней звездами.
раз такое дело, если есть бухта utp, протяни навесу, и сделай именно шину, с небольшими отростками на узлы, а лучше узлы вообще в разрыв. Думаю, что проблема уйдёт.
Попробую, но все же мне не дает покоя невозможность ресета отдельно MCP2515. Попробую сегодня setmode
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
На низких скоростях согласование может быть частичным. Достаточно поставить один терминатор примерно в центре. Если интересно, можете поискать у Velbus, у них в открытом доступе было руководство по произвольной топологии кабелей до 1 км, это при том что Velbus - это CAN bus.
Снижение до 50 kbps дало худший результат как не странно (хотя не странно частота ниже, длинна волны выше, 1/4 волны больше, согласование сложнее)
На низких скоростях согласование может быть частичным. Достаточно поставить один терминатор примерно в центре. Если интересно, можете поискать у Velbus, у них в открытом доступе было руководство по произвольной топологии кабелей до 1 км, это при том что Velbus - это CAN bus.
Спасибо.
https://www.velbus.eu/domotica
https://www.velbus.eu/downloads/files/spotlights/digimagazines/cat-velbus18en.pdf
Это как раз подтверждает, что мы с MaksVV на правильному пути.
MaksVV полистай бегло, оч интересно
https://www.velbus.eu/downloads/velbus/00_general/guide_velbus_01_hardware_en.pdf
https://www.velbus.eu/downloads/velbus/00_general/guide_velbus_02_programming_en.pdf
А еще установи софтину VelbusLink https://www.velbus.eu/support/downloads/?id=376994
и глянь как там сеть конфигурируется, строится адресация и настройка. Просто 95% попадание по нашей идеологии!
Вообще-то про Velbus я еще в своем самом первом сообщении в этом треде говорил :) http://arduino.ru/forum/proekty/ocherednoi-umnyi-dom-na-etot-raz-modulna...
ох ребята, здрасте =) осилил таки и перечитал всю тему .
У меня похожая цель, и я тоже сперва нацелился на rs485
вот темка где я целб описывал http://arduino.ru/forum/apparatnye-voprosy/provodnaya-set-iz-mnozhestva-arduino-po-vitoi-pare-s-protokolom-rs485
Хочу присоединиться к вам, и к разработке тоже, но все таки задачи у нас немного разные ...
я собираюсь собрать все на одной плате на базе atmega328 (к примеру)
ну и распаять MCP2551, вот только пока не понимаю нужен ли мне MCP2515 или действительно MCP2551 заведется по urart
По Поводу вашей проблемы, зависания, если таки дело в кабеле, то нужно терминатор с подтягивающим резистором ставить, и если в кан также как и 485 то и шунт тоже нужен, и общее сопротивление на линии не должно превышать 150 ом... ( по памяти, нужно гуглить) не забывая закон ома. =) ну если поможет...
По поводу ваших наработок, к сожалению у меня нет доступа к ядиску, не хотели бы выложиться на github или bitbucket ? там можно удобно работать коллективно и коммитить и мержить изменения, на крайняк ветки делать.. Например , то что работает, коммитим в мастер, что то новое разрабатываем в стейджинг, когда готово, фичу мержим с мастер и пулим, и все видят новую версию ... На крайняк форкнуть можно код... также и откаты и ревизии, итд ... ну вы должны знать это ?
или хотя бы пришлите код ваш, хочу посмотреть ) спасибо .
Читал долго, и все таки кажется много лишнего у вас в протоколе, статус на получение статуса ? ...
ну я бы для выключателя бы отправля бы статус, причем сразу в запросе указывал бы, нужен мне статус о выполнении или нет ?Для смены индикатора например.
А для димера зачем статус ? димер каждое значение должен отправить как можно быстрее, , а если 2 потеряются , это норма, или для датчика температуры ? отправил - хорошо, не отправил - есть сервер который мониторит все и логирует , он же PC , где на это можно вешать обработку, что датчик температуры с комнаты уже 2 часа молчит... Ну для тревожных понятное статус тоже нужен ... Пока читал пришла такая идея..
Типов у вас тоже много ... не понимаю зачем...
я бы просто выделил пару байт на серийный номер устройства, а путем некоторых комбинаций, программировали бы на реле коды кнопок, и сохранял бы в пзу. но это мое мнение.. ваш код я еще не видел, и CAN только заказал, еще не щупал ...
зато с rs485 игрался уже, и у меня там возникла похожая проблема , только не зависало, а приходила ерунда =) А все потому, что кан что 485 должны сидеть на общей шине, без больших ответвлений, а у меня вышло топология звезда которая соединена с другой звездой по общей шине ))
По поводу velbus
https://forum.arduino.cc/index.php?topic=185743.0
человек на базе mcp_can нарисовал свою библиотеку Velbus для MCP2515
Хочу присоединиться к вам, и к разработке тоже, но все таки задачи у нас немного разные ...
я собираюсь собрать все на одной плате на базе atmega328 (к примеру)
ну и распаять MCP2551, вот только пока не понимаю нужен ли мне MCP2515 или действительно MCP2551 заведется по urart
Добро пожаловать.
Тут как говориться на вкус и цвет.... Просто я пока не готов на этом этапе Э3 и Т5М делать. Проще взять готовый контроллер, с его ценой 200 руб, если надо потом нарисовать готовую плату с разу с МК и CAN.
По Поводу вашей проблемы, зависания, если таки дело в кабеле, то нужно терминатор с подтягивающим резистором ставить, и если в кан также как и 485 то и шунт тоже нужен, и общее сопротивление на линии не должно превышать 150 ом... ( по памяти, нужно гуглить) не забывая закон ома. =) ну если поможет...
Почему сбоит не главная проблема, это я сам разгребу. Важно что нам не удается после сбоя MCP сделать ему ресет без ресета МК. MCP сглючивает и по SPI начинает сыпать 0x000 с DLC 0 в МК. Попытка его перинициализации разными способами приводит либо к зависанию МК либо невозможности его проинициализировать.
По поводу ваших наработок, к сожалению у меня нет доступа к ядиску, не хотели бы выложиться на github или bitbucket ? там можно удобно работать коллективно и коммитить и мержить изменения, на крайняк ветки делать.. Например , то что работает, коммитим в мастер, что то новое разрабатываем в стейджинг, когда готово, фичу мержим с мастер и пулим, и все видят новую версию ... На крайняк форкнуть можно код... также и откаты и ревизии, итд ... ну вы должны знать это ?
или хотя бы пришлите код ваш, хочу посмотреть ) спасибо .
Систем контроля версий много, у меня на работе аппаратчики ипользуют mercurial, программисты тоже на CVS по моему сидят.
Тут нужно MaksVV убеждать, он на этом этапе сейчас главный гразработчик, а я скорее тестировщик.
А зачем доступ к ядиску просто щелкни по ссылке и качай с наших. https://yadi.sk/d/uJmEBPO_3UCBjj
Читал долго, и все таки кажется много лишнего у вас в протоколе, статус на получение статуса ? ...
ну я бы для выключателя бы отправля бы статус, причем сразу в запросе указывал бы, нужен мне статус о выполнении или нет ?Для смены индикатора например.
А для димера зачем статус ? димер каждое значение должен отправить как можно быстрее, , а если 2 потеряются , это норма, или для датчика температуры ? отправил - хорошо, не отправил - есть сервер который мониторит все и логирует , он же PC , где на это можно вешать обработку, что датчик температуры с комнаты уже 2 часа молчит... Ну для тревожных понятное статус тоже нужен ... Пока читал пришла такая идея..
Типов у вас тоже много ... не понимаю зачем...
я бы просто выделил пару байт на серийный номер устройства, а путем некоторых комбинаций, программировали бы на реле коды кнопок, и сохранял бы в пзу. но это мое мнение.. ваш код я еще не видел, и CAN только заказал, еще не щупал ...
Статус на статус это только при обмене контроллеров, если мастер рассылает бродкастом свой статус то все живые должны ответить. Это нужно для контроля сети в целом.
Статус подключеных ИУ мы не опрашиваем.
Типов как раз мало, проще получив тип сразу понимать как его обрабатывать, нежели разбираться что за устройство тебе прислало данные.
После просмотра кода станет понятнее.
я собираюсь собрать все на одной плате на базе atmega328 (к примеру)
ну и распаять MCP2551, вот только пока не понимаю нужен ли мне MCP2515 или действительно MCP2551 заведется по urart
Просто ради интереса прочитай какие ф-ии выполняет MCP2515 http://microsin.net/adminstuff/hardware/mcp2515-stand-alone-can-controller-with-spi-interface.html
mcp2551 как и tja1050 который стоит на наших готовых контроллерах https://www.makerfabs.com/index.php?route=product/product&product_id=340 это трансивер который согласует уровни, в общем он логику протокола не делает, сеть на нем не построишь.
Просто поверь на слово НЕ СТОИТ программно реализовывать CAN протокол на 8 разрядном MK когда есть готовый модуль с SPI на котором tja1050 + MCP2515.
Вернее так если интересно попробывать написать свой протокол 2 уровня то вперед.
и для синхронизации процессов в сети. В широковещательном статусе мастера содержится время. Узлы могут выполнять какие либо действия, засинхронизировавшись относительно чего то общего - статуса мастера.
Например, периодическую отправку своих параметров выполняют в "своё" время. Чтобы не накладывалось много сообщений в один момент в шине.
Ты же дятел и в программировании и в схемотехнике. О чем с тобой разговаривать. Не иначе ты влез в тему в надежде, что за тебя напишут код и разработают железку... Ты послан. Можешь не отвечать.
вот вспомнил, есть интересный проект умной теплицы уважаемого коллеги по форуму DIYMan. Много чего можно взять на заметку. Например идея конфигуратора это гуд. Но не в моих силах к сож. Автор гораздо опытнее в программировании, меня точно.
RIV заливал простейший скетч пинг понга, всё равно часа через три начинаются ошибки, откуда берётся мусор в шине, не понятно. Имхо прошивка тут не причём. У меня на трех МК разнесённых на 20м FTP 5e кабелем работает без сбоев.
да, на китайской плате не выведен.
Парни, пора переходить на ООП.
Помогут не инкапсуляция и полиморфизм, а структурное программирование.
Так что же нам поможет ;-)
Парадигма объектно-ориентированного программиования со своими основными понятиями инкапсуляция, полиформизм и наследование ( Классы там всякие со всойствами методами и событиями)
ИЛИ
Парадигма структурного программирования с принципами обеспечивающими читаемость програмыи избавлением от SC. (Ну просто логичный структурированыый код)
Тот же вопрос про легкость согласования длинноволновых линий связи. Утверждение основано на опыте или теории?