Быстрый старт с ARM Mbed: разработка на современных микроконтроллерах для начинающих +82


Привет, Хабр.

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

Спросите примерно у любого активного сторонника Arduino — и вам быстро объяснят, что можно, конечно, писать под STM32 или nRF52, но выгоды в том реальной никакой, зато вас ждут бессонные ночи над сотнями страниц даташитов и бесконечные простыни функций с длинными непонятными названиями.

Заслуги Arduino в снижении порога вхождения действительно трудно переоценить — эта платформа появилась на свет в середине нулевых годов, а после 2010 завоевала серьёзную популярность среди любителей. Особых альтернатив на тот момент ей не было — процессоры на ядрах Cortex-M только появились, по сравнению с AVR они были довольно сложны даже для профессиональных разработчиков, а отладочные платы у большинства вендоров стоили от сотни долларов и выше (и в общем в индустрии ценник за отладку на 5-долларовом контроллере в $500 никого сильно не удивлял).

Однако большая проблема Arduino в том, что её развитие за минувшие 10+ лет более всего напоминает некоторые модели АвтоВАЗа:


Так как дальше я планирую длинное вступление, то сейчас, чтобы вы представляли, в чём будет заключаться практическая часть, я приведу полный текст программы, включающий инициализацию процессора STM32 и мигание светодиодом. Программа написана для ОС ARM Mbed:

#include "mbed.h"
DigitalOut myled(LED1);

int main() {
    while(1) {
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

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

Дело в том, что в мире встраиваемой разработки с 2010 года произошло… многое. AVR, как и вообще 8-битные контроллеры, практически умерли — на 2017 год суммарная доля последних в разработках составляла 12 % (данные опроса разработчиков Aspencore), причём она делилась как минимум на три семейства: AVR, PIC и STM8. Фактически, основное их применение сейчас — замена мелкой логики, периферийные контроллеры с минимальным объёмом мозгов и т.п.

Для серии ATMega в этих 12 % места совсем мало — они избыточны в качестве вспомогательных и не могут конкурировать с 32-битными Cortex-M по соотношению цена/характеристики (STM32F030 с 16-64 КБ флэша и 4-8 КБ ОЗУ стоит в России мелким оптом 30-50 рублей). По сути, атмеги в каких-то проектах остались только по историческим причинам.


64-битные процессоры — это, очевидно, старшие Cortex-A и интелы в тяжёлых проектах

Случилось много нового и в средах разработки. Помните, я выше писал, что на старте Cortex-M отпугивали многих разработчиков своей сложностью? Помимо самой по себе развесистой программной инициализации железа (одна только корректная инициализация тактирования, чтобы процессор вообще запустился — это полстраницы кода), главной проблемой стал низкий уровень совместимости разных моделей друг с другом. Если один AVR менялся на другой иногда вообще без правки кода, то для смены STM32F1 даже на STM32L1 придётся поправить изрядно, а уж на какой-нибудь Infineon или NXP…

В пределах одного вендора проблема решалась выпуском набора библиотек, абстрагирующих софт от железа — так, STMicro на данный момент сделала их аж три штуки: SPL, HAL и LL. Однако популярность таких библиотек не всегда была так высока, как хотелось бы вендорам, а кроме того, они с очевидностью были привязаны к конкретному вендору.

Эта проблема начала решаться с появление микроконтроллерных операционных систем.

При всех словах о необходимости экономии ресурсов ОС оказались настолько удобны в разработке, что сейчас большинство проектов делается с их использованием. Впрочем, это вполне ожидаемо — при работе над крупным проектом, даже если вы не будете использовать готовую ОС, вы в итоге напишете для себя набор подсистем, фактически эту ОС составляющих. Просто потому, что они нужны (нет, по опыту людей, пишущих статьи о том, как сделать многозадачность средствами цикла loop(), я в курсе, что кому-то и не нужны — но это будет дискуссия о том, что кому-то и велосипед с круглыми обрезиненными колёсами не нужен, когда и на деревянных квадратных в принципе как-то можно ездить).

Микроконтроллерные ОС и что они дают


С точки зрения программиста ОС — это не только большой полосатый мух, но и набор сервисов «из коробки», серьёзно облегчающих ему жизнь:

  • HAL — абстрагирование от железа. В ОС очень чётко и недвусмысленно разделено взаимодействие с железом и пользовательский код. Это позволяет, во-первых, легко переносить проекты между разными контроллерами (например, у нас большая, увесистая прошивка без каких-либо модификаций собирается под STM32L072, STM32L151 и STM32L451 — достаточно просто указать, какая плата нужна сейчас), во-вторых, при работе над проектом нескольких человек разделять между ними обязанности в соответствии с навыками и квалификацией (логику приложения, например, может писать человек, имеющий крайне смутное понятие о работе с регистрами в STM32, при этом низкоуровневая часть проекта будет развиваться другим человеком параллельно, и они не будут друг другу мешать). В некоторых ОС абстрагируется даже доступ к внешним устройствам — например, в RIOT есть API под названием SAUL, которым можно пользоваться для доступа к сенсорами; в этом случае автору кода верхнего уровня будет всё равно, какой конкретно сенсор там подключён где-то внизу.
  • Многозадачность — любой серьёзный проект представляет собой набор конкурирующих и кооперирующихся задач, которые исполняются в разные периоды времени, периодически или по каким-либо событиям. Современные ОС позволяют легко выделять такие задачи в отдельные потоки, не зависящие от других потоков и обладающие собственными стеками, назначать им приоритет выполнения и отслеживать их работу.
  • Таймеры — события часто привязываются к конкретному времени, и поэтому обязательно нужны часы. Аппаратные таймеры контроллера для регистрации событий в многозадачной ОС подходят плохо в силу ограниченности своего числа, поэтому ОС предоставляют собственные таймеры. Это подсистемы, работающие на базе одного из аппаратных таймеров, и позволяющие запрограммировать практически неограниченное количество событий с точностью, равной дискретности используемого таймера. Так как подсистема работает на базе прерываний аппаратного таймера, то взаимное влияние событий ограничено собственно только пересечением обработчиков прерываний.
  • IPC — межпроцессное сообщение. Так как различные задачи работают не в вакууме, а общаются между собой, то ОС предоставляет средства такого общения, от простых семафоров и мьютексов, позволяющих, например, притормозить один поток в ожидании, пока другой освободит нужную периферию или получит нужные данные, до сообщений, в которых можно передавать данные и которые сами по себе могут являться триггером для переключения ОС из потока-отправителя в поток-получатель (так, например, делается выход из обработчика прерывания: если у вас есть тяжёлая процедура, которая должна запускаться по прерыванию, то из прерывания вы просто отправляете сообщение в собственно поток с этой процедурой, который выполняется уже в обычном контексте, не мешая работе системы).
  • Наборы стандартных библиотек и функций — помимо API работы с самим микроконтроллером, ОС может предоставлять вам доступ к стандартным библиотекам, в том числе сторонней разработки. Это могут быть простые, но востребованные процедуры типа форматирования чисел между разными представлениями, процедуры шифрования и расчёта контрольных сумм, а также большие сторонние библиотеки, например, сетевые стеки, файловые системы и так далее, адаптированные под API данной ОС.
  • Наборы драйверов — многие ОС предоставляют также «из коробки» наборы драйверов для внешних по отношению к контроллеру датчиков и систем.

В целом, благодаря ОС программирование микроконтроллеров становится всё ближе к написанию софта под большие ПК — даже API местами очень похоже на старый добрый POSIX.

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

  • FreeRTOS — строго говоря, вообще не ОС, а только ядро ОС. Обвес к нему — на усмотрение разработчика. Самая популярная на данный момент микроконтроллерная ОС (но это не значит, что вам надо использовать именно её)
  • Contiki OS — старая универстетская разработка, получившая известность благодаря сетевым возможностям, в частности, стеку 6LoWPAN. По нынешним меркам тяжеловесна, а многие концепции давно устарели (например, там нет нормальной по современным понятиям реализаци многозадачности). Сейчас переписывается под названием Contiki NG — из проекта выкидывают разный хлам, но общая концепция не меняется.
  • RIOT OS — молодая университетская разработка, претендующая на место Contiki. Поддерживает кучу процессоров разных архитектур (включая даже старшие ATMega) и бурно развивается. Легковесна и понятна. Написана на C. Многого местами не хватает, но проста в освоении, поддержке и доработке под свои нужды. Оптимальна, на мой взгляд, в качестве учебной для профильных студентов.
  • ARM Mbed — коммерческая (но опенсорсная, Apache 2.0) ОС разработки самой ARM Holdings. Была немного печальна в версии 2.0, но стремительно рванула ввысь в новой ветке 5.x. Написана на C++ и имеет достаточно понятный и простой API. Поддерживает гору различных плат, и в общем и целом делает это хорошо. У части вендоров есть собственные команды, занимающиеся поддержкой отладочных плат этого вендора в Mbed.
  • TI-RTOS — собственная разработка Texas Instruments, работает примерно со всем, что TI когда-либо выпустила, ставится из коробки сразу с поддержкой примерно всего, но установка занимает пару часов и уменьшает ваш диск на несколько гигабайт. На мой вкус, API чрезмерно тяжеловесен.

Во многих случаях ОС не привязана к какой-либо среде разработки, а в качестве тулчейна обычно используется типовой arm-none-eabi-gcc. Так, RIOT изначально сделан на Makefile'ах, а потому с ним можно работать хоть из Visual Studio, хоть из командной строки. ARM Mbed имеет собственную систему сборки на питоне (mbed-cli), а также может быть быстро и практически автоматически настроен в PlatformIO, равно как и экспортирован через mbed-cli в проекты для Keil uVision или те же Makefiles.

То же самое касается и отладчиков — слова, не слышанного в мире Arduino. Как правило, любая платформа позволяет использовать старый добрый gdb в связке с любым нравящимся вам JTAG/SWD-отладчиком.

Этот страшный входной порог


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

А ничего. Его уже давно нет. Все перечисленные выше плюшки, сервисы и возможности с точки зрения кривой обучения получаются практически бесплатно.

Например, с RIOT OS «высокий входной порог» от нулевого знакомства с микроконтроллерами до запуска первой программы выглядит так:

  1. Скачать и поставить MinGW, arm-none-eabi-gcc и GNU make (для пользователей Windows 10 первый пункт не нужен, достаточно из Магазина поставить свежую Ubuntu)
  2. Скачать и распаковать последний релиз RIOT с Гитхаба
  3. cd RIOT/examples/hello-world
  4. make BOARD=nucleo-l152re
  5. залить полученный HEX-файл любым способом на Nucleo (в свежих версиях ST-Link это можно сделать просто киданием его на виртуальный диск)

Вся программа, если вы заглянете в main.c, выглядит так:

#include <stdio.h>

int main(void)
{
    puts("Hello World!");

    printf("You are running RIOT on a(n) %s board.\n", RIOT_BOARD);
    printf("This board features a(n) %s MCU.\n", RIOT_MCU);

    return 0;
}

Видите эту страшную инициализацию процессора? Бессонные ночи, проведённые над даташитами? Бесконечной длины вызовы функций SPL? Ассемблер, наконец?

Вот и я не вижу.

В принципе, это был сложный путь. На более простом вообще ничего локально устанавливать не надо — ARM Mbed предоставляет возможность компилировать всё прямо в онлайне.

Давайте сделаем метеостанцию


(не то чтобы я любил метеостанции, просто я сейчас сижу дома с температурой, и помимо всяких сугубо специализированных вещей под разные b2b-проекты, у меня тут из дженерика под рукой только Nucleo-L152RE да несколько плат с BME280 и OPT3001)



1) Регистрируемся на mbed.com.

2) Жмём там кнопочку «Compiler» и попадаем в онлайн-среду разработки. В правом верхнем углу в ней есть кнопочка выбора платы, с которой мы будем работать. Жмём её, во всплывшем окошке жмём «Add board» и выбираем ту версию Nucleo, которая у нас имеется (у меня это L152RE, у вас может быть и другая, а может быть и вообще не Nucleo, это неважно). Вернувшись в окно с проектами, выбираем в той же менюшке нашу Nucleo как текущую плату.



3) Жмём слева вверху New > New Program. Mbed предлагает нам сразу какую-то гору образцов, но по крайней мере для Nucleo-L152 все они притащат с собой старую версию ОС. Мы же хотим новую, свежую, вышедшую три дня назад 5.9.5, поэтому выберем самое простое — «Empty program».

Для дальнейшей работы нам потребуются две вещи — во-первых, подключить собственно исходники mbed, во-вторых, создать и чем-нибудь наполнить файл main.cpp. Для подключения исходников надо не только указать #include, но и собственно импортировать в проект библиотеку mbed-os.

Для этого:

  • Жмём «Import», в открывшемся разделе справа вверху жмём малозаметную ссылку «Click here to import from URL», суём ей вот эту ссылку (при всём страшном виде, это просто ссылка на наиболее свежий релиз Mbed, которую мы взяли со страницы релизов)
  • Тыкаем радиобаттон «Library»
  • В качестве целевого проекта уже сам подставился наш проект
  • Тыкаем «Import»



Теперь жмём на имени проекта правой кнопкой > «New file» > создаём файл main.cpp. Заполняем его тут же самым тривиальным образом:

#include "mbed.h"

DigitalOut led(LED1);

int main()
{
    printf("Hello World !\n");

    while(1) {
        wait(1); // 1 second
        led = !led; // Toggle LED
    }
}

(LED1 уже определён в описании платы — это собственно единственный имеющийся на Nucleo управляемый пользователем светодиод)

4) Жмём Ctrl-D (или кнопку «Compile»), ждём секунд десять-пятнадцать, скачиваем получившийся файл. Подключаем Nucleo к USB-порту (мощная засада: на Nucleo стоят разъёмы mini-USB, шнурок для которых есть уже не у всех и не всегда), обнаруживаем на компьютере новый диск размером 540 КБ с названием «Node_L152RE». Внутри него лежит файл MBED.HTM, недвусмысленно намекающий, зачем этот диск нужен.

На самом деле, конечно, любой кинутый на него BIN- или HEX-файл автоматически прошивается в контроллер, с Mbed это напрямую не связано, просто такой интерфейс программирования.

Кидаем туда скачанный файл. Nucleo моргает светодиодиком программатора, а потом начинает размеренно моргать светодиодом на плате — тем самым LED1.

5) Теперь нам надо добавить датчик BME280, ибо метеостанция у нас или что? Пятнадцать секунд поиска приводят нас к библиотеке с его поддержкой, на странице которой надо жамкнуть «Import Library» (библиотеки, конечно, бывают разные, и всегда стоит смотреть внутрь — но пока опустим эти детали). При импорте не забываем отметить, что это Library, и импортировать её надо в наш текущий проект («Target path»).



Тут же лежит пример использования библиотеки, в котором можно вкратце посмотреть, как ей пользоваться.

6) Добавляем обращение к библиотеке в свой код, заодно убирая из него всякий хеллоуворлд:

#include "mbed.h"
#include "BME280.h"

DigitalOut led(LED1);
BME280 sensor_bme(D14, D15);

int main()
{
    while(1) {
        wait(1); // 1 second
        led = !led; // Toggle LED
        printf("%2.2f degC, %04.2f hPa, %2.2f %%\r\n", sensor_bme.getTemperature(), sensor_bme.getPressure(), sensor_bme.getHumidity());
    }
}

В качестве ножек я, ничтоже сумняшеся, напрямую указал пины, на которые мне в моей Nucleo будет удобно ткнуть I2C-датчик. Вообще, т.к. они прямо на плате подписаны как SDA и SCL (хотя вообще у STM32L1 несколько портов I2C, и каждый можно повесить на несколько вариантов ножек), то, скорее всего, дефайны I2C_SDA и I2C_SCL указали бы на них же. Но мне сейчас тяжело думать о настолько сложных материях.

7) Подключаем датчик. Четыре провода — +3,3 В, земля, SDA, SCL. Так как и STM32, и датчик 3,3-вольтовые, думать о согласовании уровней не надо.



8) Снова жмём «Compile», скачиваем новый BIN-файл и кидаем его в Nucleo.

8) ??????

(на самом деле на этом пункте мы открываем свою любимую терминалку — я обычно использую Termite, и цепляем её на виртуальный порт, соответствующий Nucleo; в современном компьютере это с большой вероятностью будет единственный наличествующий COM-порт. Скорость выставляем 9600 бит/с)

9) PROFIT!!!



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

Глобально — наверное, две вещи. Во-первых, код, крутящийся в while(1) с 1-секундной задержкой — это очень плохая концепция, так как и задержка там не 1 секунда, а 1 секунда плюс время выполнения кода, и мало ли что с другими периодами мы захотим тут ещё запустить.

Во-вторых, 9600 бит/с — это как-то грустно, 2018 год на дворе, давайте хотя бы 115200.

С портом всё просто: надо создать свой экземпляр класса Serial, указать ему нужную скорость, а потом печатать через него.

Serial pc(SERIAL_TX, SERIAL_RX);
pc.baud(115200);

С избавлением от while(1) тоже, впрочем, больших проблем не возникает. В Mbed есть такая штука, как очередь событий (EventQueue), события в которой могут вызываться через заданный промежуток времени однократно (метод call) или постоянно (метод call_every), а результатом их вызова будет выполнение той или иной функции.

Оформляем в код:

#include "mbed.h"
#include "BME280.h"

DigitalOut led(LED1);
BME280 sensor_bme(D14, D15);
EventQueue eventQueue(/* event count */ 50 * EVENTS_EVENT_SIZE);

void printTemperature(void)
{
    printf("%2.2f degC, %04.2f hPa, %2.2f %%\r\n", sensor_bme.getTemperature(), sensor_bme.getPressure(), sensor_bme.getHumidity());
    led = !led; // Toggle LED
}

int main()
{
    eventQueue.call_every(1000, printTemperature); // run every 1000 ms
    eventQueue.dispatch_forever();
    
    return 0;
}

Собираем, запускаем. Работает точно так же, как и раньше (что уже неплохо), но — теперь мы получили решение, которое можно практически неограниченно и без каких-либо проблем масштабировать. Мы совершенно спокойно можем накидать в eventQueue других событий с другими периодами (главное — следить, чтобы одномоментно у нас более 50 событий не жило), и до тех пор, пока их время выполнения не начнёт тупо пересекаться, нам вообще не надо беспокоиться о том, как они взаимодействуют.

Почему?

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

Ладно, теперь давайте добавим сюда OPT3001. Не то чтобы измерение освещённости было обязательной чертой метеостанции, но раз уж у меня есть на столе этот датчик…

С OPT3001 мы имеем некоторую проблему — это очень хороший (и точностью, и особенно энергопотреблением), но не сильно популярный по сравнению с тем же TSL2561 среди самодельщиков датчик, поэтому готовую библиотечку для него прямо в Mbed найти не получается. Я бы сказал, что драйвер для него и самому написать несложно (я писал), но давайте сунемся в гугль — и первой ссылкой обнаружим https://github.com/ashok-rao/mbed-OPT3001.

Снова кликаем Import, выбираем в заголовке малозаметную ссылку «Click here to import from URL», вставляем URL проекта на гитхабе, не забываем тыцнуть пункт «Library» — ну и собственно «Import».

На самом деле нет. Астанавитес.

На самом деле этот драйвер написан настолько на коленке, что его использовать вообще не стоит ни в каком случае. Как однажды сказал великий писатель, «открыв OPT3001.cpp, кровавые слёзы потекли из глаз моих», поэтому я отложил ненадолго все важные дела и быстренько набросал более пристойный драйвер (то есть, теперь я уже дважды писатель драйвера OPT3001).

Далее по известному уже пути: Import > Click here to import from URL > github.com/olegart/mbed_opt3001 > Library > Target Path = наш проект > Import.

Добавляем в проект остатки кода:

#include "mbed.h"
#include "BME280.h"
#include "OPT3001.h"

DigitalOut led(LED1);
BME280 sensor_bme(D14, D15);
OPT3001 sensor_opt(D14, D15);
EventQueue eventQueue(/* event count */ 50 * EVENTS_EVENT_SIZE);
Serial pc(SERIAL_TX, SERIAL_RX);

void printTemperature(void)
{
    pc.printf("%2.2f degC, %04.2f hPa, %2.2f %%\r\n", sensor_bme.getTemperature(), sensor_bme.getPressure(), sensor_bme.getHumidity());
    
    pc.printf("%ld lux\r\n", sensor_opt.readSensor());
    
    led = !led; // Toggle LED
}

int main()
{
    pc.baud(115200);
    
    eventQueue.call_every(1000, printTemperature); // run every 1000 ms
    eventQueue.dispatch_forever();
    
    return 0;
}

Compile, сохраняем файл, кидаем его в Nucleo, не забываем переключить терминалку на 115200…



PROFIT!!!

Бонус: энергосбережение


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

Среди вещей, о которых мы не задумывались, есть такая штука, как энергопотребление. Иногда о нём задумываться, однако, приходится.

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



На моём L152 ток получается в районе 10 мА, немного гуляя туда-сюда в зависимости от свечения LED1, который мы по привычке всё ещё дёргаем (он потребляет 2-3 мА). Как-то довольно негуманно для системы, которая большую часть времени ничего не делает, вы не находите?..

В данном случае нам мешает та самая очередь сообщений, которой мы недавно радовались. Дело в том, что она позволяет задавать тайминги с миллисекундной точностью, а потому работает на быстром аппаратном таймере процессора, выключающемся при уходе последнего в сон — говоря иначе, если процессор заснёт, наш eventQueue.call_every заснёт тоже, причём навсегда. На STM32L151 нет как такового специального быстрого таймера, тикающего во сне — точнее, на некоторых моделях процессора его можно вытащить из обычных часов RTC (начиная с L151CB-A и выше, регистр RTC_SSR), но в общем случае — нет.

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

Но ведь нам же здесь и не нужны миллисекундные интервалы, у нас всё равно данные снимаются раз в секунду? И ведь сообщения нам надо обрабатывать, только когда процессор проснулся, потому что если не проснулся — откуда там сообщения?

Поэтому мы смело берём штуку под названием LowPowerTicker, работающую на RTC, и начинаем переписывать код на ней — благо поменять надо всего несколько строчек. Запустив LowPowerTicker, можно сказать системе sleep() — и она уснёт глубоким сном (ну или, точнее, тем, каким позволяют другие модули — здесь есть нюансы, например, какой-то модуль, ломающийся во сне, может сон на время своей работы запретить).

Но есть одна проблема: вызовы тикера выполняются в прерывании, а в прерывании нельзя делать какие-то долгие вещи — у нас же чтение датчиков очень, очень долгое (у OPT3001, например, от запроса до ответа проходит 100 мс). С printf всё ещё хуже — он ещё и громоздкий, так что в прерывании может тупо не хватить стека. Поэтому нам надо из прерывания послать сигнал функции, собственно читающей датчики и печатающей значение так, чтобы она выполнилась уже в обычном контексте.

Грубым методом было бы устанавливать в прерывании переменную, а в основном контексте читать значение этой переменной в while(1), и если вдруг она взвелась — вызывать чтение датчиков. Но мы же ведь с вами не ардуинщики какие, чтобы в while(1) запихивать осмысленный код?

Внезапно, поможет нам в этом тот же самый EventQueue, который мы только что отбросили.

#include "mbed.h"
#include "BME280.h"
#include "OPT3001.h"

DigitalOut led(LED1);
BME280 sensor_bme(D14, D15);
OPT3001 sensor_opt(D14, D15);
EventQueue eventQueue(/* event count */ 50 * EVENTS_EVENT_SIZE);
Serial pc(SERIAL_TX, SERIAL_RX);
LowPowerTicker lpTicker;

void printTemperature(void)
{
    pc.printf("%2.2f degC, %04.2f hPa, %2.2f %%\r\n", sensor_bme.getTemperature(), sensor_bme.getPressure(), sensor_bme.getHumidity());
    pc.printf("%ld lux\r\n", sensor_opt.readSensor());        
    led = !led; // Toggle LED
}

void tickerIRQ (void)
{
    eventQueue.call(printTemperature);
}

int main()
{
    pc.baud(115200);
    
    lpTicker.attach(tickerIRQ, 1); // every second
    
    while(1)
    {
        eventQueue.dispatch(0);
        sleep();
    }
}

Что мы здесь сделали? Да в общем ничего сложного: добавили Low Power Ticker, который раз в секунду выдаёт прерывание. По прерыванию контроллер просыпается, обработчик прерывания зовёт eventQueue.call, который должен вытащить собственно тяжёлую работу из обработчика во внешнюю функцию (сонливый процессор тут ему не мешает, т.к. у него нет никакой задержки, в течение которой процессор мог бы заснуть — call подразумевает немедленное выполнение). Сам по себе .call ничего бы не сделал, но в основном теле программы у нас снова появился while(1), в котором всего две строки — метод dispatch для очереди, обрабатывающий сообщения в ней, и sleep(), уводящий процессор в сон до следующего прерывания.

Всё.

Заснули > прерывание > проснулись > call > вышли из прерывания > dispatch > сняли показания с датчиков > sleep() до следующего щелчка тикера.

PROFIT???



PROFIT!!!

(на самом деле, 0,57 мА потребления — это очень много, хотя и в пару десятков раз меньше прежнего. Но в Mbed, скорее всего, не учтён неприятный нюанс с процессорами STM32L1: у них по умолчанию ножки стоят в режиме Digital In без подтяжки, а надо бы Analog In или подтяжку включить, иначе триггеры Шмитта на входе этих ножек довольно прилично жрут из-за спонтанных переключений из-за наводок. Кроме того, в Nucleo ток может утекать через ножки JTAG в сторону встроенного на плату программатор-отладчика)

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

Единственной платой стало разве что потребление ресурсов — 55,1 КБ флэша и 9,2 КБ ОЗУ (можно посмотреть, жамкнув «Build details» в логе с сообщением об успешной сборке проекта), но и это для современных контроллеров — не то чтобы гигантские объёмы, даже совершенно типовой 2-долларовый STM32F103CB имеет 128 КБ первого и 20 КБ второго. В принципе же минимальный проект на микроконтроллере и ОС из тех, с которыми работал я, жил на STM32F030F4P6 с 16 КБ флэша и 4 КБ ОЗУ — на RIOT OS со слегка подрезанными крыльями.

Кроме того, в данном случае мы вообще никак не экономили ресурсы, в то время как в приличном обществе за использование float внутри printf на микроконтроллере разработчика просто молча выводят за дверь и расстреливают в коридоре. Ничего при этом не говорят — все и так понимают, за что. Даже malloc лучше, malloc в некоторых обстоятельствах всё же можно простить.

P.S. Для ленивых — написанный здесь код сразу в репозитарии Mbed.

P.P.S. Детали для сборки: Nucleo-L152RE (любая другая Nucleo / Discovery тоже подойдёт, проверьте только, что она есть в списке плат — но там, похоже, все есть), BME280 (внимание: на Али эти платки дешевле стоимости самого чипа не только потому, что китайцы щедрые, но и потому, что на них лепят втрое более дешёвый BMP280, который внешне неотличим). Где вам взять OPT3001 ближе Али — не знаю, если не считать родной девкит TI за три тысячи рублей.

Заключение


Я не хочу сказать, что в мире микроконтроллерных RTOS всё безоблачно, а каждая строчка кода сама собой сочится благодатью — тот же Mbed до приемлемого, с моей точки зрения, состояния дошёл где-то в последнюю пару лет, в RIOT только в релизе 2018.07 исправили часть старых болячек (а часть так и не исправили), и так далее.

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

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

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

Да, можно извернуться и за несколько дней сваять на ардуине кособокое граблеобразное подобие того, что пользователи современных платформ получают из коробки в элегантном отглаженном виде. Можно даже написать на этом какой-то осмысленный проект, который рано или поздно ценой серьёзных затраченных усилий удастся заставить работать и при этом не вываливаться из ресурсов типового AVR.

Но…



Зачем?!

Посмотрите на календарь, 2018 год на дворе! Вам настолько себя не жалко?

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (285):

  1. rub_ak
    /#19003007 / +1

    Извините за оффтоп.
    image
    Годы производства: 1938—2003

    • GarryC
      /#19003143

      «Пусть новые песни пишет тот, у кого старые плохие»

  2. RAF
    /#19003041

    Аж захотелось помигать светодиодом после прочтения!

    • kolemik
      /#19005055 / +1

      захотелось помигать светодиодом

      как вы прошли капчу при регистрации?

      • RAF
        /#19005261 / +2

        В 2006м её еще не ввели, а сейчас бы да. пришлось нанимать человека ;-)

  3. j_wayne
    /#19003089

    > Serial pc(SERIAL_TX, SERIAL_RX);

    Я правильно понимаю, что у этой платы USART доступен через встроенный стлинк и он пишет в виртуальный COM? Это у всех нуклео так? А у плат discovery интересно, так же?

    А то я пытался SWO настроить, в принципе получилось, но IDE (TrueStudio) очень глючит.
    В виндовый стлинк то судя по всему нормально пишет, но я на линуксе, texane/stlink пока не имеет поддержки SWO.

    • olartamonov
      /#19003101

      Да, там две ноги USART с контроллера заведены в ST-Link, а на нём штатный мостик USB-UART. На всех Nucleo так, на Discovery с прошивкой ST-Link/V2-A тоже.

      На платах с USB на контроллере можно также сделать Serial pc(USB_TX, USB_RX), тогда Mbed поднимет USB-CDC и организует выхлоп через него.

      • j_wayne
        /#19004203

        Спасибо. C mbed я уже поигрался, теперь не могу определиться между ST-HAL и SPL.
        Наверное все-таки SPL + свой HAL, чтобы выделить независимую от железа логику.

        Все эти фреймворки идея хорошая, но как правило, принцип Парето в них очень нагляден (сужу по не-embed программированию).
        80% кейсов покрыто замечательно, а чтобы разобраться с остальными 20%, придется потратить 80% усилий)

      • j_wayne
        /#19008233

        Жаль, но конкрентно STM32F4DISCOVERY (STM32F407VGT6) не имет соединений USART контроллера с ST-Link.
        Может кому-то пригодится:

        The ST-LINK/V2-A supports a virtual COM port (VCP) on U2 pin 12 (ST-LINK_TX) and U2
        pin 13 (ST-LINK_RX) but these pins are not connected to the USART of the STM32F407
        microcontroller for mbed support.


        Ман предлагает два варианта:
        1) внешний USB-to-Serial на пинах PA2 и PA3
        2) подпаять PA2 и PA3 к пинам контроллера ST-Link проводами

  4. geher
    /#19003099

    Я не являюсь фанатом Arduino, но все же.
    Внезапно, Arduino<>AVR.
    И развитие ее модельного ряда было совсем не таким, каким вы пытаетесь его показать.
    Ардуино — это экосистема со строгими стандартами, которая включает в себя огромное разнообразие плат (имеющих право именоваться Arduino и просто совместимых), огромное количество периферии (в том числе механически совместимой со стандартными контактами), среду разработки и набор средств разной степени официальности, позволяющих осуществлять полный цикл разработки из других сред (даже в Qt Creator).
    Никто не заставляет оставаться в рамках Arduino Uno и Arduino IDE.
    Оригинальные платы Arduino есть на разных процессорах: AVR, ARM (M0, 101) и даже Intel (Zero). Есть комбинированные платы (Yun, или как-то похоже зовется) на которой помимо AVR установлен второй микроконтроллер, на котором штатно крутится урезанная версия линукса.
    И все это объединено общим стандартом.
    А еще есть огромное количество плат разной степени совместимости и тоже на разных процессорах, в том числе и на ARM (например, Teensy).
    Так что не все так примитивно и устарело в мире Arduino.

    • olartamonov
      /#19003121

      На колу мочало, начинай с начала…

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

      А на ВАЗ 2105 есть крутой стритрейсерский обвес. И даже магнитолу с поддержкой mp3 и блютуса можно поставить.

      • igrushkin
        /#19003155

        все крутые перцы кодят Ардуино либо в VS, либо в Platformio. Убожеством под названием Arduino IDE никто давно не пользуется.
        И действительно, реализация arduino core есть сейчас почти под все. И под STM, и под Cortex

        • olartamonov
          /#19003175

          Да и на ВАЗ 2105 без нормального обвеса только лох деревенский на дорогу выползет.

          P.S. Если не секрет, крутые перцы это с какой целью делают? Самоистязания? Мне трудно придумать, зачем ещё в 2018 г. н.э. использовать платформу, вообще никак не развивавшуюся в течение десяти лет.

          • igrushkin
            /#19003205

            у Вас какая-то фиксация на ВАЗах. Во-первых речь шла про IDE.
            Во-вторых, Вам уже объяснили, что постулат про платформу «вообще никак не развивавшуюся в течение десяти лет» — неверный. Ее развивают другие, в основном Adafruit, просто перенося «быдлокод» на современные МК
            И после упоминания Adafruit. я уже совсем не уверен, что код быдло-
            Покурите их Github, если интресно.
            И потом я еще обяснил, ПОЧЕМУ: биб-ли-о-те-ки.
            Ту же пресловутую погодную станцию, я бы сейчас делал на nrf52 c его аппаратной гибкостью и нижайшим энергопотреблением + arduino core для простоты программной реализации периферии

            • olartamonov
              /#19003243

              Вы не понимаете, что такое развитие платформы.

              Развитие платформы — это современный API, RTOS, многозадачность, нормальная поддержка таймеров и IPC. На скольких процессорах это удаётся скомпилировать — вопрос вторичный, тем более, что и в нём любая современная RTOS оставляет ардуину пыль глотать.

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

              При чём тут «аппаратная гибкость и нижайшее энергопотребление» (оно, кстати, не нижайшее, хотя и достойное), я вообще не понял. В начале этого текста можно с тем же успехом выбрать NRF52-DK и сделать всё то же самое.

              • igrushkin
                /#19003449 / -1

                это современный API, RTOS, многозадачность, нормальная поддержка таймеров и IPC


                Логично, но: покажите мне энтузиаста, типа меня. которому это все нужно?

                • olartamonov
                  /#19003459 / +1

                  Нужно что?

                  Возможность удобно, быстро и аккуратно писать хорошо работающие программы?

                  Ну, не знаю, нужно ли вам это.

                  • Jef239
                    /#19006657

                    Нужно — запустить железку в серию. Собственному коду не важно — макетная покупная плата или итоговая своя.

                    А с MBed — это две большие разницы. Написать проект на стандартную плату проще, зато натянуть MBed на нестандартную плату — намного сложнее.

                    В итоге получается, что проект делится на 3 части:

                    • Прикладная. Отлаживается под Windows/linux, ибо системонезависима.
                    • Системная. В случае MBed — порт на нужный процессор и плату.
                    • Переходный слой. То, что отлично выглядит в MBed.


                    Так вот, переходный слой — он самый простой. И дает куцый опыт.

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

                    Самое главное, что в MBed — огромный разрыв между работой со стандартными компонентами и портированием на свою плату. И величина этого разрыва просто будет мешать его преодолеть.

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

                    Для домашних pet-проектов — удобно, для промышленной разработки — нет.

                    Тот же проект на FreeRTOS перетаскивается за понятное время не только на странный российский ARM, выпущенный тиражом 300 экземпляров в Зеленограде, но и на MIPS, и на прочие архитектуры.

                    А MBed? Вы вот можете назвать трудоемкость переноса MBed на свою плату? А на нестандартный процессор? А на MIPS?

                • dlinyj
                  /#19003463

                  Логично, но: покажите мне энтузиаста, типа меня. которому это все нужно?


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

                  • olartamonov
                    /#19003493 / +1

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

                    Дальше люди делятся на два класса — одни стремятся делать хорошо всё, что они делают руками, а другие «я сделяль, отвалите, мне лучше не надо».

                    Если вы себя и 99 % авторов домашних проектов относите к категории «я сделяль» — ну, это ваши личные проблемы самоидентификации.

                    • dlinyj
                      /#19003907 / +1

                      Вот ведь точно говорят: умные делают из врагов друзей, а дураки из друзей врагов.

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

                      • olartamonov
                        /#19003991

                        Господи, да пожалуйста. Если ещё и избавите меня от вида ваших комментариев, то вообще великолепно же.

                        • dlinyj
                          /#19004007

                          Вы бы ещё мысли по русски научились формулировать.

                          • olartamonov
                            /#19004037

                            Ок, я объясню проще, так как в Армию США, выражаясь иносказательно, вы по одному критерию явно не пройдёте.

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

                            Я буду только благодарен.

                            • dlinyj
                              /#19004113

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

                              • olartamonov
                                /#19004123

                                С такими друзьями врагов им, в общем и целом, не требуется.

                    • avost
                      /#19004575 / +1

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

                      Просто интересно — вы всерьёз полагаете, что если вы для ардуины способны писать только быдлокод, то на другой платформе у вас волшебным образом быдлокод как-то выправится? Удивительная самонадеянность!

                      • dlinyj
                        /#19004581

                        Удивительная самонадеянность!
                        ППКС! Лучший комментарий!

                      • olartamonov
                        /#19004781 / -2

                        Ах, этот свежий приём в дискуссии — ad hominem.

                        • avost
                          /#19007975

                          Абсолютно верно! Именно в это ваше говно я вас мордочкой и ткнул. Там у вас ещё и ошибка генерализации.

              • dlinyj
                /#19003457

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

              • u-235
                /#19003553

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

                • olartamonov
                  /#19003559

                  Вам для понимания тот же простой вопрос: habr.com/post/420435/?reply_to=19003553#comment_19003383

                  На ардуине эта задача чем конкретно с такой же простотой решается?

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

                  • igrushkin
                    /#19004041

                    в середине 90-ых в IBM Россия был легендарный энтузиаст OS/2. который всем показывал, что инструкция JMP CLI 100 (или что-то в этом роде) на ассемблере наглухо подвешивает Win95, а полуось продолжает работать.
                    И что? Где та OS/2 и где Винда?

                    • olartamonov
                      /#19004081 / -1

                      Я так понимаю, вы с Windows 95 OSR2 сейчас нам пишете, если хотите провести аналогии между виндой и ардуиной?..

                      • igrushkin
                        /#19004141

                        забавный Вы :-) я Вам говорю о том, что Вы используете синтетические «потребности», которые не нужны большинству энтузиастов.
                        А НЕэнтузиасты никогда на ардуино ничего и не делали.
                        Но кстати, я написал ниже, что сейчас актуальная фишка — CircuitPython

                        • olartamonov
                          /#19004173 / -1

                          А вот в ФИДО, мир праху его, вас, я так понимаю, не было. Иначе бы вас ещё там отучили бы говорить за всех.

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

                          • igrushkin
                            /#19004195 / +1

                            ахахаха, и это мне говорит проповедник, считающий, что всем надо срочно пересаживаться на RTOS?

                            • olartamonov
                              /#19004243

                              Вы немного не поняли, что я говорю, но в принципе это неудивительно.

                              Я не говорю, что всем надо срочно пересаживаться на RTOS.

                              Я говорю, что весь мир вообще-то уже пересел на RTOS, и если вы не хотите остаться в хвосте и наглотаться пыли, то на RTOS надо срочно пересаживаться конкретно вам.

                              • igrushkin
                                /#19004435

                                странно, что сообщество nrf52 ничего про это не знает.
                                А примеры в СДК для FreeRTOS так и воспринимаются забавной диковинкой

                                • olartamonov
                                  /#19004455 / -1

                                  Ах, эта милая привычка говорить за всех.

                                  Ну, хотите глотать пыль — дело ваше.

                                  • igrushkin
                                    /#19004481 / +1

                                    у Вас не только на ВАЗ, у Вас еше и на ФИДО фиксация.
                                    Доброго времени суток? Всем чмоки в этом чатике?

                                    так вот гляньте BBS Nordic'a, и отыщите там вопросы про RTOS среди тысяч про SDK

                                    • olartamonov
                                      /#19004727



                                      Нет, если вам нужно оправдание чисто для себя, то я могу не мешать.

                              • anprs
                                /#19005057 / +1

                                Остаться в хвосте и наглотаться пыли… в домашних хобби-проектиках?

                              • Jef239
                                /#19006539

                                Что это мне напомнило рассказ Профессия незабвенного Айзека Азимова.

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

                        • Hardcoin
                          /#19004343 / +2

                          Таймеры — это не синтетические потребности. Это явный мастхэв даже для мигания светодиодом. Зачем писать плохо, если можно с меньшими усилиями писать нормально?

                          • igrushkin
                            /#19004443

                            посмотрите пример Blink without delay в быдло-IDE

                            • olartamonov
                              /#19004461

                              www.arduino.cc/en/Tutorial/BlinkWithoutDelay

                              void loop() {
                                unsigned long currentMillis = millis();
                              
                                if (currentMillis - previousMillis >= interval) {
                                  previousMillis = currentMillis;
                                  if (ledState == LOW) {
                                    ledState = HIGH;
                                  } else {
                                    ledState = LOW;
                                  }
                                  digitalWrite(ledPin, ledState);
                                }
                              }


                              Эталонный образец индусятины, а что?

                              • Superl3n1n
                                /#19004539

                                А как нужно написать правильно?

                                • olartamonov
                                  /#19004759

                                  На подсистеме таймеров а-ля LowPowerTicker из примера в посте плюс шедулере ОС. Создаёте столько таймеров, сколько вам надо событий, каждому прописывает такой период, какой нужно этому событию, запускаете это всё — а дальше шедулер сам разберётся, когда, кого и в каком порядке звать.

                                  Здесь же

                                  1) энергосбережение сразу лесом, процессор молотит непрерывно

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

                                  Часть задач в ардуиновском подходе не решается вообще никак (ну, т.е., если на передачу данных модемом нам надо 10-15 секунд, то на эти 10-15 секунд всё остальное заблокировано), другая часть приводит к сну разума, рождающему чудовищ — простыни if'ов, авторы которых пытаются как-то вручную это всё разрулить, чтобы оно более-менее работало.

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

                                  • iig
                                    /#19005249

                                    энергосбережение сразу лесом


                                    В задачах типа «мигать светодиодом» энергосбережение вряд ли кого-то интересует. Да и не умеет ардуина энергосбережения совсем.

                                    масштабирование тоже лесом

                                    Есть куча задач, которые нет особенного смысла масштабировать. Научился мигать светодиодом (щелкать релюшкой и прочее ногодрыжество) — ну ок. Научился мигать десятком — ну тоже ок. Дальше мигать в 1000 светодиодов?
                                    если на передачу данных модемом нам надо 10-15 секунд, то на эти 10-15 секунд всё остальное заблокировано

                                    Прерывания не?

                                    А в нормальной системе про такие вещи часто думать вообще не надо, надо просто пользоваться правильным API


                                    Говнокод — это когда не думая копипастят какие-то куски кода и считают, что это правильно.

                                    • zloe_morkoffko
                                      /#19005271 / +2

                                      Говнокод — это когда не думая копипастят какие-то куски кода и считают, что это правильно.

                                      Так это и есть главная парадигма «разработки» на ардуино! Нахватать библиотек отовсюда, слепить их кое-как и воскликнуть «It's alive!»

                                      • iig
                                        /#19005473 / +2

                                        habr.com/post/420435/#comment_19005293

                                        Сейчас вот ковыряю STM32F437 — даташит там огромный, но черт возьми, зачастую проще его почитать и написать хорошо, чем взять готовую либу и потом недоумевать, почему при одновременной работе карты памяти и дисплея через некоторое время идет порча буфера i2c


                                        Зато не ардуина.

                                      • geher
                                        /#19006087

                                        Библиотеки не копипастят, а подключают по необходимости, используя готовое решение. И как правило это не "отовсюда", а от производителя модуля.
                                        В ардуиномире обычно (наверное, 99 процентов случаев) библиотеки просто реализуют работу с каким либо внешним модулем. Разве что, в отличие от обычной практики, библиотеки каждый раз пересобираются вместе с проектом.

                                        • zloe_morkoffko
                                          /#19006821

                                          Вот отличный пример работы с библиотекам на ардуино — habr.com/post/392931 Можно было бы подумать, что автор посмотрит diff, сделает merge, вдруг там поправили ошибки, сделали что-то быстрее. Но нет! Copy-paste наше все.

                                    • smart_alex
                                      /#19005451

                                      Да и не умеет ардуина энергосбережения совсем.


                                      Как это не умеет Ардуина энергосбережения? А как же батарейные долгоживущие nRF24 датчики на Pro Mini со сроком службы 1-10 лет (в зависимости от режима). Пишу этот коммент и мне весело подмигивает светодиодом раз в несколько минут такой датчик (и делает это уже больше года).

                                    • ArbeitMachtFrei
                                      /#19005459

                                      > Да и не умеет ардуина энергосбережения совсем.

                                      Ардуина не умеет. А AVR — умеет (пусть и не очень хорошо, но все же).

                                    • holomen
                                      /#19006191

                                      Да и не умеет ардуина энергосбережения совсем.

                                      Скорее ардуйнутые не умеют энергосбережение совсем. И не только энергосбережение. Т.к.
                                      Говнокод — это когда не думая копипастят какие-то куски кода и считают, что это правильно.

                                      А если не нашлось откуда скопипастить, то
                                      Да и не умеет ардуина энергосбережения совсем.

                                      • iig
                                        /#19006279

                                        Ну, покажите тогда, какой функцией из ардуиновского API реализовать энергосбережение. Мы же сначала читаем документацию?

                                        • holomen
                                          /#19008809

                                          На ардуино-апи свет клином не сошелся. И никто не запрещает обращаться к железу напрямую. Потому можно, например, так. По желанию собрать в библиотеку.
                                          Теперь вы знаете откуда скопипастить. :)

                                          • iig
                                            /#19009269

                                            Если не использовать ардуиновского API, можно получить разные результаты… Но зачем тогда стенания про то, какая ардуина ущербная, если ваша прошивка ничего ардуиновского не содержит?
                                            Обращаться к железу напрямую можно, конечно. Но ведь ардуиновское API как раз затем, чтобы так не делать.
                                            Трюк с deep sleep с помощью watchdog забавный. Но нет у меня уверенности, что все 100500 ардуиновских библиотек с ним совместимы. Если уж копипастить, то примеры из avr-libc.

                                  • smart_alex
                                    /#19005409

                                    Часть задач в ардуиновском подходе не решается вообще никак (ну, т.е., если на передачу данных модемом нам надо 10-15 секунд, то на эти 10-15 секунд всё остальное заблокировано)


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

                                    • GarryC
                                      /#19005575

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

                                  • Vanellope
                                    /#19007279

                                    А шедулер ОС разве не в цикле loop крутится?

                                    • ArbeitMachtFrei
                                      /#19007441

                                      Планировщик и ардуиновский loop() — две большие разницы. На ARM Cortex, например, планировщик обычно вызывается по прерыванию от таймера SysTick (он для этого «официально» предназначен), может (в системах с кооперативной многозадачностью, например, это единственный способ перейти к нему) вызываться из всякого рода delay(), taskYIELD() и тому подобных функций ОС.

                        • poznawatel
                          /#19006759

                          мы пишем на Micropython, интересно, CircuitPython по сравнению с ним какие имеет сильные-слабые стороны? На CircuitPython учебные материалы есть на русском?

              • anprs
                /#19004869

                Ардуина же продолжает плодить быдлокодеров

                Воу-воу-воу, полегче.

                Если ардуина используется где-то в продакшене, это по меньшей мере странно. Если для какого-то домашнего хобби-проекта, то почему бы и нет. Индусский говнокод, конечно, остаётся говнокодом, но… Ваша какая печаль? И при чём тут вообще дуина?

                • olartamonov
                  /#19004883 / -1

                  Моей печали вообще тут нет. Равно как и вашей, поэтому я даже не буду задавать запредельно бессмысленный вопрос, зачем вы пишете комментарии без печали.

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

                  • anprs
                    /#19005025 / +1

                    Ну в две последние категории обычно попадают люди навешивающие ярлыки.

                  • geher
                    /#19005073

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

                  • c_kotik
                    /#19007531 / +1

                    Вы, увы, такой же публичный выступающий, орущий ВАЗ Ардуино говно. Ваши самоделки на ней — говно.
                    Нет, статья иногда даже хороша. Но в следующих публикациях постарайтесь вкладывать больше смысла и соответсующей ресурсу тематики и поменьше своего эго. Оно у вас недружелюбное и навязчивое. Это не пикабу всё таки.

      • geher
        /#19003347 / +2

        Быдлокод внутри ардуины пишет в большей части пользователь. И другая платформа не сделает волшебным образом этот код лучше.
        Программировать под ардуину можно в разных IDE и без использования ардуиновской библиотеки.
        Так что с этой стороны проблем у ардуины как раз нет.
        А вот огромное количество периферии, которое подключается стандартным образом без плясок с бубном (в том числе благодаря наличию готовых библиотек) в наличии.
        Помигать светодиодом просто на любой платформе.
        А вот легко и просто подключить GSM модуль можно только к ардуине (воткнул шилд сверху, подключил библиотеку — и вперед. И то же самое для многих других модулей.
        Назовите платформу с такими же возможностями и с таким же многообразием поддерживаемых модулей. Имено потому из всего разнообразия начинающий пользователь с большей вероятностью возьмет ардуину UNO и будет вставлять в нее готовые шилды. А потом перейдет на ардуину посерьезнее или с другим форматом платы и будет подключать модули (опять же, готовые, причем готовые вплоть до библиотек, позволяющих подключать эти модули без изучения документации на микроконтроллеры и прочие микросхемы. И может быть только потом заинтересуется другими платформами.
        Да, для других платформ тоже формируются экосистемы с простыми готовыми решениями. Но с многообразием доступных модулей там пока до ардуины как до Луны пешком.
        Кстати, единственная причина, по которой я выбрал именно ардуину для своих поделок — наличие готового механического решения для подключения разнообразных готовых модулей без проводов и без оглядки на толерантность выводов микроконтроллера к +5 (большинство доступных модулей до сих пор заточено на такое напряжение).
        Похожая ситуация с Raspberry Pi и конкурентами. Можно сколько угодно спорить о том, что конкуренты и круче, и дешевле, и вааще, но когда начинающий пытается что-то сделать, то он получает большее количество готовых и, что важно, сразу работающих решений (в том числе просто механически подключаемых) именно на Pi, а не у конкурентов.
        И другой процессор в новых ардуинах — не крутой обвес для 2105. Это другой движок вкупе с коробкой передач.
        И формфактор у ардуин самый разнообразный (одна линейка Lillypad чего стоила).

        • olartamonov
          /#19003383 / +1

          А вот легко и просто подключить GSM модуль можно только к ардуине


          Ах, эта вечная железобетонная уверенность ардуинщиков, что они впереди планеты всей.

          os.mbed.com/teams/components/code/GSM

          (так получилось, что я неделю назад проект на Mbed сделал — ничего сложного, nRF52 непрерывно собирает из эфира данные BLE-устройств и биконов, парсит их для Eddystone, немного сортирует, матчит разные пакеты по MAC-адресу, складывает в архив и отправляет его по 3G на удалённый MQTT-брокер в формате JSON)

          Но вы мне лучше простую вещь про быдлокод скажите. Вот мы тут в примере выше совершенно элементарно завели систему с потенциально огромным количеством задач (LowPowerTicker'ов можно заводить столько, на сколько хватит ОЗУ), красивым выводом обработки из прерывания и энергосбережением. Всё это — пользуясь стандартным API, причём довольно базовыми вещами в нём.

          На ардуине эта задача чем конкретно с такой же простотой решается?

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

          А от этого мимические морщины и следы на белых футболках, сами понимаете. Хотелось бы избежать.

          • geher
            /#19003469

            Ах, эта вечная железобетонная уверенность ардуинщиков, что они впереди планеты всей.
            os.mbed.com/teams/components/code/GSM

            Ох уж это выборочное чтение. Это только часть решения. А у ардуины есть и вторая — готовый модуль (с антенной и слотом для SIM карты), который механически вставляется в контакты платы.

            • olartamonov
              /#19003501 / +1

              То есть расположение разъёма для плат расширения на Nucleo вам ничего не напоминает.

              Ок, а также ок.

              • geher
                /#19003593

                Я пробовал подключать GSM шилд к трехвольтовым платам, толерантным к 5 вольтам.
                Но шилд в этом случае не всегда нормально воспринимал данные по UART.

                • esaulenka
                  /#19003757

                  Шилд «абстрактный в вакууме»?
                  Если посмотреть документацию на модем (хоть симком, на котором любят делать у нас и в Китае, хоть квиктел, который продают на arduino.cc), напряжение на ногах модема не должно быть выше 2.8… 3 вольт.
                  Т.е. там ДОЛЖНЫ быть преобразователи уровня.

                  Оригинальная плата использует полноценные буферы, подключенные к ардуинным 3.3 вольтам (и, к слову, они превышают максимальные 3.1 вольта для квиктела). Трёхвольтовые сигналы от основного контроллера для этой схемы — как родные.

                  Какой китаец так умудрился сделать преобразователь, что он якобы не работает с трёхвольтовыми сигналами, надо разбираться

                  • olartamonov
                    /#19003809

                    У китайцев там с большой вероятностью конвертер на BC847 и паре резисторов, который герои из Simcom ещё для SIM800 рекомендовали как штатную схему.

                    Для SIM5300 (у него I/O вообще 1,8 В), слава китайским богам, официально рекомендуется нормальный транслятор TXB0108 — который, впрочем, китайцы всё равно вряд ли будут ставить, ибо дораха.

                    • esaulenka
                      /#19005181

                      Я недостаточно чётко сформулировал вывод. Там ключевое «якобы не работает». Потому что буфер там должен быть, а сделать буфер (хоть отдельной логикой, хоть на транзисторе), который будет работать от 5 вольт, но не будет работать от трёх — надо отдельно постараться.

                  • geher
                    /#19005031

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

                    • esaulenka
                      /#19005189

                      Ок. Тогда вывод надо делать «у меня (подчёркнуто) что-то где-то когда-то не заработало».

                    • ArbeitMachtFrei
                      /#19005913

                      > Потому берется то, что попадается под руку.

                      Ну удачи вам и всего такого.

          • smart_alex
            /#19005499

            А то я каждый раз, когда вижу подобный треш и угар


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

          • esaulenka
            /#19005759 / +2

            os.mbed.com/teams/components/code/GSM

            Я уж было решил, что вот оно — счастье, меня сейчас быстренько научат правильно писать драйвер модема.
            Но нет же. Отправляем команду, и ждём ровно один ответ («OK», как правило). Если в этот момент нежданно-негаданно прилетит URC, она улетит в /dev/null.

            Спасибо большое, такое г. я и сам понаписать могу.

        • GarryC
          /#19003397 / +1

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

          • Hardcoin
            /#19004367 / +1

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

            • olartamonov
              /#19004429

              Ну, паять и не на Metcal'овских станциях обычно учатся, с другой стороны.

              P.S. Хотя после них чем-то другим пользоваться трудно, почему-то уверен, что если подниму этот вопрос, услышу много мнений о незаменимости купленного на Али люкея.

              • JerleShannara
                /#19005461

                Подброшу пахнущего на вентилятор тогда, на работе сижу на MX-5000, что не мешает мне дома не плеваться от 203го квика.

            • holomen
              /#19006225

              Вы для саморазвиия поглядите здесь на статьи GarryC и про то какие они «стабильнее и яснее».

              • Hardcoin
                /#19006333

                Хорошо, ознакомлюсь. Я сам не очень в теме, просто исхожу из логики комментария


                Сама ардуиновская библиотека написано плохо
                ардуино заточено под быстрое выполнение несложных проектов (для целей обучения)

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

                • GarryC
                  /#19010461

                  Неистово плюсую — именно это мне и не нравится в Ардуино — то, что «это могут увидеть дети».

        • RPG18
          /#19003599

          в разных IDE

          Не очень понимаю фетишизма по поводу IDE, когда можно использовать cmake, а там и QtCreator и CLion.

          • poznawatel
            /#19006773

            Если б ещё бакалавры после профильного ВУЗа владели этим cmake…

            • RPG18
              /#19010755

              Я был бакалавром и самостоятельно овладел cmake.

        • holomen
          /#19006213 / +1

          Программировать под ардуину можно в разных IDE и без использования ардуиновской библиотеки.

          Вот только это уже не будет программирование под ардуину.
          Так что с этой стороны проблем у ардуины как раз нет.

          Нет, т.к. по сути и ардуины уже нет.

        • vasimv
          /#19006413

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

          • ArbeitMachtFrei
            /#19006725

            А еще можно кашу сварить из топора. Говорят, неплохо получается.

            • vasimv
              /#19008099

              Ну, одна из самых больших претензий к ардуине — что IDE плохонький. Ну да, плохонький, вот вам хороший…

              • ArbeitMachtFrei
                /#19008127

                IDE плохонький. Стандартные платы ничего интересного не представляют (https://xakep-archive.ru/xa/122/100/1.htm ). Библиотека — настолько «тонкая прослойка» между avr-gcc и высокоуровневым кодом, что отказаться от нее можно при первой же возможности (нет, не надо рассказывать про отличные от AVR платформы). Что остается-то?

          • GarryC
            /#19010531

            К сожалению, нельзя. У родных МК вообще с отладкой было никак, а загрузчик УАРТ отладку не поддерживает в принципе.

    • j_wayne
      /#19004223

      А мне вот даже для DIY как-то перестало хватать одного USART и пр.
      Atmel платы, аналогичные хотя бы банальному blue pill, какие-то очень уж маргинальные и стоят дорого.
      И перспектив, видимо, никаких.

      • JerleShannara
        /#19005477

        А чем вам кЕтайские на STM32F4 не нравятся? USART-ов дофига, всякиx USB/CAN/SPI/I2C тоже ложкой кушать можно.

        • j_wayne
          /#19006127

          Отчего же не нравятся? Я же blue pill в пример привел, у которого тоже USART не один.
          Я скорее про arduino vs stm32.
          Оригинальные демоплаты мне нравятся тем, что на них сразу есть стлинк, все заведомо работает как надо. Разница в цене для меня несущественна. А вот в конечных DIY-устройствах использовать такие платы конечно невыгодно.
          Сам не считаю ардуино вселенским злом. С него легко приобщиться к МК и цифровой электронике. А говнокодинг он везде говнокодинг. Кто-то хочет развиваться и делать лучше, кто-то нет. ИМХО дело не только в ардуино.

    • ArbeitMachtFrei
      /#19005099

      > (Yun, или как-то похоже зовется) на которой помимо AVR установлен второй микроконтроллер, на котором штатно крутится урезанная версия линукса

      Да-да, есть даже анекдот про это:

      Кабинет ветеринара. Входит медведь с белкой на голове.
      Доктор: — На что жалуетесь?
      Белка: — Да вот, к хвостику что-то прилипло…

      > Оригинальные платы Arduino есть на разных процессорах… и даже Intel (Zero).

      Ага-ага. Называлась эта штука Intel Edison Kit for Arduino, и при всей ее мощности (Atom с тактовой частотой 500 МГц, 1 Гб ОЗУ, 4 Гб флеша, Yocto Linux и так далее) «официальные» примеры исчерпывались морганием светодиодом и работой с датчиком по I2C. Зачем для этого «ардуина с Intel» стоимостью около 100$, когда с теми же задачами прекрасно справляется и обычная ардуина с AVR?

      • geher
        /#19005175

        Не путайте. Intel Gallileo, Intel Edison — продукты, с которыми интел пытался влезть в эту нишу.
        А есть просто ардуина на интеловском чипе — Zero.

        • ArbeitMachtFrei
          /#19005187

          store.arduino.cc/usa/arduino-zero

          «The board is powered by Atmel’s SAMD21 MCU, which features a 32-bit ARM Cortex® M0+ core.»

          • geher
            /#19005255

            Прошу прощения, перепутал. zero на ARM.
            101 на intel (не атом)

            • ArbeitMachtFrei
              /#19005907

              А один хрен этот интел на фоне какого-нибудь TI CC26xx или аналогов от Nordic Semiconductor (если нам уж так важен BLE) выглядит бледно.

            • geher
              /#19006101

              Точнее там Curie, в которой x86 Quark.

      • GarryC
        /#19005191

        Не, всего лишь 50$, это же почти даром… с учетом ВайФая на борту :).
        В общем, эту платформу Интел толкал-толкал, да утомился и бросил на фиг.
        Но у меня остался экземпляр для музея.

        • ArbeitMachtFrei
          /#19005231

          ЕМНИП, 50$ стоил только сам Edison, а демо-плата к нему — еще полтинник. Ну а как Интел «толкал» эту платформу — заслуживает отдельного разговора. С одной стороны — такие вот статьи «а вот вам ардуина за сотку баксов»:

          habr.com/post/256089

          а с другой — кривоватая и неполная документация (скажем, найти документ, где было бы описано назначение джамперов на Kit for Arduino — задача нетривиальная).

          • GarryC
            /#19005577

            Но схема есть, мне в принципе ничего больше не надо, кроме времени.

            • ArbeitMachtFrei
              /#19005713

              Когда я ковырялся с эдисоном, схему этой «переходной» платы найти не удалось. Может, плохо искал.

  5. igrushkin
    /#19003107

    Начинал с Ардуино. потом перешел на nrf52 c его SDK
    Могу сказать, что причина, по которой Ардуионо будет еще жить десятилетия — это библиотеки. Хочешь подлючить датчик — нашел библиотеку на Github и через 5 мин все работает.
    А потом попробуйте подключить тот же bme280 к nrf52 в рамках SDK
    Но есть компромисс: nrf52 с Arduino core :-)
    Точно так же было с esp8266: он не взлетел, пока Иван не написал для него arduino core

    • olartamonov
      /#19003137

      Я не очень понимаю условие «в рамках SDK».

      А с какой конкретно целью это надо делать именно в рамках SDK? ОС использовать религия не велит?

      • igrushkin
        /#19003147

        А зачем мне какая-то непонятная ОС? Там офигенный SDK, очень крутое коммьюнити, SDK нативно взаимодействует с их ВТ стеком

        • olartamonov
          /#19003183

          А. Ну, ок, мучайтесь дальше.

          • Peacemaker
            /#19003845 / +1

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

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

            С уважением.

            • olartamonov
              /#19003859

              Ардуина в её текущем виде тупо вредна.

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

              Поэтому ардуине как массовой платформе надо умереть и уступить место платформам более нормальным.

              • dlinyj
                /#19003939 / -1

                … толпы быдлокодеров, железобетонно уверенных в своей правоте.


                Боже, вы так точно себя характеризуете! Заметим, что ардуинщики с пеной у рта, так как вы тут не доказываете единственность пути. Они лишь использует тот инструмент который им удобен.

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

              • iig
                /#19004791

                Поэтому ардуине как массовой платформе надо умереть и уступить место платформам более нормальным.


                А ардуинщиков на лесоповал. А тех кто еще и быдлокодеры — на костер.

              • Bobnecat
                /#19006385 / +3

                Что за термин такой «быдлокодер»?
                — Наверное это человек с профессией программист ведущий себя по хамски!?

                • da-nie
                  /#19007917

                  К сожалению, тут есть неопределённость. :) Обычно, это все, кто пишут иначе, чем ты. :)
                  Но (!) я всё-таки встретил на своём пути эталонный образец подобного существа:
                  — Полное отсутствие желания вникать в проект. Отсюда — что скажете, то и напишу. Была где-то максима, что программиста следует оценивать по числу предусмотренным им ситуаций. Так вот, так как вникать в проект не планировалось, то и ситуации будут реализованы только те, которые ему написали. Остальное не его дело.
                  — Программа абсолютно нечитаема. Она написана без форматирования вообще, в ней сплошные магические числа. Редкие комментарии. Функции на 400-1000 строк. Если надо сделать одно и то же действие, но над разными элементами массива — делается столько одинаковых функций, сколько массивов. Инкапсуляцию не применяем вообще. Глобальные переменные легко и просто определяются внутри 5000 строчного файла в любом месте. Имена этих переменных могут быть a1,a2,a3. Вся огромная (да-да, программа нужна очень сложная) программа в одном или двух файлах. Язык понимается плохо. Структуры не используются из идеологических соображений («я их не люблю» было мне сказано).

    • esaulenka
      /#19003611

      попробуйте подключить тот же bme280 к nrf52

      За час переписать read()/write() adafruit'овской библиотеки?
      Или за день раскурить даташит bme и построить очередной велосипед?

      • dlinyj
        /#19003943

        Мне кажется за день даташит BME не раскуришь. Там какие-то хитрые фильтры.

  6. tretyakovmax
    /#19003113

    А как там обстоят дела с платами типа хендмэйд? Можно ли запилить поддержку своей, с блекджеком и дамами легкого поведения?

    • olartamonov
      /#19003135

      Конечно. Можно просто утащить Mbed на локальный комп и там в targets описать свою плату как отдельную сущность, можно выбрать максимально похожую и подрихтовать нужные значения в рантайме.

      P.S. Вообще для более-менее серьёзной разработки Mbed всегда утаскивают локально — там будет сильно больше настроек, чем в онлайне. Ту же скорость stdout'а можно просто в JSON-описании проекта указать сразу.

      • tretyakovmax
        /#19003153

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

        • olartamonov
          /#19003187

          Я дальше буду про RIOT.

          Он чуть менее отполированный и автоматический, зато позволяет проще понять, как это всё устроено.

      • Exeland
        /#19003405

        А откуда тащить? Как сохранить код из Mbed Compiler на локальный комп?

        • olartamonov
          /#19003427

          Вариант раз: https://github.com/ARMmbed/mbed-cli

          Вариант два: https://habr.com/post/358682/

          Любой код добавляется локально через mbed-cli add, во всех проектах на mbed.com в кнопочке Import есть два пункта — в Compiler или в mbed-cli

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

  7. kurojneko
    /#19003161 / +1

    Человек который явно раскурил все эти самые даташиты, и периодически светит знаниями и выводами из этих самых даташитов, говорит что даташиты тут не нужны )

    • GarryC
      /#19003249

      Ну действительно не нужны в наше время даташиты, не надо повторять устаревшие данные. Сейчас в любой системе разработки (навскидку — CCS, Synergy, Simplicity, ASF ...) вся работа с периферией перекрыта многими слоями софта, единственное, что нужно действительно знать — что Вы хотите получить.

      • olartamonov
        /#19003271

        Если говорить точнее, то работу можно спокойно разделить.

        Один человек ковыряет нижний уровень, и ему не надо знать ничего про верхний, кроме каких-то прилетающих оттуда хотелок типа «а можно с медленного таймера в L1 получить не секунды, а миллисекунды?».

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

        • GarryC
          /#19003433

          Да Вы знаете, Олег, сейчас уже и не нужно ковырять нижний уровень — он достаточно хорош из коробки.
          Я недавно поработал с ССS в плане EasyLink, потратил дня два, чтобы разобраться с работой SD карточки в этой библиотеке, проклял TI несколько раз (как правило, по делу) но в конце концов убедился, что у них все хорошо и вряд ли я сделаю лучше (а такое заявление от меня дорогого стоит).

          • olartamonov
            /#19003447

            Ну CCS — да, это чудище обло, озорно, стозёвно и лаяй, зато там работает вообще всё и из коробки. Масштаб поддержки TI'ного железа там пугает.

            А в том же RIOT мы довольно много в своё время на низком уровне написали, в том числе такую вещь, как миллисекундный RTC-таймер на STM32 — который основные разработчики ОС вряд ли сами будут реализовывать, потому что это такой костыль для тех, у кого LPTIMER'ов нет, и не на всех STM32 он работает.

            Но опять же, у меня сидит программист верхнего уровня, пишущий вещи типа поддержки электросчётчиков или протоколов NFC-карт, и всё, что он знает про rtctimers-millis — это тезис «на задержках от 10 мс используй только его».

  8. Reason89
    /#19003475

    Что касается абзаца про смерть AVR и исторического использования этих МК. На мой взгляд это можно сказать про Mega, Xmega и их ARM МК. Xmega и ARM от Atmel не смогли завоевать популярность народа(в России точно). Семейство Mega не обновляется и эти контроллеры все еще используются электронщиками со стажем, которые к ним привыкли. Но у Atmel есть семейство 8 битных Tiny. Которое постоянно обновляется, пользуется спросом и имеет куда более богатую аналоговую периферию и больше таймеров чем тот же STM32F030(который привели для сравнения).

    • olartamonov
      /#19003523

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

      Сейчас TI их пробует придавить немного, уже месяца три целенаправленно рекламируя младший MSP430 (25 центов штука, и это каталожная цена) в качестве альтернативы мелкой логике — при том, что TI сам является крупнейшим производителем этой логики.

      ARM'ы у Atmel, кстати, интересные, у нас ATSAMD51 довольно много лежит — пока не пригодились, в проекте, под который их взяли, в итоге оказалось по мощности достаточно более отработанного STM32L4, но в принципе интересная штука. Что-то типа $4,50 было за контроллер на 120 МГц и с развитой периферией.

      • Reason89
        /#19003663

        Для примера Tiny с которой недавно сталкивался: Attiny1616
        На мой взгляд это МК, не для замены мелкой логики=)
        Хотя не спорю, у всех задачи в плане разработки стоят разные. И понятие мелкая логика у каждого в плане масштабности несет разный характер в зависимости от уровня знаний и размеров схем, в которыми он работает.

      • igrushkin
        /#19004127

        ARM'ы у Atmel, кстати, интересные, у нас ATSAMD51 довольно много лежит

        Ви таки будете смеяться, но Adafruit их как раз сейчас активно продвигает. Через CircuitPython

        • olartamonov
          /#19004149

          Ну, Адафрут мне побоку, а вот как я писал официальную объяснительную, что обязуюсь E54 Xplained Pro в продукции военного назначения не использовать, это было смешно.

          Два месяца почти несчастную девборду покупали, блин.

  9. xztau
    /#19003609

    88% на АРМ. DIY'щиков опросили что ли?

    причём она делилась как минимум на три семейства: AVR, PIC и STM8

    Это популярные в массах.
    В автомобильном транспорте, например NEC. Теперь renesas очень много поставляет.

    • olartamonov
      /#19003641

      • Methodology: A web-based online survey instrument based on the 2015 annual survey was developed and implemented by independent research company Wilson Research Group on February 20, 2017 through to April 15, 2017 by email invitation.
      • Sample: E-mail invitations were sent to subscribers to EETimes and Embedded.com and related brands with reminder invitations sent later. Each invitation included a link to the survey and an incentive to participate.
      • Returns: Data is based on 1,234 valid respondents for an overall confidence of 95% ± 2.8%. Confidence levels vary by question.

      Ну и Renesas у них в опросе в районе топ-15 вендоров, что, полагаю, примерно долю конкретно автопрома в электронике и отражает.

  10. Reason89
    /#19003625

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

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

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

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

    • olartamonov
      /#19003645

      Ок. Возьмите RTOS, в которой не используется STM32 HAL, в чём проблема?

      скорость работы UART


      Вызов pc.baud(int baudrate) требует полноценного чтения документации? Что именно вы в ней планируете прочитать?..

      • Reason89
        /#19003747

        C RTOS я особо не работал, разве что читал цикл статей по FreeRTOS в одном журнале. Но мне кажется, что и там скорее всего найдется то, что потребует более углубленного изучения.
        К тому же изучение Reference Manual на тот же FreeRTOS(с которым я более менее знаком) займет не на много меньше времени, чем изучение документации на HAL.
        Но это опять же, сугубо мое мнение.

        • olartamonov
          /#19003761

          Любая RTOS даст вам немножечко больше возможностей, чем один только HAL. На порядок-два где-то.

    • Armleo
      /#19005935

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

      А можно убрать один флаг при компиляции и они сами уберутся :-/

      • Reason89
        /#19006013

        По подробнее с этого места пожалуйста)

      • Konachan700
        /#19006839 / +1

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

  11. Programmer74
    /#19003687

    А как насчет NuttX или ChibiOS? Вроде у обоих HAL хороший, POSIX-совместимость заявлена, есть коммьюнити.

    • olartamonov
      /#19003695 / +1

      Можно. Здесь вообще выбор очень большой, Mbed в данном случае мне нравится как отличное средство для первого шага — онлайн-компилятор, приятный API, простой импорт стороннего кода.

      Дальше я планирую RIOT OS вообще рассматривать.

    • Exeland
      /#19005237

      поправочка — Chibios не POSIX-совместима.

  12. olekl
    /#19003893 / +1

    Я как-то уже писал про mbed. Да, мигание светодиодом пишется очень быстро, но когда вдруг оказывается, что в цикле «мигнуть, подождать секунду» светодиод мигает в несколько раз чаще, чем раз в секунду, начинается самое интересное :) А еще интереснее, когда нужно поработать с датчиком, критичным ко времени между импульсами, а все прослойки mbed занимают столько времени, что ты в требуемый интервал ну вообще никак не укладываешься. Leaking abstraction в очень ярком проявлении :)

    • olartamonov
      /#19003987

      Несомненно, вы сможете посоветовать нам среду, в котором гарантируете отсутствие ошибок.

      • olekl
        /#19004189

        Если средой считать RTOS и даташиты контроллера, то да :) А из ембед-подобных штук может быть удобным взять инициализацию железа, к примеру, а более-менее серьезные вещи все равно нужно будет писать на весьма низком уровне…

        • olartamonov
          /#19004293

          Показать ошибку в STM32L151CBU6A, которой нет ни в даташите, ни в errata?..

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

          Функционалу, который в прошивку на RTOS добавить — дело ну максимум недели.

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

          А когда ещё отдел закупок в своём клювике принёс пожелание скорейшего переезда на другую линейку процессоров, которая на доллар дешевле…

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

          И это всё коммерческие проекты коммерческих компаний.

          • olekl
            /#19004317

            Так а я разве говорил про без РТОС? Без РТОС я вообще не представляю, как можно что-то более-менее серьезное сделать. Хотя заказчика пришлось очень долго в этом убеждать, к счастью, убедили… Но одно дело РТОС, а другое — классы на с++, инкапсулирующие низкоуровневую работу с контроллером…

            • olartamonov
              /#19004371

              Задач, в которых надо в бешеном темпе вручную дёргать ножкой процессора, в мире крайне мало (но да, я помню, как мейнтейнеры RIOT меня бурно убеждали, что проверка if (gpio == GPIO_UNDEF) в обработчике gpio_read — это невероятная тяжесть реализации).

              Задач, в которых в контроллере вот именно ядро вот именно вычислениями загружено настолько, что у него лишней микросекунды нет, ещё меньше.

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

    • da-nie
      /#19005865

      А еще интереснее, когда нужно поработать с датчиком, критичным ко времени между импульсами


      Во-во. У меня была игрушка с энкодером ЛИР-120. Частота импульсов — до десятков МГц (до 10000 об/мин ).

      • Armleo
        /#19005945

        У STM32 обработчик encoder-а частота 48мгц и выше, как так получилось что вы в него упёрлись?!

        • da-nie
          /#19006017

          Это был PIC, а не STM32.
          А с аппаратным обработчиком проблем не будет, разумеется.

  13. Doktorov
    /#19003919 / -2

    Микроконтроллер по цене Rapsberry Pi zero w. Спасибо, но нет, кушайте это г… сами. У меня дома всё на ESP8266 построено, ничего сложно в написании кода под неё нет.

    • olekl
      /#19004325

      А сможете сделать на нем анализатор спектра аудиосигнала в реальном времени?

      • GarryC
        /#19004375

        Задайте полосу и количество частотных сегментов — будет конкретный ответ.
        А общий ответ — можем, только полоса будет 300 Гц (это аудио) и уровень 1/0 (это анализатор).

  14. REPISOT
    /#19004001

    Видите эту страшную инициализацию процессора?

    Нет. Не вижу. Я НЕ вижу на какой частоте работает ядро, на какой USB, что идет на таймеры и АЦП. По этому коду нельзя установить ничего.

    • olartamonov
      /#19004013 / -2

      Ещё ассемблерного листинга не видите, чтобы компилятор зорким глазом проверить.

      Всё остальное можно посмотреть в описании платы на гитхабе, если эти параметры вам настолько важны.

      • REPISOT
        /#19004031 / +1

        А при чем тут плата? плата может все. А что ДЕЛАЕТ КОД?

        • olartamonov
          /#19004059 / -1

          Вы себе вообще представляете, что такое HAL? Который не библиотека, как тут многие считают, а Hardware Abstraction Layer?

          В проекте с HAL и с нормальной структурой этого проекта есть три отдельных уровня:

          1. Взаимодействие с процессором (работа с его регистрами)
          2. Описание платы (модель процессора, его базовые настройки, используемая периферия и её настройки)
          3. Пользовательский код


          В рамках индусской простыни, конечно, можно это всё смешать в одну кучу, чтобы пользовательский код настраивал частоту USB.

          Но только в рамках индусской простыни.

          В нормальном проекте это разные его части.

          • REPISOT
            /#19004333

            Вы не правы. Вы написали 6 строчек кода, и утверждаете, что инициализация ядра не нужна.
            Кто выбирает источник тактирования, частоту, делители?
            Что будет делать контроллер при ошибке пуска внешнего кварца? И прочее…
            А с какой скоростью будет передавать UART?
            Ах, это все равно НАДО прописывать отдельно на другом уровне абстракции?..
            Или все решил проектировщик ОС? А откуда он знает, что мне надо? Все равно переписывать…

            • olartamonov
              /#19004397

              Кто выбирает источник тактирования, частоту, делители?


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

              Что будет делать контроллер при ошибке пуска внешнего кварца? И прочее…


              Логика определена в драйвере этого процессора.

              А с какой скоростью будет передавать UART?


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

              Ах, это все равно НАДО прописывать отдельно на другом уровне абстракции?


              Кому-то надо, кому-то не надо. У вас каждое из разрабатываемых вами устройств имеет свою, уникальную и неповторимую, частоту процессора? Если нет, то я облегчу вам жизнь — можно каждый раз её заново не прописывать.

              То же самое, что интересно, касается где-то так 90 % параметров, которые между разными устройствами меняются крайне редко.

              P.S. И всё-таки не очень ясно, как вы миритесь с существованием языка C и компиляторов — откуда их авторы знают, какой ассемблерный код вы хотите получить?

              • REPISOT
                /#19006767 / +2

                Что будет делать контроллер при ошибке пуска внешнего кварца?
                Логика определена в драйвере этого процессора
                Ничего подобного. У STM есть ветка (по-умолчанию пустая), куда переходит программа при сбое HSE.

                А с какой скоростью будет передавать UART?
                Параметры указаны в описании платы.
                В описании платы? То есть ТОЛЬКО ГОТОВЫЕ платы? А не ардуинщик ли вы?
                Я говорю про UART контроллера. Который НАДО настраивать.

                У вас каждое из разрабатываемых вами устройств имеет свою, уникальную и неповторимую, частоту процессора?
                У нас устройства могут иметь одинаковую частоту, но кто вам сказал, что она должна совпадать с «указанной в описании платы»?

                • ArbeitMachtFrei
                  /#19006795

                  > У STM есть ветка (по-умолчанию пустая)

                  А разве это не определенная в драйвере конкретного MCU логика? У STM32 так, у какого-нибудь LPC17xx — иначе.

                  > В описании платы? То есть ТОЛЬКО ГОТОВЫЕ платы?

                  Описание платы — в Mbed это несколько файлов типа таких: github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM/TARGET_STM32F1/TARGET_BLUEPILL_F103C8 — можно (нужно) сделать самостоятельно под любое новое устройство, и указать там те параметры, которые хочется.

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

                  • REPISOT
                    /#19006949 / +1

                    Ну вот и вернулись к инициализации ядра, изучению периферии и прописыванию всего этого в коде.

                    • ArbeitMachtFrei
                      /#19006995 / -2

                      Вот вам пальцем показали — вся инициализация ядра, вся работа с периферией в достаточном для простых проектов виде УЖЕ включена в состав ОС. Что еще надо? Или вас not invented here беспокоит?

              • Jef239
                /#19009617

                А с какой скоростью будет передавать UART?
                Параметры указаны в описании платы.
                ЧТО? Нет возможности динамически менять скорость UART???

                Если это правда, то получается, что значительную часть работы с устройствами надо будет писать самостоятельно.

                • ArbeitMachtFrei
                  /#19010597

                  Где-то в середине исходной записи можно прочитать примерно такое:

                  С портом всё просто: надо создать свой экземпляр класса Serial, указать ему нужную скорость, а потом печатать через него.

                  Serial pc(SERIAL_TX, SERIAL_RX);
                  pc.baud(115200);


                  Но если в 90% проектов на конкретной плате UART используется для печати диагностических сообщений — не проще ли перенести эту инициализацию в «конфигурационный» файл?

                  • Jef239
                    /#19011085

                    У нас область специфическая — GPS. Связь с приемниками — через UART. Выдача результатов наружу — опять UART. Как пример, обмен с NV08C начинается на 4800, 8N1 (NMEA), а потом переходит на 115200, 8O1 (!!!) (проприетарный протокол). Так что что скорость надо менять динамически. Кроме того, 8O1 — это девятибитные байты (8 бит данных и бит четности).

                    Ну и желаемое качество драйвера UART — 1 сбой на 10^7 байт.

                    • ArbeitMachtFrei
                      /#19011221

                      А кто запрещает менять что скорость, что формат (https://os.mbed.com/docs/v5.9/mbed-os-api-doxy/classmbed_1_1_serial_base.html#a768f1e9fd9e14c787f693745fa2538a4 ) динамически в случае того же Mbed? Для официально поддерживаемых платформ драйвер должен все это позволять.

                      • Jef239
                        /#19011309

                        Судя по доке, 8O1 умеет, а 9N1(программная проверка четности) — уже нет. Хотя большинство портов физически это могут.

                        Ну да дело не в этом. Основная преграда для использования MBed — поддержка только Cortex-M. Поэтому переносимый куда угодно (включая MIPS) FreeRTOS и свои драйверы.

                        • ArbeitMachtFrei
                          /#19011349

                          На самом деле довольно легко притыривать драйверы из других ОС в ту же FreeRTOS, иногда довольно сильно упрощает жизнь.

                          • Jef239
                            /#19011463

                            Ну лучше не тянуть целиком, а брать идеи.

                            В целом, если понятно, что изделие разовое и надо написать побыстрее — то почему бы и не MBed. А если нам нужно будет портировать черти куда — лучше FreeRTOS.

  15. REPISOT
    /#19004025

    Очень интересно что там с дебагом при он-лайн компиляции?
    А если интернет пропал — все, кина не будет?

  16. mkulesh
    /#19004135

    Уважаемый автор, спасибо за познавательную, обоснованную и интересно написанную статью. Пишите ещё. Для меня программирование микроконтроллеров — это чистое хобби. Мне интересно Ваше мнение как профессионала — а остались ли ещё области, где RTOS в принципе не подойдёт по каким-то причинам? Причём я говорю только про ARM, AVR не рассматриваю.То есть когда может возникнуть необходимость (если вообще есть) взять, и написать, например, асинхронную подсистему ввода-вывода самому? Например, есть ли потребность в асинхронном вводе-выводе с максимальным использованием DMA (если мы говорим про STM32) и если да, то как широко DMA поддерживается имеющимися RTOS? Или ещё ситуации, когда именно нужно взять мануалы, чистый HAL (опять же, я говорю про STM32), и писать вот эти все ЕventHandlers, таймеры, асинхронный на прерываниях самому? Или сегодня, в 2018 году, таких ситуаций в принципе нет?

    • olartamonov
      /#19004225

      Остались, конечно.

      Есть масса маленьких контроллеров, например, с 2 КБ и меньше памяти. Есть специфические проекты разные, где проще написать сразу руками.

      Но с другой стороны, я вижу довольно много проектов, которые начинались с «проще написать всё руками», а потом резко забуксовали, когда от заказчиков/продажников начали приходить пачки требований на новый функционал — и быстро выяснилось, что в bare metal проект его добавлять-то на порядок сложнее, чем в проект на RTOS.

      Например, есть ли потребность в асинхронном вводе-выводе с максимальным использованием DMA


      В Mbed ввод-вывод асинхронный уже давно из коробки. В остальных RTOS — где как, в основном это определяется тем, дошли ли у разработчиков руки. В RIOT последнем, например, DMA к UART уже прикрутили, но по факту пока не используют, чтобы не менять API (и, по-моему, зря).

      Или ещё ситуации, когда именно нужно взять мануалы, чистый HAL (опять же, я говорю про STM32), и писать вот эти все ЕventHandlers, таймеры, асинхронный на прерываниях самому?


      Довольно мало, они экзотические и их стоит по возможности избегать.

      • Jef239
        /#19006519

        Вы лучше расскажите, сколько времени займет портирование MBed на собственную плату с STM32H7. Или на 1870ВЯ1Я (тоже «своя» плата, точнее заказчиков).

        Потому что написание кода для готовых плат — это хорошо для домашней разработки, не более. За сколько времени будет портирован FreeRTOS и наши драйверы — я знаю. А за сколько MBed?

        Довольно мало, они экзотические и их стоит по возможности избегать.
        Ну не особенно это экзотика — делать примерно одно и то же, но на той плате, которую хочет заказчик и теми фишками, что заказчик хочет.

        Ну как пример: импортозамещение. То есть все то же самое, но на российских или почти российских ARM. Думаете это экзотика?

        • ArbeitMachtFrei
          /#19006723

          На собтвенную плату (с поддерживаемым Mbed процессором) — ну, скажем, 1 рабочий день (включая сюда такие необходимые действия, как попить кофе, почитать хабр и тому подобные), надо описать всякие штуки типа источника тактирования, назначения выводов и так далее:

          os.mbed.com/docs/v5.9/tools/adding-and-configuring-targets.html

          На новый процессор, при наличии для него CMSIS-Core — ну не знаю, порядка недели-другой. Наличие драйверов под другую ОС или хотя бы отлаженных примеров по работе с периферией может серьезно упростить процесс:

          os.mbed.com/docs/v5.9/reference/porting-targets.html

          • Jef239
            /#19009589

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

            На новый процессор, при наличии для него CMSIS-Core — ну не знаю, порядка недели-другой.
            Глянул — поддерживаются только Cortex-M.

            То есть это vendor lock, точнее cortex-M lock.

            С другой стороны, при использовании FreeRTOS, времена примерно те же. Зато мы не ограничены даже миром ARM, не то что Cortex-M.

            Так что ежели где-то маячит импортозамещение, MBed сильно усложнит задачу.

            Ну как пример: российское, ОЗУ от 512К, ПЗУ от 512К — найдете Cortex-M? Мы нашли 1879ВЯ1Я, но это ARM1176-JFZ-S. А потраченное время на портирование FreeRTOS + написание драйверов — того же порядка.

            Для нас — выгоды не вижу. Механизм для асинхронного вызова процедур у нас есть свой, работает и под linux и под FreeRTOS. Ну да, чуть красивей на MBed пишется. но не более того.

            • vvzvlad
              /#19010239

              Как будто кто-то топит именно за Mbed. Куча же RTOS разных, бери, не хочу.

            • ArbeitMachtFrei
              /#19010289

              Скажу так — мой опыт работы именно с Mbed — нулевой :) Я уже умножил «на пи и на е» — хотя разницы, скажем, с RIOT OS (где принцип конфигурирования похож) в целом нет.

              FreeRTOS — отлично, особенно — если под нее уже есть драйверы, желательно — более-менее грамотно написанные и переносимые. В RIOT или Mbed драйверы периферии под всякую экзотику (1879ВЯ1Я, наверное, немного не для них, а вот Миландровская продукция — в самый раз), конечно, придется писать самому — а вот для внешних устройств они будут «в комплекте» (хотя толку от этого, с «импортозамещением»?).

              • Jef239
                /#19011123

                А какой смысл отказываться от заказов импортозамешенной базе? Если заказчик платит, то почему бы не сделать?

                А драйвер ком-порта на 1879ВЯ1Я мы написали за 3 дня. Там что-то очень похожее 16550, так что вспомнил юность и написал.

                Переносимость… ну даже для STM32 это фикция. F4/F7/H7 — имеют немного разные порты. Приходится #ifdef в драйвере писать.

                • ArbeitMachtFrei
                  /#19011307

                  Если импортозамещение «настоящее» — то такой же импортозамещенной должна быть и периферия (то есть не только миландровский MCU, но и все остальное). Главное, умножать цену и время разработки на пи или пи-квадрат :)

                  Писать middleware самостоятельно — занятие похвальное, но для тех же STM32 в любой нормальной современной ОС все #ifdef уже написаны (в качестве примера можно поглядеть на тот же Mbed или RIOT:

                  github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM
                  github.com/RIOT-OS/RIOT/blob/master/cpu/stm32_common/periph/uart.c

                  Единый API для «стандартной» периферии типа UART или SPI здорово упрощает жизнь, все-таки. В FreeRTOS его нет, там только более-менее нормальная работа с процессами.

                  • Jef239
                    /#19011449

                    Если импортозамещение «настоящее» — то такой же импортозамещенной должна быть и периферия
                    Да, само собой, включая корпус. Это не совсем настоящее импортозамещение — 1879ВЯ1Я делается где-то на тайване (TMSC?). Но по документам проходит. Там даже ПЛИС российская.

                    для тех же STM32 в любой нормальной современной ОС все #ifdef уже написаны (в качестве примера можно поглядеть на тот же Mbed или RIOT:
                    Мда… Глянул :(

                    MBed — нет поддержки STM32H7.
                    RIOT — 6 портов вместо 9 на SOC (8 реально используется).

                    То есть все равно допиливать руками. И или пропихивать свои правки в master или при каждом обновлении возиться с переносом.

                    Единый API для «стандартной» периферии типа UART или SPI здорово упрощает жизнь, все-таки. В FreeRTOS его нет, там только более-менее нормальная работа с процессами.
                    Как будто нельзя самому написать API? Религия запрещает?

                    Самодельный API высокого уровня на UART — работает не только в embeded, но и linux, windows и прочих ОС. И позволяет не только UART, но и TCP, UDP и файлы.

                    Самодельный API низкого уровня — работает поверх очередей FreeRTOS. В итоге он обслуживает не только физические UART, но и UART, организованные на ПЛИС.

                    Ну и, повторюсь, основной профит — это то, что мы не зажаты в рамках Cortex-M. Даже в рамках ARM не зажаты.

    • Jef239
      /#19006499

      Ну как пример — наш проект. Начали с MS-DOS, потом Windows, QNX, FreeBSD, linux, сейчас — FreeRTOS. Соответственно, система ввода-вывода — своя, прикладному коду все равно, на Linux он работает или на почти голом железе. Есть вызов CHAN_Getc(), он дает байт. А откуда этот байт прилетел… Да хоть по TCP/IP, хоть с нашего собственного драйвера на 1879ВЯ1Я.

      Собственно на любом российском чипе — в лучшем случае linux и FreeRTOS без драйверов. Хотите избавится от монстра под названием linux — значит ввод-вывод пишете свой.

      А linux — это огромный монстр. 12мегов ПЗУ, 16 мегов ОЗУ — это примерно минимум. На голом железе хватает STM32F7 — мег ПЗУ, полмега ОЗУ.

  17. sim-dev
    /#19004175

    Я только одного не понял: чем долгая работа в прерывании отличается от долгой работы в функции, вызываемой из прерывания? Разве что во втором случае расходуется еще больше стека…
    Или метод call ставит вызов в очередь, а осуществляется этот вызов в dispath? Из статьи как-то не просматривается…

    • olartamonov
      /#19004193

      Да, call ставит в очередь, а обрабатывает эту очередь уже dispatch.

  18. gerasimenkoao
    /#19004215 / +1

    Как обычно, мнения разделились.
    Кто-то с криками за Фродо Ардуино, бросился отстаивать честь любимого IDE, кто-то говорит — старье.


    BMW, ВАЗ… молоток, он не менялся столетиями.


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


    STM8 — отличная альтернатива раскрученной ардуине — плата разработки за 1$!!!


    О вкусах не спорят, а пиво я люблю "резаное" ;-)

    • Dima_Sharihin
      /#19004553

      У STM8 самую малость дорогой компилятор (IAR), на случай, если у вас больше 8 килобайт флеша.

      • tretyakovmax
        /#19004597

        Зачем, если есть Cosmic
        New!!! STM8 free tools with no limits + STM32 free tools up to 32k

  19. AVI-crak
    /#19004341

    Увлекательный бой между слепцами и глухонемыми. Одни не видят, другие не могут объяснить.
    В мире мк у всякого направления есть своя колея, если в неё попасть — то выбраться уже почти невозможно. Колея настолько глубокая — что двигаться можно только в одном направлении, вперёд. Шаг в торону — и вас затопчут свои-же.
    А мне пофиг.
    Беру то что требуется в данный момент и переделываю под себя.

  20. iAmGeorge
    /#19004381

    Ардуину можно купить за 100р на али подождав 2 недели или за 300р на ближайшем радиорынке, какую другую платформу можете предложить по данным критериям доступности и цены?

    • olartamonov
      /#19004405

      Угадайте, за сколько на Али можно купить плату на STM32.

    • GarryC
      /#19004423

      Blue pill — 117 на Али с доставкой. И Вы даже можете подключить к ней датчики для Ардуино.

  21. AlePil
    /#19004441 / +3

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

    • olartamonov
      /#19004467 / -3

      Нет никакого инакомыслия.

      Есть группы людей, пытающихся убедить окружающих, что писать индусский быдлокод — это хорошо и правильно.

      • dlinyj
        /#19004557

        Можете по именам перечислить таких людей, которые говорят, что только ардуино, а всё остальное — фигня? Или что вот говнокод хорошо, а то что вы предлагаете плохо?

        Я видел только откровенные нааезды от вас, но не виел ни одного выпада в вашу сторону от них. Хотя вы их обвиняете, что они пытаются в чём-то убедить. Можно конкретные ссылки?

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

        • olartamonov
          /#19004777

          Намёками, вижу, вы не понимаете.

          Не отвечай глупому по глупости его, чтобы и тебе не сделаться подобным ему;
          не отвечай глупому по глупости его, чтобы он не стал мудрецом в глазах своих.

          — Книга притчей Соломоновых, 26:4

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

          • dlinyj
            /#19004793

            Слив засчитан. Вы не отвечаете за свои слова перед аудиторией хабра.

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

            • olartamonov
              /#19004819

              Ну, значит, она сейчас сольёт мне карму и заминусует статью. К счастью, этот ваш тезис легко проверить.

              • dlinyj
                /#19005035

                Самые заминусованные комментарии в этом посте — ваши. А статью я плюсанул, так как с общим подходом я согласен. И я рад, что есть нормальные инструменты.

                Я опять же подчёркиваю, что идейно я с вами согласен. Не согласен с методами которыми вы несёте эту идею.

      • Lerk
        /#19004677

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

        Что касается ардуины в целом, как явления, то это замечательная штука, приобщившая к электронике множество людей. Ваша попытка сказать людям, что 32битные контроллеры классно подходят для начинающих, очевидно, совершенно некорректна. Новичок закроет вашу(без сомнения классную) статью еще на этапе таких слов, как HAL и IPC. А если даже пролистает эту часть до собственно инструкции, то упадет вот тут: make BOARD=nucleo-l152re просто не поняв, куда это вообще надо вводить и что это за магия. По сравнению с вашей инструкцией скачать ардуино IDE и нажать «аплоад» первого сектча — элементарно. И это будет реально быстрый старт.

        Те же, для кого это — работа, имеют достаточно веские причины для работы на том или ином мк.

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

        • olartamonov
          /#19004797 / -3

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

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

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

          Скажите, вы на основании чего так лихо оскорбляете такое количество людей?

          • Lerk
            /#19004859 / +1

            Я считаю, что каждому — своё. Старому дедушке, который всю жизнь крутил гайки на заводе ГАЗ, вполне посилам освоить Arduino IDE. Ваш маршрут — нет. Или вы всех меряете по себе? Успешному программисту средних лет?) Реальность сложнее.

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

            Не надо присваивать мне чужие слова, а потом за них же спрашивать, это таки не вежливо.

            • olartamonov
              /#19004865 / -2

              А вы на основании чего берётесь других людей по категориям распределять и решать, что им доступно, а что — нет?

              • Lerk
                /#19004877 / +1

                Как и всякий другой человек, я имею право на своё мнение. Вы хотите меня этим попрекнуть?) Это, право, смешно!

          • geher
            /#19004981

            Интересные выводы.
            Только на самом деле человек может не копать глубже не потому, что не может, а потому, что ему некогда. Он занят другими делами, и тратит крохи свободного времени на увлеченме, силясь малыми затратами времени и усилий получить зримый результат.
            Есть еще и другой вариант. Чтобы человек занялся соответствующим делом, часто его нужно просто заинтересовать. Если вы сразу забьете ему мозг высокими материями, то ему станет скучно, и он забьет. А если ему подсунуть нечто более простое, что небольшими усилиями позволит получить сравнительно сложный результат (не просто помигать светодиодом, а сбацать нечто с экранчиком, датчиками и т.п.), то он заинтересуется и, может быть, дальше будет заниматься всеми этими скучными вещами, чтобы получать интересные результаты уже на другом уровне. Причем для некоторых даже С/С++ сложно. И они начинают с графических конструкторов для программ. И только потом, заинтересовавшись, они переходят на реальное написание программ.
            Что интересно эти моменты в той или иной степени применимы и для других областей человеческой деятельности.
            Подозреваю, что могут найтись и другие причины для выбора в пользу ардуины, пока не создано другой платформы с подобной экосистемой.
            Только что-то мне подсказывает, что даже если эта гипотетическая платформа будет основана на самом пальцованном ARM, она будет ардуиноподобной, простой, с максимальным сокрытием от простого пользователя (заметьте, не разработчика, а именно простого пользователя) всех нюансов и тонкостей.

            • olartamonov
              /#19005011

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


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

              • geher
                /#19005159

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

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

                • geher
                  /#19006113

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

            • seri0shka
              /#19005573 / +1

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

      • Mogwaika
        /#19008113

        Можно например утверждать, что правильнее всего мигать лампочкой ножкой ПЛИСины и такой точности и изящности мигания используя встроенные digital clock manager-ы и всё такое, не даст никакой контроллер, ни с free-rtos, ни ардуиной, ни с ассемблером.
        Но это же не значит, что все, кто не пишут на vhdl дураки?

  22. sguslya
    /#19004873 / +1

    Весь этот тред про сравнение теплого с мягким. Уж коли пошла тема про тачки то расскажу что мой тесть, живет в Эстонии, и он купил в позапрошлом году новую Ниву, не спрашивайте почему, у него была своя логика. Одна знакомая имеет новенький bmw120 и считает что на нем она легко делает в потоке амгэшные гелики 6.3. А дизайнер с прошлого проекта вообще предпочитает самокат.
    Так что мир это такая многоликая штука, и у ардуино есть отличное место под солнцем на поляне школьников и всякого рода энтузиастов. Топикстартер всего лишь вносит свой вклад в отодвигании ардуины от вкусного многомиллиардного рынка.
    Скажем ему за это спасибо и прекратим ненужный хейтинг в комментариях, аминь;)

  23. Skiffrusspb
    /#19004917 / +1

    Интересно. Но не уверен что буду использовать. Для моих поделок можно, но…
    Для мелких задач у меня горсть Tiny85
    Для средних, не требовательных, Mega328
    Это для ардуиновских поделок.
    Ну а где надо быстрее-мощнее-больше прерываний — уже STM32. И вот тут уже вправду можно попробовать задуматься об ОС. Но таких задач у меня не много. Из десятка F103-их использовал пока только 4.
    Ну… это со стороны самодельщика.

    А по поводу похорон ардуины… Я это воспринимаю как очередные похороны айфона. Его всё хоронят и хоронят, а он как был, так и есть.

    • olartamonov
      /#19004935

      А по поводу похорон ардуины… Я это воспринимаю как очередные похороны айфона. Его всё хоронят и хоронят, а он как был, так и есть.


  24. DIHALT
    /#19005023 / +2

    Фи, а я люблю ардуинщиков. Вы просто не умеете их готовить. Подавляющее большинство моих заказчиков сначала натыкалось на них, они им делали прототип. Это им заказчик трахал мозги по ходу осознания своих потребностей и бесконечных переделок и изменений ТЗ. Причем трахал задешево для себя (ибо их как грязи и они дешевы). Когда же это при попытке вытащить со стола в реальное железо работающее в реальных условиях разваливалось, глючило и не работало, банально из-за непонимания физики процессов и все эти ардуинщики обсерались, то заказчик уже выходил на меня. С уже проработанным ТЗ и понятными нюансами решения его задачи. А я тут, на всем готовом, выкатываю заказчику свою цену. Причем он уже не охреневает от циферок, т.к. дешевых разработчиков он наелся.

    • dlinyj
      /#19005041 / +1

      Ди, ты пропустил праздник такого эпичного срача :)

      • DIHALT
        /#19005047 / +1

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

        • dlinyj
          /#19005077

          Да ладно тебе, надо иногда и мозги разгружать.

      • RAF
        /#19005389

        Они еще на Олега и нажаловались -)

        • dlinyj
          /#19005407

          Он уже поплакался об этом? По моему вполне справедливо. Он очень не этично себя ведёт. Я бы сказал по хамски.

    • sguslya
      /#19005111

      Я на ардуино+акселерометр+Lora +… скрутил работающий прототип продукта по контролю активности коров, нет, ну серьезно, разметка данных, машинное обучение на сервере, обучение модели, выгрузка центроидных векторов на ардуино по Lora, все очень так научно и красиво.
      Работающий продукт на ардуино я делать конечно же не буду, но прототип получился годным, так что всему свое применение найдется в этом мире;) ИЧСХ не тратил время на разработку устройства, купил втупую готовую ардуино compatible за 100 евро, да дорого, но зато быстро.

    • Armleo
      /#19005967

      Тот самый DIHALT?


      Удачи тебе с землёй, а я блин + с — ом перепутал на плате, теперь сижу тоже переделываю на 4000 штук платах, ибо заново заказывать Дорохо.

      • vvzvlad
        /#19010253 / -1

        Как вы смогли перепутать плюс с ТИРЕ?

  25. Konachan700
    /#19005293 / +3

    На мой взгляд, ОС на микроконтроллере, даже на Cortex M4/M7, надо использовать только при крайней необходимости, когда обслуживается действительно много сложных разнородных задач. Ибо многопоточность, даже на одном ядре — это адский головняк в плане синхронизации, плюс потеря перфоманса на переключение контекста. Да и всякие HAL стоит использовать осторожно, постоянно смотря в их исходники — там иногда откровенная индусятина встречается или баги.
    Сейчас вот ковыряю STM32F437 — даташит там огромный, но черт возьми, зачастую проще его почитать и написать хорошо, чем взять готовую либу и потом недоумевать, почему при одновременной работе карты памяти и дисплея через некоторое время идет порча буфера i2c… И самое главное — без фанатизма: если HAL лучше написать самому под конкретный проект — это быстро и не так сложно — то какую-нибудь библиотеку окошек для UI или криптографию стоит взять из проверенных источников, а не костылить годами свой велосипед.

    • JerleShannara
      /#19005569

      Сча дам облом из реальной жизни в подарочной упаковке:
      Одну девайсину, которая должна была что-то уметь и быть себе USB Device, я начал писать на STM32F1xx, кое-как отладил, прилетело желание «и в хвост и в девайс», окей, проектик быстро переехал на F2xx (тот, который о двух USB), далее прилетело пожелание «хватит и одного, но быстрого и вообще», проект перелетел на F4xx.
      Во сколько человеко-часов вы оцениваете эти два переезда, если мы не используем SPL/HAL?

      • Konachan700
        /#19005629

        Я так делал, тоже F1->F2->F4 прошел. F1->F2 — все переписывать, они разные. F2->F4 — мелкие правки. Но я не говорю, что всё прямо фигачить на ассемблере — без фанатизма — взять ту же libopencm3, которая по факту обертка над регистрами и дефайны, так переезд вообще безболезненный будет.
        Но зато когда надо будет реализовать, например, USB c двумя парами endpoints, времени на разгребание лапши SPL/HAL уйдет намного больше. Или когда начнет не хаватать времени где-то в критичных местах, и надо будет эти жирные абстракции выпиливать.

        • JerleShannara
          /#19005643

          На перепиливание HALа под композит у меня ушло 4 часа и три перекура. А libopencm3 — этол тоже вариант HALа.
          Ещё тогда вопрос, про нелюбимый вами куб — сколько времени у вас займет выбор камня, удовлетворяющего условиям ТЗ и имеющего минимальную стоимость, плюс вычада распиновки для разработчика печатной платы.

          • Konachan700
            /#19005815

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

        • Gryphon88
          /#19005651

          Вопрос немного не в тему: каждый раз, как надо было реализовать USB более чем с 2 парами endpointов, приходилось писать кучу в общем-то boilerplate кода и лезть в кишки HAL (пробовал ASF, libopencm и по-пионерски, на регистрах). То есть это не я дурак, а правда нет удобного инструмента?

          • Konachan700
            /#19005705

            Нет, нету. Я размышлял на тему такой проги, и сделать красиво ее — само по себе крайне трудно. А если она будет замороченной — она не нужна.

            • Gryphon88
              /#19005767

              Танцевать придётся от дескрипторов (просто больше неоткуда), благо, под них инструмент уже есть. Но всё равно пользователь должен будет знать, что:
              — есть эндпоинты и потоки
              — эндпоинты разные, выбирать их надо в зависимости от назначения
              — общаться можно просто стучась в эндпоинт и через feature
              — …
              Т.е. всяко прочитать минимум USB in a nutshell придётся.

    • olekl
      /#19007523

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

  26. vasimv
    /#19005297

    А там есть визуальный выбор функций пинов с проверками конфликтов и прочим, аналогичный STMCubeMX? А то как-то грустно на STM32-ах без него.

    • Konachan700
      /#19005393

      А зачем это нужно вообще? В даташите есть таблица всех AF на пинах — она куда более информативна, чем та штука с пинами из куба. Дальше при разводке схемы сразу дописываешь в аннотацию, что тут висит на ноге (А12/AF3/SPI-MISO). При написании кода берешь эти данные и всё ок. Откуда конфликты пинов вообще вылезают?
      Куб делает отстойный код, качеством уровня ардуино. Для академических целей и прототипов всё ок, но в прод его ставить никак нельзя.

      • vasimv
        /#19005505

        Вариантов слишком много и есть много неочевидных моментов, чтобы без углубленного чтения даташитов не напортачить. Для новичков уж точно. Не говоря уже просто о собственно выборе микроконтроллера, когда после долгого траха с вроде подошедшим микроконтроллером — его пять USART и три I2C превращаются в «только три USART и три i2c, и без возможности загрузки на переставленном USART1 и без нужного количества входов АЦП».

        • Konachan700
          /#19005579 / +1

          Про выбор… В первый прототип тянем самый жирный МК из семейства и смотрим что нам надо. Ну или берем плату, на которой таковой жирный контроллер стоит. Это таки не FPGA, и цены тут плюс-минус $5 в рознице, для отладочных целей не критично. Определяемся с фичами. По результату будет идеально точное попадание в цель, без промахов. Делать подбор по кубу — сомнительная затея.
          Для новичков же куб бесспорно хорош. Да, код не оптимален и не расширяем, но в целом все красиво и достаточно удобно.

  27. GarryC
    /#19005411

    Кстати, об индусах…
    Как верно заметили, никакая, самая лучшая среда, не спасет от криворукого программиста.
    Честно говоря, я совсем не в восторге от mbed (и здесь я солидарен с ТИ), но его нельзя назвать совсем уж плохим, но открываем раздел CODE на сайте, видим в наиболее популярных os.mbed.com/users/simon/code/TextLCD, открываем сырки и видим… все тот же Ардуино (без delay, блин) стиль во всей его красе.
    Ну и на фига тогда было от Ардуино уходить?

  28. lamerok
    /#19005489 / +2

    Отличная статья, надо сыну дать почитать, чтобы понял как разработка устройств делается. Спасибо!

    • smart_alex
      /#19005589 / +1

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

      • Am0ralist
        /#19006443

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

        • smart_alex
          /#19006621

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

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

          Причём, что интересно, с ним никто не спорит что STM32 и операционные системы это хорошо и никто не ставит под сомнение его квалификацию как специалиста. Речь идёт только о том, что Олег являет собой яркий пример «узкого специалиста, подобного флюсу» по меткому выражению Козьмы Пруткова или, другими словами, техно-гоблена, по не менее меткому выражению Сергея Голубицкого. То есть человека с мировоззрением с ноготок и не желающего ничего видеть и понимать в жизни, кроме даташита на STM32.

  29. hobbyte
    /#19005509 / +1

    Вот, вторая статья с «Быстрый старт с (RT)OS» и у неё нет тэга соответствующего… 1я статья.
    Сейчас вот, потихоньку, ковыряю книги по Си и статьи по FreeRTOS, ибо мне показалось что без планировщика не получится.
    А всего-то, хочу ESP к древней Roomba-е прикрутить. Можно пинать.:)

  30. A__D
    /#19005565 / +1

    Мда. Видимо это всё навеяно недавней статьёй — habr.com/post/419445 и у автора этого топика от неё пригорело. Только вот подход в этой статье аналогичный ардуино-кодингу, только «вид сбоку», когда ничего не изучая — бери и клепай себе, не думая как оно работает… потому и рождаются тысячи топиков потом на форумах:
    — Я вот тут взял либу, вот тут соеденил как вот там вот советовали, а оно ни работаеееттт!!1 Памагите, че исправить, а лучше дайте готовый скетч, пасиба!

    • smart_alex
      /#19005621 / +1

      Вы немного не в курсе, у автора пригорело, когда ему указали, что он несёт откровенную чушь с трибуны технического университета на головы доверчивых студентов:

      https://habr.com/post/413779/

      А автор к такому не привык. А то, что на его ляпы ему указал (посмел указать) какой-то «ардуинщик» автор воспринял как личное оскорбление. И понеслось… У той статьи 286 комментариев. :)

      • A__D
        /#19005665 / +1

        Таких подробностей не знаю) Мне показалось странным поведение, плодить по сущности тоже самое, на что недавно «бочку катил». Я сам далеко не за ардуино-подход в обучении, только за, если человек разберётся (более менее в целом хотя бы, не обязательно до последнего регистра всё знать, имхо) как оно работает и будет сам творить дальше то, что ему хочется, а не искать либы и писать по форумам — чего не пашет то, ведь в одной статье прочитал, что «бессонные ночи над даташитами» не нужно проводить…

        • smart_alex
          /#19005683

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

          • Konachan700
            /#19005799

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

            • dlinyj
              /#19005849

              Не-не, новички придут, спросят автора, он их с фекалиями смешает и на этом будет конец. И новички ничего не узнают.

              А новичкам всё равно только ардуино. Так как у RTOS, как ни крути порядок вхождения выше невероятно

              • Konachan700
                /#19005875

                Не совсем. Я вот тоже, например, при разводке хоббийных плат долгое время игнорировал многие правила типа блокировочных конденсаторов — "ну ведь и без того работает". Не наткнись я на такой же холивар по правилам разводки однажды, так и инорил бы дальше — а так полез выяснять, кто же прав и в итоге сам понял, зачем то или иное правило…

                • Peacemaker
                  /#19008999

                  Добрый день. А можно ссылочку на правила разводки?

  31. A__D
    /#19005661

    -

  32. ittakir
    /#19005883 / +1

    А я давно привык, что если вижу статью от olartamonov, то точно знаю что там будет Д'Артаньянство. Поэтому даже не лезу в полемику с такими людьми, не хочу зря время тратить.
    Сама статья для расширения кругозора была полезна, хотя сам вряд ли когда-то притронусь к mbed, т.к. полностью согласен с комментарием

    Нет. Не вижу. Я НЕ вижу на какой частоте работает ядро, на какой USB, что идет на таймеры и АЦП. По этому коду нельзя установить ничего.

    Автор напирает на энергоэффективность, а сам приводит в пример код, который полностью прячет важные параметры настройки системы.

    • smart_alex
      /#19005965

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


      Золотые слова. Проблема только в том, что наш Д'Артаньян имеет замашки Портоса и с клинком наголо влезает в комменты не только к своим статьям, но и к чужим (и изрядно гадит там). А комменты к текущей статье хорошая иллюстрация того, что Олега не могут унять всем Хабром. :)

      • dlinyj
        /#19007747

        А комменты к текущей статье хорошая иллюстрация того, что Олега не могут унять всем Хабром. :)


        Нас спасает только то, что он не может нам отвечать. Думаю когда режим ro кончится, начнётся бомбическое метание :)

        • smart_alex
          /#19007797 / +1

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

          Думаю, что вы правы, когда Олега выпустят из… бана, то он не будет себя хорошо вести. :) Может не стоит его развязывать? :)

          • dlinyj
            /#19007859 / +1

            Ну на самом деле, справедливости ради, пишет он годные вещи. Просто как человек поганый.

            • smart_alex
              /#19007871 / +1

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

  33. nerudo
    /#19006157

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

  34. philfreeeu
    /#19006437

    Самый дешевый из модулей Arduino — Pro Mini стоит на ебее чуть больше 2$. Если потребуется сделать маленькую серию девайсов, мигающих светодиодом, то во многих случаях проще взять эти модули и из них что-то быстро спаять.

    А какой самый дешевый модуль на АРМ, доступный в широкой продаже, на котором можно разрабатывать описанным вами способом?

  35. tri_botinka
    /#19007513 / -2

    Интересно, но автор походу вовсе не вкуривает, что такое Операционная система и какие обстоятельства привели к ее появлению. Для этого можно было бы почитать хотя бы Дейтла «Введение в операционные системы», первое издание на русском вышло в М: Мир еще в 1987 году. Там бы он узнал — что формально — Ardiuno вовсе не OS а скорее некая бортовая однозадачная система (БЭВМ). И до «взрослой» ОС ей еще очень долго куда расти. С другой стороны — Real time OS занимают тоже небольшую часть рынка, и это еще более экзотика чем
    БЭВМ. С другой стороны — почти ничего не мешает накатить на STM нормальную ОС, и будет вам и многозадачность, и межмашинное взаимодействие, и файловые и графические подсистемы как «у взрослых». Вопрос — а не дороговато ли для чипа в $1? может пусть большие ОС останутся для больших комплексов и больших проектов, а тут для школьников — не стоит огород городить.