вот это интересное решение со светодиодом. допустим температура\влажность (смотря что проверяем) попали выскочила за диапозон от 10 до 30 градусов -> зажгли диод, вывели номер и имя датчика (применимо только для данных формата xx.xx или x.xx), а как быть с данными вида .00 или 24. и т.д. ? проверять каждое значение на правильность формата и если оно не соответствует инициировать перезапрос температуры например?
Ну тут нужно опять пытатся отделить "в чем причина". В неверных данных с датчиков или "карябы происходят" в процессе передачи.
Подключить это все к компу, а не роутеру, посмотреть как оно выглядит в Serial мониторе. Убедится что это именно "ардуина виновата", а не роутер неправильно читает.
Попытатся воспроизвести это "без датчиков" (у меня "по быстрому", не получилось поломать формат). "Без датчиков", подразумеваете слать даже не "отключать их", а просто делать Serial.print какой-то переменной, значение которой не меняется (и вы всегда его знаете) и попытатся добится что-бы оно "поломалось".
Возможно происходит переполнение буфера. Попробуйте увеличить скорость порта и добавить delay() перед/после принтами. Может измерения где-то запрещают прерывания, не дают сериалу заниматся отправкой и он переполняется и теряет символы (кстати Serial.flush нигде не влепили? возможно это он "очищает" :( )
На "стороне роутера" попробуйте, для подобных строк, выловить ASCII коды приходящих символов. Что-бы понять что происходит - "теряются символы" или "приходят какие-то мусорные управляющие".
Длину провода снизить, экранировать, банальные "качество контакта" проверить и т.п.
дуина подключена к буку (к роутеру подключения дуины не было)
>Попробуйте увеличить скорость порта и добавить delay() перед/после
задержки стоят 1 сек. перед опросом датчиков (пробовал увеличивать), скорость прта не менял - попрробую
>Serial.flush
нигде нет
>Длину провода снизить, экранировать, банальные "качество контакта" проверить и т.п.
провод около 30см, экранированный есть, но с ним пока не тестил, контакты прозванивал тестером - в норме
с переписанным с вами кодом добились того, что в течении дня выскочила всего-лишь одна ошибка, но на всех одновременно датчиках - уже гораздо лучше чем было
с переписанным с вами кодом добились того, что в течении дня выскочила всего-лишь одна ошибка, но на всех одновременно датчиках - уже гораздо лучше чем было
Ну значит "причина" все-таки так и не "поймана". Было-бы неплохо понять кто именно "каблучится" DS или DHT. Или сразу и те и те? (тогда точно проблема где-то на стадии передачи).
Цель "переписывания" была вообщем-то именно в том, что-бы уменьшить связанность кода. Что-бы "можно было тестить кусками" и проще было искать "первопричину" (почему ваш код глючил - ведь так и не поняли).
нати какую-нибудь софтинку виртуальных ком-портов. Что-бы все приходящие от дуины направлялось на два порта - один будет слушает скприпт, на другом висеть терминал. И посмотреть, когда в скрипте видны "караулы", видно ли такие же "поломки" в терминале (или сохраненной логе). Если в терминале "все хорошо", а в базе ошибки - значит нужно смотреть принимающий скрипт. Где-то он упускает данные.
Еще можно постестить с такого конца, попробовать скетч
void setup(){
Serial.begin(ВАША_СКОРОСТЬ);
for(float i=0.0;i<100;i+=0.01){
// тут можно вставить
// опрос датчиков
Serial.println(i);
}
}
void loop(){}
Посмотреть нарушается ли форматирование где-то, нет ли пропусков. Потом на "тут можно вставить" добавить опрос какго-то датчика. Но не выводть его в Serial. Вначале опрос DS, потом опрос DHT, потом обоих. Потом "всех". Без каких-либо пауз. Проверить влияется-ли как-то опрос датчиков на быстрый вывод в Serial.
Попробовать все это на разных скоростях. На 4800, когда сам сериал может "не успевать", а потом на 115200, когда "приемный скетч" может не успевать и захлебоватся.
Вообщем задача добится "четкой воспроизводимости" проблемы. Пойти от обратного. Решить задачу не "убрать проблему", а "создать ее". Представте себя вражеским диверсантом, которому нужно так накосячить, что-бы вот начинались подобные "пропуски символов".
за ссылки спасибо буду пробовать отлавливать "зверя"
>Представте себя вражеским диверсантом...
прям какой-то экшн начинается :)
Да нет. Обычная работа программиста. Многие думаю что его работа состоит "писать код". А нефига :) До 80-90% времени на разработку может уходить именно на "глубокий дебагинг", "воспроизведение ситуации" и т.п.. Безошибочных программистов - не бывает. И "хороший", от "плохого" тем и отличается - умеет сокращать время необходимое для поиска ошибки.
Для этого:
Пишет части кода так, что-бы их можно было протестировать отдельно. Что-бы ошибку можно было "локализировать"
Автоматические тесты
Логгинг
Обработка exception, проверки на допустимые значения, assert-ы
Максимально легкочитаемый код (пусть даже иногда в ущерб эффективности)
Что-бы, если ошибка все-таки возникла (а она возникнет) узнать о нее на как можно более раннем этапе разработки, и максимально быстро узнать кто причина. В идеале - без необходимости отладки. По имени упашего теста, warning-у в логе, стектрейсу эксепшина.
В теории выполнить все эти пункты - просто. А в реальности, на живом проекте - намного труднее (иногда - невозможно). В случае с ардуиной - все еще осложняется скудными ресурсами, бедностью инструментария и языка, затрудненность воспроизведения "поведения железа". Спасает только то что сами скетчи, опять-таки из-за ограниченности ресурсов - довольно примитивны (по сравнению с PC-шными программами).
Так что остается только "пожелать удачной охоты" :) Постарайтесь, где только возможно, "автоматизировать охоту". Не "отслеживать глазами", а фантазировать всякие "триггеры-капканы" (и со стороны ардуины, и со стороны принимающего) которые могут "следить" за происходящим с гораздо большей усидчивостью чем вы.
вот это интересное решение со светодиодом. допустим температура\влажность (смотря что проверяем) попали выскочила за диапозон от 10 до 30 градусов -> зажгли диод, вывели номер и имя датчика (применимо только для данных формата xx.xx или x.xx), а как быть с данными вида .00 или 24. и т.д. ? проверять каждое значение на правильность формата и если оно не соответствует инициировать перезапрос температуры например?
>а как быть с данными вида .00 или 24. и т.д.
Ну тут нужно опять пытатся отделить "в чем причина". В неверных данных с датчиков или "карябы происходят" в процессе передачи.
Подключить это все к компу, а не роутеру, посмотреть как оно выглядит в Serial мониторе. Убедится что это именно "ардуина виновата", а не роутер неправильно читает.
Попытатся воспроизвести это "без датчиков" (у меня "по быстрому", не получилось поломать формат). "Без датчиков", подразумеваете слать даже не "отключать их", а просто делать Serial.print какой-то переменной, значение которой не меняется (и вы всегда его знаете) и попытатся добится что-бы оно "поломалось".
Возможно происходит переполнение буфера. Попробуйте увеличить скорость порта и добавить delay() перед/после принтами. Может измерения где-то запрещают прерывания, не дают сериалу заниматся отправкой и он переполняется и теряет символы (кстати Serial.flush нигде не влепили? возможно это он "очищает" :( )
На "стороне роутера" попробуйте, для подобных строк, выловить ASCII коды приходящих символов. Что-бы понять что происходит - "теряются символы" или "приходят какие-то мусорные управляющие".
Длину провода снизить, экранировать, банальные "качество контакта" проверить и т.п.
>Подключить это все к компу, а не роутеру
дуина подключена к буку (к роутеру подключения дуины не было)
>Попробуйте увеличить скорость порта и добавить delay() перед/после
задержки стоят 1 сек. перед опросом датчиков (пробовал увеличивать), скорость прта не менял - попрробую
>Serial.flush
нигде нет
>Длину провода снизить, экранировать, банальные "качество контакта" проверить и т.п.
провод около 30см, экранированный есть, но с ним пока не тестил, контакты прозванивал тестером - в норме
с переписанным с вами кодом добились того, что в течении дня выскочила всего-лишь одна ошибка, но на всех одновременно датчиках - уже гораздо лучше чем было
Попробуйте завести "виртуальный контрольный датчик". Там где вы DS-сы проверяете, увеличте цикл на colDS <number_device+1
а настоящую логику оберните в if
if(colDS<number_device){ // тут логику настоящего чтения } Ctemp_DS=29.0; // виртуальный дачик // а тут пошели наши принтыНа роутере проверяете, если с четвертого датчика пришло что-то не 29.00, то пишите предупреждение в базу и отправляете ардуине букву 'e',
Вверху дописываете
а в switch обработки комманд из serial дописываете
.... switch ... case CMD_ERROR: digitalWrite(LED_BUILDIN,HIGHT); // зажигаем ошибку ко команде от роутера break; .... }с переписанным с вами кодом добились того, что в течении дня выскочила всего-лишь одна ошибка, но на всех одновременно датчиках - уже гораздо лучше чем было
Ну значит "причина" все-таки так и не "поймана". Было-бы неплохо понять кто именно "каблучится" DS или DHT. Или сразу и те и те? (тогда точно проблема где-то на стадии передачи).
Цель "переписывания" была вообщем-то именно в том, что-бы уменьшить связанность кода. Что-бы "можно было тестить кусками" и проще было искать "первопричину" (почему ваш код глючил - ведь так и не поняли).
Можно еще, что-бы убидится что это не читающий скрипт глючит, взять терминальную прогу которая умеет логи в файл писать. Например http://easyelectronics.ru/files/soft/Terminal.exe
нати какую-нибудь софтинку виртуальных ком-портов. Что-бы все приходящие от дуины направлялось на два порта - один будет слушает скприпт, на другом висеть терминал. И посмотреть, когда в скрипте видны "караулы", видно ли такие же "поломки" в терминале (или сохраненной логе). Если в терминале "все хорошо", а в базе ошибки - значит нужно смотреть принимающий скрипт. Где-то он упускает данные.
Или вот чем-то таким воспользоватся
http://www.aggsoft.ru/serial-port-monitor/serial-port-sniffer.htm
(но сам не пробовал эту софтину)
попробую, может получится
Еще можно постестить с такого конца, попробовать скетч
void setup(){ Serial.begin(ВАША_СКОРОСТЬ); for(float i=0.0;i<100;i+=0.01){ // тут можно вставить // опрос датчиков Serial.println(i); } } void loop(){}Посмотреть нарушается ли форматирование где-то, нет ли пропусков. Потом на "тут можно вставить" добавить опрос какго-то датчика. Но не выводть его в Serial. Вначале опрос DS, потом опрос DHT, потом обоих. Потом "всех". Без каких-либо пауз. Проверить влияется-ли как-то опрос датчиков на быстрый вывод в Serial.
Попробовать все это на разных скоростях. На 4800, когда сам сериал может "не успевать", а потом на 115200, когда "приемный скетч" может не успевать и захлебоватся.
Вообщем задача добится "четкой воспроизводимости" проблемы. Пойти от обратного. Решить задачу не "убрать проблему", а "создать ее". Представте себя вражеским диверсантом, которому нужно так накосячить, что-бы вот начинались подобные "пропуски символов".
за ссылки спасибо буду пробовать отлавливать "зверя"
>Представте себя вражеским диверсантом...
прям какой-то экшн начинается :)
за ссылки спасибо буду пробовать отлавливать "зверя"
>Представте себя вражеским диверсантом...
прям какой-то экшн начинается :)
Да нет. Обычная работа программиста. Многие думаю что его работа состоит "писать код". А нефига :) До 80-90% времени на разработку может уходить именно на "глубокий дебагинг", "воспроизведение ситуации" и т.п.. Безошибочных программистов - не бывает. И "хороший", от "плохого" тем и отличается - умеет сокращать время необходимое для поиска ошибки.
Для этого:
Что-бы, если ошибка все-таки возникла (а она возникнет) узнать о нее на как можно более раннем этапе разработки, и максимально быстро узнать кто причина. В идеале - без необходимости отладки. По имени упашего теста, warning-у в логе, стектрейсу эксепшина.
В теории выполнить все эти пункты - просто. А в реальности, на живом проекте - намного труднее (иногда - невозможно). В случае с ардуиной - все еще осложняется скудными ресурсами, бедностью инструментария и языка, затрудненность воспроизведения "поведения железа". Спасает только то что сами скетчи, опять-таки из-за ограниченности ресурсов - довольно примитивны (по сравнению с PC-шными программами).
Так что остается только "пожелать удачной охоты" :) Постарайтесь, где только возможно, "автоматизировать охоту". Не "отслеживать глазами", а фантазировать всякие "триггеры-капканы" (и со стороны ардуины, и со стороны принимающего) которые могут "следить" за происходящим с гораздо большей усидчивостью чем вы.