Представляю мою библиотеку компонентов для САПР Altium Designer.
На боковой панеле сайта уже довольно давно присутствует ссылка на мою библиотеку, но видимо мало кто замечает её.
Библиотека содержит множество компонентов и шаблонов для схемного редактора и Drafsman
Предлагаю обратить внимание, попробовать. И если понравиться, то пользоваться, писать пожелания, замечания и всячески критиковать, буду только рад.
В предыдущей заметке затронул тему очередей и их использование для передачи информации из одной задачи (или прерывания) в другую. Здесь будет рассмотрен похожий, но немного другой функционал - потоковые буферы.
По сути данная статья будет являть некоторой адаптацией официального мануала расположенного здесь (RTOS Stream Buffers )
Вот что пишут о них:
Потоковые буферы позволяют передавать поток байтов из подпрограммы обработки прерываний в задачу или из одной задачи в другую. Поток байтов может иметь произвольную длину и не обязательно иметь начало или конец. Любое количество байтов может быть записано за один раз, и любое количество байтов может быть прочитано за один раз. Данные передаются путем копирования - данные копируются в буфер отправителем и из буфера считываются.
В отличие от большинства других коммуникационных примитивов FreeRTOS, потоковые буферы оптимизированы для сценариев с одним устройством записи для одного читателя, таких как передача данных из подпрограммы обработки прерываний в задачу или из одного ядра микроконтроллера в другое на двухъядерном ЦП.
Эта короткая заметка будет небольшим мануалом по налаживанию работы таких привычных си программистам функций, как printf, scanf и их модификаций.
Не думаю, сто стоит рассказывать о функциях printf и scanf. Раз читаете эту заметку, то в курсе зачем они, знаете плюсы, и возможно минусы. Обсуждение и того и другого можно расписать на целую статью, я лишь хочу показать как их завести в прошивке для микроконтроллера.
Объектом испытания будет выступать микроконтроллер фирмы STMicroelectronics STM32F205RGT6. Почему не ванильный f103? Всё просто, отладку с ним переделал под 205 чип, да и разрабатываемое устройство базируется на 205 чипе. Хотя это на самом деле и не важно, реализация полностью кросплатформенная.
Простой мануал по восстановлению прошивки программатора.
Решил сегодня с утра запустить на отладку код, который вчера написал, но вот незадача, keil виснет. Оказалось отвалился программатор.
Долго не думаю выдернул провод, воткнул снова, но ничего не произошло, единственное windows грустно сообщил, что "устройство не опознано". Мало ли что могло случиться, вкрыл корпус, плата чистая, чай/кофе не проливал, разъём хорошо пропаян, аналогично и остальные компонеты.
Быстрый поиск в гугле дал понять что слетела прошивка, что к сожалению не редкость, а может и к счастью, иначе валяться программатору в мусорном ведре.
Статей с полным перечнем всего необходимого не так много, поэтому решил собрать всё здесь, и описать всё максимально коротко, самому что бы не забыть.
Как применять показанный ранее кольцевой буфер для приёма и передачи информации по UART (и не только) в тасках RTOS.
Постановка задачи следующая: нужно принять по uart некоторое количество пакетов, линия может быть зашумлена и в паузах могут появлятся фантомные байты (которые передатчик не передавал), отделить пакеты от мусора и выполнить какие-то действия, скорость соединения не большая, допустим 115200.
Статья будет являться небольшой демонтрацией для работы с FreeRTOS и тем кольцевым буфером, о котором я однажды писал. А uart здесь каким боком? А таким, что данная заметка будет еще и небольшим туториалом для одного хорошего человека.
Погнали...
Небольшая таблица в Exel для быстрого расчета коэффициентов.
Я думаю часто приходилось использовать коэффициенты вроде 0.78, 0.23, 0.87 для корректировки измереных значений АЦП, для последующей обработки, или может где-то ещё, где это значение является константой.
Но что делать если у нас есть требования ко времени выполнения и использовать float кажется слишком дорого?