Ремонтируем printf для работы в коде скомпилированном Clang. Реализуем syscalls и ещё немного магии.
Не так давно я писал о том как перешел на Clang/LLVM и Visual Studio Code. Есть ещё один минус ко всему прочему, так как теперь используются либы от gcc не работает printf, запуск которого я описывал в статье "printf в микроконтроллере STM32 и других".
Небольшое описание процесса сборки проекта для микроконтроллера STM32 с помощью clang/llvm.
Казалось бы зачем использовать Clang/LLVM для проектов ориентированных на микроконтроллеры, лучше ли он GCC?
Сразу скажу, здесь это не рассматривается, мы будем учиться использовать, а не разбираться зачем это и почему. Раз уж вы это читаете, значит у вас есть свои причины.
Это даже не руководство, а небольшое описание и собственные ощущения о переходе с Keil'а на VSCode. Здесь нет рассказа от том, как настроить систему сборки, только немного о настройках самого редактора.
Небольшая заметка о том, как я решил отказаться от keil и перешел на visual studio code.
Давно я собирался это сделать, но никак не мог решиться. Больше всего в vscode привлекал удобный редактор с его плюшками, до которого keil'у, да и многим другим IDE расти и расти.
Основной проблемой было то, как настроить сборку, как выполнять загрузку и отладку. "У страха глаза велики" - это правда, на деле всё оказалось куда проще. Даже этот текст, который вы читаете, написан в vscode.
Если стало интересно - читайте дальше.
В предыдущей заметке затронул тему очередей и их использование для передачи информации из одной задачи (или прерывания) в другую. Здесь будет рассмотрен похожий, но немного другой функционал - потоковые буферы.
По сути данная статья будет являть некоторой адаптацией официального мануала расположенного здесь (RTOS Stream Buffers )
Вот что пишут о них:
Потоковые буферы позволяют передавать поток байтов из подпрограммы обработки прерываний в задачу или из одной задачи в другую. Поток байтов может иметь произвольную длину и не обязательно иметь начало или конец. Любое количество байтов может быть записано за один раз, и любое количество байтов может быть прочитано за один раз. Данные передаются путем копирования - данные копируются в буфер отправителем и из буфера считываются.
В отличие от большинства других коммуникационных примитивов FreeRTOS, потоковые буферы оптимизированы для сценариев с одним устройством записи для одного читателя, таких как передача данных из подпрограммы обработки прерываний в задачу или из одного ядра микроконтроллера в другое на двухъядерном ЦП.
Эта короткая заметка будет небольшим мануалом по налаживанию работы таких привычных си программистам функций, как printf, scanf и их модификаций.
Не думаю, сто стоит рассказывать о функциях printf и scanf. Раз читаете эту заметку, то в курсе зачем они, знаете плюсы, и возможно минусы. Обсуждение и того и другого можно расписать на целую статью, я лишь хочу показать как их завести в прошивке для микроконтроллера.
Объектом испытания будет выступать микроконтроллер фирмы STMicroelectronics STM32F205RGT6. Почему не ванильный f103? Всё просто, отладку с ним переделал под 205 чип, да и разрабатываемое устройство базируется на 205 чипе. Хотя это на самом деле и не важно, реализация полностью кросплатформенная.
Как применять показанный ранее кольцевой буфер для приёма и передачи информации по UART (и не только) в тасках RTOS.
Постановка задачи следующая: нужно принять по uart некоторое количество пакетов, линия может быть зашумлена и в паузах могут появлятся фантомные байты (которые передатчик не передавал), отделить пакеты от мусора и выполнить какие-то действия, скорость соединения не большая, допустим 115200.
Статья будет являться небольшой демонтрацией для работы с FreeRTOS и тем кольцевым буфером, о котором я однажды писал. А uart здесь каким боком? А таким, что данная заметка будет еще и небольшим туториалом для одного хорошего человека.
Погнали...