Pull to refresh

Comments 463

UFO just landed and posted this here
«Пусть новые песни пишет тот, у кого старые плохие»
А это эмуляция AVR внутри виртуальной машины, которая крутится на M3 =)
Аж захотелось помигать светодиодом после прочтения!
захотелось помигать светодиодом

как вы прошли капчу при регистрации?
В 2006м её еще не ввели, а сейчас бы да. пришлось нанимать человека ;-)
> Serial pc(SERIAL_TX, SERIAL_RX);

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

А то я пытался SWO настроить, в принципе получилось, но IDE (TrueStudio) очень глючит.
В виндовый стлинк то судя по всему нормально пишет, но я на линуксе, texane/stlink пока не имеет поддержки SWO.
Да, там две ноги USART с контроллера заведены в ST-Link, а на нём штатный мостик USB-UART. На всех Nucleo так, на Discovery с прошивкой ST-Link/V2-A тоже.

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

А MBed? Вы вот можете назвать трудоемкость переноса MBed на свою плату? А на нестандартный процессор? А на MIPS?
Логично, но: покажите мне энтузиаста, типа меня. которому это все нужно?


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

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

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

В общем-то я против ардуины и за нововведения. Но ваше хамство и агрессия настолько омерзительны и эти наезды так некрасивы, что я лучше буду в клане адекватных нормальных людей с говнокодом и ардуино, чем с клане с дураками.
Господи, да пожалуйста. Если ещё и избавите меня от вида ваших комментариев, то вообще великолепно же.
Вы бы ещё мысли по русски научились формулировать.
Ок, я объясню проще, так как в Армию США, выражаясь иносказательно, вы по одному критерию явно не пройдёте.

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

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

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

Удивительная самонадеянность!
ППКС! Лучший комментарий!
Ах, этот свежий приём в дискуссии — ad hominem.

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

Вы написали отличный пост, спасибо. Но видать выросли в каком-то бандитском обществе, и нормально вести беседу без оскорблений оппонента не можете. Ваше мнение не единственное, а главное не обязательно верное.
UFO just landed and posted this here
Вам для понимания тот же простой вопрос: habr.com/post/420435/?reply_to=19003553#comment_19003383

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

Понимание же заключается в том, что качество платформы влияет на качество кода на ней. Нет в ардуине родных современных средств и API — так и будет на ней не большинство кода, а весь код граблями и велосипедами.
в середине 90-ых в IBM Россия был легендарный энтузиаст OS/2. который всем показывал, что инструкция JMP CLI 100 (или что-то в этом роде) на ассемблере наглухо подвешивает Win95, а полуось продолжает работать.
И что? Где та OS/2 и где Винда?
Я так понимаю, вы с Windows 95 OSR2 сейчас нам пишете, если хотите провести аналогии между виндой и ардуиной?..
забавный Вы :-) я Вам говорю о том, что Вы используете синтетические «потребности», которые не нужны большинству энтузиастов.
А НЕэнтузиасты никогда на ардуино ничего и не делали.
Но кстати, я написал ниже, что сейчас актуальная фишка — CircuitPython
А вот в ФИДО, мир праху его, вас, я так понимаю, не было. Иначе бы вас ещё там отучили бы говорить за всех.

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

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

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

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

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

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


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

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


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

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

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

Здесь же

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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


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

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

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

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

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

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

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

Но зачем тогда стенания про то, какая ардуина ущербная

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

pinMode(, digitalWrite(, например — это что?
И вообще — этот только пример именно как усыпить ардуину.
И да, я не просто так предложил по желанию обернуть в библиотеку. Таким простым образом это сразу становится частью ардуины, правда? ;)
Но ведь ардуиновское API как раз затем, чтобы так не делать.

Не загоняйте себя в такие самостоятельно придуманные рамки.
Трюк с deep sleep с помощью watchdog забавный.

Вполне законный. Откройте даташит на процессор и ознакомьтесь по каким сигналам процессор может выходить из каких режимов сна.
Или ардуинщеги принципиально не читают даташиты на используемый процессор, т.к. «ардуина должна»? ;)
Часть задач в ардуиновском подходе не решается вообще никак (ну, т.е., если на передачу данных модемом нам надо 10-15 секунд, то на эти 10-15 секунд всё остальное заблокировано)


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

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

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

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

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

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

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

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

По крайней мере когда я пишу код на ардуино, я понимаю как он работает, понимаю что digitalWrite кушает в 20 раз больше ресурса процессора чем прямая запись в регистры порта, и позволяю себе это, когда нет нужды в большой производительности. Код у многопоточный на milis() и примитивной реализации конечных автоматов, мне не напряг контролировать их взаимоотношения самому, по крайней мере вижу как это работает а не отдаю под контроль специализированной функции, у которой тоже под капотом тёмной лес. Проекты работают стабильно, корявые библиотеки не использую или правлю и в итоге трачу мало времени на разработку коммерческих частных проектов, получаю за них деньги и клиентам нравится. Сейчас пишу систему контроля множества параметров гидропоники, около 15 датчиков, исполнительных устройств дюжина, экран, менюшка. Что я делаю не так? Пыль в горле не ощущается. Работает то все стабильно и код писать легко и удобно. Что еще надо? Производительность только и больше фарша :) Вот и открыл статью в надежде разобраться как работает арм, как к нему подступиться, зачем эти три компилируемых файла, какой где лежит за что отвечает и как работает, а получил очередной хеловорд с горой неизвестных переменных, онлайн средой которая не пойми что там собирает. Зачем вы пришли и рассказали мне какой я говнокодер но не приложили качественный материал помочь стать лучше. Чтобы самому разобраться как все это работает и устроено внутри, понадобится куча времени, которую вы могли бы сэкономить, но если это время потратить и разобраться то и пример из статьи будет мало информативным. А делать делового без понимания механизмс работы, какой толк. Чтобы сказать теперь я не говнокодер? Так это только страдающим плохой самооценкой подходит, спасибо, но нет)
С другой стороны вопрос, за вот это ваше счастье с кучей фарша обязательно платить привязкой к интернету во время разработки или можно как то локально работать с проектом допустим уже на объекте, как у меня часто бывает? И не увидел как отлаживать, ибо серийным портом и на средине все так же красиво контролируется, на тех же 115200) спасибо, если получу ответы на вопросы.
Извините, наболело.

вы, наверное, с пониманием ардуины не родились, правда? изучали, читали литературу, экспериментировали. с АРМ так же. Да, мне тоже переход между 8080 и 8048 напрягал и между 8080 и 8086. извините, развитие «железа», и соотвествующее — софта. появляется определенный уровень абстракции. когда ты уже определенным образом «отвязан» от железа. появился API, который позволяет многие операции делать легче и проще.
«открыл статью в надежде разобраться как работает арм, как к нему подступиться» — научить человека нельзя. можно лишь помочь ему научиться…

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Олег, не сочтите меня назойливым, но рекомендую в первую очередь поискать треш и угар в вашей голове.
os.mbed.com/teams/components/code/GSM

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

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

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

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

P.S. Хотя после них чем-то другим пользоваться трудно, почему-то уверен, что если подниму этот вопрос, услышу много мнений о незаменимости купленного на Али люкея.
Подброшу пахнущего на вентилятор тогда, на работе сижу на MX-5000, что не мешает мне дома не плеваться от 203го квика.
Вы для саморазвиия поглядите здесь на статьи GarryC и про то какие они «стабильнее и яснее».

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


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

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

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

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

Если б ещё бакалавры после профильного ВУЗа владели этим cmake…
Я был бакалавром и самостоятельно овладел cmake.
Программировать под ардуину можно в разных IDE и без использования ардуиновской библиотеки.

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

Нет, т.к. по сути и ардуины уже нет.
Можно еще добавить, что под ардуину можно программить и из того же Eclipse, с использованием тех же самых ардуиновских библиотек. Наверное, даже отлаживать можно, если отладчик есть соответствующий, не пробовал.
А еще можно кашу сварить из топора. Говорят, неплохо получается.
Ну, одна из самых больших претензий к ардуине — что IDE плохонький. Ну да, плохонький, вот вам хороший…
IDE плохонький. Стандартные платы ничего интересного не представляют (https://xakep-archive.ru/xa/122/100/1.htm ). Библиотека — настолько «тонкая прослойка» между avr-gcc и высокоуровневым кодом, что отказаться от нее можно при первой же возможности (нет, не надо рассказывать про отличные от AVR платформы). Что остается-то?
К сожалению, нельзя. У родных МК вообще с отладкой было никак, а загрузчик УАРТ отладку не поддерживает в принципе.
У большинства ардуинок есть разъем ICSP, он вроде как специально для отладки и сделан.

Не знаю, как на ARM, на AVR ардуинках данный разъем вроде как используется исключительно для прошивки. На некоторых ардуинках их вообще два: один для микропроцессора, а другой для преобразователя USB-UART, но оба только для прошивки.

Хм, действительно, в даташите на atmega328p описан только дебаг через пин reset. Выпаивать конденсатор на резете придется для отладки и openocd не поддерживает. :(
А мне вот даже для DIY как-то перестало хватать одного USART и пр.
Atmel платы, аналогичные хотя бы банальному blue pill, какие-то очень уж маргинальные и стоят дорого.
И перспектив, видимо, никаких.
А чем вам кЕтайские на STM32F4 не нравятся? USART-ов дофига, всякиx USB/CAN/SPI/I2C тоже ложкой кушать можно.
Отчего же не нравятся? Я же blue pill в пример привел, у которого тоже USART не один.
Я скорее про arduino vs stm32.
Оригинальные демоплаты мне нравятся тем, что на них сразу есть стлинк, все заведомо работает как надо. Разница в цене для меня несущественна. А вот в конечных DIY-устройствах использовать такие платы конечно невыгодно.
Сам не считаю ардуино вселенским злом. С него легко приобщиться к МК и цифровой электронике. А говнокодинг он везде говнокодинг. Кто-то хочет развиваться и делать лучше, кто-то нет. ИМХО дело не только в ардуино.
> (Yun, или как-то похоже зовется) на которой помимо AVR установлен второй микроконтроллер, на котором штатно крутится урезанная версия линукса

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

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

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

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

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

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

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

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

habr.com/post/256089

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

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

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

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

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

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


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

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


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

За час переписать read()/write() adafruit'овской библиотеки?
Или за день раскурить даташит bme и построить очередной велосипед?
Мне кажется за день даташит BME не раскуришь. Там какие-то хитрые фильтры.
А как там обстоят дела с платами типа хендмэйд? Можно ли запилить поддержку своей, с блекджеком и дамами легкого поведения?
Конечно. Можно просто утащить Mbed на локальный комп и там в targets описать свою плату как отдельную сущность, можно выбрать максимально похожую и подрихтовать нужные значения в рантайме.

P.S. Вообще для более-менее серьёзной разработки Mbed всегда утаскивают локально — там будет сильно больше настроек, чем в онлайне. Ту же скорость stdout'а можно просто в JSON-описании проекта указать сразу.
Понятно, спасибо. Меня заинтересовал мбэд, может хоть так быстрее руки дойдут до освоения STM больше чем «помигать».
Подписался, пишите исчо :)
Я дальше буду про RIOT.

Он чуть менее отполированный и автоматический, зато позволяет проще понять, как это всё устроено.
А откуда тащить? Как сохранить код из Mbed Compiler на локальный комп?
Вариант раз: https://github.com/ARMmbed/mbed-cli

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

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

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

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

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

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

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

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

ARM'ы у Atmel, кстати, интересные, у нас ATSAMD51 довольно много лежит — пока не пригодились, в проекте, под который их взяли, в итоге оказалось по мощности достаточно более отработанного STM32L4, но в принципе интересная штука. Что-то типа $4,50 было за контроллер на 120 МГц и с развитой периферией.
Для примера Tiny с которой недавно сталкивался: Attiny1616
На мой взгляд это МК, не для замены мелкой логики=)
Хотя не спорю, у всех задачи в плане разработки стоят разные. И понятие мелкая логика у каждого в плане масштабности несет разный характер в зависимости от уровня знаний и размеров схем, в которыми он работает.
Это не тот, который только через TPI программируется?
ARM'ы у Atmel, кстати, интересные, у нас ATSAMD51 довольно много лежит

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

Два месяца почти несчастную девборду покупали, блин.
88% на АРМ. DIY'щиков опросили что ли?
причём она делилась как минимум на три семейства: AVR, PIC и STM8

Это популярные в массах.
В автомобильном транспорте, например NEC. Теперь renesas очень много поставляет.
• 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 вендоров, что, полагаю, примерно долю конкретно автопрома в электронике и отражает.
Абсолютно ничего сложного в том, чтобы начать работать с современными контроллерами в современной среде разработки, нет. Более того, при этом вы получаете массу вкусных, полезных, и главное — грамотно реализованных вещей, радикально ускоряющих и упрощающих разработку. Нет, я не про библиотеки «мигания светодиодом», хотя и их тоже достаточно — я про таймеры, многозадачность, сообщения, сервисы и всё остальное, что не имеет никакого смысла в 2018 году нашей эры писать руками, потому что всё это уже написано до вас и, скорее всего, сильно лучше, чем когда-либо напишете вы.

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

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

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

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


Вызов pc.baud(int baudrate) требует полноценного чтения документации? Что именно вы в ней планируете прочитать?..
C RTOS я особо не работал, разве что читал цикл статей по FreeRTOS в одном журнале. Но мне кажется, что и там скорее всего найдется то, что потребует более углубленного изучения.
К тому же изучение Reference Manual на тот же FreeRTOS(с которым я более менее знаком) займет не на много меньше времени, чем изучение документации на HAL.
Но это опять же, сугубо мое мнение.
Любая RTOS даст вам немножечко больше возможностей, чем один только HAL. На порядок-два где-то.
По факту, если взять тот же HAL для STM32 и раскрыть любую его функцию то можно охренеть от всей той кучи всевозможных проверок которые там расписаны. Все это замедляет работу МК, увеличивает вес прошивки. В своих проектах, где использую HAL, я в большинстве случаев я вырезаю все эти не нужные участки, для оптимизации кода.

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

По подробнее с этого места пожалуйста)
UFO just landed and posted this here
А как насчет NuttX или ChibiOS? Вроде у обоих HAL хороший, POSIX-совместимость заявлена, есть коммьюнити.
Можно. Здесь вообще выбор очень большой, Mbed в данном случае мне нравится как отличное средство для первого шага — онлайн-компилятор, приятный API, простой импорт стороннего кода.

Дальше я планирую RIOT OS вообще рассматривать.
поправочка — Chibios не POSIX-совместима.
Я как-то уже писал про mbed. Да, мигание светодиодом пишется очень быстро, но когда вдруг оказывается, что в цикле «мигнуть, подождать секунду» светодиод мигает в несколько раз чаще, чем раз в секунду, начинается самое интересное :) А еще интереснее, когда нужно поработать с датчиком, критичным ко времени между импульсами, а все прослойки mbed занимают столько времени, что ты в требуемый интервал ну вообще никак не укладываешься. Leaking abstraction в очень ярком проявлении :)
Несомненно, вы сможете посоветовать нам среду, в котором гарантируете отсутствие ошибок.
Если средой считать RTOS и даташиты контроллера, то да :) А из ембед-подобных штук может быть удобным взять инициализацию железа, к примеру, а более-менее серьезные вещи все равно нужно будет писать на весьма низком уровне…
Показать ошибку в STM32L151CBU6A, которой нет ни в даташите, ни в errata?..

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

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

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

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

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

И это всё коммерческие проекты коммерческих компаний.
Так а я разве говорил про без РТОС? Без РТОС я вообще не представляю, как можно что-то более-менее серьезное сделать. Хотя заказчика пришлось очень долго в этом убеждать, к счастью, убедили… Но одно дело РТОС, а другое — классы на с++, инкапсулирующие низкоуровневую работу с контроллером…
Задач, в которых надо в бешеном темпе вручную дёргать ножкой процессора, в мире крайне мало (но да, я помню, как мейнтейнеры RIOT меня бурно убеждали, что проверка if (gpio == GPIO_UNDEF) в обработчике gpio_read — это невероятная тяжесть реализации).

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

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


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

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

Это был PIC, а не STM32.
А с аппаратным обработчиком проблем не будет, разумеется.
UFO just landed and posted this here
Ваше мнение очень важно для всех нас!
А сможете сделать на нем анализатор спектра аудиосигнала в реальном времени?
Задайте полосу и количество частотных сегментов — будет конкретный ответ.
А общий ответ — можем, только полоса будет 300 Гц (это аудио) и уровень 1/0 (это анализатор).
Видите эту страшную инициализацию процессора?

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

Всё остальное можно посмотреть в описании платы на гитхабе, если эти параметры вам настолько важны.
А при чем тут плата? плата может все. А что ДЕЛАЕТ КОД?
Вы себе вообще представляете, что такое HAL? Который не библиотека, как тут многие считают, а Hardware Abstraction Layer?

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

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


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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

Собственно, даже в ардуино есть нечто подобное, только там описания плат спрятаны «куда подальше» и толком не документированы.
Ну вот и вернулись к инициализации ядра, изучению периферии и прописыванию всего этого в коде.
Вот вам пальцем показали — вся инициализация ядра, вся работа с периферией в достаточном для простых проектов виде УЖЕ включена в состав ОС. Что еще надо? Или вас not invented here беспокоит?
А с какой скоростью будет передавать UART?
Параметры указаны в описании платы.
ЧТО? Нет возможности динамически менять скорость UART???

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

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

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

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


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

Ну и желаемое качество драйвера UART — 1 сбой на 10^7 байт.
А кто запрещает менять что скорость, что формат (https://os.mbed.com/docs/v5.9/mbed-os-api-doxy/classmbed_1_1_serial_base.html#a768f1e9fd9e14c787f693745fa2538a4 ) динамически в случае того же Mbed? Для официально поддерживаемых платформ драйвер должен все это позволять.
Судя по доке, 8O1 умеет, а 9N1(программная проверка четности) — уже нет. Хотя большинство портов физически это могут.

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

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

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

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

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


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

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


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

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

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

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

На собтвенную плату (с поддерживаемым 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
На собтвенную плату (с поддерживаемым 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 пишется. но не более того.
Как будто кто-то топит именно за Mbed. Куча же RTOS разных, бери, не хочу.
Скажу так — мой опыт работы именно с Mbed — нулевой :) Я уже умножил «на пи и на е» — хотя разницы, скажем, с RIOT OS (где принцип конфигурирования похож) в целом нет.

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

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

Переносимость… ну даже для STM32 это фикция. F4/F7/H7 — имеют немного разные порты. Приходится #ifdef в драйвере писать.
Если импортозамещение «настоящее» — то такой же импортозамещенной должна быть и периферия (то есть не только миландровский 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 его нет, там только более-менее нормальная работа с процессами.
Если импортозамещение «настоящее» — то такой же импортозамещенной должна быть и периферия
Да, само собой, включая корпус. Это не совсем настоящее импортозамещение — 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 не зажаты.
Самодельные API обычно печально выглядят (если за образец не взято что-то изначально приличное, типа POSIX).

Что касается правок в master — пусть olartamonov про них в следующих сериях рассказывает :)
Тут выбор простой: шашечки или ехать?

В любом случае, хуже, чем Windows API для работы с ком-портом, написать сложно. Там всего один способ не терять байты на 115200 и выше и куча способов их потерять.

Главное, что нужно от UART API — это отсутствие потери байт. А красота… Одному нравятся блондинки, а другому — брюнетки.
Кстати, отличный вопрос, что вы считаете хорошо выглядящим API? Архитектурные красоты? Ну так по мне даже POSIX довольно крив. Собственно мои требования к API порта такие:

Независимость. Независимость от ОС (Windows, POSIX, FreeRTOS, MS-DOS и так далее). Независимость от железе (UART, файл, TCP, UDP, SPI...), кроме функции связи порта с устройством.

Ортогональность — то есть основной код не меняется при смене устройства или ОС.

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

Производительность. Ну тут все просто. На 4800 мы должны передать 480 байт ± пара процентов на отличие тактовой частоты UART. Если у нас пауза длиной байт означает конец пакета (примерно как в ModBus RTU) — значит мы должны уметь передавать без пауз.

Асинхронность. Все вызовы (кроме write flush) — с нулевым ожиданием. Write flush — исключение, используется на перезапусках аппаратуры, где нужна синхронизация работы UART и GPIO.

Простота. Прежде всего простота отладки. Всякие callback — зло, ибо отлаживаются хуже.

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

Есть вызов CHAN_Getc(), он дает байт. А откуда этот байт прилетел…
Асинхронность без коллбэков, или Ну что тут может пойти не так.
UFO just landed and posted this here
1) ожидание блокирует данную задачу, коллбэк — нет
2) в ожидании не передаются параметры, в коллбэке — сколько угодно
3) таймауты в ожидании реализуются существенно менее изящно, чем в коллбэках

Понятно, что на коллбэках писать сложнее, это другая архитектура. Но они сильно гибче.
UFO just landed and posted this here
Понятно, что на коллбэках писать сложнее, это другая архитектура. Но они сильно гибче.
Ну что же, жду от вас рассказа, зачем вам эта гибкость. Ну да, ускорение на пару мс там, где оно не нужно (на ком-портовых скоростях). А что ещё?

1) ожидание блокирует данную задачу, коллбэк — нет

Такое впечатление, что про non-blocking IO вы не слышали. Калбэк, между прочим, означает блокировку буфера, в который вы читаете. А иногда — и блокировку буфера на отправку.

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

3) таймауты в ожидании реализуются существенно менее изящно, чем в коллбэках

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

В неблокирующем вводе-выводе тайматуы динамические. Мы их можем менять в любой момент.
Господи, в вашей FreeRTOS есть какие-то проблемы с тем, чтобы таймеры на ходу перенастраивать?..

Вообще, у меня один вопрос.

Вы всем этим сказать-то что хотите?

Сформулируйте, пожалуйста, законченное утверждение не длиннее 200 символов.

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

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

Там вопрос был: вы сказать-то что хотите? Какая-то мысль у всего этого есть?
Странно, что вы не рассматриваете неблокирующий ввод-вывод без ожидания.
UFO just landed and posted this here
Ой, а как вы с TCP/IP работаете? Один из самых простых способов же.

Суть в том, что бывает передача дейтаграмм (как в UDP) и передача потока (как в TCP). И для потока неблокирующий ввод-вывод — самое то. А UART — это 99.99% — передача потока. То есть делить на пакеты нужно самому, и длина пакетов — переменная.

Исключение сейчас вспоминается одно - MODBUS-RTU, его можно и как дейтаграммы принимать и как поток.

Другой момент, что на всяких иных устройствах — больше дейтаграммы. Ну так я только про UART и его удлинители говорю.
UFO just landed and posted this here
Нет, неблокирующий синхронный вариант. Отличие от вики — нулевой таймаут.

Ну вот пример:
while((ch=getc(fp))!=EOF) {
    printf("%c", ch);
  }

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

Ну а вместо printf — конечный автомат на разбор протокола и вызовы обработчиков в зависимости от типа пришедшего пакета.

На выводе ещё проще: write копирует данные в буфер, а потом асинхронно они пересылаются на устройство. То есть это как обычный printf на экран или в файл.

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

UART отличается тем, что в нем бывает пропадание байт. Overrun, Frame Error и так далее. Поэтому всегда есть протокол с передачи с делением на пакеты и продольной контрольной суммой по пакетам. 99% этих протоколов — байтовые, оставшийся процент — битовые, вроде RTCM 2.2, оптимизированные для передачи по зашумленному радиоканалу.

Соответственно дальше всегда стоит конечный автомат, который и разбирает поток байт (или битов).

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

Да, такие у нас требования. С одной стороны мы хотим от железа 1 сбой на 10^7 байт, с другой стороны — умеем выживать при сбое на 10^2 — 10^3 байт.

А что CHAN_Getc — дешевая операция ибо читает из внутреннего буфера программы, это очевидно.

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

Запрос не дошел — значит повторили. Все равно 99% случаев сбоев передачи — проблема за UART, например, в радиодлинителе. Поэтому нам даже не важно, сбой на передаче запроса или на чтении ответа устройства. Все равно в итоге — перезапрос через таймаут.

В редких случаях (смена скорости порта или ресет приемника) — ждем опустошения буфера. Это где-то от пары раз в сутки до раза в месяц. Да, теоретически тут был бы полезен callback.

Но… практически ни в Windows, ни в POSIX нету callbck на то, что последний байт ушел из регистров UART в линию. Даже аппаратные порты — далеко не всегда имеют нужное прерывание, обычно прерывание идет на опустошение FIFO, при этом 1 байт ещё передается в линию. Поэтому способ с callback — не универсален, он работает лишь на отдельных портах.

Вы лучше расскажите, что вы собираетесь делать по callback? Ну вот скажем запустили чтение на 10 байт, а пришло 9 (сбой на линии или в логике приемника). Соответственно callback не вызвался. Что дальше? Как будете избегать гонки?
UART отличается тем, что в нем бывает пропадание байт. Overrun, Frame Error и так далее


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

А окружающие при слове «асинхронность» начинают думать про буферы и прочее DMA.

В качестве домашнего задания: попробуйте привести пример протокола (из числа ходящих по UART) с единицей разбора больше байта


Мне это, если не секрет, зачем?

Да, асинхронность под капотом


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

Вы лучше расскажите, что вы собираетесь делать по callback? Ну вот скажем запустили чтение на 10 байт, а пришло 9 (сбой на линии или в логике приемника). Соответственно callback не вызвался


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

Часто даже проще — раз в секунду смотрим табличку: какие команды ешё не отработали? Ах вот эти? Ну значит их посылаем. А на более высоком уровне для выдачи команд просто корректируем табличку.

Соответственно никакого while на чтение у нас нет. И на запись — нет.

Есть общий цикл задачи. Байт пришел? В конечный автомат его. Конечный автомат собрал пакет — ок, обрабатываем. Что там в таблице команд? Кого-то послать нужно? ОК, посылаем. Ничего не нужно — спасибо, отдаем квант другой задаче. Причем это может быть как одна задача, так и две (на прием и на отсылку).

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

У меня начинает закрадываться подозрение, что вы «асинхронностью» называете тот факт, что у вас там UART не на побитовом ногодрыге сделан, а аж на целом однобайтовом USARTx_DR
Ой, прямо в детство вернулся. 35 лет назад я тоже так думал. Асинхронность означает nonblocking IO в терминах беркли-сокета. То есть ожидание на операциях ввода-вывода — нулевое. Отправили пакет — и все, забыли о нем. Можем секунду не читать — байты не потеряются.

В windows и linux это означает три уровня буферов: буфера программы, буфера ОС и буфера драйвера (для DMA). Во FreeRTOS уровней два: основные буфера (две очереди FreeRTOS) и буфера драйвера (для DMA).

Ориентация на очереди FreeRTOS позволила нам на одной из систем реализовать UART на ПЛИС с обменом с SOC по SPI без изменения кода. Я со свой стороны ровно так же общаюсь с очередями FreeRTOS, а что драйвер совсем иной — мне не важно.

Таймауты там всякие, например, — нет, не слышали?
Да, да таймауты. Вы все-таки попытайтесь на вопрос ответить. Как вы с вашими callback будете избегать гонки по таймауту? Истек таймаут, callback ещё не пришел, что дальше? Как вы избежите callback в момент обработки таймаута? Так что вопрос открыт:

Как будете избегать гонки?

Или вы из «современных» программистов, которые гонки просто считают «таинственным сбоем»?
Вы производите огромные объёмы винегрета, в котором скачете мыслью по всему подряд. Отдельно доставляет, что при этом ещё и собеседников путаете.

Послали команду — ставим таймер. Пришел ответ — таймер обнуляем. Изредка проверяем таймеры, не пришел ответ — значит перепосылка


Как вы с вашими callback будете избегать гонки по таймауту? Истек таймаут, callback ещё не пришел, что дальше? Как вы избежите callback в момент обработки таймаута?


Особенно забавно, как в этом потоке вы умудряетесь сначала тезис сформулировать от своего имени, а потом его же мне в вину поставить.
> Вы производите огромные объёмы винегрета, в котором скачете мыслью по всему подряд.

Асинхронность же, на уровне головного мозга.
То есть ответ вы не придумали. Ну ОК, бывает. Попробуете написать систему с callback — сами с этой проблемой столкнетесь.

Вот только сильно боюсь, что вы из тех программистов, которые гонки считают «таинственным сбоем». Те, кто умеет с гонками бороться — проблемы видит заранее.
(ковыряясь в MAC-уровне LoRaWAN 1.02) А?
LoRa — полудуплексная Ничего, со временем и дуплексными системами займетесь. Тогда все сами и поймете.

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

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

А linux — это огромный монстр. 12мегов ПЗУ, 16 мегов ОЗУ — это примерно минимум. На голом железе хватает STM32F7 — мег ПЗУ, полмега ОЗУ.
Есть, например, такой класс задач, как UltraLowPower — это когда каждый микроапмер считают. Тут, в большинстве своём, РТОСы плохо подходят. Хотя от конкретной задачи зависит — надо проектировать и просчитывать, в некоторых случаях Tickless RTOS большого оверхеда не добавляет. Впрочем даташиты в любом случае надо зачитывать до дыр и режимы работы периферии настраивать вручную. А вот от HAL'а (того, который от ST) 100% надо избавляться (ну хотя бы в пользу LL) — более неудобной и глючной и прожорливой либы ещё поискать надо! Благо под задачи ULP есть куда более вменяемые производители контроллеров.
Я только одного не понял: чем долгая работа в прерывании отличается от долгой работы в функции, вызываемой из прерывания? Разве что во втором случае расходуется еще больше стека…
Или метод call ставит вызов в очередь, а осуществляется этот вызов в dispath? Из статьи как-то не просматривается…
Да, call ставит в очередь, а обрабатывает эту очередь уже dispatch.

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


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


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


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


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

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

Увлекательный бой между слепцами и глухонемыми. Одни не видят, другие не могут объяснить.
В мире мк у всякого направления есть своя колея, если в неё попасть — то выбраться уже почти невозможно. Колея настолько глубокая — что двигаться можно только в одном направлении, вперёд. Шаг в торону — и вас затопчут свои-же.
А мне пофиг.
Беру то что требуется в данный момент и переделываю под себя.
Ардуину можно купить за 100р на али подождав 2 недели или за 300р на ближайшем радиорынке, какую другую платформу можете предложить по данным критериям доступности и цены?
Угадайте, за сколько на Али можно купить плату на STM32.
Blue pill — 117 на Али с доставкой. И Вы даже можете подключить к ней датчики для Ардуино.
Хуже того — залить туда ардуино :)
UFO just landed and posted this here
Нет никакого инакомыслия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

этот пользователь ещё должен изучить и другую «операционку»?
Например, с RIOT OS «высокий входной порог» от нулевого знакомства с микроконтроллерами до запуска первой программы выглядит так:
Скачать и поставить MinGW, arm-none-eabi-gcc и GNU make (для пользователей Windows 10 первый пункт не нужен, достаточно из Магазина поставить свежую Ubuntu)

Я и от 10-ки не в восторге(но на домашнем ноуте Arduino IDE под ней работает неплохо, а Магазин откючён), а уж 'nix-ы для меня — …
Можно например утверждать, что правильнее всего мигать лампочкой ножкой ПЛИСины и такой точности и изящности мигания используя встроенные digital clock manager-ы и всё такое, не даст никакой контроллер, ни с free-rtos, ни ардуиной, ни с ассемблером.
Но это же не значит, что все, кто не пишут на vhdl дураки?
Весь этот тред про сравнение теплого с мягким. Уж коли пошла тема про тачки то расскажу что мой тесть, живет в Эстонии, и он купил в позапрошлом году новую Ниву, не спрашивайте почему, у него была своя логика. Одна знакомая имеет новенький bmw120 и считает что на нем она легко делает в потоке амгэшные гелики 6.3. А дизайнер с прошлого проекта вообще предпочитает самокат.
Так что мир это такая многоликая штука, и у ардуино есть отличное место под солнцем на поляне школьников и всякого рода энтузиастов. Топикстартер всего лишь вносит свой вклад в отодвигании ардуины от вкусного многомиллиардного рынка.
Скажем ему за это спасибо и прекратим ненужный хейтинг в комментариях, аминь;)
Интересно. Но не уверен что буду использовать. Для моих поделок можно, но…
Для мелких задач у меня горсть Tiny85
Для средних, не требовательных, Mega328
Это для ардуиновских поделок.
Ну а где надо быстрее-мощнее-больше прерываний — уже STM32. И вот тут уже вправду можно попробовать задуматься об ОС. Но таких задач у меня не много. Из десятка F103-их использовал пока только 4.
Ну… это со стороны самодельщика.

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


Фи, а я люблю ардуинщиков. Вы просто не умеете их готовить. Подавляющее большинство моих заказчиков сначала натыкалось на них, они им делали прототип. Это им заказчик трахал мозги по ходу осознания своих потребностей и бесконечных переделок и изменений ТЗ. Причем трахал задешево для себя (ибо их как грязи и они дешевы). Когда же это при попытке вытащить со стола в реальное железо работающее в реальных условиях разваливалось, глючило и не работало, банально из-за непонимания физики процессов и все эти ардуинщики обсерались, то заказчик уже выходил на меня. С уже проработанным ТЗ и понятными нюансами решения его задачи. А я тут, на всем готовом, выкатываю заказчику свою цену. Причем он уже не охреневает от циферок, т.к. дешевых разработчиков он наелся.
Ди, ты пропустил праздник такого эпичного срача :)
Стар я уже для этого дерьма. Тем более недавно эпично лоханулся как школьник и просрал землю, так что ща с помощью ЧПУ станка и такой то матери экстренно правлю топологию партии готовых плат :) Благо серия небольшая.
Да ладно тебе, надо иногда и мозги разгружать.
Они еще на Олега и нажаловались -)
Он уже поплакался об этом? По моему вполне справедливо. Он очень не этично себя ведёт. Я бы сказал по хамски.
Я на ардуино+акселерометр+Lora +… скрутил работающий прототип продукта по контролю активности коров, нет, ну серьезно, разметка данных, машинное обучение на сервере, обучение модели, выгрузка центроидных векторов на ардуино по Lora, все очень так научно и красиво.
Работающий продукт на ардуино я делать конечно же не буду, но прототип получился годным, так что всему свое применение найдется в этом мире;) ИЧСХ не тратил время на разработку устройства, купил втупую готовую ардуино compatible за 100 евро, да дорого, но зато быстро.

Тот самый DIHALT?


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

Как вы смогли перепутать плюс с ТИРЕ?
UFO just landed and posted this here
Сча дам облом из реальной жизни в подарочной упаковке:
Одну девайсину, которая должна была что-то уметь и быть себе USB Device, я начал писать на STM32F1xx, кое-как отладил, прилетело желание «и в хвост и в девайс», окей, проектик быстро переехал на F2xx (тот, который о двух USB), далее прилетело пожелание «хватит и одного, но быстрого и вообще», проект перелетел на F4xx.
Во сколько человеко-часов вы оцениваете эти два переезда, если мы не используем SPL/HAL?
UFO just landed and posted this here
На перепиливание HALа под композит у меня ушло 4 часа и три перекура. А libopencm3 — этол тоже вариант HALа.
Ещё тогда вопрос, про нелюбимый вами куб — сколько времени у вас займет выбор камня, удовлетворяющего условиям ТЗ и имеющего минимальную стоимость, плюс вычада распиновки для разработчика печатной платы.
UFO just landed and posted this here
Вопрос немного не в тему: каждый раз, как надо было реализовать USB более чем с 2 парами endpointов, приходилось писать кучу в общем-то boilerplate кода и лезть в кишки HAL (пробовал ASF, libopencm и по-пионерски, на регистрах). То есть это не я дурак, а правда нет удобного инструмента?
UFO just landed and posted this here
Танцевать придётся от дескрипторов (просто больше неоткуда), благо, под них инструмент уже есть. Но всё равно пользователь должен будет знать, что:
— есть эндпоинты и потоки
— эндпоинты разные, выбирать их надо в зависимости от назначения
— общаться можно просто стучась в эндпоинт и через feature
— …
Т.е. всяко прочитать минимум USB in a nutshell придётся.
Вы внутрь freertos заглядывали? Там все красиво и изящно, никакого головняка и потери перформанса. А вот без нее сделать опрос даже пары устройств с достаточно долгими таймаутами, чтоб не увязнуть в машинах состояний — головняк еще тот…
А там есть визуальный выбор функций пинов с проверками конфликтов и прочим, аналогичный STMCubeMX? А то как-то грустно на STM32-ах без него.
UFO just landed and posted this here
Вариантов слишком много и есть много неочевидных моментов, чтобы без углубленного чтения даташитов не напортачить. Для новичков уж точно. Не говоря уже просто о собственно выборе микроконтроллера, когда после долгого траха с вроде подошедшим микроконтроллером — его пять USART и три I2C превращаются в «только три USART и три i2c, и без возможности загрузки на переставленном USART1 и без нужного количества входов АЦП».
UFO just landed and posted this here
Кстати, об индусах…
Как верно заметили, никакая, самая лучшая среда, не спасет от криворукого программиста.
Честно говоря, я совсем не в восторге от mbed (и здесь я солидарен с ТИ), но его нельзя назвать совсем уж плохим, но открываем раздел CODE на сайте, видим в наиболее популярных os.mbed.com/users/simon/code/TextLCD, открываем сырки и видим… все тот же Ардуино (без delay, блин) стиль во всей его красе.
Ну и на фига тогда было от Ардуино уходить?
Отличная статья, надо сыну дать почитать, чтобы понял как разработка устройств делается. Спасибо!
Кстати, да, никто не говорит, что статья плохая, наоборот, она весьма интересна. Неприятие вызывает узколобая и непримиримая позиция автора по отношению к инакомыслящим, сдобренная хамоватым поведением в комментах.
UFO just landed and posted this here
В общем, причина такой активности в резкой и непримиримой позиции автора, его позиция и манера вещать Абсолютную Истину с вершины Олимпа таковы, что он набирает себе оппонентов не только среди «ардуинщиков», но и среди «профессионалов».

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

Причём, что интересно, с ним никто не спорит что STM32 и операционные системы это хорошо и никто не ставит под сомнение его квалификацию как специалиста. Речь идёт только о том, что Олег являет собой яркий пример «узкого специалиста, подобного флюсу» по меткому выражению Козьмы Пруткова или, другими словами, техно-гоблена, по не менее меткому выражению Сергея Голубицкого. То есть человека с мировоззрением с ноготок и не желающего ничего видеть и понимать в жизни, кроме даташита на STM32.
Вот, вторая статья с «Быстрый старт с (RT)OS» и у неё нет тэга соответствующего… 1я статья.
Сейчас вот, потихоньку, ковыряю книги по Си и статьи по FreeRTOS, ибо мне показалось что без планировщика не получится.
А всего-то, хочу ESP к древней Roomba-е прикрутить. Можно пинать.:)
Мда. Видимо это всё навеяно недавней статьёй — habr.com/post/419445 и у автора этого топика от неё пригорело. Только вот подход в этой статье аналогичный ардуино-кодингу, только «вид сбоку», когда ничего не изучая — бери и клепай себе, не думая как оно работает… потому и рождаются тысячи топиков потом на форумах:
— Я вот тут взял либу, вот тут соеденил как вот там вот советовали, а оно ни работаеееттт!!1 Памагите, че исправить, а лучше дайте готовый скетч, пасиба!
Вы немного не в курсе, у автора пригорело, когда ему указали, что он несёт откровенную чушь с трибуны технического университета на головы доверчивых студентов:

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

А автор к такому не привык. А то, что на его ляпы ему указал (посмел указать) какой-то «ардуинщик» автор воспринял как личное оскорбление. И понеслось… У той статьи 286 комментариев. :)
Таких подробностей не знаю) Мне показалось странным поведение, плодить по сущности тоже самое, на что недавно «бочку катил». Я сам далеко не за ардуино-подход в обучении, только за, если человек разберётся (более менее в целом хотя бы, не обязательно до последнего регистра всё знать, имхо) как оно работает и будет сам творить дальше то, что ему хочется, а не искать либы и писать по форумам — чего не пашет то, ведь в одной статье прочитал, что «бессонные ночи над даташитами» не нужно проводить…
Да вообще этот сыр-бор выеденного яйца не стоит — оставьте ардуинщикам Ардуино, а тем кто хочет этим заниматься — более профессиональные инструменты. И ВСЁ!
UFO just landed and posted this here
Не-не, новички придут, спросят автора, он их с фекалиями смешает и на этом будет конец. И новички ничего не узнают.

А новичкам всё равно только ардуино. Так как у RTOS, как ни крути порядок вхождения выше невероятно
UFO just landed and posted this here
Добрый день. А можно ссылочку на правила разводки?
«Конструирование высокоскоростных цифровых устройств. Начальный курс черной магии»
Говард Джонсон, Мартин Грэхэм
А я давно привык, что если вижу статью от olartamonov, то точно знаю что там будет Д'Артаньянство. Поэтому даже не лезу в полемику с такими людьми, не хочу зря время тратить.
Сама статья для расширения кругозора была полезна, хотя сам вряд ли когда-то притронусь к mbed, т.к. полностью согласен с комментарием
Нет. Не вижу. Я НЕ вижу на какой частоте работает ядро, на какой USB, что идет на таймеры и АЦП. По этому коду нельзя установить ничего.

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


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


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

Думаю, что вы правы, когда Олега выпустят из… бана, то он не будет себя хорошо вести. :) Может не стоит его развязывать? :)
Ну на самом деле, справедливости ради, пишет он годные вещи. Просто как человек поганый.
Никаких сомнений, что Олег отличный специалист. А по поводу его личных качеств — да, есть ещё над чем поработать, но я думаю, что со временем он сможет стать осознанным и полезным членом нашего общества.
Вся проблема «этого страшного входного порога» заключается в том, что легко по-обезьяньи повторить инструкцию (если ее кто-то написал — вот на хабре теперь есть, а еще где-нибудь?). Но шаг влево-вправо типа поддержки своей платы, другого процессора, другого набора периферии или еще чего, что не вписывается в готовый example — и жизнь начинает играть совсем другими красками. И именно в этом вся сложность, а не в том, чтобы написать трех-строчный main() с printf.
Самый дешевый из модулей Arduino — Pro Mini стоит на ебее чуть больше 2$. Если потребуется сделать маленькую серию девайсов, мигающих светодиодом, то во многих случаях проще взять эти модули и из них что-то быстро спаять.

А какой самый дешевый модуль на АРМ, доступный в широкой продаже, на котором можно разрабатывать описанным вами способом?
Интересно, но автор походу вовсе не вкуривает, что такое Операционная система и какие обстоятельства привели к ее появлению. Для этого можно было бы почитать хотя бы Дейтла «Введение в операционные системы», первое издание на русском вышло в М: Мир еще в 1987 году. Там бы он узнал — что формально — Ardiuno вовсе не OS а скорее некая бортовая однозадачная система (БЭВМ). И до «взрослой» ОС ей еще очень долго куда расти. С другой стороны — Real time OS занимают тоже небольшую часть рынка, и это еще более экзотика чем
БЭВМ. С другой стороны — почти ничего не мешает накатить на STM нормальную ОС, и будет вам и многозадачность, и межмашинное взаимодействие, и файловые и графические подсистемы как «у взрослых». Вопрос — а не дороговато ли для чипа в $1? может пусть большие ОС останутся для больших комплексов и больших проектов, а тут для школьников — не стоит огород городить.
Автору спасибо. Познакомился с онлайн mbed. Действительно просто. BluePill (на его китайский аналог ссылка выше) запустился даже не с пол-, а с четверть пинка ). Надо проверить как штатными средствами устроить знергосбережение. С датчиками тоже надо поиграться.
Моя задача сбор данных с нескольких датчиков в автономном режиме, разовые задачи. Физически датчики всегда разные. Нужно быстро и по минимальной цене и в минимальном размере сделать такой «черный ящик». Пока юзаю Arduino nano + sd карта.
подскажите дураку, как добавить BluePill в доступные платы?
В онлайне её почему-то нет, пишите под Nucleo-F103RB.

В оффлайне Blue Pill есть из коробки.
Друзья, подскажите следующее: раз уж вышла такая статья — есть у меня пара esp8266-v12. Мне довелось работать с ними в паре с stm32, юзал как «модуль», через AT. А вот v12 уже на борту и памяти прилично имеет, да и вообще красавчик. Есть ли для него чего интересного, акромя NodeMCU и ардуиновской прослойки, на C(++)?
Главное чтобы был достигнут необходимый результат. И не важно что применялось, Ардуино или что-то иное — это уже идеология. (если не религия)
Главное чтобы был достигнут необходимый результат. И не важно что применялось


Мне как-то понадобился тач-сенсор оси z на 3d принтер. Сделать его на Ардуине потребовалось часов 10. Прекрасно работает до сих пор. (Плюс уже человек 50 повторили конструкцию и радуются. Цена копейки, доступно для повторения даже чайнику)

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

Конструкция на картинке нарушает ТБ и требует 2-х людей вместо одного. У Ардуины таких проблем нет.

Какие конкретно ТБ, чем конкретно нарушает? Это вообще частный дом может быть, откуда в нём правила ТБ?
Разве правилами ТБ можно пренебрегать если работы проводятся не на производстве? Мне почему-то кажется что нет…
Так или иначе, там где достаточно применить Ардуину, следует её применять, а не строить из себя «принципиального» исключительно по религиозным соображениям.
(Никто же не побежит в Home Depot за пневматическим молотком и компрессором чтобы повесить новую фотку любимой кошки на один гвоздь ;-)
Разве правилами ТБ можно пренебрегать если работы проводятся не на производстве? Мне почему-то кажется что нет…


Не знаю. Давайте проверим.

Вы дома лампочки в люстре меняете иногда? Наверняка да. Давайте попробуем проверить:

1) назначен ли руководитель работ, выполняет ли он свои обязанности?
2) прошли ли вы обучение и инструктаж по технике безопасности, а также стажировку на рабочем месте?
3) одеты ли вы в положенную для данного вида работ спецодежду?
4) огорожено ли место установки стремянки, чтобы не допустить случайные толчки от проходящих мимо членов семьи?
5) в случае, если высота подвеса люстры требует подниматься по стремянке более чем на 1,3 м, соблюдаете ли вы требования по ношению защитной каски и использованию страховочного пояса?
6) есть ли, наконец, у вас допуск к работе с низковольтным оборудованием напряжением до 1000 В?

Так или иначе, там где достаточно применить Ардуину, следует её применять


По-прежнему не вижу никакой разницы с моей картинкой. На ней приставной лестницы более чем достаточно, чтобы покрасить стену.
Давайте —
1) Да, назначен владельцем помещения. Контроль над выполнением работ так же возложен на владельца.
2) Обучение и инструктаж пройден, имею допуск к работе NFPA 70.
3) Несомненно
4) Предпочитаю ограничивать доступ неавторизованному персоналу в помещение в котором проводятся работы (кроме кота, это святое и правил он не нарушает своим присутствием)
5) Больше 1м подниматься не приходится, роста хватает. (впрочем, у нас другие стандарты)
6) Опять таки, у нас другой стандарт, но сетевые 120В в него вписываются.

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

Лестница на картинке установлена небезопасно и требует 2-х людей место одного (увеличение трудозатрат).
Ардуино требует, напротив, меньше затрат и ничуть не опаснее любого иного микроконтроллера. )))
По пункту 1, я надеюсь, приказ о назначении руководителя работ собственником помещения оформлен в письменном виде, иначе дальнейшее недействительно.

Лестница на картинке установлена небезопасно и требует 2-х людей место одного


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

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

А что мешало в ответ на картинку сказать «ну да, если надо одну стену покрасить, то в чём проблема»?
По Пункту 1 вы путаете Процедуру с Техникой выполнения работ. Поправьте если ошибаюсь, но Приказ никак не влияет на сами работы, а лишь определяет ответственности.

Вообще, если говорить по делу, а не плодить флуд — Ответе, что бы Вы использовали для оперативного создания тач-сенсора оси Z?
Заранее спасибо.
(Я уложился в пару баксов и 10 часов — ваш выход ;) )
Нет, не путаю. Нельзя проводить работы, если не назначен ответственный за них (и за соблюдение техники безопасности). Любая проверка вас просто немедленно закроет до устранения, а скорее всего ещё и оштрафует.

Что такое «тач сенсор» в этом контексте? Датчик касания? Ну, в смысле, металлический щуп касается металлического же корпуса (основы, подставки или что у вас там)?

Взял бы ближайшую плату на мелком STM32 за три бакса и за пятнадцать минут набросал бы туда прошивку.
Вот, чтобы долго не объяснять (автокалибровка самим соплом об стол): www.youtube.com/watch?v=NPOp-cZX050

Взял бы ближайшую плату на мелком STM32 за три бакса

А почему не Intel i7?
Если уж палить из пушки по воробьям, так со всех орудий… )))
(Зачем STM32 для такой примитивной приблуды то?)
(пожав плечами) Могу взять STM32F030 за 50 центов, у меня их много. У вас задача какая — сделать это с минимальными затратами усилий, с максимальной оптимизацией по цене или на ардуине?

Это три разные задачи.
У меня задача сделать из того, что будет работать и под рукой.
Ардуина была как раз под рукой и она работает. ))
UFO just landed and posted this here
А я, заметьте, вообще никак своё отношение к картинке не проиллюстрировал :)

Плохого тут только то, что если всё же навернёшься — лететь очень далеко; но шансы навернуться, если не быть совсем дебилом, невелики.

Ну и то, что это кривое, сиюминутное, неудобное при необходимости масштабирования решение. Хотя в данном случае и работает. Как и ардуина.
UFO just landed and posted this here
если можно сделать красиво — нужно делать красиво.
А можно ссылочку на определение «красоты» в данном контексте?
Ну чтобы знать что красиво, а что нет…
Мне просто всегда казалось, что важны характеристики девайса, а не маркировка микроконтроллера. )))
(очень печально, если для кого-то самоцель инструмент, а не результат)
MISRA C, разумеется.

Шучу.

Но стремление людей во что бы то ни стало пользоваться неудобным инструментом удивляет.
Очень любопытно, а кто решил за всех остальных какой инструмент является удобным, а какой нет?
Было бы любопытно глянуть подобное евангелие. )))
Приятно видеть, что кроме как перевести стрелки Вам нечего ответить. )))
Понимаете ли, трудно убедить человека, что сточенной до состояния тупого шила дедовской отвёрткой пользоваться менее удобно, чем новой Wiha, если он не хочет даже пробовать.
Вот не нужно только этого менторского тона. Вы понятия не имеете с чем я работаю и какие инструменты применяю.
Что, впрочем, мне ничуть не мешает для простых поделок юзать и Ардуину — не вижу в этом никакой проблемы.
А что касается убеждений: Я интересовался не ими, а аргументацией.
Но, как вижу, как раз таки аргументов у вас и нет. Посему пошла чистой воды демагогия. )))
Удобным является инструмент, позволяющий обеспечить максимальное качество выполняемых работ при приложении минимальных усилий.
В первую очередь, субъективно Удобным является тот инструмент, которым вы лучше всего владеете, а потом уже всё остальное. )))
Мягко говоря не умная картинка.
Для простых проектов (для которых и существует Ардуина) никаких существенных преимуществ другая среда не даст.
Как я уже много раз говорил — Всё зависит от преследуемой цели.
Я тебе один умный вещь скажу, только ты не обижайся.

Обсуждаемый тут Mbed — это та же ардуина, только сделанная головой, а не жопой (ну и в целом приближенная к реалиям 2018 года).
С Mbed понятно. Непонятно другое — почему у многих такая классовая ненависть к Ардуине?
Людей прямо закорачивает «я пишу на этом, значит это самое удобное и все должны на этом писать!»
Даже с медицинской точки зрения, не очень здоровый подход. ;-)
потому, что вместо применения нормальных методов ардуина прививает дурной подход (начиная от говнокодерства, и заканчивая говносборкой). для вхождения в мир электроники — дуйня вполне себе нормальна. у меня сын с нее начинал. если планируется либо регулярная работа (не обязательно профессиональная — просто много идей для поделок), либо долгая (поделку планируется развивать и дополнять), либо сложная (нужны средства отладки) — лучше выбирать более современный инструментарий — он удобнее, проработаннее, и чаще всего не дороже.
ну и если есть выбор — имхо, не стоит выбирать старое решение без существенных причин.
Не, ну понятно, что серьёзный проект на Ардуине никто делать не будет. Но об этом вроде речи и не было.
во-первых, к сожалению, пытаются. и ладно бы, если из-за легаси.
во-вторых, если у вас есть серьезные и несерьезные проекты — не проще и логичней ли использовать для них один инструментарий? тем более, что стоимость одинакова?
По первому пункту: Ну что поделаешь, люди разные. ))
(впрочем, есть и коммерчески удачные проекты)
По второму: Шут его знает, разнообразие же.
1. ну да, каждый сам кузнец своего геморроя. но чаще это связано с боязнью нового и с предубеждениями, что дуйня — это просто, а остальное слишком сложно.
2.разнообразие… вот представьте, что у вас три клавиатуры — для форумов, для программирования и для работы с офисом. большой в этом смысл?
1. Для совсем чайника Ардуина действительно проще. А для нормального уровня вообще без разницы по сути.
2. У меня долгое время было 3 клавиатуры: для текста, для графики и для игр. (последние 10 лет одна, после того как на Mac перешёл и постарел для игр )))
игровые — понятно. там несколько иные требования. но я говорю про клавиатуры с одинаковыми требованиями и характеристиками. просто с искуственно разгранченным применением.
Ненависть? Да нет, скорее, вбитая в детстве брезгливость — не трожь говно, испачкаешься.
Брезгливость не оборачивается тягой при любом удобном и не очень случае напомнить всем о говне. Так что тут чистая ненависть.
К тому же — судя по количеству и качеству комментариев — ТС испачкаться всё же довелось и весьма изрядно.
В вас говорит инфантильный снобизм и хамство, в данном случае.
важны характеристики, безусловно. но при прочих равных — красивое решение приятнее.
понятие «красоты», конечно, субьективно — но оно есть. как есть оно и в математике, и в физике.
и да, складывается ощущение, что для очень многих (в т.ч. в этой ветке) самоцель — именно инструмент. ардуина. сделать обязательно на ней. хотя есть аналогичные инструменты, где не нужно чесать пяткой ухо.
Мне вот интересно, а как вы определяете на чём написан код, если использован один и тот же контроллер, выполняет точно те же функции, но первый написан под Ардуино, а второй на чистом С?
Или это как-то на уровне святого духа проникает в самую глубь сознания? ;)
Дайте определение вашей «красоте», если не затруднит.
А это очень легко.

Описываемый способ реализации многозадачности можно охарактеризовать как «soft-realtime», типовое время задержки в системе составляет 10 мс (но пиковые задержки могут быть значительно больше и не нормируются). Это накладывает известные ограничения на спектр применения данного решения, но для большинства «бытовых» задач (и не только) он прекрасно подходит, см. пример выше.

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


Типичное описание работы написанной через пень-колоду ардуиновской программы, крутящейся в loop().
Есть масса задач, для которых подобные ограничения не являются препятствием для построения необходимого девайса.
(В конце-концов, для каждого контроллера и для каждой среды разработки есть свои ограничения. Главное их знать и подобрать соотвествующий поставленной задаче. Не так ли?)

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

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

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

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

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

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

Очень просто: в 2018 году нет пока ещё диктатуры «писать только на чём-то одном». Каждый выбирает что ему больше нравится.

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

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

Ну ОК, а что б тогда на ассемблере сразу не писать?
Зачем все эти костыли типа Си, Mbed и прочая гадость?
Вы же сами понимаете, что тру-программист должен говорить на языке процессора! ))))))
Ну вот, теперь началось паясничание.
Значит молоток+шуруп это не паясничание, а ассемблер так сразу оно?
Двойные стандарты, уважаемый.
Я то хотя бы в рамках программирования ёрничаю, а вас всё на стройку тянет.
Ага… всё равно… Спустя десятки десятки ответов и цитат на эту тему… если не сотни. Кого вы пытаетесь этим обмануть? Самоубеждение не иначе.
Было бы всё равно — комментариев к статье раз так в 5 было бы меньше.
Я вот, честно говоря, теперь не понимаю — вы статью писали то зачем — делиться знаниями или религией?
Статью я писал, чтобы немного уменьшить количество людей, которых любители ардуины приобщат к типовому ардуиновскому говнокоду, убеждая, что «везде всё сложно, только у нас всё просто, а работает так вообще зашибись».

И продолжу, кстати, работать в этом же направлении.

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

Ребята, вы на это не заработали.

И с таким подходом — не заработаете никогда.

Это не мироощущение. Это объективная реальность. Живите с этим, продолжайте убаюкивать друг друга.
Реальность в том, что мы с вами тут на равных. А не как в армии, где есть устав, и будь вы моим командиром, я бы блаженно вытянувшись по команде смирно, выслушивал какое я говно.
Вам жить со своими экстраопляциями многообразия жизни на говно. Могу только соболезновать.
К сожалению, у вас не очень много вариантов.

Вы можете:

1) Убедительно доказать несостоятельность моей позиции, показав красивые, современные и изящные проекты на Arduino, возможно, даже написав про это отдельный пост. Правда, тут вас ждёт ряд трудностей, которые будет трудно списать на моё мироощущение.

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

3) Стоять и выслушивать. Правда, вам это не нравится.

Выбор за вами.
Кто о чём а вшивый о бане профи про ардуину.
Ничего, что я сетовал лишь на подачу материала и не защищал ардуину? Опять мимо ушей…

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


Поясню: это вы в safe zone хотели. Где нельзя дрянь называть дрянью, потому что дрянь может обидеться.

Вот и выслушивайте дальше, что ваш стиль подачи материала — говно


С моим стажем написания разного более 15 лет и с десятками тысяч читателей на один материал — вы меня очень сильно сейчас напугали.
Пффф… ардуинщики (раз вы с них слезть не можете — то давайте о них и поговорим) «со стажем» имеют не меньшую аудиторию и написали всякого разного. То же мне — нашли чем выделиться. Можно подумать ваши исходники — сплошные постулаты и ни капли говнокода.
Да на этом ресурсе таких как вы каждый если не второй, то пятый. И что то бить пяткой в грудь себя никто не спешит. По умерьте пыл и уймите гонор. Всем плевать по большому счёту. Но ваша слепая упёртость и правда забавна.
Ардуино для многих просто хобби. Зачем на нём зарабатывать? Что за глупость? )))
для многих хобби — бег и велосипед (я напротив парка живу, вижу любитеей). и я не видел ни одного, кто вместо кроссовок купил бы для бега лапти (а они стоят примерно одинаково, кстати). или кто выбирал бы велосипед похуже но за ту же цену…
До вас даже не дошло, что не заработали вы не денег, а репутации.
О репутации беспокоятся девки на выданье и прыщавые «подающие надежды» студенты.
А меня интересуют только деньги. )))
UFO just landed and posted this here
Людям просто хочется показать какие они «продвинутые», купили Segger и установили Keil. Ну и конечно, все кто что-то там клацает на Ардуине, это уже низшая каста.
Ну пусть теребят своё эго, нам не жалко. )))
UFO just landed and posted this here
Главный и несомненный плюс Ардуины — это, конечно же, лёгкое освоение азов.
Ну а дальше, да, как пойдёт и насколько лежит душа во всём этом копаться. (да и надо ли вообще).
но, как показал в статье Олег — mbed не сложнее. железо не дороже.
Тогда нужно и от mbed отказаться. Это ведь тоже «слой».
Давайте вернёмся к чистым регистрам и тд тп, к чему эти посредники? )))
чистые «регистры» — сложнее. «дороже» в плане затраченного времени. и на написание, и на отладку.
Это понятно. Но в обоих случаях мы используем дополнительный слой. Пусть один получше, другой похуже, но всё-таки слой.
так я и пытаюсь узнать — зачем использовать «похуже»?
А я пытаюсь выяснить почему НЕ использовать похуже? ))
Потому, что он ХУЖЕ?
В чём-то хуже, в чём-то лучше. По ситуации.
Понимаете, если бы вы не провели последние 10 лет на форумах ардуинщиков — вы бы, наверное, хотя бы что-то услышали про BBC micro:bit — куда лучше подходящий для школьников, чем любая «ардуина».
UFO just landed and posted this here
Я вас сейчас немного удивлю, но micro:bit изначально поддерживает Scratch — «для самых маленьких», Python — для тех, кто не собирается связывать жизнь с вычислительной техникой, и, разумеется, С со всем многообразием современных подходов к программированию встраиваемых систем. А что касается ардуины… Чему можно научить с ее помощью? Писать развесистые простыни в loop()?
UFO just landed and posted this here
1. И именно поэтому он поддерживается в micro:bit, причем официально — а не как в ардуине, «шоб было».

2, 3 — да при том, что ардуина, с ее диалектом C (как он там называется? Processing или Wiring? не суть важно) пригодна только для достаточно мотивированных школьников этак из 8 класса, по нашим меркам. Вокруг более свежих платформ можно построить «сквозной» курс.

4. Профессор кислых щей, ага. Ты тут хоть где-то слово professore видишь? it.wikipedia.org/wiki/Massimo_Banzi

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

Ардуина занимает свою нишу не потому, что она такая очень хорошая, а потому, что другие эту нишу занять даже не пытаются.
Видел я этот ваш micro:bit. Для "помигать светодиодиком" — отличная платформа. Что-то с видимым, относительно сложным и выглядящим полезным результатом малой кровью — шиш вам, он просто неудобен, в отличие от ардуины, которая тоже не верх удобства, но поудобнее будет в механическом плане. И продвижение его практически никакое в отличие от.
Другие альтернативы, вроде того же нуклео, пытаются паразитировать на ардуине (колодки ардуиновского формата). А реальных действий по продвижению и популяризации, по созданию развитой экосистемы совместимых модулей — почти ноль в отличие от (типа пусть ардуинщики клепают свои пятивольтовые модули, гладишь, что и у нас заработает).

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

— Встречаются ли буковки «C++» в официальных материалах по ардуине?
— Упрощает ли это ее освоение школьниками?
UFO just landed and posted this here
1. Нужно планировать, в том числе и запас на новые фичи. А что если вы сделали проект на STM32, а завтра вас попросят чтобы он рендерил 4К в реалтайм? Сразу Intel Xeon ставим? Ну смешно же…

2. Ошибки пропускают всегда и везде, даже в НАСА. Это неизбежно в принципе.

3. Не всегда такая возможность нужна. Особенно когда делается для собственных нужд.

4. Адекватность понятие растяжимое. Особенно если его помножить на «Расширяемость». Какое-то время назад г-н Гейтс считал что 640K ought to be enough for anybody ))

5. Порой самописные решения совершеннее сторонних. (да и сторонние не даны нам свыше, их ведь тоже кто-то писал)

6. …ну это очевидно вроде. Без комментариев.

7. …зависит от проекта. (Если это «метиостанция» на батарейке, то плевать. Но если это управление котлами пивоварни, то даже не «стремление», а обязательное соответствие.)

8. Согласен. Но тоже зависит от проекта.
1. Вы путаете планирование ресурсов с планированием архитектуры проекта. Я вам привёл дословное описание потрохов проекта, который изначально написан немасштабируемым, независимо от того, сколько у него ресурсов. К тому же классу относится большинство проектов на bare metal, в которых авторы руками не сделали нормальную архитектуру с разделением на HAL, плату и пользовательский код.

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

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

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

Я пока только одного не понял: зачем вам так надо доказать окружающим, что вот этот ваш глубоко персональный шуруп, который вообще никого, кроме вас, не волнует и волновать никогда не будет, был забит правильным образом.
Вообще-то это вы изначально присоединились к беседе, а не я.
Никто же вас не заставляет её продолжать, не так ли?
Но нет, вы продолжаете доказывать, что Ардуино это шуруп и молоток. )))
Вообще-то вы это всё пишете под моим постом, на секундочку. Который не дал вам спокойно пройти мимо, а заставил который день доказывать, что шуруп, забитый молотком, имеет право на жизнь.
А свой коммент вы оставили в ответ на мой коммент — так что уж извините, но это всё-таки вы присоединились к беседе, а не наоборот. ;)
Автор меня просто удивляет своей дубовостью. Мне кажется ему просто хочется троллировать людей, а истина — это не очень важно.
Так или иначе, но беседа получилась не скушной.
(почти 9 утра, а я ещё не ложился, при том, что завтра с утра на океан ехать. капец режиму. )))
кстати, пульт очень часто хочется усовершенствовать.
И что мешает? ;-)
Против лени ни одна среда не поможет, это да…
(у самого уже полгода очень интересный проект лежит на полпути. Главное что схемотехника сделана, платы заказаны, прототип обкатан. Осталось только собрать всё в кучу и написать статью на Хабр )
UFO just landed and posted this here
Всё что вы описали относится не к выбору платформы и/или среды, а к квалификации самого разработчика.
1. в линейке STM32 можно будет выбрать контроллер пошустрее, с бОльшим количеством памяти — и доработки софта будут небольшими.
2. если есть средства разработки, включающие средсва контроля/отладки — наверное, лучше пользоваться ими?
3.даже если «делается для собственных нужд» — это не повод злобно говнокодить. кроме всего прочего, даже сам можешь что-нибудь забыть.
4. в плане адекватности — иногда обидно, что на камне столько неиспользуемой периферии. но вся эта периферия есть за цену той же дуйни.
5. порой — да. но чаще всего сторонние решения обкатаны и оттестированы бОльшим количеством пользователей. свое самописное решение еще нужно оттестировать. это касается и дуйни, и стм.
1. Верно. Взять STM32 помощнее (или nRF52832) и разработать необходимое в среде Ардуины. ))
2. Несомненно лучше.
3. Культура кода не зависит от среды или языка, она либо есть, либо её нет. Все свои проекты (любого объема и назначения) лично я всегда снабжаю комментами, хотя бы минимальным планом, описанием и тд тп. Просто привычка.
4. За содержимое кристалла кремния мне совершенно не обидно. Иначе давно бы покончил с собой от осознания того, что процессор iPhone в разы мощнее бортовых систем Шатлов, а я просто по нему звоню и СМСки отправляю. ))
5. Все «отточенные» теперь решения когда-то были сырыми — это дело времени и востребованности компонента. Сделаешь потенциально полезное и оно будет жить и шлифоваться.
1.а зачем среда ардуины, если есть гораздо более удобная среда? и зачем ардуинский стиль, если есть более удобная методика?
2. ну и зачем тогда дуйня?
3. культура — она в том числе создается окружением. той самой средой.
4. мне, начинавшему с «рассыпухи», иногда обидно. жадность совковая.
5. естественно. но в момент написания оно еще только «потенциально полезное», зато уже «потенциально глючное».
1. Да просто, just for fun. Это же хобби, оно не обязано быть на 100500%% рациональным. (или вообще рациональным хоть на 1%)
А почему люди выращивают помидоры в горшках? Проще же купить в магазине — Для удовольствия. ))
2. Смотрите ответ №1
3. Это человек вокруг себя создаёт культурную среду, а не среда человека. (если человек разумный, конечно, а не просто ****)
4. Ну я тоже начинал с рассыпухи. Хотя и тогда её было уже не жаль.
5. На момент создания всё глючное, хоть на Си пишите, хоть на Клингонском. (Ведущие софтверные конторы не могут порой годами пофиксить даже критичные моменты, что уж говорить о любительском программировании.)
т.е. иррациональный мазохизм в рафинированом виде?
Так уж устроен человек. Вон сколько попыток сделать ИИ на рациональной основе. И нифига не получается. Нет в нём «искорки идиотизма». )))
только порой мне кажется, что вместо «искорки» пытаются добавить минимум «костер»
я не «определяю». я стараюсь делать красиво.
не вот так. habr.com/post/419445/#comment_18998655
понимаете, ходить в рваных носках и дырявых трусах — неприятно. мне неприятно, самому. хотя, казалось бы, никто не видит…
«Так» можно и на Си написать и в Ардуине.
Это не от среды зависит, а от навыков разраба.
естественно, наговнокодить можно везде. но некоторые среды к говнокоду располагают. а некоторые — нет.
Некоторые статьи располагают к развивающим дискуссиям, некоторые к срачу… Зачем писать статьи со срачем?
Тогда бы все Си-программисты были образчиком культуры, а все, скажем, Swift говнокодерами. Но как показывает практика, такого не происходит.
Напротив, если человек неряшливо пишет на одном, то и на всех других у него будет такая же каша.
Код — проекция содержимого головы. Только и всего.
но в голове оно не само берется. а в результате в том числе наработки опыта. (ну и обучение, литература, чтение чужого кода)
Если бы мне в свое время не попалась книга ВанТассела — было бы грустно…
Интересные графики в начале статьи. Доля 32-битных процесоров сокращается, а 8-битных растет. :-|
Во-первых, 2017 год на этих графиках слева, во-вторых, колебания — в пределах, так сказать, погрешности измерения.
Я в курсе что 2017 год слева. Кстати для 16-бит и 64-бит 2017 похоже тоже стал переломным годом.
Что бы судить была ли это погрешность неплохо иметь еще данные за 2018 год.
А раз про ардуину напомнил…

Ты случайно не знаешь распространённых аналогов firmata но под «экосистему» арм?

Хочется найти распространённый протокол (и либу) через который с хоста по USB можно было бы подёргать ногами, условно.
Не интересовался, хотя в принципе саму Firmata не должно быть сложно портировать на платформы на C++.
Уважаемый olartamonov! Я попробовал Ваш пример с LowPowerTicker на плате Nucleo-STM32L011. И онлайн-компилятор пишет мне, что не хватает памяти. Более того, не хватает памяти на все, что сложнее примера blinky.
Ошибка: Error: No space in execution regions with .ANY selector matching scanf_char.o(.text).
Код:
#include "mbed.h"

LowPowerTicker toggle_led_ticker;

DigitalOut myled(LED1);

void toggle_led(void) {
myled = !myled;
}

int main() {
toggle_led_ticker.attach(&toggle_led, 1);
while(1) {
sleep();
}
}

Вопрос: что делается не так и как правильно?
Оно не влезает в такой объём памяти. Контроллер слишком маленький.

В Mbed по умолчанию используются библиотека newlib без суффикса nano, в ней очень, очень, очень жирные printf и scanf, буквально десятки килобайт. К ней меньше чем с 64К флэша можно не соваться.

В локальной установке Mbed её можно поменять на newlib-nano, тогда становятся возможны 16КБ и флэша и 4КБ ОЗУ. 2 КБ ОЗУ — опять будут проблемы с printf даже в newlib-nano (он лично под себя в стэке может отожрать сотни байт), такие контроллеры для bare metal, не для ОС. Ну или для ОС, но без тяжёлых функций типа printf.
Ваш текст мотивировал меня попробовать mbed и все действительно выглядит красиво и удобно… но не все так однозначно)
Например никак не ожидал проблем с DS18B20 (датчик температуры), а оказалось что через медленную реализацию IO на STM32 «Blue Pill» ничего не работает (имею в виду существующие библиотеки).

Articles

Change theme settings