Не высокоточные (+-3% RH) датчики относительной влажности Si7021

Честно говоря, никогда не понимал этой погони за десятыми долями градуса в измерении температуры и относительной влажности в измерениях окружающей среды. Без герметической камеры с принудительной циркуляцией уже в 10 сантиметрах от датчика микроклимат будет отличаться достаточно сильно. А если можно сэкономить на датчике — почему бы и нет?


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

Источник Перебойного Питания постоянного тока ТР12-4

Тут недавно была статья про ИБП постоянного тока СКАТ. Я продолжу тему.
ТР12-4
Разрабатываем мы шкаф с оборудованием и заложили в него сначала источник СКАТ-24-2.0 DIN. В процессе работы, так сложилось, что перешли с 24В на 12В и источник заменили не на другой СКАТ, а на альтернативное решение — ТР12-4 компании ТрансЭТ. Казалось бы всё хорошо — и тока достаточно и дискретные выходы есть и места меньше занимает. В общем потестили, закупили сотню этих блоков и стали партию собирать. Но, как оказалось, тестили мы недостаточно хорошо — в пятницу в процессе ковыряния с железкой я выдернул шнур из розетки и забыл воткнуть обратно. В понедельник сутра я обнаружил обесточенную железку, воткнул в розетку и, ничего не подозревая, продолжил работу. В определённый момент я опять выдернул вилку и с удивлением обнаружил, что девайс отрубился.


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

Самый простой программный таймер

Если у вас стоит задача посчитать время от а до б, а потом выполнить определенные действия в связи с этим, то данный вариант вам вполне пригодится.
Самый весомый плюс у данной системы — нет необходимости в прерываниях.
Так же у данного таймера отсутствует весомый обработчик событий. Все необходимые вычисления происходят распределённо.


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

Высокоточные (±1.8 % RH) датчики относительной влажности

Клон хабры (да ещё и из корпоративного блога) с описанием датчиков серии HYT от швейцарского производителя IST.



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



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

Особенности адресации контроллера TM1638 для индикаторов с ОА.

  Приобрел модуль для экспериментов и возможно встраивания «LED&KEY» на чипе TM1638 от китайского чипмейкера Titan Micro Electronics. В пакете кроме самого модуля ничего не было, пришлось разбираться, благо модули на чипе TM1638 популярны у Ардуинщиков и в инете разрозненная информация по ним есть.
  Все разнообразие модулей сводится к трем разновидностям, о них ниже…


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

Самопальная "третья рука" с подсветкой и вытяжкой

Без держателя «третья рука» пайка и монтаж иногда превращаются в мучение, это всем известно. Так что вещь в хозяйстве незаменимая. Из экземпляров, предлагаемых китайпромом, что-то мне ни один не приглянулся: все они на одно лицо — 2 крокодила и лупа(впрочем для многих задач вполне годны). Если хочешь немного наворотов типа подсветки, то цены уже возмущают. Так что решил заколхозить сам. Получилось отакэ:



Далее по-порядку.


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

Реалиазция стандартного GATT-BLE профиля на RSoC фирмы Cypress

Эта статья является продолжением моей статьи [1]. Здесь речь пойдёт о программной реализации стандартного GATT (Generic Attribute Profile) профиля ESP (Environmental Sensing Profile), включающего два также стандартных сервиса: ESS (Environmental Sensing Service) и BAS (Battery Service). К описанному серверу можно будет подключиться с любого устройства, поддерживающего протокол BLE (Bluetooth Low Energy), например смартфон или планшет, для мониторинга температуры и относительной влажности воздуха, а также состояния батареи. Помимо этого будут представлены некоторые программные и аппаратные средства для разработки и отладки BLE приложений.

Устройство наше основано на том-же радиомодуле CYBLE-022001-00 фирмы Cypress Semiconductor, подробнее о нем см. в первой части статьи [1]. В состав модуля входит микроконтроллер с архитектурой ARM Cortex-M0, в который помимо стека BLE можно загрузить программу пользователя. В схему добавлена пара резисторов для измерения напряжения батареи встроенным в RSoC АЦП.

схема


Читать дальше
  • +3
  • 08 июня 2016, 09:31
  • Ser60

Месяц HAL продолжается: HAL для LPC

В продолжение месяца постов о HAL решил написать и о своей библиотеке, правда, в отличие от предыдущих она в основном специализируется на контроллерах от NXP. Библиотека не использует дополнительных прослоек и работает напрямую с регистрами. Она состоит из двух обязательных частей, которые собираются с помощью GCC ARM, make и kconfig, и затем статически линкуются с основным проектом.


Читать дальше
  • +1
  • 29 мая 2016, 18:19
  • StXt

Цифровой датчик температуры LMT01

Решил написать заметку про убийцу вариант замены всеми полюбившегося датчика ds18b20.
Все мы знаем ds18b20 — это цифровой датчик температуры, который позволяет делать замеры с достаточно высокой точностью и обмениваться данными с окружающим миром по протоколу 1 wire. И все хорошо в этом датчике, да вот только протокол 1 wire не всегда реализован в железе МК и как часто это бывает, приходится городить свой трехколесный или же пользоваться сторонними либами. При этом больше всего обидно, когда нам нужно сделать устройство, которое питается от батарейки и должно работать миллисекунды, а потом засыпать на часы, а для банального замера температуры приходится общаться с датчиком, тратить на это клоки МК, ждать и «засорять» флеш и RAM кодом, который можно было бы использовать более оптимально.
Читатель может возразить — так можно поставить термопару или другой аналоговый прибор и замерять через АЦП — и будет прав, но при этом возрастает количество элементов на схеме и плате, а так же всегда есть шанс ошибиться при монтаже и т.д.
И вот на помощь нам пришла компания Texas instruments которая разработала цифровой датчик LMT01, который по своим характеристикам не уступает народному ds18b20, а в некоторых случаях его даже превосходит (даташит).
Но самое главное — у датчика всего две ноги, они же служат ему питанием и коммуникацией с внешним миром. А коммуникация у него проста как двери — подаем на него питание и через мгновение датчик начинает дрыгать ногой. Сколько раз дрыгнул — столько и насчитал единиц температуры! Один «дрыг» = 0.0625°С. т.е. нам нужно всего-то подключить одну ногу к МК, подать в нужный момент на него питание и посчитать сколько раз датчик дёрнет за нашу ногу. Как считать — думаю что тут уже каждый сам для себя придумает. Самый простой способ — прерывание на ноге. Способ посложнее — подсчет таймером. Согласитесь — просто до неприличия. Даже примеры коды приводить смысла нет.
Длинна проводников, которыми он может быть подключен к МК может достигать двух метров, тут конечно не сравнить с шиной 1 wire но это не сильно критический минус.

Единственный критический минус, который может оттолкнуть — это пока его цена. Колеблется она начиная от 1,5 вечнозеленых президентов и на китайских барахолках он пока не доступен. Но, видимо китайцы скоро наделают его клонов.
Как оказалось на терраэлектронике этот датчик дешевле далласа.

Ну и для тех кому лень лезть в даташит немного характеристик:
Основные характеристики:
Корпус: TO-92/LPG(2)
Тип датчика: Цифровой
Диапазон измеряемых температур: -50...150 С
Точность измерения ±: 0,5 С
Разрешение: 0,0625 С

UPD:
Для сравнения с ds18b20:
Только включил и через 54мс получаем температуру, ничего не нужно отправлять, инициализировать и конфигурировать.
Время получения данных о температуре максимум 50мс. при 150 C, минимум 0мс при -50С.
Итого суммарное время получения макс. 104мс.
В далласе при двуногом подключении нужно выдерживать интервалы из даташита, для 12 бит это уже 750мс. + время на отправку команд для измерения и чтение данных.
Ну и разница в потреблении питания миллиамперы у далласа против микроампер у LMT01.
Так же, для некоторых специфических задач можно получать непрерывное измерение температуры со интервалом 104мс если не отключать датчик…

Минусы:
одна нога — один датчик.
не везде цена адекватная, но как писал выше — есть дешевле далласа.
короткий провод до датчика — не более 2 м. по даташиту.
протокол не совсем протокол, скорее тупое получение данных.

Простая схемка подключения. В ДШ есть и другие.

Мысли о STM32 HAL или стоит ли стремиться в метапрограммирование на C++

Навеяно сообщением коллеги evsi
Что же до либ, то есть куда более перспективный путь, хотя он и не лежит в плоскости очередного HAL от конкретного производителя. Я имею в виду вот эту либу: github.com/andysworkshop/stm32plus
Кстати, сам Andy Brown (автор либы) ведет весьма интересный сайт andybrown.me.uk/
в недавнем обсуждении STM32 Peripheral Libs: FWLib -> SPL -> Middleware+HAL+CubeMX -> Middleware+Snippets -> CMSIS-Driver API? Куда это все ведет и есть ли истинный путь?

Шаблонное метапрограммирование.
По мере изучения С++, я вижу, что все пути ведут туда. Но пока я не способен (легко) понимать такой код, а уж тем более написать.
У меня к такой библиотеке вопросы:

1. Полностью ли абстрагирует эта конкретная библиотека железо, во всей его сложности? Вопрос шире. Пусть не эта конкретная, а в принципе, можно ли с помощью шаблонного метапрограммирования написать библиотеку, с помощью которой можно включить железо в любом описанном в datasheet режиме?
Не будем брать GPIO, возьмем АЦП. Какой-нибудь сложный режим совместного использования отдельных модулей АЦП, с пересылкой по DMA, запуском по таймеру. Повторюсь, простая периферия не интересует, интересует сложная в извращенных режимах.
Если кто-то из гуру положительно ответит на этот вопрос, буду расти в ту сторону.

2. Вот пишу я код в таком стиле, ухожу из конторы. Сколько будет стоить специалист, способный поддерживать такой код? Как легко его будет найти?

Хорошо, допустим можно написать на шаблонах вообще все, что угодно, во всей полноте. Что мы видим? С помощью достаточно сложного в применении языка шаблонов мы заставляем компилятор сгенерировать нужный нам код.

Почему бы не взять для генерации исходников более мощный язык, предназначенный для манипулирования текстом? Perl, Python, Javascript и так далее.
Описать в декларативном стиле (a-la QML) в JSON формате, что нам нужно от периферии. Парсим этот файл, генерируем C++ исходник, в котором классы периферии имеют простое АPI, минимально необходимое в конкретной задаче.

class AdcSigmaDelta
{
public:
    enum Gain
    {
        Gain05,
        Gain1,
        Gain2,
        Gain4,
        Gain8,
        Gain16,
        Gain32,
    };

    AdcSigmaDelta(const std::vector<Pin> & pins);

    bool start();
    int16_t code(size_t idx) const;
    float voltage(size_t idx) const;
    bool setGain(Gain gain);
...
}

Методы класса наш генератор реализует напрямую регистрами максимально эффективно.
Генератор должен не давать использовать одну периферию в разных местах, GPIO, задействованные в АЦП не задействовать для ШИМ.
Отсюда плавно приходит в голову использовать GUI для генерации JSON файла описателя.

Та-дам! Вот и он — STM32CubeMx.

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

Тот Cube, который я хотел бы видеть:
открытый исходный код — чтобы тысячи эмбеддеров совместно развивали проект (тысячи бесплатных тестировщиков!),
гибкий, настраиваемый — чтобы код генерился в моем стиле, раскиданный по мной описанному заголовочному файлу.