Согласен с автором , что модульные тесты надо вызывать из интерфейса командной строки по последовательному порту. (Глава 3, страница 98, команда и ответ)
при использовании RTT через openocd, нарушаются тайминги BLE, и SoftDevice валится в Hard fault, просто потому что прошивка останавливается на время отладчиком.
Вот именно поэтому и надо отлаживаться через UART-Shell.
CLI не так грубо нарушает timing(и) время исполнения программ как пошаговая отладка , при отладке через CLI код протекает в естественном режиме и лишь изредка слегка замедляется редким выводом в UART. Это вам не точки останова JTAG, которые полностью останавливают программу на несколько секунд и полностью нарушают логику приложения (особенно многоядерного). Для современных 200MHz микроконтроллеров 1 секунда это как для человека эра. С Shell(ом) получается none disturb отладка.
Вот еще хорошие замечание по дизайну PCB. Буквально накануне увидел этот новый класс косяков.
1) Делать всё разъёмы разного форм фактора. Старайтесь сделать так, чтобы все разъёмы были разного форм фактора. Чтобы не было такого что, например, в разъём для CAN нечаянно подключают питание 12V и наоборот. При сборке всякое может случиться. Надо закладывать механическую защиту от неправильного включения.
2) Hi-Side управление на PWM
Если плата предназначена для управления ключами, например Hi-Side, то управляющие пины надо заранее заводить на PWM совместимые пады микроконтроллера. Это поможет Вам потом делать плавное управление нагрузкой.
Если уж и использовать IAR, то только его консольные утилиты: iccarm.exe, iasmarm.exe, ielftool.exe , iarchive.exe , ilinkarm.exe. Вызывать их из Mаke. Суть в том, чтобы иcпользовать IAR без .ewp файлов. Тогда это нормально и здорово.
Aspell был бы очень кстати для автопроверки грамотности при компиляции доков на LaTeX.
У меня на Win make скрипт не отработал.
Что можно предпринять?
Тревожно, что автор ничего не сказала про важность сборки прошивок из скриптов.
Почему важно собирать код из скриптов
https://habr.com/ru/articles/723054/
Сборка и отладка прошивки IoT-модуля: Python, make, апельсины и чёрная магия
https://habr.com/ru/companies/whoosh/articles/825330/
@faruk_yussuf
В предметном указателе даже нет таких слов как make, cmake, скрипты, devOps и т. п.
Согласен с автором ,что надо строить прошивки через proxy mcal
Proxy MCAL для Микроконтроллера / Хабр https://habr.com/ru/articles/829886/
( Стр.122 , глава 4 , рис 4.3)
https://habr.com/ru/articles/698092/
Согласен с автором ,что моторы надо двигать по треугольным и трапециевидным профилям.
Теория управления шаговым двигателем (или как вертеть PTZ камеру) / Хабр https://share.google/bSzYNSKMh2eNIGGiG
(Глава 14, Профили движения, что 414)
Они как будто по моим habr текстам учебник нафаршировали.
Согласен с автором, что надо строить графы зависимостей между программными компонентами.
Генерация зависимостей внутри программы / Хабр https://share.google/MUrPGg6xXoBcdjQxx
(Глава 2, Органиграмма, стр 39)
Согласен с автором ,что перед программированием прошивки надо рисовать блок -схему электронной платы.
Правила Хорошей Структурной Схемы для Электронных Плат / Хабр https://habr.com/ru/articles/667030/
(Глава 2, блок-схема, стр 36)
Согласен с автором , что модульные тесты надо вызывать из интерфейса командной строки по последовательному порту. (Глава 3, страница 98, команда и ответ)
Согласен с автором, что не надо увлекаться написанием очевидных текстовых комментариев в коде. (Стр 27)
Надо же. Автор учебника - женщина программист- микроконтроллеров. Элесия Уайт.
В РФ в этой профессии обычно только мужчины. А в США мало того ,что женщины попадаются Дак они ещё и учебники про embedded пишут!
Вот именно поэтому и надо отлаживаться через UART-Shell.
Почему Нам Нужен UART-Shell? (или Добавьте в Прошивку Гласность)
https://habr.com/ru/articles/694408/
CLI не так грубо нарушает timing(и) время исполнения программ как пошаговая отладка , при отладке через CLI код протекает в естественном режиме и лишь изредка слегка замедляется редким выводом в UART. Это вам не точки останова JTAG, которые полностью останавливают программу на несколько секунд и полностью нарушают логику приложения (особенно многоядерного). Для современных 200MHz микроконтроллеров 1 секунда это как для человека эра. С Shell(ом) получается none disturb отладка.
Вот еще хорошие замечание по дизайну PCB.
Буквально накануне увидел этот новый класс косяков.
1) Делать всё разъёмы разного форм фактора.
Старайтесь сделать так, чтобы все разъёмы были разного форм фактора.
Чтобы не было такого что, например, в разъём для CAN нечаянно подключают питание 12V и наоборот. При сборке всякое может случиться. Надо закладывать механическую защиту от неправильного включения.
2) Hi-Side управление на PWM
Если плата предназначена для управления ключами, например Hi-Side, то управляющие пины надо заранее заводить на PWM совместимые пады микроконтроллера. Это поможет Вам потом делать плавное управление нагрузкой.
Есть ли возможность привести примеры?
Почему бы Вам не написать методичку про то, как по swv настроить full duplex tui ?
Покраска Cтека (Stack Painting) в GCC
https://habr.com/ru/articles/936766/?ysclid=mml1zeutc748967920
Если уж и использовать IAR, то только его консольные утилиты: iccarm.exe, iasmarm.exe, ielftool.exe , iarchive.exe , ilinkarm.exe.
Вызывать их из Mаke.
Суть в том, чтобы иcпользовать IAR без .ewp файлов.
Тогда это нормально и здорово.
https://habr.com/ru/articles/794206/
А что делать тем, кто собирает GCC?
Какой статический анализатор порекомендуете?