STM32 ADC Multiple Channels HAL

Ну или подобными вопросами заполнены тематические конференции. И большинство из них без ответов.

Суть проблемы проста: если в STM32CubeMX включить в АЦП один канал, то все работает изумительно. Примеры есть повсюду и код работает стабильно. Но если включить несколько, то все ломается. При вызове HAL_ADC_GetValue на выходе получается «мусор», содержащий случайную выборку с каналов.

Решение: в коде HAL содержится ошибка. В функции HAL_ADC_ConfigChannel индусы заложили такую логику, которая препятствует работе более чем с одним каналом. Согласно ей, перед измерением надо каждый канал конфигурировать с Rank = ADC_RANK_NONE, а затем снова его же конфигурировать, но уже с другим rank.

Если делать по документации, то вместо конфигурирования одного канала происходит конфигурирование всех каналов.

В общем, рассказывать дольше, чем показать код

Контроллер версия 2

У меня уже была версия 1, но недавно с испытаний вернулась более новая и улучшенная версия. Теперь она выглядит так:

Это по-прежнему шилд для Arduino Nano, но функционал немного поменялся.

Во-первых, эта версия умеет «распознавать» на входе сигналы уровнем как 220В, так и 24В. При этом без разницы, постоянное или переменное напряжение. Бонусом добавил световую индикацию состояния входов.

Во-вторых, плата теперь имеет два выхода 0-10В. Мелочь, но это очень приятная мелочь.

И наконец, сделал «закладку» для универсального порта. Это маленькая плата-расширение на снимке снизу

Сам порт с испытаний не вернулся, но если все будет хорошо, он обеспечит вход/выход 0-10В, вход-выход 0-20мА и измерение сопротивлений от 100Ом до 100кОм. Разрабатывался в расчете на «закрытие» всех потребностей обычных автоматизаторов. Или говоря другими словами, для тех кому не нужны защиты в 5кВ, гальванические развязки и прочее. Благодаря этому конечная цена данной версии колеблется в районе 2000 рублей в зависимости от объемов.

Но нет пределов совершенству. Скоро будет 3я версия платы, которая закроет найденные недочеты. Например, можно и нужно выровнять реле. И добавить еще немного индикации. И … в общем, все некритично, но практично.

Кто такие DevOps?

Слово модное…это да!! Но если публиковать как «Системный администратор», то откликаются мальчики-настройщики компов, если «Программист», то жесткие программеры без фантазии © Объяснения одной дамы

Любой, кто интересовался этой темой, знают, что данное сокращение произошло от Development и Operations. Или если перевести на русский – Программисты и Сисадмины. Да, operations дословно переводится не так, но здесь я использую слово «сисадмины» в самом широком смысле.

Кто такие «сисадмины»? Если кратко, то это именно те люди, на руках которых держится вся инфраструктура. Где-то этим словом называют приходящих «аникейщиков», которые меняют картриджи в принтере и изредка чистят компьютеры от вирусов и троянов. А где-то это целые залы людей, разбитых на свои касты. Кто-то занимается сетями, кто-то базами данных, а кто-то обслуживанием датацентров и их инфраструктуры. Титаны антистрессовых методик.

Точно такое же широкое определение имеют и «программисты». И тот, кто пишет на javascript проверку ввода на сайт и тот, кто добавляет код во внутренний модуль корпоративной системы – все они «программисты». И даже тот, кто пишет на встроенном языке 1С, тоже программист, что бы об этом не думали другие.

В чем же основная причина, приведшая к появлению девопсов? Для этого необходимо немного углубиться в специфику работы каждой «секты».

Для сисадмина самое важное это то, что бы вверенная ему система работала без перебоев. Не обращая внимания на тупых пользователей, идиотов-разработчиков, отключения питания и поломок оборудования. Все, абсолютно все, рассматривается с точки зрения надежности. И венцом этой надежности является достижение времени доступности системы в 99,999% (или «5 девяток»). Поверьте, заставить современные системы работать так, чтобы их время недоступности не превышало 5 минут в год – это очень сложная задача. И когда вы добиваетесь, что максимальное время, когда подчиненная система может сказать «ой, я не могу» — это 6 секунд в сутки, то спокойно можете брать с полки пирожок.

У разработчиков же другое положение. Над ними коршунами вьются кровососы-менеджеры, которые постоянно требуют новый функционал, который должен работать быстрее или лучше. И всё это великолепие не должно поломать уже существующий функционал. И код, который прекрасно работает на твоей машине, почему-то отказывается работать как надо даже в тестовом окружении. А еще эти гамадрилы-сисадмины не дают нормально покопаться в получившейся у них системе и понять, что пошло не так даже после успешно пройденных тестов. Эти чудаки на букву «м» постоянно орут как резанные и набрасывают говен на вентилятор при любом чихе. И никто кроме коллег не способен оценить красоты получившегося кода или изящества алгоритма.

А рядом вьются … коллеги из отдела тестирования. Эти вообще постоянно нудят про то, что с говнокодом пора кончать и им опять нужна свежая копия базы данных.

В эту сложную и нервную обстановку добавляет перцу то обстоятельство, что «сисадмины» никогда не писали код размером больше чем на пару страниц, а «разработчики» никогда не обслуживали написанные ими системы (а часто даже и не пользовались ими). Результат абсолютно предсказуемый: тотальное непонимание друг друга и подковёрные войны.

Вот в горниле этих битв и родилось новая каста – DevOps или девопсы. Как водится, поначалу были перегибы с обоих сторон и презрение к «переметнувшимся». Плюс из-за молодости самого термина у него множество толкований и определений. Кто-то считает девопс методологией, направленной на автоматизацию и увеличение числа релизов, а кто-то – на уменьшение ошибок. Я же считаю, что девопс – это прежде всего человек, главной задачей которого является снижение головной боли у программеров, сисадминов и QAшников. А те уже сами напишут, отконфигурят и оттестируют нужное.

Ибо если поглядеть с любой стороны, девопс будет выглядеть как некий недоучка, лишь в редких случаях способный выдать что-то толковое. Бегает со своими скриптами наперевес, чего-то там курочит в коде и лишь принадлежность к «своим» не позволяет его послать в очень далекое эротическое путешествие. У меня нет ни капли сомнения, что программер переиграет девопса в программировании, сисадмин – в администрировании, а тестировщик – на своем тестировочном поле.

Но ценность девопса именно в стоянии нараскоряку в постоянном процессе разрушения стен непонимания между «сейчас зальем, а там разгребут» и «чего там эти опять одноклеточные выделили». Да, сложно, но как показывает практика, вполне возможно.

Сейчас, в самом начале жизни девопсов (с 2009 года же), самой основной их задачей является автоматизация. Объёмы того, что необходимо автоматизировать – поистине ужасающие. Ведь все (программеры и сисадмины) непрерывно трудятся над увеличением завалов не один десяток лет.

Что обычно автоматизируют?
— Развертывание очередного релиза кода. В тест, в стейджинг, в продакшн. Да хоть на машину разработчика. С необходимыми сервисами и данными. Разных версий.
— Обновление. Сервера, сервисы и сайты. Быстро и еще быстрей.
— Управление инфраструктурой. Сегодня 100 серверов в одном датацентре, завтра 500 в трех, а послезавтра 1000 снова в одном. Мониторинг, сбор логов и куча других мелких задач, которые раньше выполнялись вручную или не выполнялись совсем.

Это самые общие задачи. Где-то спектр для автоматизации побольше, а где-то поменьше.

Широкий характер выполняемых задач автоматически формирует и необходимые требования к девопсам:

— Необходимо знать все используемые продукты, языки и технологии. Только тогда стандартная для девопса задача «скрестить ужа с ежом и заставить их летать» автоматически становится выполнимой. Сисадмин сделал бекап? А девопс должен забрать этот бекап, выкинуть из него всякую конфиденциальную информацию и засунуть в систему (которую построил он же), которая позволит разработчикам и тестировщикам без опаски гонять свои творения на «почти продакшене».

— Наличие знаний (есть еще умное слово «компетенций») по всему процессу разработки. Причем знания должны быть реальными и боевыми. Потому что некому кроме девопса остановить программера, когда он решит напрямую засовывать json в обычную базу данных. Для разработчика в этом нет ничего крамольного (база поддерживает? поддерживает!), для сисадмина тоже (ну растет база и требует больше ресурсов – это нормально), а DBA по привычке обматерит всех и молча пойдет строить индексы и партиционировать базу. А то, что полученная конструкция могла быть быстрее и надежней – это никому не интересно. Кроме девопсов.

Нет ни того, ни другого? Тогда получаются люди, которые прекрасно характеризуются как «чуваки с накачанным ЧСВ и недержанием кода».

Требования большие? Да, большие. Зато и награда велика.

Сама возможность пощупать возведенное твоими трудами, а не какого-нибудь сферического коня в вакууме стоит дорого. Причем ощутить весь процесс возведения от «долбанное ничего» до «обалдеть какая няшка». Ни разработчики, ни сисадмины, ни тестировщики такой возможностью не обладают …

P.S. Ну и денег дают нормально.

Контроллер версия 1

Тут можно и подлиннее, чем в фейсбучике.

Как-то раз ко мне пришел заказчик. И захотел он странного для меня: шилд для ардуины. Вернее, первоначально задача была поставлена еще проще: вот есть нцать шилдов, собери их в одну кучу, что бы без проводов. И что бы arduino uno управляла всем этим. После выяснения, где и что будет этим управлять, я немного офигел. Оказывается, в вентиляции и теплоснабжении есть куча мест, которые требуют простого и тупого управления в духе «вон там сигнал появился? Ну и щелкни вот тут». И ничего больше не надо. Вообще.

Но почему-то ничего простого не доступно от слова совсем. Либо дорогущие контроллеры от именитых производителей, либо чуть более доступные, но от наших. Но все равно стоимость получается внушительной.

Поговорили, почесали макушки и ударили по рукам. Я пошел делать, заказчик пошел переводить денег.

Долго ли, коротко, но я сделал первую версию контроллера. 4 входа 220в, 4 переключающих реле, выход 0-10В, и развязанный rs-485. Плюс пара подтянутых выходов для 1-Wire и все это под управлением ардуинки, запрограммированной в fl-prog. Ну и питаться может от 7В до 40В.

photo_2017-02-03_09-44-40

photo_2017-02-03_09-44-33

В общем-то ничего особенного от слова вообще. Обычный навороченный шилд для ардуины и особенного в нем только то, что он у меня первый. Ну не делал я раньше шилдов для ардуинок 🙂

Первым же неприятным фактом стало то, что ардуинка отказывалась прошиваться, когда она стоит в контроллере. Это 100% мой косяк, ибо «сделай как там» привело к тому, что я использовал драйвер rs-485 «как у китайцев». А этот ADM485 при отсутствии сигнала на линии тупо подтягивает линию RX в 1. Ну ладно, прошить можно и вытащив ардуинку из платы.

Второй проблемой стало то, что при «автономной» работе rs-485 не работал. То есть питаешь плату через ардуинку — все ок. Питаешь через внешний источник — rs-485 мертв. Проблема осложнялась тем, что у меня все работало, а у заказчика — нет. На одном и том же коде.

Опуская подробности, оказалось, что в мире существует две версии arduino nano. «Дешевая» версия и «дорогая». Естественно, что «дешевой» версией забиты все магазины Москвы и алиэкспресса. Разница только в одном — чипы мостов usart-usb. На дешевой версии стоит CH340, на дорогой — FTDI.

И этот дешевый CH340 при питании «снаружи» видя, что на входе usb у него ничего нет, тупо подтягивает RX/TX в ноль. А дорогой FTDI — ставит в Z.

Вышли из положения, заиспользовав Software Serial, откусили ножки на самой ардуине и тупо бросили два проводка на плате. То, что у меня заинвертирован RE/DE сигнал, решили ручной правкой кода. Ну не умеет flprog в такое. У них все прямо …

Следующей претензией стало, что «даю 220в, датчик показывает 0, но это ок. Не ок, когда секунд через 40 он переходит в 1, и еще через 40 обратно». Тут я офигел мрачно.

После разбирательств стало понятно, что ардуинка насколько перегружена кодом от flprog, что тупо не успевает реагировать на полуимпульсы от опторазвязки. А в прерывания оно не умеет. Мы взяли 20МГц чип и тормознули его до 50Гц. Ну почти до 50 …

Не, я и там дунул-плюнул и поправил.

И тут оказалось, что вообще-то такие простые контроллеры очень нужны совершенно другим людям. Например, местные любители самогоноварения очень возбудились на характеристики и стоимость контроллера. Настолько, что наплевав на все, отобрали у меня единственный рабочий экземпляр (остальные у заказчика) на тест.

В результате по вечерам я проектирую новую, улучшенную версию контроллера. Для безопасности добавлю опторазвязку вообще на все выходы, ибо пользователи явно его будут совать куда не попадя, наплевав на правила техники безопасности. Будет изолировано все от всего. Люблю ночью спать спокойно.

В качестве главного процессора будет STM32F072. Мощный, умеет программироваться через USB и имеет кучку ножек. А ардуинка … ну дам ей «кроватку». Пусть используют те, кто привык 🙂

Raspberry PI 3 и QT 5.8

Рабочая инструкция. На выполнение требуется примерно 30 часов


sudo apt-get update
sudo apt-get upgrade

sudo apt-get install libfontconfig1-dev libdbus-1-dev libfreetype6-dev libudev-dev libicu-dev libsqlite3-dev libxslt1-dev libssl-dev libasound2-dev libavcodec-dev libavformat-dev libswscale-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev gstreamer-tools gstreamer0.10-plugins-good gstreamer0.10-plugins-bad libraspberrypi-dev libpulse-dev libx11-dev libglib2.0-dev libcups2-dev freetds-dev libsqlite0-dev libpq-dev libiodbc2-dev libmysqlclient-dev firebird-dev libpng12-dev libjpeg9-dev libgst-dev libxext-dev libxcb1 libxcb1-dev libx11-xcb1 libx11-xcb-dev libxcb-keysyms1 libxcb-keysyms1-dev libxcb-image0 libxcb-image0-dev libxcb-shm0 libxcb-shm0-dev libxcb-icccm4 libxcb-icccm4-dev libxcb-sync-dev libxcb-render-util0 libxcb-render-util0-dev libxcb-xfixes0-dev libxrender-dev libxcb-shape0-dev libxcb-randr0-dev libxcb-glx0-dev libxi-dev libdrm-dev libssl-dev

sudo apt-get install libxcb-xinerama0-dev

Install libpng16-16! Default libpng is too old.

mkdir ~/opt
cd ~/opt

git clone git://code.qt.io/qt/qt5.git

cd qt5

./init-repository

./configure -v -opengl es2 -device linux-rasp-pi-g''+ -device-option CROSS_COMPILE=/usr/bin/ -opensource -confirm-license -optimized-qmake -reduce-exports -release -qt-pcre -qt-libpng -make libs -prefix /usr/local/qt5 &> output

make -j4 &> output_make

sudo make install &> output_make_install

pi@raspberrypi:~ $ cat >> .bashrc
export LD_LIBRARY_PATH=/usr/local/qt5/lib/
export PATH=/usr/local/qt5/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
pi@raspberrypi:~ $ source .bashrc

Вторая альфа-версия книги

Screenshot 2016-05-09 15.30.19

https://multik.org/stm32book/stm32book.pdf

Наконец-то добрал материала еще на десять готовых страниц. И еще на сотню лежит в «запасниках» и ждет своего часа.

Альфа-версия книги

Для предварительной оценки заинтересованными решил выложить начало книги. Да и праздник сегодня, в конце-то концов.

Книга

Исходники

Любые комментарии лучше отправлять мне на почту: multik@multik.org или в скайп kiltum

Решил написать книгу …

… про реальную разработку устройств на stm32. Поэтому думаю обновления если и будут, то нерегулярным и в основном в виде кусочков из книги. Ну прёт меня пока.

Что бы не было скучно, вот вам малюсенький кусочек, можно сказать бета-версия про кварцевые резонаторы и вообще частоты.

Программируем микроконтроллеры в QtCreator

Это копия моей статьи, опубликованной на хабре

qbs03
Почему-то в интернете мало документации про qbs, пора немного исправить эту ситуацию.

Как-то у меня сложилось так, что практически исчезли проекты, в которых надо сделать что-то одно. Обычно надо и написать прошивку для микроконтроллера и управляющую программу для смартфона или десктопа. Можно делать все по старинке: писать код для каждого устройства в родной для него среде разработки.

Но поверьте, это довольно быстро задалбывает. Под виндовс — MSVC, под ARM — CooCox или Keil (приношу свои соболезнования вынужденным работать под IAR), под MSP — CCS, под андроид — eclipse, под ios — Xcode, под пики — MPLAB. И ладно бы, со всем этим работать можно было бы, но ведь фиг: везде свои заморочки, тонкости и неписанные правила. Все это накладывается на общую тормознутость так популярного эклипса помноженную на криворукие дополнения от производителей.

Некоторое время назад я начал сводить все свои разработки под мобильные и десктопные приложения под одну платформу. После довольно долгого чеса по интернетикам мой выбор остановился на Qt. Есть все, что надо, при необходимости можно подцепить нативный код. В общем, задача закрылась.

Но вот с микроконтроллерами ситуация не желала складываться категорически. В основном из-за того, что везде свои хотелки и желалки. Ну ладно, про это я уже жаловался. Я бы еще долго мучался, пока внезапно не наткнулся на краткое описание qbs.

Желающие могут пошариться по инету сами, но если кратко, то это заменитель всяких make и cmake, использующая нормальный (тут должен быть смаил) язык программирования. И сам QtCreator собирается с ее помощью, значит она уже вылезла из штанишек …

Да, документации по ней как обычно кот наплакал, но исходники еще никто не отменял, поэтому довольно быстро ко мне пришло понимание, что это практически то, что я искал. Посудите сами: сидишь в одной среде разработки (самой по себе очень приятной и быстрой) и спокойно пишешь и редактируешь файлы под несколько платформ. И тебе, как кодописателю, пофиг на наличие всяких там заморочек с «родными» средами.

Хватит излияний, пора попробовать. Создадим очень простой проект, в котором у нас будет десктопная и микроконтроллерная составляющая.

Открываем QtCreator, выбираем создать Non-Qt Project (что бы пока не заморачиваться сильно) и далее выбираем то, где присутствует C и Qbs. Обратите внимание на приятные взгляду слова Platform independent

qbs01

В результате получаем один main.c и qbs. Можно уже нажать «build» и получить вывод Hello World.

Открываем qbs и ничего не понимаем. Поэтому все стираем, вооружаемся интернетом и начинаем писать. Яваскрипт и все такое.

import qbs

Так, тут вроде понятно. Импортируем всякое необходимое для работы самого qbs.

Project {
name: "simple"
}

Сохраняем и наблюдаем исчезновение main.c с левой панели. При попытке запустить проект QtCreator спросит: а чего пускать-то? В принципе пока все логично.

Из чего состоит проект в терминологии qbs? Из продуктов. И их может быть несколько, но пока я сделаю один.

Project {
name: "simple"
Product {
name: "desktop"
}
}

Теперь для нашего «десктопного» укажем исходник.

Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
}
}

При попытке скомпилировать не изменится ровным счетом ничего. Подсмотрим в некоторые обучалки и добавим зависимость от cpp и укажем, что вообще-то это приложение.

Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
Depends {name: "cpp"}
type: "application"
}
}

И вот теперь при попытке собрать приложение QtCreator пошуршит немного диском и в панельке Application Output появится искомое

qbs02

Ага, значит мы на верном пути. Осталось разобраться, что делают те самые две магические строки.

Depends {name: "cpp"}

Читаю документацию и понимаю, что данной командой я устанавливаю зависимость проекта от какого-то модуля с именем cpp. Понятней стало? Мне нет.

Простым поиском нахожу что-то подобное в /usr/share/qtcreator/qbs/share/qbs/modules/ (Если у вас другая операционка, то скорее всего аналогичное лежит где-то неподалеку от QtCreator). Если говорить коротко, то там куча яваскрипта, которая в зависимости от платформы подбирает компилятор под эту платформу. Полностью повторять подобное мне смысла нет, поэтому оставляю как есть.

type: "application". Из документации: The file tags matching the product’s target artifacts. Артефакт … An Artifact represents a single file produced by a Rule or Transformer. … ерр .. Rule? Creates transformers for input tags. Напоминает ситуацию про сепулькарий .. Transformer? Creates files, typically from other files.

Ползаю по доступному и понимаю, что примерно это некий набор правил, который говорит системе сборки, как надо собирать скомпилированное. Ну грубо говоря, на выходе надо получить приложение, библиотечку или вообще что-то иное. Опять же, хоть и стало немного понятней, но ненамного. Опять пока примем за данность.

Но вернемся к нашему проекту. Давайте добавим еще один продукт, только уже для микроконтроллера

Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
Depends {name: "cpp"}
type: "application"
}
Product {
name: "micro"
files: "blink.c"
}
}

При попытке что-то сделать, нам сразу выскочит сообщение, что вообще-то файла blink.c нет. Ну, ок, добавим в проект фаил blink.c. Как видно из названия, это тот же HelloWorld, только для микроконтроллеров. Я взял из примеров для микроконтроллера семейства msp430.

#include <msp430.h>

int main(void)
{
WDTCTL = WDTPW + WDTHOLD;
P1DIR |= 0x01;

while (1) {
P1OUT ^= 0x01;
__delay_cycles(1000000); // 1 second @ 1MHz
}

return 0;
}

Будучи скомпилированным и залитым, он начнет дергать ножкой P1.0 с интервалом в одну секунду. А так как на этой ножке у большинства демо- и девелоперских плат висит светодиодик, то он замигает.

Теперь QtCreator не ругается, но и в микроконтроллер ничего не заливается. Странно, да?

Добавлять Depends {name: «cpp»} смысла нет, потому что установленный в системе родной gcc не в курсе про существование такой платформы, да и в дальнейшем пригодится, например для пиковских контроллеров, где вообще все свое.

Теперь воспользуемся обрывками тех сакральных буковок, что встретились раньше.

Для начала, я предпочитаю в микроконтроллерных проектах расписывать каждый функционал в своем файле. Записывать каждый файл руками? Лень. Подсматриваем решение и переписываем блок

Product {
name: "micro"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
}

Тут создаем группу файлов, которые обзываем «msp430 sources» и тупо включаем в нее все файлы, которые подходят под маску src/*.c. Для дальнейшей работы с ними тегируем их буквой С.

Что с ними делать? У qbs есть на этот случай две штуки — Rule и Transformer. По сути они близки, но немного разные. Счас попробую описать на пальцах разницу.

Rule умеет срабатывать на каждый файл, попадающий под что-то. Может срабатывать по разу на каждый фаил (например, для вызова компилятора), а может один раз на все (линкер).

Transformer предназначен для срабатывания только на один фаил, с заранее определенным именем. Например, прошивальщик или какой-нибудь хитрый скрипт.

Ок, добавляем правило, которое должно будет сработать на все наши файлы, промаркированные как «с».

Product {
name: "micro"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
Rule {
inputs: ["c"]
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "file passing"
cmd.silent = false;
cmd.highlight = "compiler";
cmd.sourceCode = function() {
print("Nothing to do");
};
return cmd;
}
}
}

В принципе из синтаксиса уже все понятно. Есть inputs, есть prepare, в который засовывается яваскрипт, который выполняет необходимое. В данном случае он должен в окошке Compile Output показать file passing, и куда-то вывести Nothing to do. Ну по документации вроде так.

Запускаем перекомпиляцию всего и смотрим. Не знаю, как у вас, но я ничего не вижу. Почему? Потому что qbs больно умный, а документация к нему страдает лакунами.

Правило не срабатывает, потому что qbs считает, что оно не производит никаких действий в системе и от него ничего не зависит. В принципе это соответвует реальности, но провести проверку мешает.

Ок, за это отвечают те самые артефакты. Под ними подразумеваются результаты деятельности Rule или Transformer. Лучше всего это объяснить на примере компиляции. Когда мы компилируем .с файл, то на выходе мы получим объектный файл .о. Он нам нужен для дальнейшей линковки, но с другой стороны, мы его можем удалить, так как потом спокойно сможем сгенерировать заново.

Опять копируем пример из документации и чуть-чуть модернизируем.

Rule {
inputs: ["c"]
Artifact {
fileTags: ['obj']
filePath: '.obj/' + qbs.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "Compiling "+ input.fileName
cmd.silent = false;
cmd.highlight = "compiler";
cmd.sourceCode = function() {
print("Nothing to do");
};
return cmd;
}
}

Теперь мы говорим, что после нашей деятельности останутся артефакты в каталоге .obj (ну и я добавил вывод того, над каким файлом мы сейчас работаем). Запускаем. Опять ничего в ответ. Почему? Ответ тот же — никому не нужны файлы с тегом ‘obj’.

Хорошо, для проверки сделаем так, что они нужны нам. И вообще, наше приложение — это один сплошной obj.

Product {
name: "micro"
type: "obj"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
Rule {
inputs: ["c"]
Artifact {
fileTags: ['obj']
filePath: '.obj/' + qbs.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "Compiling "+ input.fileName
cmd.silent = false;
cmd.highlight = "compiler";
cmd.sourceCode = function() {
print("Nothing to do");
};
return cmd;
}
}
}

Пробуем, и удача! В окошке появился заветный «Compiling blink.c». Теперь давайте добавим, что бы оно реально компилировало и сразу по-быдлокодерски, то есть тупо забив все необходимое в одну кучу.

prepare: {
var args = [];
args.push("-mmcu=cc430f5137")
args.push("-g")
args.push("-Os")
args.push("-Wall")
args.push("-Wunused")
args.push('-c');
args.push(input.filePath);
args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'compiling ' + input.fileName;
cmd.highlight = 'compiler';
return cmd;
}

Перекомпилируем все с нуля и смотрим в каталог .obj

$ ls -R1
.:
f27fede2220bcd32

./f27fede2220bcd32:
blink.c.o

Ура! Файлик появился. Теперь, для проверки я делаю еще один файлик, с хитрым названием hz.с. Если я прав, то после перекомпиляции рядом появится еще один объектный файл.

В выводе появилось

compiling blink.c
compiling hz.c

а в каталоге

./f27fede2220bcd32:
blink.c.o
hz.c.o

Все вроде ок. Теперь необходимо все это дело слинковать. А значит опять правило, только теперь для линковки.

Rule {
multiplex: true
inputs: ['obj']
Artifact {
fileTags: ['elf']
filePath: project.name + '.elf'
}
prepare: {
var args = [];
args.push("-mmcu=cc430f5137")

for (i in inputs["obj"])
args.push(inputs["obj"][i].filePath);

args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'linking ' + project.name;
cmd.highlight = 'linker';
return cmd;
}
}

Где отличия? Во-первых, добавился флаг multiplex, который говорит о том, что это правило обрабатывает сразу все файлы данного типа скопом. А во-вторых, во входных параметрах исчез input. Появился inputs, который является массивом файлов данного типа. Ну и я вопользовался именем продукта, что бы брать имя для финальной прошивки.

Ставим тип приложения elf и пробуем собрать. Через некотрое время мы в каталоге для сборки обнаружим файл simple.elf

$ file simple.elf
simple.elf: ELF 32-bit LSB executable, TI msp430, version 1, statically linked, not stripped

То, что нам и необходимо. Его можно уже заливать в плату и наслаждаться мигающим светодиодиком.

Исходная цель достигнута: мы в одной среде разработки делаем все: и редактирование и компиляцию.

На всякий случай конечный qbs

import qbs
Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
Depends {name: "cpp"}
type: "application"
}
Product {
name: "micro"
type: "elf"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
Rule {
inputs: ["c"]
Artifact {
fileTags: ['obj']
filePath: '.obj/' + qbs.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var args = [];
args.push("-mmcu=cc430f5137")
args.push("-g")
args.push("-Os")
args.push("-Wall")
args.push("-Wunused")
args.push('-c');
args.push(input.filePath);
args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'compiling ' + input.fileName;
cmd.highlight = 'compiler';
return cmd;
}
}
Rule {
multiplex: true
inputs: ['obj']
Artifact {
fileTags: ['elf']
filePath: project.name + '.elf'
}
prepare: {
var args = [];
args.push("-mmcu=cc430f5137")

for (i in inputs["obj"])
args.push(inputs["obj"][i].filePath);

args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'linking ' + project.name;
cmd.highlight = 'linker';
return cmd;
}
}
}
}

PS Вынос «захардкоденных» переменных в более удобное место оставлю на вашей совести, ибо это уже к обучалке по яваскрипту.

MSP430 и Fedora Linux

В принципе, в программировании микроконтроллеров под Linux нет ничего сложного. Более-менее доступны средства разработки, а некоторые производители и вовсе официально поддерживают Linux как среду разработки.

TI тоже имеет свою фирменную среду, но она … скажем так, для хардкорных железячников. Старый, тормознутый эклипс и какие-то невнятные настройки. Залитие прошивки и ее отладка тоже доставляют много удовольствия привыкшим к нормальным средам.

В общем, долой разврат — будем делать все по-правильному, что бы программирование доставляло удовльствие, а не требовало героического преодоления трудностей.

Расписывать я буду под Fedora Linux (21), потому что я сейчас под ней. Под другие дистрибутивы инструкций как-то больше.

В чем проблема с федорой? Ведь они кровь и плоть от редхата, а тот официально поддерживает msp430-gcc, который использует и сама TI. Проблема в том, что это федора, а значит в ней все нестабильное и вообще может не работать.

И с MSP430 случилось ЭТО. В 20й версии он работал, а в 21й — уже нет. Подробнее можно посмотреть тут. Если кратко, то в федоре сломали линкер.

Что делать? Есть несколько вариантов, из которых самый простой это взять старую версию компилятора из CCS или Energia. Но добрый Brandon Nielsen решил эту проблему по-другому: просто сделал репозиторий со правильными версиями.

Открываем рутовую консоль и подключаем нужный репозитарий

dnf copr enable nielsenb/msp430-development-tools

И ставим все необходимое, соглашаясь с тем, что никто ни за что не отвечает.

yum install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files dos2unix srecord

Теперь скопипастим Makefile
#
# Makefile for msp430
#
# 'make' builds everything
# 'make clean' deletes everything except source files and Makefile
# 'make install' builds everything, and programs the MSP430 using MSPFLASHER
# You need to set TARGET, MCU and SOURCES for your project.
# TARGET is the name of the executable file to be produced
# $(TARGET).elf $(TARGET).hex and $(TARGET).txt nad $(TARGET).map are all generated.
# The TXT file is used for BSL loading, the ELF can be used for JTAG use
#
TARGET = project0
MCU = msp430f5529
# MSP430Flasher name
MSPFLASHER = MSP430Flasher
# List all the source files here
# eg if you have a source file foo.c then list it here
SOURCES = main.c delay.c
# Include are located in the Include directory
INCLUDES = -IInclude
# Add or subtract whatever MSPGCC flags you want. There are plenty more
#######################################################################################
CFLAGS = -mmcu=$(MCU) -g -Os -Wall -Wunused $(INCLUDES)
ASFLAGS = -mmcu=$(MCU) -x assembler-with-cpp -Wa,-gstabs
LDFLAGS = -mmcu=$(MCU) -Wl,-Map=$(TARGET).map
########################################################################################
CC = msp430-elf-gcc
LD = msp430-elf-ld
AR = msp430-elf-ar
AS = msp430-elf-gcc
NM = msp430-elf-nm
OBJCOPY = msp430-elf-objcopy
RANLIB = msp430-elf-ranlib
STRIP = msp430-elf-strip
SIZE = msp430-elf-size
READELF = msp430-elf-readelf
MAKETXT = srec_cat
CP = cp -p
RM = rm -f
MV = mv
########################################################################################
# the file which will include dependencies
DEPEND = $(SOURCES:.c=.d)
# all the object files
OBJECTS = $(SOURCES:.c=.o)
all: $(TARGET).elf $(TARGET).hex $(TARGET).txt
$(TARGET).elf: $(OBJECTS)
echo "Linking $@"
$(CC) $(OBJECTS) $(LDFLAGS) $(LIBS) -o $@
echo
echo ">>>> Size of Firmware <<<<" $(SIZE) $(TARGET).elf echo %.hex: %.elf $(OBJCOPY) -O ihex $< $@ %.txt: %.hex $(MAKETXT) -O $@ -TITXT $< -I unix2dos $(TARGET).txt # The above line is required for the DOS based TI BSL tool to be able to read the txt file generated from linux/unix systems. %.o: %.c echo "Compiling $<" $(CC) -c $(CFLAGS) -o $@ $< # rule for making assembler source listing, to see the code %.lst: %.c $(CC) -c $(ASFLAGS) -Wa,-anlhd $< > $@
# include the dependencies unless we're going to clean, then forget about them.
ifneq ($(MAKECMDGOALS), clean)
-include $(DEPEND)
endif
# dependencies file
# includes also considered, since some of these are our own
# (otherwise use -MM instead of -M)
%.d: %.c
echo "Generating dependencies $@ from $<" $(CC) -M ${CFLAGS} $< >$@
.SILENT:
.PHONY: clean
clean:
-$(RM) $(OBJECTS)
-$(RM) $(TARGET).*
-$(RM) $(SOURCES:.c=.lst)
-$(RM) $(DEPEND)
install: $(TARGET).txt
$(MSPFLASHER) -n $(MCU) -w "$(TARGET).txt" -v -z [VCC]

Если при попытке компиляции Вы получите

Makefile:48: *** missing separator. Stop.

то это означает лишь то, что вы нарвались на tab-hell. Все отступы выше — это не пробелы, а символы табуляции. Если отвлечься и открыть этот фаил в mc, то вы должны увидеть следующее:

mc_tab

Обратите внимание на символы «<---->» — именно ими mc показывает табуляцию. Поправьте где надо.

Теперь осталось поправить параметры MCU под мой процессор и SOURCES под мой проект и запустить make. Если все сделано правильно, то вы должны увидеть побежавшие строки, завершающиеся чем-то похожим.

Linking blink.elf

>>>> Size of Firmware <<<< text data bss dec hex filename 2906 214 152 3272 cc8 blink.elf unix2dos: converting file blink.txt to DOS format...

Если оно так, то можете себя поздравить. Теперь можно развиваться дальше.

PS С автором, чьи наработки я использовал, можно познакомиться тут

Дисплеи 4D …

… или не ходите дети в Австралию гулять.

Есть в далекой загранице такая компания — 4D Systems. Основной продукт — «интеллектуальные дисплеи». По роду деятельности я с ними очень глубоко познакомился, так что устриц ел.

Задумка совершенно шикарная. Купив такую штуку, разработчик получает полностью готовый блок, где есть дисплей с тачскрином и в который можно загрузить программу, воткнуть микро-sd карточку и подцепить какие-то внешние датчики или устройства.

Причем последние версии дисплеев отличаются только разрешением или формой (да, у них есть круглые дисплеи) — все остальное у них одинаково.

Как заведено в «корпративном» мире, к этим дисплеям полагается софт для их программирования. Софт работает только под Windows и может загонять дисплеи в три режима работы.

1. Режим тупого usart терминала. Цепляем к дисплею любой внешний микроконтроллер через совершенно стандартный usart и отправляете в дисплей команды в духе «нарисуй точку», «смонтируй флешку», «покажи картинку с флешки». Работает очень медленно.

2. Написание «визуальных программ». Есть библиотечка страшненьких контролов, из которых делаются экраны, а потом в специально отведенные места записывается код. Что-то сложное написать невозможно.

3. «Полноценный». Можно писать программы на 4DL — некой смеси паскаля и си.

Плюс прямо в IDE встроено немного утилиток типа калибровки экрана, разметки microsd карточек и терминалки. В принципе штуки полезные в плане «все свое ношу с собой».

В общем, почти счастье любого программиста встраиваемых систем. Но как обычно, все портит реализация.

Начинается всё с редактора. Эта штука абсолютно не умеет форматировать код. Ни работы с блоками, ни нормального свертывания. Зато раздражающие комментарии — в полном объеме. Короче, этакий notepad с подсветкой. Результат — очень страшно выглядящий код.

Компилятор тоже доставляет немного удовольствия: иногда программа компилируется, но отказывается заливаться в дисплей. Добавляем где-нибудь в незначащем месте лишний пробел или что-нибудь типа i:=i; и все прекрасно компилируется и заливается. Еще больше доставляют ошибки, когда программа на дисплее просто падает на ровном месте, которое в прошлые разы не вызывало никаких нареканий. Лечится точно так же: либо лишние команды, либо просто поменять что-нибудь местами.

«Исполнятор» тоже не свободен от греха: например, если вы «примонтировали» с microsd файловую систему и с нее только читаете, то при падении программы вы с 50% вероятностью получите «убитую» флешку, которую надо снова форматировать.

Да, и большие microsd не поддерживаются. Если вам удалось найти карточку на 2Гб, то вам повезло. Если у вас больше — то будьте добры сделать раздел на 2Гб, а про остальное — забудьте.

Где еще проблемы? Перечислю кратко:

— Ошибки в документации. Неправильные аргументы, неправильные примеры, код скопипащен из примера для другой функции.
— Программисту не дают доступа ни к прерываниям, ни к какой-либо многозадачности. Вообще. Делай большой цикл на все и молись, что бы стек не переполнился.
— Сильно грузить порты ввода-вывода нельзя. Например, если включить проигрывание wav-ки с карточки и побежать исполнять код дальше, то вместо «чистого» звука услышишь его же с треском. Начнешь много и часто читать с карточки — получишь мешанину байт вместо ожидаемого. Рисуешь картинку — будь готов к потерям байт в последовательном порту.
— Отладчика нет. Вообще ни в каком виде. Отладочный вывод? Ну можно писать в usart, если он не занят. Но проще тупо на экран.

После всего этого проблемы вида «есть возможность загрузить шрифты, но нет ни описания формата, ни редактора для них» кажутся такими пустяками …

Но с другой стороны, если вы достаточно сильны духом, то за $185 долларов (сама дорогая модель) вы получите готовую уберштуку, в которой 7″ дисплей (800х480), маленький динамик и слот для карточек. Попутно будет доступно нцать выводов, на которые можно повесить всякие енкодеры, пзушки (внутри хоть и есть флеш, но писать не дают) и прочие штуковины. И после кучки оптимизаций все это будет крутиться довольно быстро и не раздражать пользователя.

В этой реальности я бы посоветовал найти отдельно 7″ дисплей и какой-нибудь контроллер. Будет и дешевле и быстрее и удобней.

Как-то так 🙂

STM32 и FreeRTOS. 5. Приносим пользу и добро!

Как-то раз попросили меня посмотреть на одно очень дорогостоящее устройство. Проблема была одна: среди использующих это устройство возникло стойкое убеждение, что 99,99% его цены происходит от того факта, что производитель этого устройства монополист в своей сфере и деваться пользователям этого устройства некуда.

Вооружившись осциллографом, я полез внутрь.

Через некоторое время поиски привели к двум проводкам, которые были в жгуте, соединявшем блоки устройства. Осциллограмма показала, что в проводках почти обычный USART. Почти — потому что «туда» данные бежали на скорости 9600, а обратно на 115200.

Продолжение тут

STM32 и FreeRTOS. 4. Шаг в сторону HAL

Одним из основных препятствий для перехода на STM32 является обилие текстов, инструкций и мануалов, описывающих работу с контроллером. Виновником этого обилия стала сама STMicroelectronics, которая поначалу планомерно запутывала своих пользователей, а затем предлагала неверные варианты выхода.

Проблема заключается в многообразии выпускаемых контроллеров, которые почему-то требовали разных процедур инициализации даже для одной и той же периферии. И код, работающий на одном контроллере, отказывался работать на другом. В результате по сети гуляют сборники шаманских рецептов, для понимания которых требуется куча времени и воскуривание даташитов.

Но не так давно ST поняла, в какую яму она угодила и начала усиленно из нее выбираться, привлекая новые силы. И именно благодаря этому сейчас время старта сократилось до несуразно маленьких величин. Как это выглядит на практике?

Статья на хабре

Еще один способ отъема денег у …

… бедных программистов с помощью компилятора.

Маленькая программка на С.

Внутри код

uint8_t i[]="123456789012345678901234567890";

Или +30 байт.

Результат:

Program space used F9h ( 249) of 2000h words ( 3.0%)
Data space used 49h ( 73) of 200h bytes ( 14.3%)

А теперь добавим const перед i, показывая компилятору, что неплохо бы переменную перенести в «программную» часть.

Program space used D9h ( 217) of 2000h words ( 2.6%)
Data space used Bh ( 11) of 200h bytes ( 2.1%)

Хм. 249-217=32 байт освободили в программной части и 73-11=62 (!) байта в области данных

Говоря другими словами, родной компилятор XC8, если не сказать другого, при любом использовании переменной хранит 2 копии переменной в программной памяти и 2 копии в области данных. Сказать, что я офигел мрачно, значит ничего не сказать.

После этого становится понятно, откуда компилятор берет ресурсы для оптимизации и гордо сообщает при любом удобном случае Running this compiler in PRO mode, with Omniscient Code Generation enabled, produces code which is typically 40% smaller than in Free mode.

(Чуть позже) решил перепроверить, а то вдруг всякие библиотеки/типа навязались

Сделал пустой проект с одним файлом для PIC16F1503.

void main(void) {
char i[30]="123456789012345678901234567890";
int q;
q=i[2];
}

Ничего больше, ни инклюдов, ни библиотек, ни инициализаций.

Program space used 4Ah ( 74) of 800h words ( 3.6%)
Data space used 42h ( 66) of 80h bytes ( 51.6%)

добавляем const

Program space used 2Fh ( 47) of 800h words ( 2.3%)
Data space used 6h ( 6) of 80h bytes ( 4.7%)

Хорошие, добрые и отзывчивые люди!

STM32 и FreeRTOS. 3. Очереди

Это черновая версия, финальная опубликована на хабре

«Вас много, а я одна!» — классическая фраза продавщицы, которую затерроризировали покупатели с вопросами «А есть …?». Вот и в микроконтроллерах случаются полностью аналогичные ситуации, когда несколько потоков требуют внимания от какой-либо медленной штуки, которая просто физически не способна обслужить всех разом.

Возьмем наиболее яркий и богатый проблемами пример, на котором «валятся» большинство неопытных программистов. Есть мощный и достаточно быстрый микроконтроллер. К нему подключен с одной стороны адаптер com-порта, через который пользователь подает команды и получает результаты, а с другой — шаговый двигатель, который согласно этим командам поворачивается на какой-то угол. И конечно же, прикольная кнопочка, которая тоже что-то этакое значит для пользователя. Где можно наловить проблем?

Пойдем со стороны пользователя. Com-порт, или USART (universal asynchronous receiver/transmitter) — штука очень нежная и капризная. Основной каприз заключается в том, что ее нельзя оставлять без внимания. По одной простой причине — для экономии выводов в 99% случаев выводят только сигналы приема и передачи, оставляя сигналы разрешения приема и передачи за бортом. И стоит микропроцессору хоть чуть-чуть замешкаться, как символ будет потерян. Судите сами: магические цифры 9600/8N1 говорят нам, что в секунду по линии летит 9600 бод, а один символ кодируется 9 импульсами. В итоге максимальная скорость передачи составляет 9600/9 = 1066 байт в секунду. Или чуть меньше одной миллисекунды на байт. А если по ТЗ скорость передачи 115200? Там может прилететь 128 байт за миллисекунду. А ведь микроконтроллеру надо еще обработать эти данные. Кажется, что все плохо, но в реальности куча устройств работает и не доставляет проблем. Какие же решения применяются?

Cамым распространенным (и правильным) решением является перекладка всей работы по приему или передаче символов на плечи микроконтроллера. Делать аппаратный usart порт научились сейчас все, поэтому типовое решение в большинстве случаев выглядит вот так:

void URARTInterrupt()
{
a=GetCharFromUSART();
if(a!=0x13)
buffer[count++]=a;
else
startProcessing();
}

Где проблема? Во-первых, проблема в вызове startProcessing. Стоит ей хоть чуть-чуть задержаться с работой, как очередной символ будет потерян. STM32L1 на минимальной частоте успевает за 1мс обработать 84 команды. В итоге при более-менее развесистой логике полученная конструкция будет терять символы.

После дружеского похлопывания по голове у нас в студии программист переписывает код так, что бы вместо вызова startProcessing поднимался семафор, который и запускал бы обработку полученных данных. И тут же получил следующую проблему в полный рост: пока startProcessing что-то там перемалывает из буфера, обработчик прерывания по получению нового символа начинает планомерно затирать еще не обработанный буфер. После очередного разорванного свитера и скуренной книжки по буферам программист реализует кольцевой буфер с указателями, чем закапывает проблему еще глубже.

Обычно где-то на этом месте я замечаю удивленные глаза народа и возмущенные выкрики в духе «ну такие алгоритмы же работают в куче проектов и ничего, никаких проблем». Да, работают. Но в каких проектах? Только в тех, где можно все общение с контроллером перевести на синхронную логику. Вот пример диалога пользователя (П) и контроллера (К)

П: ATZ (Контроллер, ты живой?)
К: ОК (Ага, я тут)
П: М340,1 (Сделай чего-то)
(тут может быть пауза, иногда очень большая)
К: ОК (Сделал типа)

Где проблемы? Во-первых, нельзя послать несколько команд подряд. Значит либо надо будет менять логику или делать сложные команды с несколькими параметрами. Во-вторых, между запросом и ответом не может быть никаких других запросов и ответов. А вдруг пользователь в процессе движения нажмет кнопку? Что делать? Выход только один — использовать родную природу порта, а именно его асинхронность. В результате диалог между пользователем и контроллером выглядит примерно так

П: ATZ (жив?)
К: ОК (ага)
П: M340,1
К: К1=1 (кнопку нажали)
П: Е333,25,2
(тишина)
К: Е=1 (задачу Е выполнил)
К: М=1 (задачу М выполнил)

Конечно, логика обработки подобного потока немного усложняется, зато благодаря такой асинхронности мы сразу получаем множество преимуществ перед «классической школой».

Во-первых, резко повышается отзывчивость интерфейса с пользователем. Ну работает там где-то моторчик или считается что-то, но это же не повод «замирать» или «тормозить». А когда пользователь понимает, что величина тормозов практически не зависит от мощности контроллера, у него возникают резонные вопросы …
Во-вторых, легко реализовать совместное управление. Скажем, у меня на плате 8 выводов. Легко можно сделать так, что бы первые 3 управлялись через USART1, вторые 3 через USB-CDC, а последние два — совместно. И все это на одном контроллере.
И наконец, очень легко отвязать логику от аппаратного интерфейса. Нам все равно, откуда приходят команды — от соседнего процесса, от пользователя или вообще от другого контроллера.

А теперь со всеми этими задумками взглянем на противоположную сторону — на сторону исполнителя. Он достаточно медлителен, что бы попросту не успеть обработать команды по порядку. И время запуска-остановки моторчика очень большое, поэтому хорошо бы сделать примитивную оптимизацию в духе «если поступило две команды на поворот в одну сторону, то поверни за раз».

Что делает обычный программист? Так как он прочитал предыдущие статьи и кучку книжек, то он рисует логику расставляя семафоры по необходимости, а для блокирования одновременного доступа к моторчику использует мутексы. Все хорошо, но код получается громоздкий и тяжело читаемый. Что делать? У нас в studiovsemoe.com мы используем рецепт Шарикова: «В очередь, сукины дети! В очередь!»

В данном примере можно просто создать три очереди. Первая это команды, полученные от пользователя. В нее засовывается все (ну или после минимальной проверки), что принято со всех входных портов. Вторая это те данные, которые необходимо выдать пользователю. Состояние кнопок, результаты расчетов и так далее. И наконец, третья очередь служит для заданий моторчику/считалке.

Все, всего три очереди, а дикая куча проблем решена. Во-первых, нет даже потенциальной проблемы потери или переписи буфера принятых символов. Правда результатом станет чуть больший расход памяти, но это допустимая цена. Во-вторых, нет проблем с выводом. Все процессы просто пишут в одну очередь, а как выводить, в каком формате и прочее — это уже не их забота. А значит упрощается код и понижается стоимость разработки и поддержки. И наконец благодаря такому подходу задачи очень легко разделить на более мелкие и раскидать их по потокам/ядрам микропроцессора.

Что бы не отходить от практики мигания светодиодами, сделаю следующую демонстрацию: создам очередь, из которой раз в секунду будет забираться элемент (имитация обсчета). По нажатию кнопки два раза в секунду в очередь будет помещаться элемент (управляющие команды). Ну а светодиодики будут показывать загруженность очереди. Опять же, предупреждаю что код для повышения читаемости написан без обработки ошибок, поэтому аккуратней.

Где-то в начале кода определим очередь

xQueueHandle q;

Код светодиодов поменяем по принципу «в очереди больше Н элементов? зажигаем, если нет, то нет»

if(uxQueueMessagesWaiting(q)>1)
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_9,GPIO_PIN_SET);
else
НAL_GPIO_WritePin(GPIOE,GPIO_PIN_9,GPIO_PIN_RESET);
osDelay(100);

Перед запуском планировщика проинициализируем очередь так, что бы она могла хранить 8 байт.

q = xQueueCreate( 8, sizeof( unsigned char ) );

Ну и код кнопки для помещения символов в очередь

if(HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_0)==GPIO_PIN_SET)
{
unsigned char toSend;
xQueueSend( q, ( void * ) &toSend, portMAX_DELAY );
}
osDelay(500);

Чего не хватает? Воркера, который забирает из очереди задания. Пишем.

static void WorkThread(void const * argument)
{
for(;;)
{
unsigned char rec;
xQueueReceive( q, &( rec ), portMAX_DELAY );
osDelay(1000);
}
}

Как видите, все параметры аналогичны тем, что используются в семафорах. Результат проще показать.

Как обычно, использующийся код доступен по адресу http://kaloshin.ru/stm32/freertos/stage3.rar

STM32 и FreeRTOS. 2. Семафорим.

Это черновая версия, финальная опубликована на хабре

В реальной жизни часто случается так, что некоторые события происходят с разной переодичностью. Скажем, заказ сока в «Макдональдсе», нажатие кнопки пользователем или заказ лыж в прокате. А наш могучий микроконтроллер должен все это обрабатывать. Но как это сделать наиболее удобно?

Рассмотрим процесс заказа сока в макдаке. Покупатель говорит «хочу сок», один продавец пробивает стоимость в чек, а другой смотрит в экранчик и идет наливать сок. Налил, принес и опять смотрит в экранчик, чего надо принести. И так продолжается до бесконечности или до конца смены. Мы заменяем человеческий труд машинным, поэтому автоматизируем это!

Обычный программист, прочитав предыдущую статью, радостно садится и пишет примерно такой код.

bool sok=false;

void thread1(void)
{
for(;;) if(user_want_juice) sok=true; else sok=false;
}

void thread2(void)
{
for(;;;) if(sok) prinesi_sok();
}

Логика думаю понятна: один поток контролирует ситуацию и ставит флаг, когда надо принести сок. А другой контролирует этот флаг и приносит сок, если надо. Где проблемы?

Первая проблема в том, что приносящий сок постоянно спрашивает «сок принести надо?». Это раздражает продавца и нарушает первое правило программиста встроенных устройств «если функции нечего делать, то отдай управление планировщику». Казалось бы, ну воткнем osDelay(1), что бы другие задачи отработали или просто понизим приоритет и пускай крутится, ведь железка-то железная выдержит … В том-то и дело, что не выдержит. Перегрев, недостаток ресурсов и так далее и тому подобное …

А вторая проблема зарыта гораздо глубже. Дело в компиляторах,оптимизациях и многопоточности. Вот для примера: у нас подносчик сока такой шустрый, что может обслужить сразу трех продавцов. В итоге легко может получиться классическая «гонка», когда процессы передерутся между собой.

Продавец1 (далее П1) «Мне нужен сок!» sok=true;
Соконосец (далее С) (просыпаясь) «О! Сок нужен, пошел»
П2 «Мне тоже сок нужен» sok=true;
П3 «Мне тоже!» sok=true;
C (принес сок), П1 — на тебе сок. sok=false;

П2 и П3 в печали.

Программист думает, думает и придумывает бинарный счетчик вместо логического. Смотрит, что получилось.

П1 «Соку!» sok++;
C «Счас»
П2 «Соку!» sok++
П3 «Мне тоже два сока!» sok++;sok++;
С -П1 «на сок!» sok- -;
C (sok>0?) «О, еще надо!»
С — П2 «держи» sok- -;
C «и еще надо?»
С- П3 «велкам» sok- -;
C — и еще разок
С -п3 «пжлста» sok- -;
C «О, сока больше никому не надо, пойду спать».

Код работает красиво, понятно и в принципе ошибок не должно быть. Программист закрывает задачу и приступает к следующей. В конце концов перед финальной сборкой проекта обычно начинается нехватка ресурсов и кто-то хитрый включает оптимизацию или просто меняет контроллер на многоядерный. И все. задача выше перестает работать как положенно. Причем что самое гадкое, иногда она работает как положено, а под отладчиком в 99% случаев она вообще ведет себя идеально. Программист плачет, рыдает и начинает следовать шаманским советам типа «объяви переменную как static или volatile».

А что происходит в реальности?

Когда соконосец выполняет операцию sok- -; в реальности происходит следующее:

1. Берем во временную переменную значение sok
2. Уменьшаем значение временной переменной на 1
3. Записываем значение временной переменной в sok

А теперь вспоминаем, что у нас многопоточная (и может многоядерная) система. Потоки реально могут выполняться параллельно. И поэтому в реальности, а не под отладчиком, происходит следующее (или продавец и соконосец одновременно обратились к одной переменной)

С. Берем во временную переменную значение sok
П. Берем во временную переменную 2 значение sok;
С. Уменьшаем значение временной переменной на 1
П. Увеличиваем значение временной переменной 2 на 1.
П. Записываем значение временной переменной 2 в sok
С. Записываем значение временной переменной в sok

В результате в sok у нас совершенно не то значение, которое мы ожидали. Обнаружив данный факт, программист рвет на себе свитер с оленями, восклицая что-то типа «я же читал об этом, ну как я мог забыть!» и оборачивает код работы с переменной в обертку, которая запрещает многопоточный доступ к этой переменной. Обычно это связно с запретом переключения задач и прочими штуками. Запускает оптимизации — все работает отлично. Но тут приходит архитектор проекта (или главный технарь в studiovsemoe.com, то есть я) и дает программисту по башке, ибо все запреты и прочее очень сильно просаживают производительность и пускают под откос практически все, что завязано на временные промежутки.

Казалось бы, почти безвыходная ситуация, ибо придется переписывать кучу кода, да еще так, что бы не нарушить первое правило программиста … Но я внезапно подобрел и дал ссылку на статью, которую вы сейчас читаете.

В любой приличной ОС есть семафоры. В FreeRTOS есть два типа семафоров — «бинарный» и «счетный». Все их отличие в том, что бинарный — это частный случай счетного, когда счетчик равен 1. Плюс бинарный очень опасно применять в высокоскоростных системах.

В чем преимущество семафоров против обычной переменной?

Во-первых, можно попросить планировщик задач не выделять ресурсов потоку, пока данный семафор не изменит свое состояние. То есть соконосец не будет больше терроризировать продавца «а нужен ли сок?», а будет спать где-то в подсобке до тех пор, пока кому-то не понадобится сок.

И во-вторых, планировщик задач выполняет все необходимые проверки для сохранения целостности семафора и его значения. То есть можно запускать на один семафор несколько соконосцев, которые таскают сок с разной скоростью и они не передерутся между собой и не притащат сока больше, чем необходимо.

В чем проблема с высокоскоростными системами и бинарными семафорами? В принципе ситуация полностью аналогична первому примеру про соконосцев, только перевернутой с ног на голову.

Представим себе, что контролером в макдак взяли тормознутого паренька (далее К). Его задача простая — подсчитать, сколько сока заказали.

П1-С «Сок!»
К — «О, сок заказали, надо нарисовать единичку!»
П2-С «Сок!»
П3-С «Соку!»
(все это время К, высунув язык, рисует единичку)
К — Так, единичку нарисовали, ждем следующего заказа.

Как понимаете, данные в конце дня совершенно не сойдутся. И именно поэтому у нас в студии запрещено использовать бинарные семафоры как класс — скорости контроллеров всегда разные, а ловить такие ошибки очень сложно.

Как работают счетные семафоры? Возьмем для примера все тот же макдак, отдел приготовления бутербродов (или как там одним словом называются гамбургеры с бигмаками?). С одной стороны есть куча продавцов, которые продают бигмаки. Бигмаки продаются по одному, по два или по десятку разом. В общем, не угадаешь. А с другой стороны есть делатель бигмаков. Он может быть одним, молодым и неопытным, а может быть матерым и быстрым. Или все сразу. Продавцу на это пофиг — ему нужен бигмак и кто его сделает ему все равно. В результате:

П1 «Нужен 1 бигмак» (ставит семафор в 1ку)
Д1 «Ок, я могу делать 1 бимак». (молодой, оказался ближе, снимает семафор в 0)
П2 «Нужно 3 бигмака» (увеличивает семафор на 3)
Д2 «Ок, я могу сделать 1 бигмака» (следующим в очереди на ожидание. семафор в 2)
(тут приходит Д1)
Д1 «сделал бигмак, еще один могу сделать» (семафор 1)
Д2 «ок, я свой сделал, сделаю счас еще один». Семафор 0
(приходит назад, он быстрый)
Д2 «Еще бигмаки надо? я подожду 10 тиков, если нет, то уйду»
Д1 «Все, сделал. Разбудите, как еще надо будет» (планировщик тормозит тред)
Д2 «Чего, не надо? ну я ушел. загляну через Нцать тиков»

В итоге бигмаки может делать один человек, а могут 10 — разница будет только в числе произведенных бигмаков в единицу времени. Ладно, хватит про бигмаки и макдональдсы, надо реализовывать все это в коде. Опять же берем плату и код из прошлого примера. У нас 8 светодиодов, которые мигают по разному, с разной скоростью. Вот пусть будет один сделанный «мырг» равен одному «бутерброду». На плате есть пользовательская кнопка, поэтому сделаем так, что бы одно нажатие требовало 1 «бутерброд». А если кнопку держим, что пусть требует по 5 «бутербродов в секунду».

Где-нибудь в «глобальном» коде создаем семафор.

xSemaphoreHandle BigMac;

В коде треда StartThread инициализируем семафор

BigMac = xSemaphoreCreateCounting( 100, 0 );

То есть максимум мы можем заказать 100 бигмаков, а сейчас их надо 0

И изменим код бесконечного цикла на следующий

if(HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_0)==GPIO_PIN_SET)
{
xSemaphoreGive(BigMac);
}
osDelay(200);

То есть если кнопка (а она на плате прицелена к PА0) нажата, то каждые 200мс мы выдаем один семафор/требуем бигмак.

И к каждому коду мигания светодиодиком добавим

xSemaphoreTake( BigMac, portMAX_DELAY);
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_15,GPIO_PIN_RESET);
...

То есть ждем семафора BigMac до опупения (portMAX_DELAY). Можно поставить любое число тиков или через макрос portTICK_PERIOD_MS задать число миллисекунд для ожидания.

Внимание! В коде я не стал вводить никаких проверок для повышения его читабельности.

Компилируем, запускаем. Чем дольше держим кнопку, тем больше светодиодиков мигает. Отпускаем — перестают. Но один, самый быстрый (и дальний в очереди) у меня не замигал — ему просто не хатает «заказов». Ок, увеличиваю скорость до 50мс на каждый бутерброд. Теперь заказов хватает всем и все мигают. Отпускаешь кнопку — они некоторое время продолжают мигать, делая собранные заказы. Что бы было совсем хорошо, я разрешил заказывать бигмаков аж 60 тыщ (можно до unsigned long) и период заказа поставил 10мс.

Теперь все стало совсем красиво — нажал, светодиодики замигали. Чем дольше держишь кнопку, тем дольше мигают светодиодики после отпускания. Полная аналогия реальной жизни.

Что бы продолжить аналогию с реальной жизнью, вспомним, что это в макдаке всегда есть какие-то сборщики бутербродов. То есть продавец может не оборачиваясь, махнуть «надо бутерброд» и кто-нибудь его сделает. А если это обычная столовая в необеденное время? Там кассирша может хоть обмахаться — никто просто не увидит, ибо все кроме нее смотрят очередной сериал. Кассирше надо понять, чего хочет забредший в неурочное время посетитель и крикнуть что-то типа «Татьяна Васильевна, выйдите пожалуйста, тут суп налить надо».

Для таких адресных случаев семафоры использовать нет смысла. В старый версиях FreeRTOS можно было просто через API разбудить задачу («там суп надо»), а в новых появился вызов vTaskNotify (отличие только в передаваемом параметре «там борщ надо»), использование которого полностью аналогично семафорам, но адресно. По сравнению с обычными обещают дикое повышение производительности, но на данный момент мы масштабных тестов не проводили.

Есть еще один подвид семафоров — мутексы (mutex), но это те же самые бинарные семафоры. А рекурсивные мутексы — это счетные семафоры. Сделаны абсолютно так же, работают абсолютно так же, только «можно делать» состояние у них не «больше нуля», как у обычных, а «только ноль». Используются для разделения к ресурсам и переменным. Предлагаю придумать примеры применения самим.

Результат работы кода

Как обычно, полный код с обновлениями из поста можно найти тут http://kaloshin.ru/stm32/freertos/stage2.rar

STM32 и FreeRTOS. 1. Развлекаемся с потоками

Это черновая версия, финальная опубликована на хабре

IMG_0278

Очень часто (да что там часто, практически всегда) микроконтроллеры применяют в условиях, когда необходимо отслеживать сразу несколько параметров. Или наоборот, управлять одновременно несколькими устройствами.

Вот задача для примера: у нас есть 4 выхода, на которых необходимо выводить импульсы разной длительности с разными паузами. Все, что у нас есть — это системный таймер, который считает в миллисекундах.

Усложняем задачу в духе «сам себя замучаю на ардуино». Таймеры заняты другим, PWM не подходит, ибо не на всех ножках он работает, да и не загонишь его на нужные режимы обычно. Немного подумав, садимся и пишем примерно такой код


// инициализация
int time1on=500; // Время, пока выход 1 должен быть включен
int time1off=250; // Время, пока выход 1 должен быть выключен
unsigned int now=millis();
....
// где-то в цикле
if(millis()<now+time1on)
{
port1=ON;
}
else
{
port1=OFF;
if(millis()>now+time1on+time1off)
{
now=millis();
}
}

И так или примерно так для всех 4 портов. Получается приличная портянка на несколько экранов, но эта портянка работает и работает довольно быстро, что для микроконтроллера важно.

Потом внезапно программист замечает, что при каждом цикле дергается порт, даже если его состояние не меняется. Правит всю портянку. Потом число портов с такими же потребностями увеличивается в два раза. Программист плюет и переписывает все в одну функцию типа PortBlink(int port num).

Почти наступило счастье, но внезапно потребовалось что бы на каком-то порту вместе с управлением «на выход» что-то предварительно считывалось и уже на основе этого считанного управлялся порт. Программист снова матерится и делает еще одну функцию, специально под порт.

Счастье? А вот фигу. Заказчик что-то этакое прицепил и это считанное может легко тормознуть процесс на секунды … Начинается стенания, программисты правят в очередной раз код, окончательно превращая его в нечитаемый треш, менеджеры выкатывают дикие прайсы заказчику за добавление функционала, заказчик матерится и решает больше никогда не связываться со встроенными решениями.

(типа реклама и восхваление) А все почему? Потому что изначально было принято неправильное решение о платформе. Если есть возможность, мы предлагаем навороченную платформу даже для примитивных задач. По опыту стоимость разработки и поддержки потом оказываются гораздо ниже. Вот и сейчас для управления 8мю выходами я возьму STM32F3, который может работать на 72МГц. (шепотом) На самом деле просто у меня под рукой демоплата с ним (смаил). Была еще с L1, но мы ее нечаянно использовали в одном из проектов.

Открываем STM32Cube, выбираем плату, включаем галочку около FreeRTOS и собираем проект как обычно. Нам ничего этакого не надо, поэтому оставляем все по умолчанию.

Что такое FreeRTOS? Это операционная система почти реального времени для микроконтроллеров. То есть все, что вы слышали про операционные системы типа многозадачности, семафоров и прочих мутексов. Почему FreeRTOS? Просто ее поддерживает STM32Cube ;-). Есть куча других подобных систем — та же ChibiOS. По своей сути они все одинаковые, только различаются командами и их форматом. Тут я не собираюсь переписывать гору книг и инструкций по работе с операционными системами, просто пробегусь широкими мазками по наиболее интересным вещам, которые очень сильно пмогают программистам в их нелегкой работе.

Ладно, буду считать что прочитали в интернете и прониклись. Смотрим, что поменялось

Где-то в начале

static void StartThread(void const * argument);

и после всех инициализаций

/* Create Start thread */
osThreadDef(USER_Thread, StartThread, osPriorityNormal, 0, configMINIMAL_STACK_SIZE);
osThreadCreate (osThread(USER_Thread), NULL);

/* Start scheduler */
osKernelStart(NULL, NULL);

И пустая StartThread с одним бесконечным циклом и osDelay(1);

Удивлены? А между тем перед вами практически 90% функционала, которые вы будете использовать. Первые две строки создают поток с нормальными приоритетом, а последняя строка запускает в работу планировщик задач. И все это великолепие укладывается в 6 килобайт флеша.

Но нам надо проверить работу. Меняем osDelay на следующий код

HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_RESET);
osDelay(500);
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_SET);
osDelay(500);

Компилируем и заливаем. Если все сделано правильно, то у нас должен замигать синий светодиодик (на STM32F3Discovery на PE8-PE15 распаяна кучка светодиодов, поэтому если у вас другая плата, то смените код)

А теперь возьмем и растиражируем полученную функцию для каждого светодиода.

static void PE8Thread(void const * argument);
static void PE9Thread(void const * argument);
static void PE10Thread(void const * argument);
static void PE11Thread(void const * argument);
static void PE12Thread(void const * argument);
static void PE13Thread(void const * argument);
static void PE14Thread(void const * argument);
static void PE15Thread(void const * argument);

Добавим поток для каждого светодиода
osThreadDef(PE8_Thread, PE8Thread, osPriorityNormal, 0, configMINIMAL_STACK_SIZE);
osThreadCreate (osThread(PE8_Thread), NULL);

И перенесем туда код для зажигания светодиода
static void PE8Thread(void const * argument)
{
for(;;)
{
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_RESET);
osDelay(500);
HAL_GPIO_WritePin(GPIOE,GPIO_PIN_8,GPIO_PIN_SET);
osDelay(500);
}
}

В общем все однотипно.

Компилируем, заливаем … и получаем фигу. Полную. Ни один светодиод не мигает.

Путем страшной отладки методом комментирования выясняем, что 3 потока работают, а 4 — уже нет. В чем проблема? Проблема в выделенной памяти для шедулера и стека.

Смотрим в FreeRTOSConfig.h

#define configMINIMAL_STACK_SIZE ((unsigned short)128)
#define configTOTAL_HEAP_SIZE ((size_t)3000)

3000 байт на все и каждой задаче 128 байт. Плюс еще где-то надо хранить информацию о задаче и прочем полезном. Вот поэтому, если ничего не делать, планировщик при нехватке памяти даже не стартует.

Судя по факам, если включить полную оптимизацию, то сам FreeRTOS возьмет 250 байт. Плюс на каждую задачу по 128 байт для стека, 64 для внутреннего списка и 16 для имени задачи. Считаем: 250+3*(128+64+16)=874. Даже до килобайта не дотягивает. А у нас 3 …

В чем проблема? Поставляемая с STM32Cube версия FreeRTOS слишком старая (7.6.0), что бы заиметь vTaskInfo, поэтому я зашел сбоку:

Перед и после создания потока я поставил следующее (fre — это обычный size_t)

fre=xPortGetFreeHeapSize();

Воткнул брекпоинты и получил следующие цифры: перед созданием задачи было 2376 свободных байт, а после 1768. То есть на одну задачу уходит 608 байт. Повтыкал еще. Получил цифры 2992-2376-1768-1160. Цифра совпадает. Путем простых логических умозаключений понимаем, что те цифры из фака взяты для какого-нибудь дохлого процессора, со включенными оптимизациями и выключенными всякими модулями. Смотрим дальше и понимаем, что старт шедулера отьедает еще примерно 580 байт.

В общем, принимаем для расчетов 610 байт на задачу с минимальным стеком и еще 580 байт для самой ОС. Итого в TOTAL_HEAP_SIZE надо записать 610*9+580=6070. Округлим и отдадим 6100 байт — пусть жирует.

Компилируем, заливаем и наблюдаем, как мигают все светодиоды разом. Пробуем уменьшить стек до 6050 — опять ничего не работает. Значит, мы подсчитали правильно 🙂

Теперь можно побаловаться и позадавать для каждого светодиодика свои промежутки «импульса» и «паузы». В принципе, если обновить FreeRTOS или поколдовать в коде, то легко дать точность на уровне 0,01мс (по умолчанию 1 тик — 1мс).

Согласитесь, работать с 8ю задачами поодиночке гораздо приятней, чем в одной с 8ю одновременно? В реальности у нас в проектах обычно крутится по 30-40 потоков. Сколько было бы смертей программистов, если всю их обработку запихать в одну функцию я даже подсчитать боюсь 🙂

Следующим шагом нам необходимо разобраться с приоритетами. Как и в реальной жизни, некоторые задачи «равнее» остальных и им необходимо больше ресурсов. Для начала заменим одну мигалку мигалкой же, но сделанной неправильно, когда пауза делается не средствами ОС, а простым циклом.

То есть вместо osDelay() вставляется вот такой вот ужас.

for(int i=0;i<1000000;i++) { c++; }

Число циклов обычно подбирается экспериментально (ибо если таких задержек несколько, то куча головной боли в расчетах обеспечено). Эстеты могут подчитать время выполнения команд.

Заменяем, компилируем, запускаем. Светодиодики мигают по прежнему, но как-то вяло. Просмотр осциллографом дает понять, что вместо ровных границ (типа 50мс горим и 50мс не горим), границы стали плавать на 1-2мс (глаз, как ни странно, это замечает). Почему? Потому что FreeRTOS не система реального времени и может позволить себе такие вольности.

А теперь давайте поднимем приоритет этой задаче на один шажок, до osPriorityAboveNormal. Запустим и увидим одиноко мигающий светодиод. Почему?

Потому что планировщик распределяет задачи по приоритетам. Что он видит? Что задача с высоким приоритетом постоянно требует процессор. Что в результате? Остальным задачам времени на работу не остается.

А теперь понизим приоритет на один шаг от нормального, до osPriorityBelowNormal. В результате планировщик, дав поработать нормальным задачам, отдает оставшиеся ресурсы "плохой".

Отсюда можно легко вывести первое правило программиста: если функции нечего делать, то отдай управление планировщику.

В FreeRTOS есть два варианта "подожди"

Первый вариант "просто подожди N тиков". Обычная пауза, без каких либо изысков: сколько сказали подождать, столько и ждем. Это vTaskDelay (osDelay просто синоним). Если посмотреть на время во время выполнения, то будет примерно следующее (примем что полезная задача выполняется 24мс):

... [0ms] - передача управления - работа [24ms] пауза в 100мс [124ms] - передача управления - работа [148ms] пауза в 100мс [248ms] ...

Легко увидеть, что из-за времени, требуемой на работу, передача управления происходит не каждые 100мс, как изначально можно было бы предположить. Для таких случаев есть vTaskDelayUntil. С ней временная линия будет выглядеть вот так

... [0ms] - передача управления - работа [24ms] пауза в 76мс [100ms] - передача управления - работа [124ms] пауза в 76мс [200ms] ...

Как видно, задача получает управление в четко обозначенные временные промежутки, что нам и требовалось. Для проверки точности планировщика в одном из потоков я попросил делать паузы по 1мс. На картинке можете оценить точность работы с 9ю потоками (про StartThread не забываем)

1ms

Думаю, для первой части достаточно 🙂

Как обычно, полный пакет проекта можно взять тут: http://kaloshin.ru/stm32/freertos/stage1.rar

Загадочный AES

В процессе обкатки модулей для супер-мега-экстра часов добрался до СС модулей от Texas Instruments. Документации куда больше, чем на nRF серию от Nordic, демоплатки тоже завелись без проблем.

Читаю документацию к SimplyciTI (это такой фирменный сетевой стек для этих чипов, сразу позволяет делать точки доступа, репитеры и прочее). Добираюсь до секурности — ведь никто не должен знать температуру за моим окном или включать-выключать свет в туалете (это одна из моих претензий к noolite)

There are 3 components of the encryption scheme that can be used to maintain security: the 128 bit key, a 32-bit Initialization Vector (IV) and a 32-bit counter. The key and the IV are fixed at build time.

Офигеть. Даже мне, далекому от криптографии, становится смешно. 32 бита «энтропии», которые меняются по жесткому алгоритму … Ну ладно, что там еще

The scheme encrypts 64-bit blocks using an encryption scheme available in the public domain (XTEA: EXtended Tiny Encryption Algorithm). The 64-bit block is a concatenation of the 32-bit IV and a 32-bit counter. Changing the counter for each encryption guarantees a unique block for each encryption action. The key length used in the encryption is 128 bits.

Читаю дальше …

Because SimpliciTI does not support guaranteed delivery there must be a mechanism to synchronize the counters. Otherwise correct decryption could not occur. The synchronization is done by supplying a counter hint in the frame containing the encrypted payload. The hint is a single byte representing the least significant byte (lsb) of the 4 byte counter value used to encrypt the accompanying payload. It is sent in the clear over the air.

Вот так вот просто, берут и выдают последний байт счетчика в открытом виде в воздух. Круто, разом на треть уменьшают и без того маленький «ключ»

И как-то все. В задумчивости сижу, думаю, что не так.

Потом вспоминаю рекламные зазывалки.

The CC1110’s integrated AES-128 co-processor makes it ideal for wireless payment systems, since strong encryption can be done on the chip itself

Ну AES-128 это круто. Странно, что не написали в аппноуте, как до него добраться. Но счас почитаю оставшуюся документацию.

(пропущено несколько часов ползанья по докам и исходникам)

А нигде нету ни слова про AES вообще. Печаль. Может это из-за того, что я скачивал документацию с фирменного сайта TI, а там меня спрашивали, откуда я. Вот может под какие санкции попал. Пошел спрашивать интернет.

И тут открылось обычное. На более-менее приличных сайтах, которые не занимаются тупой перепечаткой, нет ни слова про AES. Вообще.

Вот такой вот AES. То он есть, то его сразу нет …

ЗЫ И именно поэтому я не люблю маркетологов, которые уцепившись за циферку 128, сразу прилепили к ней слева магические (в 2009 году) буквы AES.

Мега-часы. 2. Новые горизонты

Опытно-промышленное тестирование бутерброда из Arduino Leonardo и Arduino Wifi Shield показало, что wifi shield … В общем, очень плохо работает. Может тупо не запуститься или взять и повиснуть прямо на середине работы. А может завестись без каких-либо проблем и проработать сутки под нагрузкой.

В итоге wifi (да и вообще вся сетевая) часть переезжает на raspberry. Там с этим гораздо лучше просто по определению.

Следующее тестирование (в предидущих постах можно прочитать подробнее) показало, что первоначально выбранный контроллер nRF24 оказался тоже не очень хорошим. То ли китайцы чего-то не так распаяли, что ли у меня руки кривые, но дальность действия радиочасти оказалась ниже плинтуса. А я уже раскатал губу про выносные датчики и прочие штуки …

Но не одним nordic’ом полон мир. Тут же на замену был приобретен комплект разработчика на чипе MSP430+СС1100 от Texas Instruments производства нашей ТерраЭлектроники . Что бы дополнительно «замативировать» себя, взял еще СС430-Chronos. Настоящие умные часы, которые можно запрограммировать так, как тебе надо, а не просто менять циферблатики.

IMG_0269

Период прочтения документации принес очень много удовольствия: её просто на порядки больше, чем про nRF24. На первый взгляд кажется, что описано все. Вторым взглядом не смотрел еще.

Так как я с MSP430 не работал до этого момента, то из launchpad был вынут «крутой» проц и засунут простой.

IMG_0272

Первый шаг сделан — он замигал светодиодиком. Теперь осталось проверить мысль, хватит ли этому ресурсов заменить ардуинку в деле мигания дисплейчиком и считывания кнопок …