А вот такой вопрос. Есть такая штука, ARM semihosting. Когда, например, стандартные printf заводится особым образом на, например, UART.
Или, как вариант, выводить printf-ом не на UART, а через SWD Я, например, OpenOCD пользуюсь, и, как вариант, было бы неплохо там подобный вывод иметь.
Кто-нибудь заводил подобное? Помимо отладки дебаггером, благо с STM32 тут всё хорошо, хотелось бы иметь и подобную возможность, но как-то толкового руководства по настройке не видел.
Через встроенные средства IDE я вывод в семихостинг делал, но это под каждую среду нужно настраивать, что ломает. Поэтому делаю "печать" в последовательный порт. На примере F0:
Код:
/* Send a char via UART */ void __STATIC_INLINE uputc(uint8_t c) { /* Polling idle frame Transmission */ while((USART1->ISR & USART_ISR_TXE) != USART_ISR_TXE) { /* Timeout handler follows here */ } USART1->ICR = USART_ICR_TCCF; /* Сlear TC flag */ USART1->TDR = c; /* Send char */ }
/* Send a string via UART */ void __STATIC_INLINE uputs(char *s) { while (*s != 0) uputc(*s++); /* Send string char by char */ }
/* MACRO to emulate printf() via UART */ #define uprintf(...) for(char _b[100]; snprintf(_b, sizeof(_b), __VA_ARGS__), uputs(_b), 0;){}
Дальше можно макрос uprintf() использовать полностью аналогично printf(). Переписав нужным образом uputc(), можно хоть азбукой морзе в блинк форматированную печать выдавать.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Да, этот вариант более очевиден. Хотя я имел в виду чуть другое - а именно сам printf "завернуть" на UART или куда там нужно. То есть, сам stdout перенастроить
Я вот вчера этот семихостинг "пощупал" - прикольно, но всё-таки не очень удобно. Во-первых, в момент вызова print всё словно подвисает на какую-то долю секунды. То есть, такой вариант, похоже, сам по себе медленный, и ещё работу МК приостанавливает. Даже таймеры "плывут". Во вторых, прошивка с семихостингом без подключенного отладчика виснет. То есть, годится только для отладки, потом же приходится снова компилировать обычную, без всех этих printf-ов.
В общем, немножко разочаровался с семихостингом. Вариант с UART получше будет. Разве что доработать его так, чтобы это был не поллинг, а работало оно через прерывания, дабы не блокировать основной поток программы на время вывода в UART.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
dosikus, А можно чуть по подробнее что это такое ? На хабре читал не давно "функции отладочного вывода асинхронные и практически не занимают процессорного времени и не оказывают никакого влияния на ход выполнения программы при отсутствии подключения отладочного адаптера." Это как там сделано ?
Если на пальцах, то в ОЗУ выделяется область памяти в которую приложение кладёт информацию, которую хочет вывести во внешний мир. То есть, для приложения скорость вывода отладочной информации равна скоростью копирования память-память. Далее вступает в действие "магия отладчика". В канале управления SWD выделено 25% пропускной способности, чтобы J-Link забирал из этого буфера информацию в фоне. После того как J-Link заберёт данные из буфера, он отдаёт их клиенту, подключившемуся к нему по Telnet. Если же отладчик не подключен, то данные из буфера просто никто не забирает и они вытесняются новыми данными. Приложению до этого никакого дела нет.
Из плюсов: - не задействованы никакие аппаратные ресурсы. Не надо резервировать UART для отладки, например. - скорость вывода сообщений приложением очень высока. Это просто копирование память-память. Можно мониторить очень быстрые события практически не влияя на скорость их обработки. - не надо никаких лишний подключений типа SWO или UART. Всё по тем же SWDIO и SWC идёт. - можно не пересобирать приложение, если отладка больше не нужна. Просто не подключать отладчик и всё. Приложение ничего об этом не узнает.
Из минусов: - работает только на J-Link. - общая скорость считывания сообщений из буфера не очень высока. Для J-Link-OB это около 500 кбит. В то время как в UART можно мегабиты пропихнуть. - ну и собственно нужно некоторое количество памяти для буфера. 1-2 кбайт.
Если же отладчик не подключен, то данные из буфера просто никто не забирает и они вытесняются новыми данными.
Зависит от флагов, если при полном буфере выбрано ожидание его освобождения, то данные не будут теряться, но без отладчика при переполнении все зависнет.
VladislavS, телнет клинет это только часть , в SES так же встроена поддержка.
Очень большая вероятность, что внутри SES тот же телнет. Впрочем, какая разница, есть поддержка - хорошо. Нет - подключаемся любым телнет-клиентом хоть локально, хоть удалённо.
dosikus, не пробовали, а осуждаете? У EB Monitor принцип работы такой же как выше написал VladislavS и если по вашему EB Monitor "хуже семихостинга", то RTT такой же.
Читал как-то про эти потуги. Назвать это словом "работает" язык не поворачивается.
А что именно не так? Как патч примут - так сразу все и начнут пользоваться. В platformio дебагер через stlink кстати весьма шустрый, уж не знаю что они там внутри намутили.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
