Pull to refresh

Comments 19

Неужели cout удобно использовать для отладочного вывода?

Я давно перешел на fmt, которая поддерживай цветной вывод в консоль из коробки, есть еще spdlog, основанный на fmt
Да, как gnu-arm начнет его поддерживать, как часть 20-го стандарта, обязательно попробую.
Доброе утро! А разве пример в самом начале статьи не очень убедительно это показывает? Когда единственный оператор вывода из двух печатных знаков работает со всеми форматами чисел, строковыми литералами и контейнерами, а также трансформациями над ними? Или я не совсем понял ваше сомнение? Тогда попрошу пример удобного на Ваш взгляд варианта. Спасибо за отзыв!

Доброе.

Неубедительно. У cout есть ровно одно преимущество – type safety. Но ведь type-safe аналогам printf сто лет в обед.

А конкретно для логгинга ещё есть всякие удобные макросы, позволяющие из вызова LOG(a,b) сделать печать "a=..., b=...".

код примера выстреливается за 9,2 мкс

Время работы физики определяется выбранным интерфейсом, и не является качественным показателем. Так-же как и режим блокирования основной программы, просто это нужно делать иначе — использовать внешний буфер для дма при работе с физикой, копировать туда данные для передачи, и обновлять задание для дма. Само дма полностью на прерываниях, связь через задания.
моё github.com/AVI-crak/Rtos_cortex/blob/master/sPrint.h
физики там нет, время преобразования в строку для одинарной или двойной точности 2us,
F7 на частоте 216MHz.
А с кодом вы что-то намудрили H7 умеет прекрасно умножать и делить, и не только целые числа. При этом печать массивов — самая большая глупость что можно придумать, такие данные оформляются в сырые пакеты, и отдаются как есть.
AVI-crak, доброе утро! Признателен за ваше внимание к моей статье. Когда около 3-х лет назад я решил сменить профессию и засел за изучение МК и С/С++, неоднократно встречал ваши заметки в разных сообществах. Нередко они помогали разобраться в тех или иных вопросах.
Теперь по существу вашего отзыва:
… нужно делать иначе — использовать внешний буфер для дма при работе с физикой...
Так у меня ровно так и реализовано.
H7 умеет прекрасно умножать и делить, и не только целые числа.
Бесспорно. Вот только основной посыл моей статьи был о том, как заменить именно интерфейс printf-а, используя возможности самого последнего, 20-го плюсового стандарта. И честно указал, что позаимствовал алгоритмы и код конвертации в строку. Можно ли переписать и улучшить заимствованный код с учетом эволюции камней? Весьма вероятно, просто не это основная тема конкретно этой статьи. Ссылку на вашую имплементацию обязательно посмотрю, поэкспериментирую.
При этом печать массивов — самая большая глупость что можно придумать...
Резковато, конечно, но почему? Разве не удобно, напечатав два символа <<, быстро вывести в терминал фрагмент массива с «сырыми» данными любого числового типа? Или, использовав функционал views, прямо в операторе вывода сразу как-то отфильтровать их, выделить поддиапазон etc.?
… время преобразования в строку для одинарной или двойной точности 2us...
У меня за 9 мкс выводится не одно значение, а пример суммарно с 8 значениями разных типов, 2 строковых литерала с операциями выделения поддиапазона и реверса. Вы воспроизвели эти же условия?
Ну и еще раз подчеркну, цель у меня была понять, что могут дать современные плюсы с 20-м стандартом в задаче замены интерфейса printf-a. Насколько универсальным, лаконичным, эффективным и эффектным может выглядеть решение. На мой взгляд, чуть менее 180 строк кода, чтобы получить вполне функциональный аналог стандартного stream-а для embbed-a, это неплохо.
Не знаю, как в eclipse, но в VSCode+PlatformIO я просто руками заменил папку тулчейна и все заработало. Мб и у вас таким образом получится.
Вопрос! SWO к DMA никак не прикрутить?
Ну, фактически отправка символа по SWO это запись в регистр ITM->PORT. А ДМА в режиме MEM_TO_PERIPH для этого и предназначено. Другой вопрос, дотянется ли он до адреса 0xE0000000 (ITM). Не задумывался над этим… Сомневаюсь, но можно будет полюбопытствовать в RM.

а триггер что из ячейки данные утекли в ПК? ITM вряд ли умеет пинать DMA на предмет " я все, давай ещё"

там скорости не слишком то и большие были. Как в данном случае проверить, что DMA не перетрет данные?

Saalur
Подмена интерфейса выхлопа cout — замечательно. Но меня не радует способ реализации. Использовать наработки урезанных по функционалу мк в виде базовых — очень плохая идея.
Хуже может быть только переключение типа ядра в готовой собранной библиотеке. Есть такие товарищи, и вы с ними обязательно столкнётесь.
Для совместной печати в ITM интерфейс — можно принудительно назначить номер порта. Это поможет избежать каши, но не уберёт взаимную блокировку. Кстати, это достаточно удобно.
Совместная печать через физику без деления на каналы — всегда головная боль. Нормального решения нет.

Кстати, вы подумали как отключать отладочную печать? Как реагировать в случае недоступности физического интерфейса? Каким образом управлять печатью в разных исполняемых файлах?
Причёсывать код конечно нужно, и даже необходимо. Но упор на ленивое программирование требует минимального количества нажатия клавиш.

А что понимается под "... подходящий протокол, предусмотренный вендром камня"?

И вроде всё хорошо и красиво, но на сколько релевантно оценивать ассемблерные листинги скопилированного кода, с заданными в коде значениями? Я к тому, что естественно компилятор все такие значения соптимизирует и на выходе выдаст короткий листинг. Например, первый листинг похож на то, что выдало бы на int main() { printf("tst msg\n"); }

Правда ваша, что в статье нужно было привести пример с рантаймовыми данными.
Исправляюсь: gcc.godbolt.org/z/nhhK64drr
(спойлер: тоже все весьма достойно)

Спасибо!
Ой, сколько ошибок-то у меня в предыдущем комменте =)

Sign up to leave a comment.

Articles