Пины и EEPROM
- Войдите на сайт для отправки комментариев
Всем доброго дня!
Работаю над одним проектом, суть которого заключается в том, что надо управлять 8 отдельными лентами с адресными светодиодами WS2812B.
Для этого использую 8 различных пинов Ардуино (со второго по одиннадцатый) и библиотеку NeoPixel.
Все хорошо работало и ничего не предвещало головняка, пока не потребовалось доработка.
Добавилась запись определенных переменных в энергонезависимую память.
С записью/чтением все хорошо.
НО
отвалилось управление лентой на 11 пине.
Пробовал много различных вариантов и проверок (это далеко не первый мой проект), но с таким встречаюсь впервые. Добавляею функцию с запись в память - нет управления ленты, убираешь функцию с памятью - все ок.
Отсюда вопрос: влияет ли работа библиотеки EEPROM на какие либо пины?
Ну или может кто подскажет, в какую сторону копать, так как перепаять на другой пин уже довольно проблематично. Да и вообще хочу понять, в чем дело.
Поправка: с четвертого по 11 пин.
Ардуино нано использую.
Не влияет. Копать в сторону внимательного чтения кода.
возможно не хватает памяти. Восемь адрессных лент (какой длины?) на Нано - это может быть много.
Код перечитал, увы. Видимо, что то упускаю
По 200 диодов на каждой.
В память записываются 8 чисел (значения от о до 4 каждое) в восемь ячеек, соответственно.
Возьмите ардуину побольше.
Если цветовая картинка на каждой ленте своя, то это выходит 200 * 8 * 3 = 4800 байт, что абсолютно нереально для Нано
Если картинка одинаковая на все 8 лент - то как вы копируете сигнал с одного пина на 7 других?
Теперь самому стало интересно, как оно работало)
Каждая лента целиком горит одним из 5 цветов.
Цвета в ленте меняются с помощью цикла, в котором применяется цвет для n-го диода каждой из 8ми лент и отправляется команда зажечь его.
То есть лента загораются не одновременно, а по одному диоду, но быстро.
Возможно, оно работало поэтому.
Судя по развитию событий - без черной магии тут не обошлось.
Там все запаковано уже, с защитой от темных сил)
Ардуино побольше взять = перепаять все, чего хотелось бы избежать.
Но если не найду причин до понедельника, то, видимо, придется взять что то с большей памятью и пробовать.
Судя по развитию событий - без черной магии тут не обошлось.
нее, ту жеж сразу видно - шаман, а это Практическая магия )))
Мля, мы скетч когда-нибудь увидим?
А заодно проверку памяти в нём?
Или так и будем языком по ягодицам шлёпать?
Судя по развитию событий - без черной магии тут не обошлось.
Да, какая нахрен магия - стек пропорол кучу и началось веселье. "Вот тут вроде работает, а запятую поменял - всё свалилось нахрен". Впервой, что ли?
Судя по развитию событий - без черной магии тут не обошлось.
Да, какая нахрен магия - стек пропорол кучу и началось веселье. "Вот тут вроде работает, а запятую поменял - всё свалилось нахрен". Впервой, что ли?
Очень на это похоже.
Скажем так, не часто с таким сталкивался, а на Ардуино первый раз. И в голову не пришло в ту сторону копать)
За идею спасибо.
Но тут у меня опыта маловато.
Есть какие-либо варианты вылечить?
На ум пока приходит только какой-либо костыль типа очищения памяти после отправки в ленту (скорее всего чушь спорол, но хз)
Мля, мы скетч когда-нибудь увидим?
А заодно проверку памяти в нём?
Или так и будем языком по ягодицам шлёпать?
Как до ноута доберусь, скину.
Думаю, ближе к вечеру.
Мля, мы скетч когда-нибудь увидим? А заодно проверку памяти в нём? Или так и будем языком по ягодицам шлёпать?
Видел, говорю ж, чуть ближе к вечеру.
ну, таком разе "думаю, ближе к вечеру" и поговорим. А сейчас говорить не о чем.
Только ты уж сразу там и на память посмотри MemoryExplorer'ом. Библиотеку можно взять здесь.
Если гражданин уверяет, что на его nano точно работала конфигурация, которая требует 5кб рамы, то никакого стека тут нет - исключительно черная магия.
MemoryExplorer сказал следующее:
Ну, да, распашка, только не такая простая, как я думал.
Скажи, пожалуйста, у тебя всё правильно подключено - именно к тем пинам, которые написаны в скетче? Например, в строке №60? Именно к этим пинам всё и подключено?
Уверен?
Ну, да, распашка, только не такая простая, как я думал.
Скажи, пожалуйста, у тебя всё правильно подключено - именно к тем пинам, которые написаны в скетче? Например, в строке №60? Именно к этим пинам всё и подключено?
Уверен?
Да, уверен.
Dfplayer'у нужен только tx для работы, назад он не возвращает инфы, кроме busy пина.
А 99 это рандом зачение. Компилятор кушает, плеер работает, все довольны)
В общем так, ошибку я тебе указал. Посмотри как устроен софтверный сериал и, если внимательно посмотришь, то поймёшь, что он при твоём "рандоме" он может гадить тебе на любой пин или вообще в любой IO порт. А может и не гадить - как повезёт. В какой именно порт (и гадит ли вообще) зависит от того, что ещё в программе написано - что ты, собственно и наблюдаешь.
Впрочем, если все довольны, то можешь и не смотреть, просто закрой тему. Чего воду в ступе толочь, если ты доволен?
Чего воду в ступе толочь, если ты доволен?
Вопрос то был не про то, что я доволен.
За помощь спасибо, не знал этого нюанса с сериал. Изучу .
Видимо, до этого мне часто везло, раз не всплывало.
В понедельник попробую, отпишусь.
Нашел инфу тут.
https://forum.arduino.cc/index.php?topic=112013.0
Может, кому понадобится, там вроде допилили библиотеку только на прием или только на передачу.
За помощь спасибо, не знал этого нюанса с сериал.
Ты так ни в чём и не разобрался, а, значит, проблема ждёт в засаде до следующего случая. Это вовсе не "нюанс с сериал". Это нюанс использования левых (особенно больших) чисел в место номера пина.
Я ж тебе писал "внимательно посмотри как устроен сериал". Ты этого либо не сделал, либо не разобрался в чём именно проблема. Если не можешь разобраться - спрашивай.
За помощь спасибо, не знал этого нюанса с сериал.
Ты так ни в чём и не разобрался, а, значит, проблема ждёт в засаде до следующего случая. Это вовсе не "нюанс с сериал". Это нюанс использования левых (особенно больших) чисел в место номера пина.
Я ж тебе писал "внимательно посмотри как устроен сериал". Ты этого либо не сделал, либо не разобрался в чём именно проблема. Если не можешь разобраться - спрашивай.
Попытка понять твою мысль пока не вышла успехом.
Попробую пояснить, что и как я искал, если ошибся - буду благодарен, если укажешь.
Из работы софт сериал я понял, что он устанавливает моё "рандом значение" как порт INPUT.
Далее логично посмотреть, что будет, если установить вместо номера порта "рандом значение". (Об этом ты мне написал утром.) Да и вообще pinMode в целом.
Далее инфа взята отсюда: https://garretlab.web.fc2.com/en/arduino/inside/hardware/arduino/avr/cores/arduino/wiring_digital.c/pinMode.html
А именно, при вызове pinMode происходит проверка "на адекватность":
Каким образом? - Вызовом макроса digitalPinToPort(pin);
Как он работает? далее инфа отсюда: https://garretlab.web.fc2.com/en/arduino/inside/hardware/arduino/avr/cores/arduino/Arduino.h/digitalPinToPort.html
То есть он ищет значение в массиве
И далее, если находит, продолжает работу, если нет, то, выходит, что команда pinMode игнорируется.
Поэтому я не могу понять, почему значение 99 может "гадить" в любой порт.
Буду благодарен, если пояснишь свою идею.
Всё же доступно. Игнорируется пинмоде или выдает на кой то пин можно проверить вставив контрольный вывод. Я где то натыкался внутри кода ардуиновского ядра, что нога с большим номером усекается на максимальное число ног до тех пор, пока не окажется в диапазоне 0 - мах и уже тогда применяется. Для какого чипа это было сделано я не помню, но в голове осталось, что опасно давать номера с большими числами, что бы не попасть на непонятный глюк.
У тебя изначально неверный подход. Вернее, начал ты правильно (с просмотра исходных кодов) Ну, так бы и продолжал. Причём здесь какой-то https://garretlab.web.fc2.com/? Самый достоверный источник инофрмации о программном коде - сам код, а вовсе не какие-то левые сайты.
Вот смотри, как это делается - именно это я имел в виду, когда говорил "посмотри внимательно":
Смотрим текст конструктора SoftwareSerial и видим:
Ага, смотрим текст setRX
теперь смотрим текст pinMode (потом можно и digitalWrite посмотреть). Итак, pinMode
таак! А что ж у нас такое digitalPinToBitMask и digitalPinToPort и что там за NOT_A_PIN такой? Смотрим на них:
Ага. Ну, вот теперь всё понятно. digitalPinToPort - это просто чтение из прогмема по адресу digital_pin_to_port_PGM со смещением, равным номеру пина. А NOT_A_PIN - всего лишь ноль. Что мы прочитаем из байта с таким большим смещением? А хрен его знает, что там есть, то и прочитаем. Если там окажется ноль - сработает проверка на валидность. Если не ноль, то опять же смотря что. Если вдруг по адресу digital_pin_to_port_PGM + 99 вдруг окажется число, совпадающее с номером порта (любого DDRx/PORTx/PINx/etc.), а по адресу digital_pin_to_bit_mask_PGM + 99 окажется число от 0 до 7 включительно (а таковая вероятность есть - это как повезёт!!!), то мы получим "разумный адрес порта" в который и начнём радостно гадить!!!
Понятно? Собственно на этом можно и прекратить исследование, но если любопытно, то можно глянуть а куда же мы таки попадаем? Давай посмотрим. Для этого скомпилируем такой скетч, например, для Nano.
Теперь запустим objdump на наш скомпилированный скетч:
Ну, что digital_pin_to_port_PGM мы видим и видим, что она нормальная, а вот со смещением 99 (по адрес DF) мы видим уже просто область кода - библиотечные коды там. Какие именно коды - а зависит от того, что мы у себя используем.
Вот так оно и получается.
На том сайте, на который я ссылался, довольно не плохо, на мой взгляд, расписано.
Но да, соглашусь, исходники лучше.
Большое спасибо за пояснения и пример, в этом вопросе разобрался. Было интересно)
По теме поста: ошибку с пином исправил - не спасло; поставил мегу и всё работает как надо.
Спасибо всем, кто отписался!