Коллеги, предлагаю дискутировать , не переходя на личности. Уважайте друг друга. Читать такие вещи противно если честно. Взрослые ведь уже. Мы тут письками не мереемся, мы пытаемся сеть построить.
Коллеги, предлагаю дискутировать , не переходя на личности. Уважайте друг друга. Читать такие вещи противно если честно. Взрослые ведь уже. Мы тут письками не мереемся, мы пытаемся сеть построить.
(Так тут я сбредил, здесь пишут про ресет на 17 ноге и выводе на INT)
19 нога не задействована я уже почти пришел к тому чтобы через 10кОм на 19 ногу GPIO от ардуино подпаять и держать там HIGH для ресета дать LOW на 10-20 мс
автосброс по этой схеме используется для того чтобы он происходил автомаически один раз при подаче питания (требование даташита MCP2515 делать сброс после подачи питания), но нам это не нужно, т.к. мы с ардуины делаем сброс при помощи SPI.
Вообще сброс по SPI эквивалентен, я так понял, сбросу по пину Reset. Вот выдержка из текста описания MCP2515
1. Hardware Reset (аппаратный сброс) - низким уровнем на выводе /RESET.
4
2. SPI Reset - подачей команды Reset через SPI.
5
Функционал обоих видов сброса эквивалентен. Важно осуществить один из этих способов сброса после включения питания, чтобы гарантировать переход логики и регистров в свое состояние по умолчанию.
Я научился делать фильтры правильно. Маске 0 соответсвуют фильтры 0 и 1. Маске 1 соответствуют фильтры 2,3,4,5. Так вот нужно задавать все маски и фильтры, иначе MCP воспринимает маску и фильтр как 0, что не правильно.
Но, т.к. у нас один из фильтров на второй разряд ID равен 00 (шириоковещательные), то в целом будут пролетать ID вообще со всеми нулями, что нам не нужно. Тут два выхода:
- Сделать широковещательные 0xFF (будет проблем с enum, т.к. выходит за пределы)
- устанавливать брошенный нами бит direction в 1 на ВСЕХ используемыми нами сообщениях, таким образом, наши сообщения никогда не будут с ID равном полностью 0 - считаю наилучший вариант.
если мы так сделаем, то аппаратно не будут проходить большие ID 0х00000000 и маленькие 0х000. Думаю это даст шанс на исправление косяков.
(Так тут я сбредил, здесь пишут про ресет на 17 ноге и выводе на INT)
19 нога не задействована я уже почти пришел к тому чтобы через 10кОм на 19 ногу GPIO от ардуино подпаять и держать там HIGH для ресета дать LOW на 10-20 мс
(Нужно схему смотреть с платы, вешером посмотрю)
бывают два корпуса MCP2515 - 20 ногий TSSOP и 18 ногий PDIP/SOIC.
У нас 18 ногий PDIP/SOIC. Поэтому пин reset у нас 17 нога. У 20 ногого TSSOP reset, всё правильно, 19 нога. Надеюсь до этого гемора с хард ресетом не дойдет.
ЗЫ есть ещё корпус 20 ногий 4x4 QFN* у него reset тоже 17 нога.
пока вот 11 версия. Теперь аппаратно не просачиваются 0х00000000 и 0х000. Поставил в нашем скетче в отправляемом фрейме в заголовке бит direction везде "1" (надеюсь везде исправил).
И судя по схеме через R3 на 17 ногу всегда подается +5. Знаешь номинал R3?
дак конечно, это потяжка к питанию, чтобы помехи не влияли, а то бы так постоянно спонтанно перезагружался MCP2515. Я думаю кОм 10 он. Да, всё верно, щас проверил 10кОм. (маркирвка резистора 103)
Протокол CAN предоставляет изощренные механизмы определения наличия ошибок. Можно детектировать следующие ошибки.
04
05
CRC Error. Проверка контрольной суммы (Cyclic Redundancy Check, CRC): передатчик вычисляет специальные проверочные биты для данных начиная от SOF и заканчивая полем данных. Последовательность бит CRC передается в поле CRC фрейма. Принимающий узел также вычисляет последовательность бит CRC по той же самой формуле, что и передатчик, и сравнивает вычисленную CRC с принятой. Если обнаружено несовпадение, то произошла ошибка CRC, и тогда генерируется фрейм ошибки. Передача сообщения повторяется.
06
07
Acknowledge Error. В поле подтверждения сообщения передатчик проверяет, находится ли там доминантный бит (доминантный бит должен быть установлен приемником сообщения, тогда как передатчик посылает этот бит как рецессивный). Если в поле подтверждения отсутствует доминантный бит, то значит противоположный узел не принял корректно фрейм. Как следствие возникает ошибка подтверждения (acknowledge error), генерируется фрейм ошибки и передача сообщения повторяется.
08
09
Form Error. Если узел детектирует доминантный бит в одном из 4 сегментов, где его не должно быть - включая конец фрейма end-of-frame (EOF), промежуток между фреймами interframe space (IFS), разделитель подтверждения (acknowledge delimiter) или разделитель CRC, то тогда возникает ошибка формы, и генерируется ошибка фрейма. Передача сообщения повторяется.
10
11
Bit Error. Ошибка бита возникает, если передатчик детектирует противоположный уровень бита, не соответствующий тому, который был послан (например, передавался доминантный бит, но был детектирован рецессивный, или был передан рецессивный бит, но на шине вместо него был обнаружен доминантный бит).
12
13
Исключение имеется только для поля арбитража и слота подтверждения: если передатчик посылает рецессивный бит, и детектирует доминантный, то не генерируется ошибка бита, потому что это нормальные ситуации арбитража и получения подтверждения в протоколе CAN.
14
15
Stuff Error. Если в промежутке между началом фрейма (start-of-frame, SOF) и разделителем CRC, обнаружено 6 следующих друг за другом бит одинаковой полярности, то нарушено правило бит-стаффинга. Тогда происходит ошибка бит-стаффинга и генерируется ошибка фрейма. Передача сообщения повторяется.
16
17
Состояния ошибки. Про обнаруженные ошибки все другие узлы сети CAN узнают через генерацию и получение фреймов ошибки (error frame, см. рис. 2-4). Передача фрейма ошибочного сообщения прерывается, и этот фрейм повторяется, как только это становится возможным. Кроме того, каждый узел CAN находится в одном из 3 состояний ошибки, каждое из которых соответствует значению внутренних счетчиков ошибок:
18
19
1. Error-active (состояние активной ошибки).
20
2. Error-passive (состояние пассивной ошибки).
21
3. Bus-off (шина выключена, это относится только к передатчику).
22
23
Состояние error-active это обычное состояние, когда узел может передавать сообщения и фреймы активной ошибки (построенного из доминантных бит, см. рис. 2-4) без каких-либо ограничений.
24
25
В состоянии error-passive могут передаваться сообщения и фреймы пассивной ошибки (состоящие из рецессивных бит).
26
27
Состояние bus-off временно делает невозможным для узла участвовать в обмене по шине. Во время этого состояния сообщения не могут ни приниматься, ни передаваться. Только передатчики могут перейти в состояние bus-off.
28
29
Режимы ошибки и счетчики ошибок. Контроллер MCP2515 содержит 2 счетчика ошибок: счетчик ошибок приема Receive Error Counter, REC (см. регистр 6-2) и счетчик ошибок передачи Transmit Error Counter, TEC (см. регистр 6-1). Значения этих обоих счетчиков может прочитать управляющий микроконтроллер. Эти счетчики инкрементируются / декрементируются в соответствии со спецификацией шины CAN.
30
31
MCP2515 находится в состоянии error-active, если значение обоих счетчиков меньше 128, предела error-passive. В состояние error-passive MCP2515 переходит, если как минимум один из счетчиков ошибок равен или больше 128.
32
33
В состояние bus-off контроллер переходит, если TEC превышает 255, предел bus-off. Контроллер остается в этом состоянии, пока не будет принята последовательность восстановления шины (bus-off recovery sequence). Bus-off recovery sequence состоит из 128 передач следующих друг за другом 11 последовательных рецессивных бит (см. рис. 6-1).
34
35
Примечание: после того, как MCP2515, перейдет в bus-off, он восстановится обратно в состояние error-active без какого-либо вмешательства со стороны управляющего микроконтроллера, если шина остается в состоянии ожидания (idle) на время 128 * 11 бит. Если это нежелательно, то такая ситуация должна быть адресована обработчику прерывания.
36
Текущий режим работы MCP2515 может быть прочитан управляющим микроконтроллером через регистр EFLG (см. регистр 6-3).
37
38
Дополнительно есть бит флага предупреждения о состоянии ошибки (error state warning flag, EFLG:EWARN), который установится, если как минимум один из счетчиков ошибок превысит лимит 96. Бит EWARN сбрасывается, если оба счетчика ошибок станут меньше 96.
По идее в момент глюка можно вывести инфу в каком режиме по ошибкам находится MCP2515. Переполнены ли буферы.
И судя по схеме через R3 на 17 ногу всегда подается +5. Знаешь номинал R3?
дак конечно, это потяжка к питанию, чтобы помехи не влияли, а то бы так постоянно спонтанно перезагружался MCP2515. Я думаю кОм 10 он. Да, всё верно, щас проверил 10кОм. (маркирвка резистора 103)
Я тут посоветовался со своими разработчиками, они насоветовали от GPIO DUE через диод и резистор 500 ом + стабилитрон на ногу 17 подать 0. Ну это на бегу.
Воткнул твою функцию readErrorFlags_MCP2515 (); в 5 мест
1. в RX() в начале где return по 0 ID
2. в RX() в конце где default case
3. в test() под 9
4. В printStatus() в начале.
5 В конце MCP2515_Init
В итоге при кадом выводе статуса имеем список ошибок, при сбое имеем список ошибок, после инит имеем список ошибок, ну и ручками всегда можем посмотреть.
Поставил ждем.
Кстати к размышлению. У меня громе DUE которые включены в комп, все осталные платы (узлы 6-21) на автономном питании от единого БП, я из как включил 2 дня назад так и не выключал. Так вот там ошибок нет.
Но они интенсивно в отличии от мастера с передачей 1 раз в секунду не обмениваются.
Т.е получается валимся при интенсивном обмене и не в терминаторах дело. В общем буду смотреть накопление ошибок.
вот немного подкорректированная функция чтения ошибок. Показывает кроме флагов также количество ошибок. Я в два места запихал. CTRL+F ом найдешь. 12 версия.
поставь 12 версию, посмотрим как количество ошибок меняется. В описании написано что счётчики увеличиваются и уменьшаются в соответствии со спецификацией CAN - уж не знаю по какому алгоритму.
ага неизвестный тип сообщения , да ещё фрейм ремоут докучи О_О. Эта шина над нами издевается, ноль убрали - дак это стало просачиваться. При том что MCP2515 виснет к тому же при получении такого сообщения. И видимо на пине INT висит сигнал что сообщение принято, и он одно и тоже глюкавое б/у шное сообщение показывает.
отключи узел 13, может он козлит. По одному отключай и смотри. Судя по логу, вообще беда. еще и ардуина докучи перезагружалась , смотри время сбрасывалось вначале лога на 4 мин.
отключи узел 13, может он козлит. По одному отключай и смотри. Судя по логу, вообще беда. еще и ардуина докучи перезагружалась , смотри время сбрасывалось вначале лога на 4 мин.
Ну а сейчас от 9 было
041
-------CAN MESSAGE RX ADRRESSED TO ME-------
042
ID 8E090400
043
type_msg - Неизвестное сообщение
044
node_addr - node_9_Kitchen_net_center
045
Rem_addr - node_4_Net_center_Due1
046
Dev_type - NULL DEVICE
047
DATA FRAME 00 00 00 00 00 00 00 00
048
--------------------------------------------
Важно же не только из-за чего но и что делать если. Мало того CAN сам должкн отрабатывать
ООП более структурировано, привыкнете писать красиво и правильно. По своему опыту знаю проекты, начавшиеся на чистом С, обычно переписываются на С++, обратно никогда.
riv пишет:
вопрос про легкость согласования длинноволновых линий связи. Утверждение основано на опыте или теории?
Опыт в соответствии с теорией. Произвольную топологию в принципе нельзя согласовать. Задержка распространения сигнала в медном кабеле 4.8 мкс/км, 19200 это предел для несогласованной линии 1 км.
ООП более структурировано, привыкнете писать красиво и правильно. По своему опыту знаю проекты, начавшиеся на чистом С, обычно переписываются на С++, обратно никогда.
riv пишет:
вопрос про легкость согласования длинноволновых линий связи. Утверждение основано на опыте или теории?
Опыт в соответствии с теорией. Произвольную топологию в принципе нельзя согласовать. Задержка распространения сигнала в медном кабеле 4.8 мкс/км, 19200 это предел для несогласованной линии 1 км.
Я то насчет КСВ с КБВ и четверть волонового трансформатора имел в виду. Ну и чем длиннее волна тем сложнее согласовывать линии. Снижение скорости снижаетчастоту но и увеличивает длинну волны.
Я конечно понимаю что тут манипуляция а не модуляция, так как физ линия, но все же.
Ну и проблемы то у нас другого характера, ошибки на CAN есть но они очень эпизодические. Явно если бы линиям было недостаточно согласования она бы часами не стояла нормально.
А вообще регистры неадекватно показывает. То все биты сразу 1. То все 0. Ошибки то 255, то 0 - бред. Хотя проверял на регистре режима работы (нормал, лупбэк, листен онли, слип) - нормально показывает, значит правильно запрашиваю. и раз ID начинается с 8 значит direction равно 0. А я везде сделал его 1. То бишь бабайка этот фрейм отправил. Домовёнок у тебя к кану подключился. 21 век как никак.
И самое главное как оно просочилось через фильтр? О_О
Фильтр стоит что direction только с 1 должен проходить. можешь проверить на простом скетче. Это не поддается объяснению.
А вообще регистры неадекватно показывает. То все биты сразу 1. То все 0. Ошибки то 255, то 0 - бред. Хотя проверял на регистре режима работы (нормал, лупбэк, листен онли, слип) - нормально показывает, значит правильно запрашиваю. и раз ID начинается с 8 значит direction равно 0. А я везде сделал его 1. То бишь бабайка этот фрейм отправил. Домовёнок у тебя к кану подключился. 21 век как никак.
dlc 8 не везде. В REQUEST_SEND я вообщето direction исправил в 11 версии ещё вроде как . Ты хоть мои скетчи то заливаешь или гибриды опять делаешь? А то наворотим щас тут. Я буду думать что исправил, а у тебя в итоге не исправлено. А потом думай, почему не работает. Часы 3231 есть. код выложу
короче если опять шина закозлит заливай опять упрощённый скетч - я его немного поправил. Он на коротких ID. мастер шлёт статус ID 666. Узлы отвечают 0XX, где ХХ - адрес узла. Посмотрим как себя поведёт. Заметь скорость поставил 125 кбит. 500 больше не ставь нигде, нафиг такая большая не нужна. Тем более расстояния довольно большие. 125 в самый раз.
dlc 8 не везде. В REQUEST_SEND я вообщето direction исправил в 11 версии ещё вроде как . Ты хоть мои скетчи то заливаешь или гибриды опять делаешь? А то наворотим щас тут. Я буду думать что исправил, а у тебя в итоге не исправлено. А потом думай, почему не работает. Часы 3231 есть. код выложу
Заливаю твои, но подкручиваю дебаг, сам видишь как выводит, меня это отправлено в CAN достает в логе.
Вроде залита 11 с измененной ф-й вывода ошибок из 12. Я специально спросил, ты только ее изменил.
Я кстати про это и говорил что
1. Вставляй в основной файл что то вроде //ver 12
2. По времени подготовить код и залить его во все контроллеры это 2-3 часа. Поэтому без серьезных изменения я только в DUE меняю код. И кстати МК не вснут
короче если опять шина закозлит заливай опять упрощённый скетч - я его немного поправил. Он на коротких ID. мастер шлёт статус ID 666. Узлы отвечают 0XX, где ХХ - адрес узла. Посмотрим как себя поведёт. Заметь скорость поставил 125 кбит. 500 больше не ставь нигде, нафиг такая большая не нужна. Тем более расстояния довольно большие. 125 в самый раз.
Ок завтра поставлю. Пусть 12 простоит ночь. Уже 4 часа без малого стоит.
Вроде залита 11 с измененной ф-й вывода ошибок из 12. Я специально спросил, ты только ее изменил.
нужно наверное убрать в 5 местах обращения к регистрам - коряво всё это работает почему то
riv пишет:
1. Вставляй в основной файл что то вроде //ver 12
ладно, просто в шапке показывается же название файла. Но ок, мне не сложно это добавлять.
riv пишет:
По времени подготовить код и залить его во все контроллеры это 2-3 часа. Поэтому без серьезных изменения я только в DUE меняю код.
но вот это конечно не гуд, из-за этого и могут быть проблемы. Где то скетч старый остался, а мы тут гадаем, че за шляпа творится. И убери пока DUE - глючная она. Потом вернёшь когда всё наладится.
ладно, просто в шапке показывается же название файла. Но ок, мне не сложно это добавлять.
но вот это конечно не гуд, из-за этого и могут быть проблемы. Где то скетч старый остался, а мы тут гадаем, че за шляпа творится. И убери пока DUE - глючная она. Потом вернёшь когда всё наладится.
Посмотри файл лога, как на DUE добиться такого вывода настройками?
Я беру твой пакет, создаю под каждый папку с именем узла, переименовываю основной файл, открываю, настраиваю. На выходе если нет указателя что за версия то хрен поймешь что стоит. Так что лучше даже в лог пусть выводит вместе с именем узла.
Ну я условно сказал. Везде стоит 11 версия, так как лог я снимаю только с DUE то протсо вставил ф-ю снятия ошибок из регистров.
DUE завтра поменяю. Но я думаю не в DUE дело. Каждая плата свои либы имеет и может конфликтовать.
какое то Default msg_id !=0 && >12 вспыло. зачем ты ID_Print в труе ставишь. Нафиг эти рамки - по ID уже и так на глаз всё определяем, примелькаклось уже.
У меня кстати при удачной перинициализации вообще не так в отадке всё было . см видос. Че то у тебя не так как у меня в скетче, похоже.
какое то Default msg_id !=0 && >12 вспыло. зачем ты ID_Print в труе ставишь. Нафиг эти рамки - по ID уже и так на глаз всё определяем, примелькаклось уже.
У меня кстати при удачной перинициализации вообще не так в отадке всё было . см видос. Че то у тебя не так как у меня в скетче, похоже.
я не знаю в чём у тебя там проблема, но на узле аж на 4 часа хватает такой записи в мониторе порта. Этого хватит, чтобы косяки засечь. Не говоря уже про мастер, где данные два раза в минуту пишутся. Там весь лог записался от начала до конца. Вот 5-часовой тест мастера и одного узла №10. Глюки отсутсвуют полностью. В конце, для прикола, сделал с монитора порта переинициализацию MCP2515. Если бы были косяки, по такой отладке у узла можно определить что и когда он отсылал и получил. Время у него посмотреть, не простаивало ли. Сравнить что в это время на мастере творилось.
я не знаю в чём у тебя там проблема, но на узле аж на 4 часа хватает такой записи в мониторе порта. Этого хватит, чтобы косяки засечь. Не говоря уже про мастер, где данные два раза в минуту пишутся. Там весь лог записался от начала до конца. Вот 5-часовой тест мастера и одного узла №10. Глюки отсутсвуют полностью. В конце, для прикола, сделал с монитора порта переинициализацию MCP2515. Если бы были косяки, по такой отладке у узла можно определить что и когда он отсылал и получил. Время у него посмотреть, не простаивало ли. Сравнить что в это время на мастере творилось.
Представь определения в студию, и к ним интерфейсы добавь. Посмотрим, что ты нафантазировал, посмеемся когда у тебя SPI "асинхронным" окажется.
Напомни мне где я врал и на чем был ловлен с поличными
В #781 врал, в #797 был пойман на вранье.
Ты послан. Можешь не отвечать.
А, так ты слился, соплячок. Накозлил глупостей с три короба - и теперь в кусты.
Коллеги, предлагаю дискутировать , не переходя на личности. Уважайте друг друга. Читать такие вещи противно если честно. Взрослые ведь уже. Мы тут письками не мереемся, мы пытаемся сеть построить.
Коллеги, предлагаю дискутировать , не переходя на личности. Уважайте друг друга. Читать такие вещи противно если честно. Взрослые ведь уже. Мы тут письками не мереемся, мы пытаемся сеть построить.
Согласен полностью.
Т.к. согласно схемы http://electronicsworld.ru/wp-content/uploads/2017/11/niren_mcp2515-CAN-Bus-Module-Schematics.png
(Так тут я сбредил, здесь пишут про ресет на 17 ноге и выводе на INT)
19 нога не задействована я уже почти пришел к тому чтобы через 10кОм на 19 ногу GPIO от ардуино подпаять и держать там HIGH для ресета дать LOW на 10-20 мс
http://microsin.net/images/stories/hard/MCP2515-RESET-pin-example-fig9-1.png
Думаю диод с конденсатором и R не нужны т.к автосброс мы не реализуем.
(Нужно схему смотреть с платы, вешером посмотрю)
автосброс по этой схеме используется для того чтобы он происходил автомаически один раз при подаче питания (требование даташита MCP2515 делать сброс после подачи питания), но нам это не нужно, т.к. мы с ардуины делаем сброс при помощи SPI.
Вообще сброс по SPI эквивалентен, я так понял, сбросу по пину Reset. Вот выдержка из текста описания MCP2515
1MCP2515 различает два способа сброса:231. Hardware Reset (аппаратный сброс) - низким уровнем на выводе /RESET.42. SPI Reset - подачей команды Reset через SPI.5Функционал обоих видов сброса эквивалентен. Важно осуществить один из этих способов сброса после включения питания, чтобы гарантировать переход логики и регистров в свое состояние по умолчанию.Я научился делать фильтры правильно. Маске 0 соответсвуют фильтры 0 и 1. Маске 1 соответствуют фильтры 2,3,4,5. Так вот нужно задавать все маски и фильтры, иначе MCP воспринимает маску и фильтр как 0, что не правильно.
Но, т.к. у нас один из фильтров на второй разряд ID равен 00 (шириоковещательные), то в целом будут пролетать ID вообще со всеми нулями, что нам не нужно. Тут два выхода:
- Сделать широковещательные 0xFF (будет проблем с enum, т.к. выходит за пределы)
- устанавливать брошенный нами бит direction в 1 на ВСЕХ используемыми нами сообщениях, таким образом, наши сообщения никогда не будут с ID равном полностью 0 - считаю наилучший вариант.
если мы так сделаем, то аппаратно не будут проходить большие ID 0х00000000 и маленькие 0х000. Думаю это даст шанс на исправление косяков.
(Так тут я сбредил, здесь пишут про ресет на 17 ноге и выводе на INT)
19 нога не задействована я уже почти пришел к тому чтобы через 10кОм на 19 ногу GPIO от ардуино подпаять и держать там HIGH для ресета дать LOW на 10-20 мс
(Нужно схему смотреть с платы, вешером посмотрю)
бывают два корпуса MCP2515 - 20 ногий TSSOP и 18 ногий PDIP/SOIC.
У нас 18 ногий PDIP/SOIC. Поэтому пин reset у нас 17 нога. У 20 ногого TSSOP reset, всё правильно, 19 нога. Надеюсь до этого гемора с хард ресетом не дойдет.
ЗЫ есть ещё корпус 20 ногий 4x4 QFN* у него reset тоже 17 нога.
Нв выходе пока бъемся с софтом?
И судя по схеме через R3 на 17 ногу всегда подается +5. Знаешь номинал R3?
пока вот 11 версия. Теперь аппаратно не просачиваются 0х00000000 и 0х000. Поставил в нашем скетче в отправляемом фрейме в заголовке бит direction везде "1" (надеюсь везде исправил).
Исправил фильтры
И судя по схеме через R3 на 17 ногу всегда подается +5. Знаешь номинал R3?
дак конечно, это потяжка к питанию, чтобы помехи не влияли, а то бы так постоянно спонтанно перезагружался MCP2515. Я думаю кОм 10 он. Да, всё верно, щас проверил 10кОм. (маркирвка резистора 103)
вот инфа из описания MCP2515 как детектируются ошибки в MCP2515
01[Детектирование ошибок]0203Протокол CAN предоставляет изощренные механизмы определения наличия ошибок. Можно детектировать следующие ошибки.0405CRC Error. Проверка контрольной суммы (Cyclic Redundancy Check, CRC): передатчик вычисляет специальные проверочные биты для данных начиная от SOF и заканчивая полем данных. Последовательность бит CRC передается в поле CRC фрейма. Принимающий узел также вычисляет последовательность бит CRC по той же самой формуле, что и передатчик, и сравнивает вычисленную CRC с принятой. Если обнаружено несовпадение, то произошла ошибка CRC, и тогда генерируется фрейм ошибки. Передача сообщения повторяется.0607Acknowledge Error. В поле подтверждения сообщения передатчик проверяет, находится ли там доминантный бит (доминантный бит должен быть установлен приемником сообщения, тогда как передатчик посылает этот бит как рецессивный). Если в поле подтверждения отсутствует доминантный бит, то значит противоположный узел не принял корректно фрейм. Как следствие возникает ошибка подтверждения (acknowledge error), генерируется фрейм ошибки и передача сообщения повторяется.0809Form Error. Если узел детектирует доминантный бит в одном из 4 сегментов, где его не должно быть - включая конец фрейма end-of-frame (EOF), промежуток между фреймами interframe space (IFS), разделитель подтверждения (acknowledge delimiter) или разделитель CRC, то тогда возникает ошибка формы, и генерируется ошибка фрейма. Передача сообщения повторяется.1011Bit Error. Ошибка бита возникает, если передатчик детектирует противоположный уровень бита, не соответствующий тому, который был послан (например, передавался доминантный бит, но был детектирован рецессивный, или был передан рецессивный бит, но на шине вместо него был обнаружен доминантный бит).1213Исключение имеется только для поля арбитража и слота подтверждения: если передатчик посылает рецессивный бит, и детектирует доминантный, то не генерируется ошибка бита, потому что это нормальные ситуации арбитража и получения подтверждения в протоколе CAN.1415Stuff Error. Если в промежутке между началом фрейма (start-of-frame, SOF) и разделителем CRC, обнаружено 6 следующих друг за другом бит одинаковой полярности, то нарушено правило бит-стаффинга. Тогда происходит ошибка бит-стаффинга и генерируется ошибка фрейма. Передача сообщения повторяется.1617Состояния ошибки. Про обнаруженные ошибки все другие узлы сети CAN узнают через генерацию и получение фреймов ошибки (error frame, см. рис. 2-4). Передача фрейма ошибочного сообщения прерывается, и этот фрейм повторяется, как только это становится возможным. Кроме того, каждый узел CAN находится в одном из 3 состояний ошибки, каждое из которых соответствует значению внутренних счетчиков ошибок:18191. Error-active (состояние активной ошибки).202. Error-passive (состояние пассивной ошибки).213. Bus-off (шина выключена, это относится только к передатчику).2223Состояние error-active это обычное состояние, когда узел может передавать сообщения и фреймы активной ошибки (построенного из доминантных бит, см. рис. 2-4) без каких-либо ограничений.2425В состоянии error-passive могут передаваться сообщения и фреймы пассивной ошибки (состоящие из рецессивных бит).2627Состояние bus-off временно делает невозможным для узла участвовать в обмене по шине. Во время этого состояния сообщения не могут ни приниматься, ни передаваться. Только передатчики могут перейти в состояние bus-off.2829Режимы ошибки и счетчики ошибок. Контроллер MCP2515 содержит 2 счетчика ошибок: счетчик ошибок приема Receive Error Counter, REC (см. регистр 6-2) и счетчик ошибок передачи Transmit Error Counter, TEC (см. регистр 6-1). Значения этих обоих счетчиков может прочитать управляющий микроконтроллер. Эти счетчики инкрементируются / декрементируются в соответствии со спецификацией шины CAN.3031MCP2515 находится в состоянии error-active, если значение обоих счетчиков меньше 128, предела error-passive. В состояние error-passive MCP2515 переходит, если как минимум один из счетчиков ошибок равен или больше 128.3233В состояние bus-off контроллер переходит, если TEC превышает 255, предел bus-off. Контроллер остается в этом состоянии, пока не будет принята последовательность восстановления шины (bus-off recovery sequence). Bus-off recovery sequence состоит из 128 передач следующих друг за другом 11 последовательных рецессивных бит (см. рис. 6-1).3435Примечание: после того, как MCP2515, перейдет в bus-off, он восстановится обратно в состояние error-active без какого-либо вмешательства со стороны управляющего микроконтроллера, если шина остается в состоянии ожидания (idle) на время 128 * 11 бит. Если это нежелательно, то такая ситуация должна быть адресована обработчику прерывания.36Текущий режим работы MCP2515 может быть прочитан управляющим микроконтроллером через регистр EFLG (см. регистр 6-3).3738Дополнительно есть бит флага предупреждения о состоянии ошибки (error state warning flag, EFLG:EWARN), который установится, если как минимум один из счетчиков ошибок превысит лимит 96. Бит EWARN сбрасывается, если оба счетчика ошибок станут меньше 96.По идее в момент глюка можно вывести инфу в каком режиме по ошибкам находится MCP2515. Переполнены ли буферы.
И судя по схеме через R3 на 17 ногу всегда подается +5. Знаешь номинал R3?
дак конечно, это потяжка к питанию, чтобы помехи не влияли, а то бы так постоянно спонтанно перезагружался MCP2515. Я думаю кОм 10 он. Да, всё верно, щас проверил 10кОм. (маркирвка резистора 103)
Я тут посоветовался со своими разработчиками, они насоветовали от GPIO DUE через диод и резистор 500 ом + стабилитрон на ногу 17 подать 0. Ну это на бегу.
По идее в момент глюка можно вывести инфу в каком режиме по ошибкам находится MCP2515. Переполнены ли буферы.
Сможешь это сделать? Я с регистрами вообще на Вы.
вот фукция, а вот когда её вызывать вопрос. Если мастер , то можно при каждом получении статуса от узла
Если узел, то при каждом получении статуса мастера.
01voidreadErrorFlags_MCP2515 () {0203SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));// начало связи по SPI ( скорость , очередность, режим SPI)04digitalWrite(csPIN, LOW);// выбираем устройство на шине SPI (пин CS нужного устройства в лоу)05SPI.transfer(0x03);// команда прочитать регистры MCP2515 в BIN это 0000001106SPI.transfer(0x2D);// адрес регистра 6-3 EFGL - Error Flag07byteinByteSPI = SPI.transfer(0x00);// получение данных из шины SPI08digitalWrite(csPIN, HIGH);// отпускаем пин CS09SPI.endTransaction();// конец связи по SPI1011// ниже разборка полученного байта на биты12if(inByteSPI != 0) {for(inti=0; i<8; i++) {13if(i==0) {if(bitRead (inByteSPI, i))Serial.print (F(" RX or TX errors >= 96 "));}14elseif(i==1) {if(bitRead (inByteSPI, i))Serial.print (F(" RX errors >= 96 "));}15elseif(i==2) {if(bitRead (inByteSPI, i))Serial.print (F(" TX errors >= 96 "));}16elseif(i==3) {if(bitRead (inByteSPI, i))Serial.print (F(" RX errors >= 128. Mode ErrorPassive "));}17elseif(i==4) {if(bitRead (inByteSPI, i))Serial.print (F(" TX errors >= 128. Mode ErrorPassive ")); }18elseif(i==5) {if(bitRead (inByteSPI, i))Serial.print (F(" TX errors == 255. Mode BusOff ")); }19elseif(i==6) {if(bitRead (inByteSPI, i))Serial.print (F(" Переполнен буфер приёма RX0 ")); }20elseif(i==7) {if(bitRead (inByteSPI, i))Serial.print (F(" Переполнен буфер приёма RX1 "));Serial.println(); }21}2223}24elseSerial.println (F("NO Errors"));2526}Воткнул твою функцию readErrorFlags_MCP2515 (); в 5 мест
1. в RX() в начале где return по 0 ID
2. в RX() в конце где default case
3. в test() под 9
4. В printStatus() в начале.
5 В конце MCP2515_Init
В итоге при кадом выводе статуса имеем список ошибок, при сбое имеем список ошибок, после инит имеем список ошибок, ну и ручками всегда можем посмотреть.
Поставил ждем.
Кстати к размышлению. У меня громе DUE которые включены в комп, все осталные платы (узлы 6-21) на автономном питании от единого БП, я из как включил 2 дня назад так и не выключал. Так вот там ошибок нет.
Но они интенсивно в отличии от мастера с передачей 1 раз в секунду не обмениваются.
Т.е получается валимся при интенсивном обмене и не в терминаторах дело. В общем буду смотреть накопление ошибок.
вот немного подкорректированная функция чтения ошибок. Показывает кроме флагов также количество ошибок. Я в два места запихал. CTRL+F ом найдешь. 12 версия.
Вот вылезло
поставь 12 версию, посмотрим как количество ошибок меняется. В описании написано что счётчики увеличиваются и уменьшаются в соответствии со спецификацией CAN - уж не знаю по какому алгоритму.
Ты в ней только
да
Вот смотри что происходит
001NODES CAN COMMUNICATION:002node_5_Net_center_Due2 OK003node_6_Hallway_net_center OK004node_7_Hallway_main OK005node_8_Hallway_light OK006node_9_Kitchen_net_center OK007node_10_Kitchen_main OK008node_11_Kitchen_light OK009node_12_WC_main OK010node_13_WC_waterleak OK011node_14_Bathroom_main OK012node_15_Boxroom_main OK013node_18_Loggia_recuperator OK014node_19_Livingroom_main OK015node_20_Bedroom_main OK016node_21_Cabinet_main OK017018-------CAN MESSAGE RX ADRRESSED TO ME-------019ID CE0D0401020type_msg - Неизвестное сообщение021node_addr - node_13_WC_waterleak022Rem_addr - node_4_Net_center_Due1023Dev_type - ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ024DATA FRAME NOT DATA, BECAUSE REMOTE FRAME025026--------------------------------------------027028NO ErrorFlags029030TX Errors = 0031RX Errors = 12032Error Initializing MCP2515...033034Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!035036NO ErrorFlags037038TX Errors = 7039RX Errors = 0040Init1041NO ErrorFlags042043TX Errors = 0044RX Errors = 0045046-------CAN MESSAGE RX ADRRESSED TO ME-------047ID CE0D0401048type_msg - Неизвестное сообщение049node_addr - node_13_WC_waterleak050Rem_addr - node_4_Net_center_Due1051Dev_type - ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ052DATA FRAME NOT DATA, BECAUSE REMOTE FRAME053054--------------------------------------------055056NO ErrorFlags057058TX Errors = 0059RX Errors = 0060Error Initializing MCP2515...061062Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!063064NO ErrorFlags065066TX Errors = 0067RX Errors = 0068Init1069NO ErrorFlags070071TX Errors = 0072RX Errors = 0073074-------CAN MESSAGE RX ADRRESSED TO ME-------075ID CE0D0401076type_msg - Неизвестное сообщение077node_addr - node_13_WC_waterleak078Rem_addr - node_4_Net_center_Due1079Dev_type - ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ080DATA FRAME NOT DATA, BECAUSE REMOTE FRAME081082--------------------------------------------083084NO ErrorFlags085086TX Errors = 0087RX Errors = 12088Error Initializing MCP2515...089090Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!091092NO ErrorFlags093094TX Errors = 7095RX Errors = 0096Init1097NO ErrorFlags098099TX Errors = 0100RX Errors = 0101102-------CAN MESSAGE RX ADRRESSED TO ME-------103ID CE0D0401104type_msg - Неизвестное сообщение105node_addr - node_13_WC_waterleak106Rem_addr - node_4_Net_center_Due1107Dev_type - ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ108DATA FRAME NOT DATA, BECAUSE REMOTE FRAME109110--------------------------------------------111112NO ErrorFlags113114TX Errors = 0115RX Errors = 0116Error Initializing MCP2515...117118Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!119120NO ErrorFlags121122TX Errors = 0123RX Errors = 0124Init1125NO ErrorFlags126127TX Errors = 0128RX Errors = 0129130-------CAN MESSAGE RX ADRRESSED TO ME-------131ID CE0D0401132type_msg - Неизвестное сообщение133node_addr - node_13_WC_waterleak134Rem_addr - node_4_Net_center_Due1135Dev_type - ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ136DATA FRAME NOT DATA, BECAUSE REMOTE FRAME137138--------------------------------------------139140NO ErrorFlags141142TX Errors = 0143RX Errors = 12144Error Initializing MCP2515...145146Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!147148NO ErrorFlags149150TX Errors = 7151RX Errors = 0152Init1153NO ErrorFlags154155TX Errors = 0156RX Errors = 0157158-------CAN MESSAGE RX ADRRESSED TO ME-------159ID CE0D0401160type_msg - Неизвестное сообщение161node_addr - node_13_WC_waterleak162Rem_addr - node_4_Net_center_Due1163Dev_type - ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ164DATA FRAME NOT DATA, BECAUSE REMOTE FRAME165166--------------------------------------------Вот глянь весь лог
https://yadi.sk/d/ozOcbX7B3V5hYy
log_18.05.18.txt
лог не скачивается. почему опять всё время инит происходит? Сделай отладку для мастера таким образом
1#define debug //отладка в сериал_монитор. Закоментировать строку после отладки23#ifdef debug4#define debugStatus //отладка в сериал_монитор - таблица статусов узлов CAN сети (для МАСТЕРА) Закоментировать строку после отладки5boolID_Print = 0 ;//флаг распечатки CAN FRAMES в монитор. 0 - будут, только адресованные на данный узел. 1 - все CANFRAMES6boolstatusprint = 0 ;//флаг распечатки статусов в монитор.7#include "debug.h"8#endifСмотри полный лог, файл просто долго синхронизировался.
Инит происходит т.к постоянно получаем то что попадает в default
А вот сейчас ресетнулось
001NODES CAN COMMUNICATION:002node_5_Net_center_Due2 OK003node_6_Hallway_net_center OK004node_7_Hallway_main OK005node_8_Hallway_light OK006node_9_Kitchen_net_center OK007node_10_Kitchen_main OK008node_11_Kitchen_light OK009node_12_WC_main OK010node_13_WC_waterleak OK011node_14_Bathroom_main OK012node_15_Boxroom_main OK013node_18_Loggia_recuperator OK014node_19_Livingroom_main OK015node_20_Bedroom_main OK016node_21_Cabinet_main OK01701800:00:38:30019NO ErrorFlags020021TX Errors = 0022RX Errors = 0023024NODES CAN COMMUNICATION:025node_5_Net_center_Due2 OK026node_6_Hallway_net_center OK027node_7_Hallway_main OK028node_8_Hallway_light OK029node_9_Kitchen_net_center OK030node_10_Kitchen_main OK031node_11_Kitchen_light OK032node_12_WC_main OK033node_13_WC_waterleak OK034node_14_Bathroom_main OK035node_15_Boxroom_main OK036node_18_Loggia_recuperator OK037node_19_Livingroom_main OK038node_20_Bedroom_main OK039node_21_Cabinet_main OK040Default msg_id !=0 && >12041-------CAN MESSAGE RX ADRRESSED TO ME-------042ID 8E090400043type_msg - Неизвестное сообщение044node_addr - node_9_Kitchen_net_center045Rem_addr - node_4_Net_center_Due1046Dev_type - NULL DEVICE047DATA FRAME 00 00 00 00 00 00 00 00048--------------------------------------------049050RX or TX errors >= 96051RX errors >= 96052TX errors >= 96053RX errors >= 128. Mode ErrorPassiveisON054TX errors >= 128. Mode ErrorPassiveisON055TX errors == 255. Mode BusOffisON056Переполнен буфер приёма RX0057Переполнен буфер приёма RX1058059060TX Errors = 255061RX Errors = 255062063064MCP2515 Initialized Successfully! after REINIT065066Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!067068NO ErrorFlags069070TX Errors = 0071RX Errors = 255072073Init!074075RX or TX errors >= 96076RX errors >= 96077TX errors >= 96078RX errors >= 128. Mode ErrorPassiveisON079TX errors >= 128. Mode ErrorPassiveisON080TX errors == 255. Mode BusOffisON081Переполнен буфер приёма RX0082Переполнен буфер приёма RX1083084085TX Errors = 255086RX Errors = 25508708808900:00:39:00090NO ErrorFlags091092TX Errors = 0093RX Errors = 0094095NODES CAN COMMUNICATION:096node_5_Net_center_Due2 OK097node_6_Hallway_net_center OK098node_7_Hallway_main OK099node_8_Hallway_light OK100node_9_Kitchen_net_center OK101node_10_Kitchen_main OK102node_11_Kitchen_light OK103node_12_WC_main OK104node_13_WC_waterleak OK105node_14_Bathroom_main OK106node_15_Boxroom_main OK107node_18_Loggia_recuperator OK108node_19_Livingroom_main OK109node_20_Bedroom_main OK110node_21_Cabinet_main OK11111200:00:39:30113NO ErrorFlags114115TX Errors = 0116RX Errors = 0117118NODES CAN COMMUNICATION:119node_5_Net_center_Due2 OK120node_6_Hallway_net_center OK121node_7_Hallway_main OK122node_8_Hallway_light OK123node_9_Kitchen_net_center OK124node_10_Kitchen_main OK125node_11_Kitchen_light OK126node_12_WC_main OK127node_13_WC_waterleak OK128node_14_Bathroom_main OK129node_15_Boxroom_main OK130node_18_Loggia_recuperator OK131node_19_Livingroom_main OK132node_20_Bedroom_main OK133node_21_Cabinet_main OKНу вот откуда эти левые ID 8E090400
ага неизвестный тип сообщения , да ещё фрейм ремоут докучи О_О. Эта шина над нами издевается, ноль убрали - дак это стало просачиваться. При том что MCP2515 виснет к тому же при получении такого сообщения. И видимо на пине INT висит сигнал что сообщение принято, и он одно и тоже глюкавое б/у шное сообщение показывает.
отключи узел 13, может он козлит. По одному отключай и смотри. Судя по логу, вообще беда. еще и ардуина докучи перезагружалась , смотри время сбрасывалось вначале лога на 4 мин.
отключи узел 13, может он козлит. По одному отключай и смотри. Судя по логу, вообще беда. еще и ардуина докучи перезагружалась , смотри время сбрасывалось вначале лога на 4 мин.
Ну а сейчас от 9 было
041-------CAN MESSAGE RX ADRRESSED TO ME-------042ID 8E090400043type_msg - Неизвестное сообщение044node_addr - node_9_Kitchen_net_center045Rem_addr - node_4_Net_center_Due1046Dev_type - NULL DEVICE047DATA FRAME 00 00 00 00 00 00 00 00048--------------------------------------------Важно же не только из-за чего но и что делать если. Мало того CAN сам должкн отрабатывать
Я то насчет КСВ с КБВ и четверть волонового трансформатора имел в виду. Ну и чем длиннее волна тем сложнее согласовывать линии. Снижение скорости снижаетчастоту но и увеличивает длинну волны.
Я конечно понимаю что тут манипуляция а не модуляция, так как физ линия, но все же.
Ну и проблемы то у нас другого характера, ошибки на CAN есть но они очень эпизодические. Явно если бы линиям было недостаточно согласования она бы часами не стояла нормально.
Вот новый сбой но ресетнулось нормально
0100:01:31:3002NO ErrorFlags0304TX Errors = 005RX Errors = 00607NODES CAN COMMUNICATION:08node_5_Net_center_Due2 OK09node_6_Hallway_net_center OK10node_7_Hallway_main OK11node_8_Hallway_light OK12node_9_Kitchen_net_center OK13node_10_Kitchen_main OK14node_11_Kitchen_light OK15node_12_WC_main OK16node_13_WC_waterleak OK17node_14_Bathroom_main OK18node_15_Boxroom_main OK19node_18_Loggia_recuperator OK20node_19_Livingroom_main OK21node_20_Bedroom_main OK22node_21_Cabinet_main OK23Default msg_id !=0 && >1224-------CAN MESSAGE RX ADRRESSED TO ME-------25ID 8E0D040026type_msg - Неизвестное сообщение27node_addr - node_13_WC_waterleak28Rem_addr - node_4_Net_center_Due129Dev_type - NULL DEVICE30DATA FRAME 61 80 00 00 00 00 00 0031--------------------------------------------3233RX or TX errors >= 9634RX errors >= 9635TX errors >= 9636RX errors >= 128. Mode ErrorPassiveisON37TX errors >= 128. Mode ErrorPassiveisON38TX errors == 255. Mode BusOffisON39Переполнен буфер приёма RX040Переполнен буфер приёма RX1414243TX Errors = 25544RX Errors = 255454647MCP2515 Initialized Successfully! after REINIT4849Мой адрес в сети CAN: node_4_Net_center_Due1 MASTER!5051NO ErrorFlags5253TX Errors = 054RX Errors = 2555556Init!5758RX or TX errors >= 9659RX errors >= 9660TX errors >= 9661RX errors >= 128. Mode ErrorPassiveisON62TX errors >= 128. Mode ErrorPassiveisON63TX errors == 255. Mode BusOffisON64Переполнен буфер приёма RX065Переполнен буфер приёма RX1666768TX Errors = 25569RX Errors = 25570717200:01:32:0073NO ErrorFlags7475TX Errors = 076RX Errors = 07778NODES CAN COMMUNICATION:79node_5_Net_center_Due2 OK80node_6_Hallway_net_center OK81node_7_Hallway_main OK82node_8_Hallway_light OK83node_9_Kitchen_net_center OK84node_10_Kitchen_main OK85node_11_Kitchen_light OK86node_12_WC_main OK87node_13_WC_waterleak OK88node_14_Bathroom_main OK89node_15_Boxroom_main OK90node_18_Loggia_recuperator OK91node_19_Livingroom_main OK92node_20_Bedroom_main OK93node_21_Cabinet_main OKПричем заметь опять ID 8E0D0400
Это не глюк это системная ошибка, причем приглядись к датафрейму 61 80 00 00 00 00 00 00.
говорю отключай этот 13 узел, он несчастливый)
А вообще регистры неадекватно показывает. То все биты сразу 1. То все 0. Ошибки то 255, то 0 - бред. Хотя проверял на регистре режима работы (нормал, лупбэк, листен онли, слип) - нормально показывает, значит правильно запрашиваю. и раз ID начинается с 8 значит direction равно 0. А я везде сделал его 1. То бишь бабайка этот фрейм отправил. Домовёнок у тебя к кану подключился. 21 век как никак.
И самое главное как оно просочилось через фильтр? О_О
Фильтр стоит что direction только с 1 должен проходить. можешь проверить на простом скетче. Это не поддается объяснению.
Вот уже 3 часа работает с 2мя сбоями и самовосстановлением.
Просбочка есть встрой код часов, стобы выдавалось не только милс время но и от часов. Или я свой набросаю, встрой потом в скетч.
У меня трое часов загашнике нашлось
DS1302
DS1307
DS3231
Если у тебя нет каких то из них я тогда свой код под DS3231 напишу.
А вообще регистры неадекватно показывает. То все биты сразу 1. То все 0. Ошибки то 255, то 0 - бред. Хотя проверял на регистре режима работы (нормал, лупбэк, листен онли, слип) - нормально показывает, значит правильно запрашиваю. и раз ID начинается с 8 значит direction равно 0. А я везде сделал его 1. То бишь бабайка этот фрейм отправил. Домовёнок у тебя к кану подключился. 21 век как никак.
Это из твоего кода ф-я RX case REQUEST_SEND
1TX(0,REQUEST_ANSWER, dev_addr, dev_TYPE, EXTENDED, DATA_CANFRAME, DlC, DataP);Первый 0 это dir 0
Ну и вообще может уйти от 11bit ID и произвольных DLC
Везде 29 и 8?
dlc 8 не везде. В REQUEST_SEND я вообщето direction исправил в 11 версии ещё вроде как . Ты хоть мои скетчи то заливаешь или гибриды опять делаешь? А то наворотим щас тут. Я буду думать что исправил, а у тебя в итоге не исправлено. А потом думай, почему не работает. Часы 3231 есть. код выложу
короче если опять шина закозлит заливай опять упрощённый скетч - я его немного поправил. Он на коротких ID. мастер шлёт статус ID 666. Узлы отвечают 0XX, где ХХ - адрес узла. Посмотрим как себя поведёт. Заметь скорость поставил 125 кбит. 500 больше не ставь нигде, нафиг такая большая не нужна. Тем более расстояния довольно большие. 125 в самый раз.
001#include <mcp_can.h>002#include <SPI.h>003004// Выбираем аппаратную часть узла005006#define ARD_UNO007//#define ARD_MEGA008//#define ARD_DUE009010011#ifdef ARD_UNO012#define can CAN0013MCP_CAN can(10);014#endif015#ifdef ARD_MEGA016#define can CAN0017MCP_CAN can(53);018#endif019#ifdef ARD_DUE020#define can CAN3021MCP_CAN can(52);022#endif023024typedefenumNode_addr_enum025{026broadcast,//0027node_1_Net_center_PC,//1028node_2_Net_center_oraPi1,//2029node_3_Net_center_oraPi2,//3030node_4_Net_center_Due1,//4031node_5_Net_center_Due2,//5032node_6_Hallway_net_center,//6033node_7_Hallway_main,//7034node_8_Hallway_light,//8035node_9_Kitchen_net_center,//9036node_10_Kitchen_main,//10037node_11_Kitchen_light,//11038node_12_WC_main,//12039node_13_WC_waterleak,//13040node_14_Bathroom_main,//14041node_15_Boxroom_main,//15042node_16_Balcony_meteo,//16043node_17_Loggia_main,//17044node_18_Loggia_recuperator,//18045node_19_Livingroom_main,//19046node_20_Bedroom_main,//20047node_21_Cabinet_main,//21048SIZE_Node_addr_ENUM//22 size049}Node_addr_enum;050051constbyteNODS_NUMBER = SIZE_Node_addr_ENUM;052053054055// Назначаем адрес данного узла056057//const byte node_address = node_1_Net_center_PC; //1058//const byte node_address = node_2_Net_center_oraPi1; //2059//const byte node_address = node_3_Net_center_oraPi2; //3060//const byte node_address = node_4_Net_center_Due1; //4061//const byte node_address = node_5_Net_center_Due2; //5062//const byte node_address = node_6_Hallway_net_center; //6063constbytenode_address = node_7_Hallway_main;//7064//const byte node_address = node_8_Hallway_light; //8065//const byte node_address = node_9_Kitchen_net_center //9066//const byte node_address = node_10_Kitchen_main; //10067//const byte node_address = node_11_Kitchen_light; //11068//const byte node_address = node_12_WC_main; //12069//const byte node_address = node_13_WC_waterleak; //13070//const byte node_address = node_14_Bathroom_main; //14071//const byte node_address = node_15_Boxroom_main; //15072//const byte node_address = node_16_Balcony_meteo; //16073//const byte node_address = node_17_Loggia_main; //17074//const byte node_address = node_18_Loggia_recuperator; //18075//const byte node_address = node_19_Livingroom_main; //19076//const byte node_address = node_20_Bedroom_main; //20077//const byte node_address = node_21_Cabinet_main; //21078079080081// Выбираем узлы подключенные к CAN шине082083constboolNodeCANpresence[22] =084{0850,// broadcast, //00860,// node_1_Net_center_PC, //10870,// node_2_Net_center_oraPi1, //20880,// node_3_Net_center_oraPi2, //30891,// node_4_Net_center_Due1, //40900,// node_5_Net_center_Due2, //50910,// node_6_Hallway_net_center, //60921,// node_7_Hallway_main, //70931,// node_8_Hallway_light, //80940,// node_9_Kitchen_net_center, //90951,// node_10_Kitchen_main, //100960,// node_11_Kitchen_light, //110970,// node_12_WC_main, //120980,// node_13_WC_waterleak, //130990,// node_14_Bathroom_main, //141000,// node_15_Boxroom_main, //151010,// node_16_Balcony_meteo, //161020,// node_17_Loggia_main, //171030,// node_18_Loggia_recuperator, //181040,// node_19_Livingroom_main, //191050,// node_20_Bedroom_main, //201060,// node_21_Cabinet_main, //21107};108109110// Выбираем смысловую нагрузку узла111112113//#define type_node_master114//#define type_node_slave115#define type_node_mk116117118119longunsignedintrxId;120unsignedcharlen = 0;121unsignedcharrxBuf[8];122123124#define CAN0_INT 2 // Set INT to pin 2125126byteStatusMK[22] = {0};127128129unsignedlongprevtimeStatus = 0;130boolTimerStatus = 0;131unsignedlongprevPrintStatus = 0;132133voidsetup()134{135Serial.begin(115200);136137138if(can.begin(MCP_STDEXT, CAN_125KBPS, MCP_8MHZ) == CAN_OK)139Serial.println("MCP2515 Initialized Successfully!");140else141Serial.println("Error Initializing MCP2515...");142#ifdef type_node_master143can.init_Mask(0,0,0x07000000);//маска на самый левый разряд ID - для мастера144can.init_Filt(0,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера145#else146can.init_Mask(0,0,0x07FF0000);// маска на весь ID - для узла147can.init_Filt(0,0,0x06660000);// только ID 666 проходят - для узла148#endif149can.setMode(MCP_NORMAL);150151pinMode(CAN0_INT, INPUT);152153Serial.println("MCP2515 Library Receive Example...");154}155156voidloop()157{158if(!digitalRead(CAN0_INT))159{160can.readMsgBuf(&rxId, &len, rxBuf);161#if defined (type_node_slave) or defined (type_node_mk)162if(rxId == 0x666) {prevtimeStatus = millis(); TimerStatus = 1;Serial.println(F("Receive StatusMaster"));}163#endif164165#ifdef type_node_master166if(rxId >0 && rxId<22) StatusMK[rxId] = 0;167168#endif169}170171#if defined (type_node_slave) or defined (type_node_mk)172if(TimerStatus && millis() - prevtimeStatus > node_address*50) {173bytedata[8]= {255,255,255,255,255,255,255,255};174bytesndStat = can.sendMsgBuf(node_address, 0, 8, data);175if(sndStat == CAN_OK){Serial.println(F("Send my Status successfully!"));}176else{Serial.println(F("Error Send my Status!!! "));}177TimerStatus = 0;}178#endif179180181182183184185#ifdef type_node_master186if(millis() -prevtimeStatus > 2000) {187for(inti = 0; i<22; i++) StatusMK[i]++;188189bytedata[8]= {0,0,0,0,0,0,0,0};190can.sendMsgBuf(0x666, 0, 8, data);191prevtimeStatus = millis();}192193194195if(millis() - prevPrintStatus > 15000) {196197Serial.println();Serial.println(F("NODE STATUS"));198for(inti = 1; i<22; i++) {if(i!=4 && NodeCANpresence[i]) {Serial.print (i);if(StatusMK[i]<=4)Serial.println (F(" OK"));elseSerial.println (F(" FAIL")); }}199Serial.println();200prevPrintStatus = millis();201}202203#endif204}dlc 8 не везде. В REQUEST_SEND я вообщето direction исправил в 11 версии ещё вроде как . Ты хоть мои скетчи то заливаешь или гибриды опять делаешь? А то наворотим щас тут. Я буду думать что исправил, а у тебя в итоге не исправлено. А потом думай, почему не работает. Часы 3231 есть. код выложу
Заливаю твои, но подкручиваю дебаг, сам видишь как выводит, меня это отправлено в CAN достает в логе.
Вроде залита 11 с измененной ф-й вывода ошибок из 12. Я специально спросил, ты только ее изменил.
Я кстати про это и говорил что
1. Вставляй в основной файл что то вроде //ver 12
2. По времени подготовить код и залить его во все контроллеры это 2-3 часа. Поэтому без серьезных изменения я только в DUE меняю код. И кстати МК не вснут
короче если опять шина закозлит заливай опять упрощённый скетч - я его немного поправил. Он на коротких ID. мастер шлёт статус ID 666. Узлы отвечают 0XX, где ХХ - адрес узла. Посмотрим как себя поведёт. Заметь скорость поставил 125 кбит. 500 больше не ставь нигде, нафиг такая большая не нужна. Тем более расстояния довольно большие. 125 в самый раз.
Ок завтра поставлю. Пусть 12 простоит ночь. Уже 4 часа без малого стоит.
код часов. Не проверял, нету под рукой DS3231. библиотека
01#include <RTC.h>02#include <Wire.h>0304RTC time;05bytess;//секунда06bytemm;//минута07bytehh;//час08bytedd;//день месяца09bytewd;//день недели10bytemn;//месяц1112voidsetup() {13time.begin(RTC_DS3231);// RST, CLK, DAT инициализация модуля часов14}1516voidloop() {17DS_3231 ();1819}2021voidDS_3231 () {22time.gettime();23ss = time.seconds;24mm = time.minutes;25hh = time.Hours;26dd = time.day;27wd = time.weekday;28mn = time.month;29}в либе смотри пример, как часы настроить и вообще почитай коменты
Опять сбойнуло https://yadi.sk/d/ozOcbX7B3V5hYy
log_18.05.18-2.txt
Опять сбойнуло https://yadi.sk/d/ozOcbX7B3V5hYy
log_18.05.18-2.txt
Да и смотри какое кино реконект по com порту ресетит MCP нормально.
Заливаю твои, но подкручиваю дебаг, сам видишь как выводит, меня это отправлено в CAN достает в логе.
Я же тебе говорил как дебаг настроить
нужно наверное убрать в 5 местах обращения к регистрам - коряво всё это работает почему то
ладно, просто в шапке показывается же название файла. Но ок, мне не сложно это добавлять.
но вот это конечно не гуд, из-за этого и могут быть проблемы. Где то скетч старый остался, а мы тут гадаем, че за шляпа творится. И убери пока DUE - глючная она. Потом вернёшь когда всё наладится.
Я же тебе говорил как дебаг настроить
ладно, просто в шапке показывается же название файла. Но ок, мне не сложно это добавлять.
но вот это конечно не гуд, из-за этого и могут быть проблемы. Где то скетч старый остался, а мы тут гадаем, че за шляпа творится. И убери пока DUE - глючная она. Потом вернёшь когда всё наладится.
Посмотри файл лога, как на DUE добиться такого вывода настройками?
Я беру твой пакет, создаю под каждый папку с именем узла, переименовываю основной файл, открываю, настраиваю. На выходе если нет указателя что за версия то хрен поймешь что стоит. Так что лучше даже в лог пусть выводит вместе с именем узла.
Ну я условно сказал. Везде стоит 11 версия, так как лог я снимаю только с DUE то протсо вставил ф-ю снятия ошибок из регистров.
DUE завтра поменяю. Но я думаю не в DUE дело. Каждая плата свои либы имеет и может конфликтовать.
ну вот что это в отладке ?
1Default msg_id !=0 && >122----------CAN BROADCAST MESSAGE RX----------3ID 204type_msg - NULL_C5node_addr - ШИРОКОВЕЩАТЕЛЬНО6Rem_addr - ШИРОКОВЕЩАТЕЛЬНО7Dev_type - Неизвестное устройство8DATA FRAME9--------------------------------------------какое то Default msg_id !=0 && >12 вспыло. зачем ты ID_Print в труе ставишь. Нафиг эти рамки - по ID уже и так на глаз всё определяем, примелькаклось уже.
У меня кстати при удачной перинициализации вообще не так в отадке всё было . см видос. Че то у тебя не так как у меня в скетче, похоже.
ну вот что это в отладке ?
1Default msg_id !=0 && >122----------CAN BROADCAST MESSAGE RX----------3ID 204type_msg - NULL_C5node_addr - ШИРОКОВЕЩАТЕЛЬНО6Rem_addr - ШИРОКОВЕЩАТЕЛЬНО7Dev_type - Неизвестное устройство8DATA FRAME9--------------------------------------------какое то Default msg_id !=0 && >12 вспыло. зачем ты ID_Print в труе ставишь. Нафиг эти рамки - по ID уже и так на глаз всё определяем, примелькаклось уже.
У меня кстати при удачной перинициализации вообще не так в отадке всё было . см видос. Че то у тебя не так как у меня в скетче, похоже.
1#define debug //отладка в сериал_монитор. Закоментировать строку после отладки23#ifdef debug4#define debugStatus //отладка в сериал_монитор - таблица статусов узлов CAN сети (для МАСТЕРА) Закоментировать строку после отладки5boolID_Print = 0 ;//флаг распечатки CAN FRAMES в монитор. 0 - будут, только адресованные на данный узел. 1 - все CANFRAMES6boolstatusprint = 0 ;//флаг распечатки статусов в монитор.Эээ я как бы твой код из другого места (чуть выше) взял и ткнул в нужное мне место ( RX default)
У меня отладка Ночью идет и места на твой развернутый как в видео дебаг в консоле нет, она начнет затираться.
Я вывожу раз в 60 сек сост узлов и при аварии состояние авариии. Смотреть чем обмениваются в другое время узлы нет смысла.
я не знаю в чём у тебя там проблема, но на узле аж на 4 часа хватает такой записи в мониторе порта. Этого хватит, чтобы косяки засечь. Не говоря уже про мастер, где данные два раза в минуту пишутся. Там весь лог записался от начала до конца. Вот 5-часовой тест мастера и одного узла №10. Глюки отсутсвуют полностью. В конце, для прикола, сделал с монитора порта переинициализацию MCP2515. Если бы были косяки, по такой отладке у узла можно определить что и когда он отсылал и получил. Время у него посмотреть, не простаивало ли. Сравнить что в это время на мастере творилось.
я не знаю в чём у тебя там проблема, но на узле аж на 4 часа хватает такой записи в мониторе порта. Этого хватит, чтобы косяки засечь. Не говоря уже про мастер, где данные два раза в минуту пишутся. Там весь лог записался от начала до конца. Вот 5-часовой тест мастера и одного узла №10. Глюки отсутсвуют полностью. В конце, для прикола, сделал с монитора порта переинициализацию MCP2515. Если бы были косяки, по такой отладке у узла можно определить что и когда он отсылал и получил. Время у него посмотреть, не простаивало ли. Сравнить что в это время на мастере творилось.
Поставил 12 версию на мастер без
1// SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));2// digitalWrite(csPIN, LOW);3// SPI.transfer(0xC0);4// digitalWrite(csPIN, HIGH);5// SPI.endTransaction();6// delay (100);+
1#define debug //отладка в сериал_монитор. Закоментировать строку после отладки23#ifdef debug4#define debugStatus //отладка в сериал_монитор - таблица статусов узлов CAN сети (для МАСТЕРА) Закоментировать строку после отладки5boolID_Print = 0 ;//флаг распечатки CAN FRAMES в монитор. 0 - будут, только адресованные на данный узел. 1 - все CANFRAMES6boolstatusprint = 0 ;//флаг распечатки статусов в монитор.Так нужно?
Инициализация у меня тоже работает.
Но вот когда глюк серьезный то сеть летит. Лог сам видел.
Так 12 версия не работает.
Постиавил 11 с теми же настройками и скопировал тольуо ф-ю с ошибками MCP
что в 12 не работает?