Проблема с получением инфракрасных кодов дистанционного управления

Фотисл
Пт 19 мая 2017 г. 8:52 утра
Привет всем,
Я создаю контроллер светодиодной полосы, используя чертеж. Я хотел бы добавить инфракрасный пульт дистанционного управления (у него уже есть соединение с датчиком жеста ESP8266 и APDS9960), поэтому я попытался использовать порт IRMP, выполненный Каравином (https: // github.com/karawin/irmp-master). Даже если библиотека работала с некоторыми тестовыми программами, когда я интегрировал его в свой более крупный проект, она просто перестала возвращать какие -либо результаты. Меня интересовали только протокол NEC, и я не так уверен в результатах IRMP, поэтому я создал свою собственную библиотеку. Это можно найти в https: // github.com/fotisl/necirdecode, И это простой статей, который декодирует только коды дистанционного управления по протоколу передачи NEC IR. Но, опять же, это прекрасно работает с некоторыми простыми программами тестирования, но когда я интегрирую его в свой более крупный проект, у меня возникают проблемы. Я думаю о каком -то взаимодействии с каким -то другим оборудованием, но я не знаю, как найти проблему.
Моя библиотека использует жесткий. Я попробовал с каждым доступным жестким. Остальная часть проекта использует USB -последовательный порт, последовательный порт 1, I2C в PB13/PB15 (мягкий, а не хардвор), SPI2, некоторые контакты GPIO и 2 контакты для ADC.
Любые идеи о том, что может быть проблемой, или как я могу отладить это? У меня есть stlinkv2, но кажется, что это немного трудно отлаживать, так как прерывание исполнения наверняка вытащит меня из синхронизации.

С уважением,
Фотис

AG123
Пт 19 мая 2017 г. 9:31
Возможно, у него закончилась память, вы можете проверить доступное пространство стека E.глин.
http: // www.STM32duino.com/viewtopic.PHP?F = 18&t = 2065

Фотисл
Пт 19 мая 2017 г. 9:59
AG123 написал:Возможно, у него закончилась память, вы можете проверить доступное пространство стека E.глин.
http: // www.STM32duino.com/viewtopic.PHP?F = 18&t = 2065

AG123
Пт 19 мая 2017 г. 10:09
Я также получаю фанки USB -серийные киоски, в частности, когда я включил Freertos в его часть, я отметил, что Freertos выделил блок 8K в качестве своей кучи, которую он использовал для управления своими задачами. С другими объектами я отметил, что около 12 тыс. (8K для RTOS + 4K для других) используется в куче после того, как я его составил и проверяю файл карты
http: // www.STM32duino.com/viewtopic.PHP ... 070#P27711
Если я удалю Freertos, сняв более 8 тысяч, эскиз работает. Следовательно, в моем случае я думаю, что у меня просто заканчивается память, но я тоже не слишком уверен в этом
Для меньших набросков с Freertos он работает

Фотисл
Пт 19 мая 2017 г. 10:14
Проблема в том, что я продолжаю получать такую ​​же проблему с моей библиотекой, которая не использует RTO и отлично работает в простых программах.
Кстати, мой проект светодиодной полосы не использует таймеры.

Фотис

AG123
Пт 19 мая 2017 г. 10:19
Здесь есть какое -то обсуждение http: // www.STM32duino.com/viewtopic.PHP?f = 3&t = 2091 о кольцевом буфере UART, который, по -видимому, задерживает, если некоторые из кольцевых буферных переменных не объявляются как летучие. Вы можете попробовать эти исправления, если это связано с USB - серийными киосками, я не слишком уверен, что этот кольцевой буфер относится к USB -сериалам, надеясь, что это поможет

Фотисл
Пт 19 мая 2017 г. 12:02
Я подтвердил, что обработчик прерываний называется каждые 50us, как скоро, используя логический анализатор. Таким образом, нет проблем с таймером.

Я довольно уверен, что кольцевой буфер UART не связан с моей проблемой, но я обязательно должен проверить, нужно ли измениться некоторые переменные в рамках обработчика прерыва.

Фотис

Эдогальдо
Пт 19 мая 2017 г. 12:23
AG123 написал:Здесь есть какое -то обсуждение http: // www.STM32duino.com/viewtopic.PHP?f = 3&t = 2091 о кольцевом буфере UART, который, по -видимому, задерживает, если некоторые из кольцевых буферных переменных не объявляются как летучие. Вы можете попробовать эти исправления, если это связано с USB - серийными киосками, я не слишком уверен, что этот кольцевой буфер относится к USB -сериалам, надеясь, что это поможет

Фотисл
Пт 19 мая 2017 г. 13:49
На самом деле, если вы не объявляете переменную VAR как летучиемую, и вы измените VAR только в контексте прерывания, то компилятор может оценить состояние внутри вашего цикла во время компиляции и либо преобразовать его до некоторое время (1), удалить целое Цикл, если условие оценивается до 0 или измените его на другое выражение в зависимости от вашего условия.

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

Фотис

AG123
Пт 19 мая 2017 г. 15:17
GCC, как известно, является * удалением кодов *, если по какой -либо причине это казалось неиспользованным

Это, в частности, когда мы попробовали эталон Whetstone и отметили такое поведение, но дало «несправедливо» высокие тесты с оптимизами -O3 :ржу не могу:
http: // www.STM32duino.com/viewtopic.PHP ... &начало = 160

Основными будут то, где локальные переменные объявляются и используются в некоторых заданиях, но в противном случае не используются. Я не слишком уверен, что объявление этих переменных изменчивые могут помешать компилятору «оптимизировать» коды таким образом

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

Фотисл
Пт 19 мая 2017 г., 17:13
С помощью логического анализатора я обнаружил, что проблема фактически вызвана вмешательством от остальных компонентов. Добавление фильтра RC на поставке TSOP4838 немного помогла, и теперь я проверяю, помогает ли питание от снабжения +5 В.

Спасибо за ваши ответы!

I2C переполняет до 1 МГц

конвертировать порт в int