Это очень плохо. Судя по Вашему описанию, контроллер у Вас начинает часто перегружаться. так это или нет было бы видно по этому “Started”. Попробуйте решить эту проблему. Это важнее и информативнее, чем выводить millis
я думал о перезагрузке в BtRead() но с чего тогда светодиоду моргать?
Коллеги! Что за дурацкие гадания? “…за окошко башмачок, сняв с ноги, бросали”, так?
Сперва необходимо исправить ошибку - то есть добавить проверку на границы массива и установку 0 в последний элемент в случае переполнения.
И только ПОТОМ изучать вопрос, что и где перезагружается.
потому, что на стеке затирается нолями адрес возврата из функции и возврат происходит на адрес 00, что равносильно ресету. в новом цикле снова вызывается функция без задержки, такое поведение подтверждается в заявлении ТС о том, что “ответ на БТ приходит сразу”. Это очевидно, и наш коллега выше на это и указал, написав о перезагрузке.
ЗЫ: кстати для любителей говнокода - это поведение легче всего сымитировать на массиве не static. Просто заполнить его нолями с небольшим перебором… как раз на стеке на адрес возврата попадаешь. Это использовалось в С на ПиСюке еще до всяких Ардуин… чтобы сделать переход на нужный автору зловреда адрес.
1 лайк
ещё раз - с чего тогда светодиоду моргать, до зажигания жеж не доходит
Родное сердце! Он моргает при перезагрузке, в ответ на вызов pinMode(). потому что перед ним НАДО поставить установку в “выключено”.
Да, но и millis() по идее даст тот же ответ. Если он постоянно обнуляется - значит ресетит, или если наоборот перестает выводится, то ресетит еще до его вывода
Вот это уже полноценная конкретная информация, спасибо. Завтра будет время - намеренно попробую вызывать переполнение и понаблюдать за результатом
Тогда надо мигать на старте замысловато, чтобы понять, что это ресет.
он у нас Линуксоид, знает какой длины надо закинуть пакет чтобы получить консоль в управление )))
Всем привет. Небольшой отчет. Я убрала строки проверки длины строки и намеренно грузила память. На 100+ длине у меня ломалась millis(), а на 200+ реально происходил ресет.
Первым правильный ответ дал MMM, однако наиболее ценным был процитированный мною ответ от WladDrakula. Именно он позволил мне понять механику происходящего. Ведь недостаточно просто знать как правильно, лучше всего знать что и почему произойдет, если делать не так.
Всем спасибо за помощь)
По моему опыту анализировать неправильную работу (почему именно так глючит) труднее, чем просто сделать правильно. И потому нет в этом смысла.
Правильный вариант обычно один, а неправильных тыщщи.
1 лайк
MMM просто жопой чует, что тут что-то не так. А Дракула знает почему
2 лайка
а в лужу, постоянно садится ua6em - бригада!
а по моему опыту знание механизма одной ошибки может в будущем помочь в решении другой. Но да, безусловно, это много труднее
чисто хакерский подход, а вывод миллис дал больше информации, сначала рушится процедура миллис, дальше уже перезагрузка, хотя можно настроить выдачу листинга и точно знать, где и что в памяти лежит, здесь на сайте есть как это сделать )))
Это вряд ли.
Анализ одной ошибки не поможет в остальных 999 случаях. А знание, как делать правильно, - вполне.
Вот только конкретно в этом примере как правильно сводится к фразе “хорошо делай, а плохо не делай”)
Такое вряд ли поможет в остальных 999 случаях
Спасибо. Интересная информация, мб однажды пригодится
То есть Вы твердо решили в остальных 999 случаях делать плохо…