Очередной "Умный дом", на этот раз модульная система...

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Эту шляпу long array_request_status[NODS_NUMBER][6]; я переделаю. Помнишь вначале вообще Float испоьзовался. Главное чтобы заработало, потом отладка и оптимизация.

В любом случае мне кажется у нас на выходе не плохо получается, взаимная критика дает плоды и код живет.

я думаю не нужен тебе этот массив вовсе. У меня же стабильно вроде работает, проверь. Не нужно занового делать, то что уже сделано. 
riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

посмотри, там полюбому все по указателям или ссылкам передается между функциями. А классами и структурами я не умею пока оперировать. Учиться надо. 

Нужно проще всё делать, по возможности. Вот ты запрашиваешь статус каждого узла. потом они отвечают. А посмотри как я сделал. Один статус мастера и все отвечают. Так сказать статус за статус. И кода мимимум. причем периодическую отправку статуса мастером запихал в таймер периодической проверки "а на связили узлы" (StatusControl()). 

Гениально!

Я совершенно серьезно, вот что значит на проблему с другой стороны не в лоб решать.

У тебя опыт как раз с МК а я всегда с тяжелой сетевухой общался, там на экономии ресурса так не заморачивались. За 20 лет от 10 Мб до 10Гб сети потолстели.

Я все пытаюсь с перезапросами с подтверждениями решать, а тут полоса ограничена да и наш ресурс не безграничен.

Я только сейчас увидель что ты StatusControl () переделал. С этой лежащей на поверхности но незамеченой никем логикой, статус за статус. (Надо только названия тогда в типах сообщений поменять а то ОТВЕТ СТАТУСА, как бы предполагает что был запрос.)

riv
Offline
Зарегистрирован: 20.07.2017

Кстати я об этом и говорю, я просто твой код проанализировать не успеваю.

Сегодня попробую причесать, убрать все косячные функции и выстроить структуру.

MaksVV
Offline
Зарегистрирован: 06.08.2015

ну вот вроде закончил обработку основных типов сообщений. Скетч. Нужно тестировать все функции. Что добавлено:

- как у тебя директивы условной компиляции на мегу, due и т.д.;
- разделение массива типа устройств dev_type на два. Массив - параметров и массив исполнительных механизмов;
- соответсвенно пришлось править и debug.h (взято из твого правленного);
- настройка массива параметров. настройка во вкладке can_struct.h наличия конкретных параметров на узле, а также задача типа данных этого параметра;
- периодическая отправка мастеру всех параметров, присутствующих на узле, со смещённым во времени таймером для разных адресов МК;
- отправка мастеру конкретного параметра, присутствующего на узле, по факту  изменения  значения параметра ;
- отправка параметров запрашивающему узлу конкретных параметров, указанных в запросе;
- по факту отправки параметра, в поле данных присутствует байт отчета, по какому случаю отправляем параметр;
- выполнение различных команд . Например, почти все команды действуют непосредсвенно
на порты ардуино, т.е. тип устройства в данном случае - адрес в массиве исп. механизмов. Но это всё кроме команды PARAMETER_WRITE. Данная команда воздействует уже не на массив исп. механизмов, а на массив параметров и изменяет на нужное значение любого параметра. Т.е. при этой команде последний разряд ID заголовка dev_type это адрес в массиве parameter[][]. Таким образом, мы можем изменять переменные на любом узле;
- Также сделано при отправке соответствующей команды - мы воздействуем на устройства, управление которыми осуществляется импульсом. (правда эта часть скетча не проверена) . Т.е. реализовано управление почти всеми видами подключения устройств. 
 
PS. настройка массива device[][] также осталась, также остались смещенные во времени отсылки статусов узлами  после получения ими периодического широковещательного статуса от мастера. 
 
Следующий этап - можно на мастере сделать массив parameter[PARAMETER][dev-type][dev_addr]. 
т.е. всё тоже самое в массиве, только третье измерение показывает от какого узла массив. В этот массив будем писать данные, которые подчинёные шлют периодически или по факту изменения параметра. 
Потом уже чё хошь с этими данными делай, хоть на сервер, хоть ещё куда. Главное чтоб у DUE оперативы хватало, а то компилятор только заполнение флеш памяти пишет. 
riv
Offline
Зарегистрирован: 20.07.2017

Для MaksVV

Приветствую. 

Отлаживаю сеть. Вроде все заработало. Но есть проблема.

CanHacker не отображает информацию из шины, отправляет но не показывает программе.

Менял версии CanHacker, менял ардуино (nano, uno, mega, due), менял MCP2515. Менял положение терминаторов и настройки. Ничего не помогает.

Help!

MaksVV
Offline
Зарегистрирован: 06.08.2015

Подцепи кан хакер на сеть из двух устройств. Посмотри заработает ли. У меня чето подобное было помоему. Смотри там в программе канхакер еще тоже есть настройки фильтра сообщений, может нечаяно фильтр какой нибудь установился, хотя маловероятно если ты прогу переставлял. Еще попробуй заново скачать библиотеки и скетч, канхакера , которые я давал, лучше на отдельном компе.

MaksVV
Offline
Зарегистрирован: 06.08.2015

что именно не показывает? сообщения, которые ты с канхакера отправляешь (TX), не будут показываться в окне RX канхакера.  

MaksVV
Offline
Зарегистрирован: 06.08.2015

Короче я опять немного переделал концепцию хранения и обмена массива параметров. В общем раньше в массиве лежали ВСЕ возможные параметры, которые мы придумали (задефайнили). А ведь на отдельных узлах естественно используются не все из этих параметров. Поэтому большинство ячеек занимали в массиве место просто так. 

Раньше адресом параметра являлось второе измерение массива. Теперь я сделал по-другому: 

Теперь в массиве лежат только те параметры, которые мы ходим использовать на данном конретном узле. Т.е. во втором измерении массива уже не адрес параметра, а как бы просто порядковый номер. А адрес лежит в одной из ячеек первого измерения массива. Короче скетч простроен так , что он сам находит по адресу конкретного параметра порядковый номер в массиве. Собственно это детали, глобально параметры также используются как и раньше. 

Скетч 

При отправлке параметра поле данных имеет вид по байтам:

0                 1                       2                             3                     4           5          6          7 

счетчик    не исп.   причина отправки              тип данных       далее байты самого параметра 

Также ячейки массива параметров отправляются либо периодически  и по изменению какого нибудь параметра на адрес который мы можем настроить. Т.е. мы можем задать у каждого параметра  - куда он будет отсылаться периодически и по изменению. 

Поле данных запроса параметров от другого узла будет выгляеть так: каждый байт поля данных этого запроса, это адрес параметра который мы запрашиваем, т.е. за один запрос мы можем запросить 7 параметров (0 байт это счетчик). при этом получим 7 ответных сообщений с параметрами. Запрос может слать любой узел, ему и придёт ответ. 

 

 

 

riv
Offline
Зарегистрирован: 20.07.2017

CanHacker не видит ничего, в окне сверху. Если пытаюсь что то отправлять то на узлах принимаю.

MaksVV
Offline
Зарегистрирован: 06.08.2015

блин даже не знаю, сеть из двух устройств то попробовал? тоже не работает? Терминатор на самом канкахере пробовал добавлять убирать? 

MaksVV
Offline
Зарегистрирован: 06.08.2015

вместо кан хакера залей в это устройство скетч из примеров: Rx. Будет ли принимать CAN сообщения ?

riv
Offline
Зарегистрирован: 20.07.2017

Я пока аппаратную часть доделал, раскидал контроллеры по помещениям, на com порты подпаял ESP07, в итоге есть CAN сеть и проброс RS232 от компа до ардуино через ESP (напрямую не прошивает из IDE, приходится делать heх и заливать скриптом). 

Отладка показала что MCP2515 бывают битые или глючные, вроде инициализируются но не работают, кстати то же и про ESP07. 

Т.о. на первом этапе самое главное добиться проверки аппаратной части и правильной расстановки терминаторов. После чего ставим на сутки просто на опрос сотстояния. И тоько потом нормальный скетч заливать.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

вместо кан хакера залей в это устройство скетч из примеров: Rx. Будет ли принимать CAN сообщения ?

В том то и дело что замена скетча приводит к нормальному приему (в консоли), меняю скетч на CanHacker подключаюсь и пустота. Обыдна да. И нечего не помогает.

riv
Offline
Зарегистрирован: 20.07.2017

Да кстати на ESP07 поднял MQTT клиентов и отправляю на сервер подписки, + на сервере поставил CACTI и собираю в него статистику доступности ESP07 и ETH в сети.

MaksVV
Offline
Зарегистрирован: 06.08.2015

эти mcp2515 похоже не то что глючные , мы просто не умеем их готовить. Они как то блокируются чтоли иногда. У меня такое уже несколько раз было.  Оживлял вроде этим скетчем: 

Его сначала залить, поюзать, потом, не убирая питания с mcp2515, уже свой скетч заливаешь. 

тут чёто с масками-фильтрами беда похоже. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

у меня в пользлвании ещё вот такой адаптер для канхакер. Он на STM  - глючить не должен вообще, т.к. разработан вообще для автомобилей, где трафик в CAN шине  серьезный. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

у меня в пользлвании ещё вот такой адаптер для канхакер. Он на STM  - глючить не должен вообще, т.к. разработан вообще для автомобилей, где трафик в CAN шине  серьезный. 

В общем думаю нужно его и купить иначе отладка сети мучение. 

Его только в Новосибе можно взять или есть еще места? Я из СПб.

MaksVV
Offline
Зарегистрирован: 06.08.2015

я так понял, что если мы в программе кан хакер установили (даже нечаяно) какой-нибудь фильтр и маску, это всё передается  в mcp 2515, причём в энергонезависимую память. И чтобы потом это убрать, нужно загрузить такие маски 0x00000000 (их две там), при которых будет приём ВСЕХ сообщений. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

только там, там паренёк Артём занимается, не сильно у него всё раскручено, но очень граммотный чел. почитай его сайт, много полезной инфы. Пересыл махом делает, 300 руб. вроде

MaksVV
Offline
Зарегистрирован: 06.08.2015

есть на али ещё такой прибор. Классная вещь тоже безотказно у меня работает. Основная задача коррекция одометра на фордах. Но имеет функцию кан анализатора, причём двух канального. Также можно писать ключи и ЭБУ ДВС на форды платформы фокус 2. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

проверил работу с устройствами, управляемыми импульсом. Естественно с первого раза не работало ничё. Сейчас всё исправил

Тема такая. Когда в can_struct.h назначаем вид устройства - импульсное, то у нас сразу быбирается полярность импульса, пин на ардуино, на котором будет импульс, а также я ещё сделал сразу назначение пина, который будет входом состояния устройства (вход мониторит выключено в данный момент устройство или включено). 

Т.е. если послать команду на включение устройства (а вход смониторил, что оно УЖЕ включено), соответственно импульса не будет. 

Также одновременно можно управлять 5 импульсными устройствами. (имеется ввиду ,что допускается наложение друг на друга во времени импульсов от  5 разных устройств)

А вот если импульс ещё не кончился , а мы опять пытаемся послать импульс на ТОЖЕ устройство, это будет просто игнорироваться. 

Также проверил работу с видом подключения устройсв - PWM. Вроде бы всё работает.

riv
Offline
Зарегистрирован: 20.07.2017

Привет. Ты структуру ID  и поля данных опять изменил.  Можешь расписать структуру в виде

ID X.Y.Z....

Data A.B.C..... 

Чтобы не занимться реверсинжинирингом.

riv
Offline
Зарегистрирован: 20.07.2017

Да и еще мне пришлось изменить немногог структуру с адресами, когда большая сеть нужно и номер и имя знать. Я по номеру и имя нода Wi-Fi ставлю и его IP.  Добавил номер нода.

node_8_Hallway_light имее арес 192.168.2.108 а

node_15_Boxroom_main 192.168.2.115

В общем при настройке сети лучше иметь и имя и цифру номер узла чтобы справочники не смотреть.

01// Задаем перечисления для адресов узла
02typedef enum Node_addr_enum
03{
04    NULL_A,                        //0
05    node_1_Net_center_PC,                 //1
06    node_2_Net_center_oraPi1,             //2
07    node_3_Net_center_oraPi2,             //3
08    node_4_Net_center_Due1,               //4
09    node_5_Net_center_Due2,               //5
10    node_6_Hallway_net_center,            //6
11    node_7_Hallway_main,                  //7
12    node_8_Hallway_light,                 //8
13    node_9_Kitchen_net_center,            //9
14    node_10_Kitchen_main,                  //10
15    node_11_Kitchen_light,                 //11
16    node_12_WC_main,                       //12
17    node_13_WC_waterleak,                  //13
18    node_14_Bathroom_main,                 //14
19    node_15_Boxroom_main,                  //15
20    node_16_Balcony_meteo,                 //16                         
21    node_17_Loggia_main,                   //17                            
22    node_18_Loggia_recuoerator,            //18                            
23    node_19_Livingroom_main,               //19                            
24    node_20_Bedroom_main,                  //20                            
25    node_21_Cabinet_main,                  //21                            
26    node_22_Cabinet_main4,                  //22                            
27    SIZE_Node_addr_ENUM            //23 size   
28}Node_addr_enum;

 

MaksVV
Offline
Зарегистрирован: 06.08.2015
riv пишет:
  Привет. Ты структуру ID  и поля данных опять изменил.  Можешь расписать структуру в виде
ID X.Y.Z....
Data A.B.C Чтобы не занимться реверсинжинирингом.
 
всмысле опять? Как же её не переделывать, если мысли по ходу пьесы приходят. Например, 
- если говорить про параметры (фреймы REQUEST_ANSWER) ,  я не знал, что помимо самого параметра, придётся в теле сообщения (читай в поле данных) также передавать какой тип данных у этого параметра;
 
- если говорить про команды, то не представлял, что для разных команд будет разное тело сообщения. Пример. Возмём тип сообщения  - команды (фреймы COMMAND_SEND вид команды  DIMMER_TURN_ON и PARAMETER_WRITE). У DIMMER_TURN_ON  - 3 байт поля данных это тип команды, остальные байты поля данных как бы не важны. а у PARAMETER_WRITE  - 3 байт поля данных это тоже тип команды, но также в 4-ый байт несёт информацию о новом значении параметра, которым мы пытаемся управлять. 
 
и так можно долго перечислять. Да согласен, конечно, что нужно таблицу чтоли какую-нибудь разрисовать , где разбайтовка тел различных типов  сообщений приводится. 
 
В любом случае в поле данных:
 
А -  байт  глобальный счётчик, 
 
B- неисп.
 
C- байт  информация о смысловой нагрузке отчёта (для типов сообщений: ответов)
 

riv пишет:
Да и еще мне пришлось изменить немногог структуру с адресами, когда большая сеть нужно и номер и имя знать. Я по номеру и имя нода Wi-Fi ставлю и его IP.  Добавил номер нода.

node_8_Hallway_light имее арес 192.168.2.108 а

node_15_Boxroom_main 192.168.2.115

В общем при настройке сети лучше иметь и имя и цифру номер узла чтобы справочники не смотреть.

С этим согласен, переделаю

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Привет. Ты структуру ID  и поля данных опять изменил.  Можешь расписать структуру в виде

ID X.Y.Z....

Data A.B.C..... 

Чтобы не занимться реверсинжинирингом.

 
всмысле опять? Как же её не переделывать, если мысли по ходу пьесы приходят. Например, 
- если говорить про параметры (фреймы REQUEST_ANSWER) ,  я не знал, что помимо самого параметра, придётся в теле сообщения (читай в поле данных) также передавать какой тип данных у этого параметра;
 
- если говорить про команды, то не представлял, что для разных команд будет разное тело сообщения. Пример. Возмём тип сообщения  - команды (фреймы COMMAND_SEND вид команды  DIMMER_TURN_ON и PARAMETER_WRITE). У DIMMER_TURN_ON  - 3 байт поля данных это тип команды, остальные байты поля данных как бы не важны. а у PARAMETER_WRITE  - 3 байт поля данных это тоже тип команды, но также в 4-ый байт несёт информацию о новом значении параметра, которым мы пытаемся управлять. 
 
и так можно долго перечислять. Да согласен, конечно, что нужно таблицу чтоли какую-нибудь разрисовать , где разбайтовка тел различных типов  сообщений приводится. 
 
В любом случае в поле данных:
 
А -  байт  глобальный счётчик, 
 
B- неисп.
 
C- байт  информация о смысловой нагрузке отчёта (для типов сообщений: ответов)
 

riv пишет:
Да и еще мне пришлось изменить немногог структуру с адресами, когда большая сеть нужно и номер и имя знать. Я по номеру и имя нода Wi-Fi ставлю и его IP.  Добавил номер нода.

node_8_Hallway_light имее арес 192.168.2.108 а

node_15_Boxroom_main 192.168.2.115

В общем при настройке сети лучше иметь и имя и цифру номер узла чтобы справочники не смотреть.

С этим согласен, переделаю

riv
Offline
Зарегистрирован: 20.07.2017

Еще вопрос, ты используешь #include <avr/pgmspace.h>

PrintTypeDEV (byte Str_nomer) при выдаче параметра 1  ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ

сыпет абракадабру,  причем остальные без проблем.

Поменял 

1void PrintTypeDEV (byte Str_nomer) {
2strcpy_P(buf, (char*)pgm_read_word(&(string_tableDEV[Str_nomer])));
3Serial.print (buf);}

на

1void PrintTypeDEV (byte Str_nomer) {
2Serial.print (string_tableDEV[Str_nomer]);}

Все заработало, зачем

1strcpy_P(buf, (char*)pgm_read_word(&(string_tableDEV[Str_nomer])));
riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

всмысле опять? Как же её не переделывать, если мысли по ходу пьесы приходят.

Я же без претензий, просто если меняешь структуру меняй плиз и описание. А то всю башку сломал.  У меня же мой код на твой завязан. Ты поменяешь что либо, структуры снесешь переменные уберешь, и сразу все поехало.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Все заработало, зачем

1strcpy_P(buf, (char*)pgm_read_word(&(string_tableDEV[Str_nomer])));

я так понимаю, если не использовать эту строку, то теряется смысл использования PROGMEM. Хотя я в этом сильно не разбирался. Может ты и прав. Я просто нашёл пример использования PROGMEM и тупо закопипастил.  Посмотри, может у тебя буфер ещё маленький стоит. Я до 100 байт увеличил, глюки ушли. Т.к. русский текст мы стали использовать, а он по два байта на символ вроде ест. у меня так:

1#include <avr/pgmspace.h>
2 
3#define  BUF_LENGTH 100
4char buf[BUF_LENGTH]; // буффер для работы прогмем, если нужны строки более 100 символов, тут ставим бОльшее значение

Сейчас проверил у себя, ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ норм у меня показывает. 

 

PS и это не параметр, а девайс, ну или устройство. Можно ещё исполнительный механизм называть. Я решил их чётко разграничивать.  Ну так, лучше правильно говорить,  чтоб не путаться. А то уже столько терминов у нас тут фигурирует и все похожи, блин: Вид устройства, тип устройства и т.д.)))

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

PrintTypeDEV (byte Str_nomer) при выдаче параметра 1  ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ сыпет абракадабру,  причем остальные без проблем.

Поменял ... на

1void PrintTypeDEV (byte Str_nomer) {
2Serial.print (string_tableDEV[Str_nomer]);}

Все заработало, зачем

Проверил, у меня НЕ работает так, как ты предлагаешь. Вот что в мониторе

1ринято  из  CAN:  КОМАНДА  " БУЛЕВОЕ ВКЛ " На тип устройства:   (./456789:;     Глобальный счетчик:  1  От Кого:  Net_center_Due1

 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:

PrintTypeDEV (byte Str_nomer) при выдаче параметра 1  ЛАМПА НА ПОТОЛКЕ БУЛЕВАЯ сыпет абракадабру,  причем остальные без проблем.

Поменял ... на

1void PrintTypeDEV (byte Str_nomer) {
2Serial.print (string_tableDEV[Str_nomer]);}

Все заработало, зачем

Проверил, у меня НЕ работает так, как ты предлагаешь. Вот что в мониторе

1ринято  из  CAN:  КОМАНДА  " БУЛЕВОЕ ВКЛ " На тип устройства:   (./456789:;     Глобальный счетчик:  1  От Кого:  Net_center_Due1

 

 

А ты на DUE проверял? Там другие библиотеки.

MaksVV
Offline
Зарегистрирован: 06.08.2015

у меня нет due

MaksVV
Offline
Зарегистрирован: 06.08.2015

del

MaksVV
Offline
Зарегистрирован: 06.08.2015

Структура полей данных разных типов сообщений: 

 

COMMAND_SEND:  (команда) 01

A                    B          C                 D                         E                             F          G          H

счетчик      не исп.   не исп.   тип команды    значение команды           пока нереализованы

COMMAND_ANSWER: (ответ на команду) 02

   A                B              C                  D                         E                             F          G          H

счетчик      не исп.   суть отчёта     тип команды    значение команды         пока нереализованы

PS  счетчик здесь возвращается  тот же что и в команде)

REQUEST_SEND:    (запрос параметра) 03

A                    B          C           D            E           F          G          H

счетчик      далее адреса  запрашиваемых параметров (т.е. в одном запросе можно запросить до 7 параметров, оппонент ответит 7-ми сообщениями с параметрами )

REQUEST_ANSWER:   (параметр) 04

A                 B                    C                       D                   E           F          G          H

счетчик    не исп.   причина отправки    тип данных        далее байты самого параметра 

STATUS_REQUEST_SEND: (запрос статуса) 05

A      B       C      D       E      F     G      H

поле данных пока все нули, нужно придумывать что тут размещать

STATUS_REQUEST_ANSWER: (статус) 06

A      B       C      D       E      F     G      H

поле данных пока все нули, нужно придумывать что тут размещать

MaksVV
Offline
Зарегистрирован: 06.08.2015

переделал адреса узлов ,

задефайнил пины входов импульсных устройств,

добавил флаг распечатки статусов в отладку и занулил его, а то надоело - всё прыгает из-за статусов при отладке.

Флаг statusprint см. где настройка #debug  в самом начале

Скетч

riv
Offline
Зарегистрирован: 20.07.2017

Добавь плиз в свой код типы сообщений об аварии

01typedef enum Message_enum
02{
03    NULL_C,                //0
04    COMMAND_SEND,          //1
05    COMMAND_ANSWER,        //2
06    REQUEST_SEND,          //3
07    REQUEST_ANSWER,        //4
08    STATUS_REQUEST_SEND,   //5
09    STATUS_REQUEST_ANSWER, //6
10    MULTIFRAME_SEND,       //7
11    MULTIFRAME_ANSWER,     //8
12    MULTIFRAME_ANSWER_END, //9
13    SIZE_MESSAGE_ENUM,      //10 size
14    ACCIDENT_SEND,
15    ACCIDENT_ANSWER
16} Message_CAN_ENUM;

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

опиши логику фреймов аварии:   как, сколько раз, когда и куда должны посылаться аварийные сообщения. 

riv
Offline
Зарегистрирован: 20.07.2017

Я у себя в коде ввел аварию уже месяц как https://yadi.sk/d/qCKaB5ic3V3QAx

Если мастер обнаружил стабильно битый узел то он должен отправить на узел мониторинга сообщение об аварии. Мониторинг должен подтвердить. 

riv
Offline
Зарегистрирован: 20.07.2017

Твой код  через 30-40 сек работы наглухо вешает контроллер.

riv
Offline
Зарегистрирован: 20.07.2017

Заработало только в таком виде

1void PrintTypeDEV (byte Str_nomer) {
2Serial.print (string_tableDEV[Str_nomer]);
3}

в таком

1void PrintTypeDEV (byte Str_nomer) {
2if (Str_nomer==0)
3Serial.print ("NULL");
4else
5{
6strcpy_P(buf, (char*)pgm_read_word(&(string_tableDEV[Str_nomer])));
7Serial.print (buf);
8}
9}

вместо 0 заглючила 1, такое ощущение что при инициализации буфера сыпется хлам

riv
Offline
Зарегистрирован: 20.07.2017

И еще просьба, можешь в основном файле ничегог кроме настроек, setup и loop  не вставлять - это для совмеместимости версий.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Твой код  через 30-40 сек работы наглухо вешает контроллер.

Ты там ничего не меняешь? Либо где-то есть конкретная ошибка (но у меня то работает днями норм), либо DUE не воспринимает чтото в коде. 

Тут явное переполнение какого-то буфера. Конечно в таком случае будут глюки, впоть до зависания.

Попробуй то же самое на МЕГЕ. 

Также возможно виной всему русский текст. На латинице такое врядли будет происходить. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

А вообще, если смотреть на твой скрин отадки, непонятно, почему байт С поля данных ОТВЕТА ПАРАМЕТРА принимает значения 01 и 02. 

Возможные варианты должны быть такие: 

1#define PERIODICALLY       0x09   // параметр отправлен периодически
2#define CHANGEVALUE        0x0A   // параметр отправлен по факту изменения его значения на узле
3#define ON_REQUEST         0x0B   // параметр отправлен по запросу от другого узла
4 
5// ЕСЛИ ПРИХОДИТ ЗАПРОС НА ПАРАМЕТР, НЕ УКОМПЛЕКТОВАННЫЙ НА УЗЛЕ - ОТЧЁТ БУДЕТ ТАКОЙ:    #define NOT_INCLUDED       0x06

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

скинь сюда код мастера node_4 и подчинённого node_18 я их у себя залью и посмотрю что будет, сравню  с твоим скрином

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

И еще просьба, можешь в основном файле ничегог кроме настроек, setup и loop  не вставлять - это для совмеместимости версий.

я пробовал убрать всё , кроме setup  и loop, из первой страницы.  Но не смог добиться чтобы заработало - компилятору что-нибудь да не нравится. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:

И еще просьба, можешь в основном файле ничегог кроме настроек, setup и loop  не вставлять - это для совмеместимости версий.

я пробовал убрать всё , кроме setup  и loop, из первой страницы.  Но не смог добиться чтобы заработало - компилятору что-нибудь да не нравится. 

Я сегодня наконец доделаю гибрид твоего и моего кода, твой оставляю неизменным за исключением основного файла, чтобы не глядя твои новые версии закидывать в проект. И выложу. Вот что на сейчас. https://yadi.sk/d/ozOcbX7B3V5hYy Осталось вытащить вызовы функций в loop

Да я еще RX_TX разбиваю на 2 файла. В одном каркас функции в другом обработчики.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Твой код  через 30-40 сек работы наглухо вешает контроллер.

Ты там ничего не меняешь? Либо где-то есть конкретная ошибка (но у меня то работает днями норм), либо DUE не воспринимает чтото в коде. 

Тут явное переполнение какого-то буфера. Конечно в таком случае будут глюки, впоть до зависания.

Попробуй то же самое на МЕГЕ. 

Также возможно виной всему русский текст. На латинице такое врядли будет происходить. 

Попробую, самое главное ты зачем русский текст ввел? А потом смысл текста теряется. Перевести зачастую короткое Eng  сообщение на Ру нереально. Либо изврат получается либо длинна растет.

Да и еще на суточном прогоне вылетают узлы сети (2-3). RX сыпет Default msg - Recive Uncnown type message и видно что пустые поля приходят в RX. Спасает только перезагрузка МК. Прошивки одинаковые. Попробую контроллеры заменить. Вылетают одни и те же.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

скинь сюда код мастера node_4 и подчинённого node_18 я их у себя залью и посмотрю что будет, сравню  с твоим скрином

мастер node_4  товой RIV_full_typemsg4.rar

node_18 с вложением твоего кода https://yadi.sk/d/ozOcbX7B3V5hYy

там же последняя версия гибрида RIV_full_typemsg4.rar с моим кодом

riv
Offline
Зарегистрирован: 20.07.2017

Нашел от чего все зависает!!! Ты не поставил во многих местах защиту от выбора несуществующего параметра

Если у тебя только

1Serial.print(F(" Dev_type  - ")); PrintTypeDEV (dev_type); Serial.println ();

и прилетает значение dev_type вне диапазона string_tableDEV[]

то крах системы.

Нужно обязательно

1Serial.print(" Dev_type   -     ");
2if (dev_type<SIZE_DEVICE_ARRAY) //
3{  PrintTypeDEV (dev_type); Serial.println ("  ");}
4else Serial.println (F("Unknown "));

Возможно DUE уже косяки не прощает.

Переделал твой debug, теперь можно использовать ф-ии принта без оглядки на наличие параметра

riv
Offline
Зарегистрирован: 20.07.2017

Да и кстати рекомендую схему для IDE. В ней удобно сворачиваются все {}  (Ты их ставить не любишь ;))

https://github.com/jeffThompson/DarkArduinoTheme

https://codingblog.pl/arduino-ide-dark-theme-czyli-stworzyc-wlasny-motyw...

riv
Offline
Зарегистрирован: 20.07.2017

Да кстати по поводу переноса кода из файла в файл. Очень важно учитывать последовательную логику компилятора. 

Вот например не мог долго понять почему не срабатывет 

1#ifdef ARD_DUE
2  //Serial.print ("ARD_DUE ");
3  Serial.print (string_tableDEV[Str_nomer]);
4#else
5  strcpy_P(buf, (char*)pgm_read_word(&(string_tableDEV[Str_nomer])));
6  //Serial.print ("ARD_MEGA || ARD_UNO ");
7  Serial.print (buf);
8#endif

а ларчик просто открывался

я объявил #define ARD_DUE ПОСЛЕ #include "debug.h" т.е код был включен до объявления #define ARD_DUE