Также постоянное уникальное напряжение (например 1,54V) заведенное через резистивный делитель напряжения на pin микроконтроллера необходимо для юнит-теста ADC.
Отладка по JTAG это тоже так себе подход. Ведь любая точка останова нарушает тайминги и с пошаговой отладкой вы отлаживаете уже не ту программу, что будет работать в реальности. Только с CLI можно делать Non Invasive Debug. Когда есть CLI(шка), команды установки уровней логирования и чтения памяти по адресу, то отпадает даже необходимость в пошаговой отладке по JTAG.
Когда есть CLI то есть возможность убедиться, что устройство реальноработает в run-time(е).
Когда нет CLI, то остается только нанять в штат православного дьякона, чтобы тот благословлял устройства на работу. Это частая практика в российских технологических компаниях.
Еще для отладки в RTOS можно использовать периферию DAC (ЦАП Цифро Аналоговый Преобразователь) при исполнении каждой задачи выставлять уникальное для задачи напряжение.
Тогда можно осциллографом увидеть во времяисполнения какая задачакогда исполняется и какдолго.
О том что "в embedded DevOps невозможен" мне доказывали не только "очень опытные инженеры" из всяких НИИ “РосПил” но и 28...35 летние Team Lead(ы) некоторых московских контор.
Ситуация такова, что нет доступа к плате. Нет доступа к пину, который переключает исполнение на BackDoor загрузчик. Одна плата на 3 разработчика подключена в офисе к NetTop компьютеру (зомбику) по UART. У разработчиков, сидящих на карантине, есть только Win Remote Desktop Connection и доступ к CLI через Putty. И в этих условиях надо после каждого коммита в репу автоматически обновить приложение на target(e), прогнать тесты.
Я раньше не обращал внимание на эти каплеобразные пины. Плюс схемы той платы у меня не было как и самой платы сейчас нет. Помню, что это 100BaseTx разъём. У меня несколько версий:
1 для жесткости крепления разъема.
2 для электромагнитной совместимости. что-то связанное с высокими частотами
3 может для автоматической конвейерной сборки так удобнее
Также постоянное уникальное напряжение (например 1,54V) заведенное через резистивный делитель напряжения на pin микроконтроллера необходимо для юнит-теста ADC.
Будет гарантия, что драйвер ADC вообще работает.
Отладка по JTAG это тоже так себе подход. Ведь любая точка останова нарушает тайминги и с пошаговой отладкой вы отлаживаете уже не ту программу, что будет работать в реальности. Только с CLI можно делать Non Invasive Debug. Когда есть CLI(шка), команды установки уровней логирования и чтения памяти по адресу, то отпадает даже необходимость в пошаговой отладке по JTAG.
Когда есть CLI то есть возможность убедиться, что устройство реально работает в run-time(е).
Когда нет CLI, то остается только нанять в штат православного дьякона, чтобы тот благословлял устройства на работу. Это частая практика в российских технологических компаниях.
https://www.youtube.com/watch?v=SWYKvpOTrXI
Еще можно добавить, что можно делать так называемые BareBone сборки.
Это когда всего один поток прокручивает SuperLoop из BareMetal сборок.
Так можно отладить часть механизмов RTOS.
Хороший вариант.
Дату выпуска софта можно взять распарсив макросы
__TIME__
__DATE__
и ими же проинициализировать часы реального времени RTC
Еще для отладки в RTOS можно использовать периферию DAC (ЦАП Цифро Аналоговый Преобразователь) при исполнении каждой задачи выставлять уникальное для задачи напряжение.
Тогда можно осциллографом увидеть во время исполнения какая задача когда исполняется и как долго.
«Измерение производительности программного обеспечения по строкам кода похоже на измерение прогресса на самолете по его весу», - Билл Гейтс.
О том что "в embedded DevOps невозможен" мне доказывали не только "очень опытные инженеры" из всяких НИИ “РосПил” но и 28...35 летние Team Lead(ы) некоторых московских контор.
DevOps для firmware
https://habr.com/ru/post/656449/
Есть 2 таких текста
17 атрибутов хорошей PCB
https://habr.com/ru/post/655879/
9 атрибутов хорошего firmware
https://habr.com/ru/post/655641/
Лучшие практики формируются во время работы. Надо походить по граблям.
Можно почитать ISO26262 части 5 и 6
Part 5: Product development at the hardware level
Part 6: Product development at the software level
У нас 55 сборок и каждая 5 минут. Чтобы пересобрать артефакты после 1 комита надо 4 ч 30 мин.
Ситуация такова, что нет доступа к плате.
Нет доступа к пину, который переключает исполнение на BackDoor загрузчик. Одна плата на 3 разработчика подключена в офисе к NetTop компьютеру (зомбику) по UART. У разработчиков, сидящих на карантине, есть только Win Remote Desktop Connection и доступ к CLI через Putty.
И в этих условиях надо после каждого коммита в репу автоматически обновить приложение на target(e), прогнать тесты.
Я раньше не обращал внимание на эти каплеобразные пины. Плюс схемы той платы у меня не было как и самой платы сейчас нет. Помню, что это 100BaseTx разъём. У меня несколько версий:
1 для жесткости крепления разъема.
2 для электромагнитной совместимости. что-то связанное с высокими частотами
3 может для автоматической конвейерной сборки так удобнее
Для контроля пайки. Если припой останется на белой полоске, то это значит, что тут короткое замыкание.
Отличный дизайн. Устройство похоже на коммутатор питания со счетчиком мощности. Так?
Пользовался Tag-Connect(ом) полтора года подряд каждый день по 5 раз. Еще ничего не отламывалось. Tag-Connect - нормальный современный разъём.