Comments 27
Нет смысла инициализировать UART, если не проинициализирован GPIO.
Возьмём для примера ATmega328P, один из самых распространённых микроконтроллеров в DIY (ну просто ввиду распространённости, хотим мы того или нет, Arduino).
Какая разница, сначала мы выставим делитель UART, а потом направление GPIO или наоборот?
UART при инициализации должен выдать Hello сигнал. Если инициализировать UART до GPIO, то вы не увидите в терминале или на осциллографе Hello текста.
А техники сочтут, что ваша прошивка вообще зависла, и нажалуются на вас вашему начальнику.
Инит - это только инит и ничего более. А игите ничего не должно генерироваться и так далее.
Прошли все-все иниты - и только потом приртуем и запускаем железки.
UART при инициализации должен выдать Hello сигнал.
Кому должен? Это какой-то стандарт разработки типа MISRA C? Или это ваш авторский подход?
Если второе, то создаётся ощущение, что у вас синдром неприятия чужой разработки по отношению к JTAG )))
То вы тестирование непропаев/замыканий через UART пытаетесь делать. То отладочную информацию пытаетесь через UART же выдать. За что вы ненавидите JTAG? ))))
К jtag я нормально отношусь. Когда прошивка наглухо зависает, то включаю пошаговую отладку jtag. Если он есть. В 99% случаях на плате только интерфейс SWD.
А все остальное отлично отлаживается через uart cli
А когда я на работе попросил схемотехников протестировать плату на протай с помощью JTAG по Net List(у) и них глаза на лоб полезли.
Вот и пришлось делать программный Cross-Detect прямо на чипе.
Кому должен? Это какой-то стандарт разработки типа MISRA C?
Это требование стандарта ISO 26262
-UART при инициализации должен выдать Hello сигнал.
-Кому должен? Это какой-то стандарт разработки типа MISRA C?
-Это требование стандарта ISO26262
Можете ли вы указать конкретный пункт в данном стандарте, интерпретируя который вы предполагаете обязательным выдачу сигнала Hello в конце процедуры инициализации UART?
Или речь идёт скорее об интерпретации общего духа стандарта?
То вы тестирование непропаев/замыканий через UART пытаетесь делать.
UART это только более простой вариант.
Никто не запрещает вам крутить автомат поиска непропая на PC и управлять GPIO по JTAG.
Вот только отдельный MCAL для PC для каждого MCU вам придется писать самим.
Как и убеждать начальство, что вам на это надо подарить 80-100 часов.
А почему не написать инициализатор UART, который вызывает инициализацию тактирования UART и соответствующих GPIO?
Сама идея такого решения мне нравится, но проблема мне кажется слегка надуманной. Хотя я не работал с реально БОЛЬШИМИ сборками для МК...
Не понимаю, что именно мешает сначала инициализировать всё, что нужно, а потом уже слать всякое в UART и т.д.? Процесс инициализации можно сделать меганаглядным (нужна одна свободная нога GPIO):
1) самым первым инициализируем GPIO
2) подаём импульс на некоторую ногу
3) инициализируем что там ещё нам надо
4) подаём импульс на эту же ногу
И так на каждом шаге.
Если что-то пошло не так - вешаем осциллограф и смотрим сколько импульсов прошло: 6 - значит повисло на 7 шаге, 4 - значит на 5 и т.д.
На запуск главного цикла импульс тройной ширины, на исследкемые функции ещё какие-нибудь хитрые импульсы или их наборы. Сиди и смотри, что называется...
Процесс инициализации можно сделать меганаглядным (нужна одна свободная нога GPIO):
Наглядность повысится еще лучше, если просто запустить UART-CLI. Так делают во всем мире.
И дорогой осциллограф не нужен.
Если что-то пошло не так - вешаем осциллограф и смотрим сколько импульсов прошло: 6 - значит повисло на 7 шаге, 4 - значит на 5 и т.д.
Тогда Вам придется все функции init упаковать в массив указателей на функции.
Вместо "программной смеси":
dot -Tplain mcu.dot | awk '/^edge / { print $2 " " $3 }' | tsort >order.txt
Из недостатков — не показывает, для каких компонент порядок не важен.
Кстати, если подать на вход приведенный пример, tsort находит в нем цикл:
tsort: -: input contains a loop:
tsort: CORTEX_M4
tsort: NVIC
Как Проинициализировать Микроконтроллер [часть 2]