Комментарии 6
Есть пара вопросов:
1. Насчет отладки — что Вы думаете о Visual Micro? Я понимаю, что она под Ардуино (что не стыкуется с основной идеей ваших статей), но наличие возможности отладки (хоть какой-то), с моей точки зрения, является большим плюсом. Правда, по ряду причин я этой возможностью воспользоваться не смог.
2. Я столкнулся с проблемами при организации обмена данными между двумя Тинси 4.0 по UART, в результате чего пришел к выводу, что лучше всего в этом случае использовать синхронную передачу данных (например, тот же SPI). Интересно было бы узнать Вашу точку зрения на описанные мной случаи. Я допускаю, что, в частности, проблемы в работе UART при подключении другого Тинси к ПК (да и другие траблы) могли быть вызваны использованными библиотеками, но так глубоко я не копал — не было ни времени, ни серьезной необходимости.
По первому пункту, я наловчился хоть как-то вести отладку через MCUXpresso, но используя UART вместо JTAGа. Так можно. На стороне Тинси реализуется функционал GDB Stub, а самому GDB надо сообщить, что он работает через UART. В одной из следующих статей планирую рассказать про это, если интерес будет (часть статей уже написана, они точно будут опубликованы, а эта - ещё не оформлена даже в виде DOC файла, так как первая статья была встречена очень холодно, а писать ради писанины - скучно). Но там полный изврат. Лучше, чем ничего, конечно. Можно ставить точки останова и просматривать любые переменные. Но шагать - опасно. Так что хоть оно и работает, я продолжаю утверждать, что нормальная отладка под Тинсей 4.1 невозможна.
А так я вообще люблю работать с Кейлом и не стремлюсь к изучению каких-то новых сред разработки. Но у нас был проект. Нам надо было освоить работу именно Тинси 4.1 именно через MCUXpresso и именно со всем широчайшим спектром тех библиотек. Заказчик разрешил опубликовать все результаты. Отчёт для Заказчика был на английском и несколько скучный. А тут я публикую своё видение на русском, со своей расстановкой акцентов. Так что изучал MCUXpresso я за зарплату, имея точный список библиотек, которые следует освоить. А силы на изучение Visual Micro, может, и появятся, но даже не знаю, когда. А в описании там деталей нет, как там отладка выполняется.
По второму же пункту - я прочитал статью. Скажу честно, по такому описанию какую-то диагностику сделать не смогу. Синхронная передача - всегда лучше, чем асинхронная. Но сам я с асинхронной никаких проблем не имел. Однако, там такое дикое сочетание возможных проблем... Вплоть до соотношения Baud Rate с частотами кварцев на обеих сторонах. И масса, масса, масса всего прочего. Так что ничего не могу сказать, не пощупав реальную систему. Иногда ощупывать приходится долго.
Не нашёл, как в новом дизайне править комментарии.
Я-то в голове MCUXPressные библиотеки держал. А Ардуиновские UART библиотеки настолько удивительные, что там всё, что угодно может случиться, если работать через верхний уровень. Низкоуровневые - относительно приличные. Но опять же, в статье не показано, как шла работа.
Т.е., например, организовывал передачу данных из ведомого Тинси в ведущий, а из него — в ПК. Т.е. отладка шла на самом верхнем уровне (ПК). Соответственно, если происходил сбой в передаче данных из ведомого, то я ничего в ПК не мог увидеть. Но, в конце концов, оно все заработало.
Насчет Visual Micro — как я понял, они используют способность Тинси создавать до трех СОМ-портов, и один из них используют для передачи отладочной информации и даже для организации точек останова. Это бы мне ну очень пригодилось при отладке ведомого Тинси, но система таки заработала до того, как я дошел до точки )).
Кстати, то, что не получилось параллельно использовать UART и I2C — это баг или фича? Я написал в статье, что где-то наткнулся на упоминание, что в Ардуино это таки фича (для ATmega), но является ли это сознательным решением для Тинси — непонятно. Может, при использовании родных библиотек от NXP были бы совсем другие проблемы.
Вот Вам готовое решение для Тинси, основанное на библиотеках Ардуино. Я своё делал на его базе. Повторю - шагать нельзя! Только ставить точки останова и смотреть переменные, когда эти точки сработали. Дело в том, что там всё делается за счёт внедрения в точку останова команды SVC, если неверно определено положение следующей вставки - всё упадёт.
GitHub - ftrias/TeensyDebug: GDB proxy and debugging support to Teensy 3/4
Проблем с UART и I2C не замечали во время проекта. Да и откуда им там быть? Может, конечно, тестовые задачи были недостаточно суровые. Но надеюсь, нет их.
Teensy 4.1 через MCUXpresso. Часть 2. Осваиваем GPIO и UART