Comments 463
Я правильно понимаю, что у этой платы USART доступен через встроенный стлинк и он пишет в виртуальный COM? Это у всех нуклео так? А у плат discovery интересно, так же?
А то я пытался SWO настроить, в принципе получилось, но IDE (TrueStudio) очень глючит.
В виндовый стлинк то судя по всему нормально пишет, но я на линуксе, texane/stlink пока не имеет поддержки SWO.
На платах с USB на контроллере можно также сделать Serial pc(USB_TX, USB_RX), тогда Mbed поднимет USB-CDC и организует выхлоп через него.
Наверное все-таки SPL + свой HAL, чтобы выделить независимую от железа логику.
Все эти фреймворки идея хорошая, но как правило, принцип Парето в них очень нагляден (сужу по не-embed программированию).
80% кейсов покрыто замечательно, а чтобы разобраться с остальными 20%, придется потратить 80% усилий)
Может кому-то пригодится:
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 и блютуса можно поставить.
И действительно, реализация arduino core есть сейчас почти под все. И под STM, и под Cortex
P.S. Если не секрет, крутые перцы это с какой целью делают? Самоистязания? Мне трудно придумать, зачем ещё в 2018 г. н.э. использовать платформу, вообще никак не развивавшуюся в течение десяти лет.
Во-вторых, Вам уже объяснили, что постулат про платформу «вообще никак не развивавшуюся в течение десяти лет» — неверный. Ее развивают другие, в основном 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 % домашних проектов, не делает его менее идусским и менее быдлокодом.
Просто интересно — вы всерьёз полагаете, что если вы для ардуины способны писать только быдлокод, то на другой платформе у вас волшебным образом быдлокод как-то выправится? Удивительная самонадеянность!
На ардуине эта задача чем конкретно с такой же простотой решается?
Понимание же заключается в том, что качество платформы влияет на качество кода на ней. Нет в ардуине родных современных средств и API — так и будет на ней не большинство кода, а весь код граблями и велосипедами.
И что? Где та OS/2 и где Винда?
А НЕэнтузиасты никогда на ардуино ничего и не делали.
Но кстати, я написал ниже, что сейчас актуальная фишка — CircuitPython
Хотя в общем и без ФИДО можно бы догадаться, что в концепции «энтузистам современные средства не нужны, им бы лишь слабать чего побыстрее» есть отдельные слабые места.
Я не говорю, что всем надо срочно пересаживаться на RTOS.
Я говорю, что весь мир вообще-то уже пересел на RTOS, и если вы не хотите остаться в хвосте и наглотаться пыли, то на RTOS надо срочно пересаживаться конкретно вам.
А примеры в СДК для FreeRTOS так и воспринимаются забавной диковинкой
Ну, хотите глотать пыль — дело ваше.
- А кто создает образовательные ленты? Специалисты по производству лент? А кто же тогда создает ленты для их обучения? Специалисты более высокой квалификации? А кто создает ленты... Ты понимаешь, что я хочу сказать. Где-то должен быть конец. Где-то должны быть мужчины и женщины, способные к самостоятельному мышлению.
- Ты прав, Джордж.
Чем больше народу разучатся писать драйверы и работать с голым железом — тем больше зарплата у тех, кто умеет эти самые драйверы писать.
Таймеры — это не синтетические потребности. Это явный мастхэв даже для мигания светодиодом. Зачем писать плохо, если можно с меньшими усилиями писать нормально?
void loop() {
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;
if (ledState == LOW) {
ledState = HIGH;
} else {
ledState = LOW;
}
digitalWrite(ledPin, ledState);
}
}
Эталонный образец индусятины, а что?
Здесь же
1) энергосбережение сразу лесом, процессор молотит непрерывно
2) масштабирование тоже лесом — представьте, что в эту концепцию вам надо накидать десяток событий, которые происходят с периодом от миллисекунд до суток, этот период у каждого события может меняться независимо от остальных, а время обработки события может быть от микросекунд (мигнуть светодиодом) до десятков секунд (включить модем и передать данные)
Часть задач в ардуиновском подходе не решается вообще никак (ну, т.е., если на передачу данных модемом нам надо 10-15 секунд, то на эти 10-15 секунд всё остальное заблокировано), другая часть приводит к сну разума, рождающему чудовищ — простыни if'ов, авторы которых пытаются как-то вручную это всё разрулить, чтобы оно более-менее работало.
А в нормальной системе про такие вещи часто думать вообще не надо, надо просто пользоваться правильным API.
энергосбережение сразу лесом
В задачах типа «мигать светодиодом» энергосбережение вряд ли кого-то интересует. Да и не умеет ардуина энергосбережения совсем.
масштабирование тоже лесом
Есть куча задач, которые нет особенного смысла масштабировать. Научился мигать светодиодом (щелкать релюшкой и прочее ногодрыжество) — ну ок. Научился мигать десятком — ну тоже ок. Дальше мигать в 1000 светодиодов?
если на передачу данных модемом нам надо 10-15 секунд, то на эти 10-15 секунд всё остальное заблокировано
Прерывания не?
А в нормальной системе про такие вещи часто думать вообще не надо, надо просто пользоваться правильным API
Говнокод — это когда не думая копипастят какие-то куски кода и считают, что это правильно.
Говнокод — это когда не думая копипастят какие-то куски кода и считают, что это правильно.
Так это и есть главная парадигма «разработки» на ардуино! Нахватать библиотек отовсюда, слепить их кое-как и воскликнуть «It's alive!»
Сейчас вот ковыряю STM32F437 — даташит там огромный, но черт возьми, зачастую проще его почитать и написать хорошо, чем взять готовую либу и потом недоумевать, почему при одновременной работе карты памяти и дисплея через некоторое время идет порча буфера i2c
Зато не ардуина.
Библиотеки не копипастят, а подключают по необходимости, используя готовое решение. И как правило это не "отовсюда", а от производителя модуля.
В ардуиномире обычно (наверное, 99 процентов случаев) библиотеки просто реализуют работу с каким либо внешним модулем. Разве что, в отличие от обычной практики, библиотеки каждый раз пересобираются вместе с проектом.
Да и не умеет ардуина энергосбережения совсем.
Как это не умеет Ардуина энергосбережения? А как же батарейные долгоживущие 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 крутится?
Ардуина же продолжает плодить быдлокодеров
Воу-воу-воу, полегче.
Если ардуина используется где-то в продакшене, это по меньшей мере странно. Если для какого-то домашнего хобби-проекта, то почему бы и нет. Индусский говнокод, конечно, остаётся говнокодом, но… Ваша какая печаль? И при чём тут вообще дуина?
Я просто не люблю быдлокодеров, дураков и лжецов. Человек же, публично изрекающий что-то в духе «только в ардуино есть такая простота, в остальных системах вы умрёте под грузом даташитов, а вот какой код я написал в доказательство этого» обычно попадает во все три категории одновременно.
Под грузом датшитов никто на задачах создания домашних самоделок не умирал. Просто забивали на это, когда груз казался слишком обременительным (не был и не неподъемным, а именно казался и обременительным).
Нет, статья иногда даже хороша. Но в следующих публикациях постарайтесь вкладывать больше смысла и соответсующей ресурсу тематики и поменьше своего эго. Оно у вас недружелюбное и навязчивое. Это не пикабу всё таки.
По крайней мере когда я пишу код на ардуино, я понимаю как он работает, понимаю что digitalWrite кушает в 20 раз больше ресурса процессора чем прямая запись в регистры порта, и позволяю себе это, когда нет нужды в большой производительности. Код у многопоточный на milis() и примитивной реализации конечных автоматов, мне не напряг контролировать их взаимоотношения самому, по крайней мере вижу как это работает а не отдаю под контроль специализированной функции, у которой тоже под капотом тёмной лес. Проекты работают стабильно, корявые библиотеки не использую или правлю и в итоге трачу мало времени на разработку коммерческих частных проектов, получаю за них деньги и клиентам нравится. Сейчас пишу систему контроля множества параметров гидропоники, около 15 датчиков, исполнительных устройств дюжина, экран, менюшка. Что я делаю не так? Пыль в горле не ощущается. Работает то все стабильно и код писать легко и удобно. Что еще надо? Производительность только и больше фарша :) Вот и открыл статью в надежде разобраться как работает арм, как к нему подступиться, зачем эти три компилируемых файла, какой где лежит за что отвечает и как работает, а получил очередной хеловорд с горой неизвестных переменных, онлайн средой которая не пойми что там собирает. Зачем вы пришли и рассказали мне какой я говнокодер но не приложили качественный материал помочь стать лучше. Чтобы самому разобраться как все это работает и устроено внутри, понадобится куча времени, которую вы могли бы сэкономить, но если это время потратить и разобраться то и пример из статьи будет мало информативным. А делать делового без понимания механизмс работы, какой толк. Чтобы сказать теперь я не говнокодер? Так это только страдающим плохой самооценкой подходит, спасибо, но нет)
С другой стороны вопрос, за вот это ваше счастье с кучей фарша обязательно платить привязкой к интернету во время разработки или можно как то локально работать с проектом допустим уже на объекте, как у меня часто бывает? И не увидел как отлаживать, ибо серийным портом и на средине все так же красиво контролируется, на тех же 115200) спасибо, если получу ответы на вопросы.
Извините, наболело.
«открыл статью в надежде разобраться как работает арм, как к нему подступиться» — научить человека нельзя. можно лишь помочь ему научиться…
Быдлокод внутри ардуины пишет в большей части пользователь. И другая платформа не сделает волшебным образом этот код лучше.
Программировать под ардуину можно в разных 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 карты), который механически вставляется в контакты платы.
Ок, а также ок.
Я пробовал подключать GSM шилд к трехвольтовым платам, толерантным к 5 вольтам.
Но шилд в этом случае не всегда нормально воспринимал данные по UART.
Если посмотреть документацию на модем (хоть симком, на котором любят делать у нас и в Китае, хоть квиктел, который продают на arduino.cc), напряжение на ногах модема не должно быть выше 2.8… 3 вольт.
Т.е. там ДОЛЖНЫ быть преобразователи уровня.
Оригинальная плата использует полноценные буферы, подключенные к ардуинным 3.3 вольтам (и, к слову, они превышают максимальные 3.1 вольта для квиктела). Трёхвольтовые сигналы от основного контроллера для этой схемы — как родные.
Какой китаец так умудрился сделать преобразователь, что он якобы не работает с трёхвольтовыми сигналами, надо разбираться
Для SIM5300 (у него I/O вообще 1,8 В), слава китайским богам, официально рекомендуется нормальный транслятор TXB0108 — который, впрочем, китайцы всё равно вряд ли будут ставить, ибо дораха.
Именно шилд абстрактный в вакууме.
У меня куча других занятий, совершенно не связанных с использованием микроконтроллеров, чтобы тратить свое время на выбор правильного шилда, который заработает.
Потому берется то, что попадается под руку.
В результате только часть имеющихся шилдов и модулей способна корректно работать с трехвольтовыми платами, что и предопределяет выбор платы, к которой все это добро будет прикручиваться.
А то я каждый раз, когда вижу подобный треш и угар
Олег, не сочтите меня назойливым, но рекомендую в первую очередь поискать треш и угар в вашей голове.
os.mbed.com/teams/components/code/GSM
Я уж было решил, что вот оно — счастье, меня сейчас быстренько научат правильно писать драйвер модема.
Но нет же. Отправляем команду, и ждём ровно один ответ («OK», как правило). Если в этот момент нежданно-негаданно прилетит URC, она улетит в /dev/null.
Спасибо большое, такое г. я и сам понаписать могу.
Сама ардуиновская библиотека написано плохо, и она навязывает пользователю такой же стиль, потому что он ее видит.
Библиотеки, конечно, есть, но они написаны ничуть не лучше, ни в коей мере не оптимизированы и довольно таки глючные.
А по поводу плат с датчиками для ардуино — это отдельная песня, посмотрите на любом форуме — постоянные конфликты.
Общий вывод — ардуино заточено под быстрое выполнение несложных проектов (для целей обучения) и попытка натянуть ее на нечто большее — это на вина ее авторов.
Для целей обучения библиотеки и датчики должны быть стабильнее и яснее, чем для боевых проектов, а не наоборот. Никто не учится паять сломанным паяльником (я надеюсь).
P.S. Хотя после них чем-то другим пользоваться трудно, почему-то уверен, что если подниму этот вопрос, услышу много мнений о незаменимости купленного на Али люкея.
Хорошо, ознакомлюсь. Я сам не очень в теме, просто исхожу из логики комментария
Сама ардуиновская библиотека написано плохо
ардуино заточено под быстрое выполнение несложных проектов (для целей обучения)
Плохое не должно использоваться для обучения. Переучивать с плохого навыка сложнее, чем учить с нуля, любой тренер подтвердит.
Программировать под ардуину можно в разных IDE и без использования ардуиновской библиотеки.
Вот только это уже не будет программирование под ардуину.
Так что с этой стороны проблем у ардуины как раз нет.
Нет, т.к. по сути и ардуины уже нет.
Не знаю, как на ARM, на AVR ардуинках данный разъем вроде как используется исключительно для прошивки. На некоторых ардуинках их вообще два: один для микропроцессора, а другой для преобразователя USB-UART, но оба только для прошивки.
Atmel платы, аналогичные хотя бы банальному blue pill, какие-то очень уж маргинальные и стоят дорого.
И перспектив, видимо, никаких.
Я скорее про arduino vs stm32.
Оригинальные демоплаты мне нравятся тем, что на них сразу есть стлинк, все заведомо работает как надо. Разница в цене для меня несущественна. А вот в конечных DIY-устройствах использовать такие платы конечно невыгодно.
Сам не считаю ардуино вселенским злом. С него легко приобщиться к МК и цифровой электронике. А говнокодинг он везде говнокодинг. Кто-то хочет развиваться и делать лучше, кто-то нет. ИМХО дело не только в ардуино.
Да-да, есть даже анекдот про это:
Кабинет ветеринара. Входит медведь с белкой на голове.
Доктор: — На что жалуетесь?
Белка: — Да вот, к хвостику что-то прилипло…
> Оригинальные платы Arduino есть на разных процессорах… и даже Intel (Zero).
Ага-ага. Называлась эта штука Intel Edison Kit for Arduino, и при всей ее мощности (Atom с тактовой частотой 500 МГц, 1 Гб ОЗУ, 4 Гб флеша, Yocto Linux и так далее) «официальные» примеры исчерпывались морганием светодиодом и работой с датчиком по I2C. Зачем для этого «ардуина с Intel» стоимостью около 100$, когда с теми же задачами прекрасно справляется и обычная ардуина с AVR?
Не путайте. Intel Gallileo, Intel Edison — продукты, с которыми интел пытался влезть в эту нишу.
А есть просто ардуина на интеловском чипе — Zero.
«The board is powered by Atmel’s SAMD21 MCU, which features a 32-bit ARM Cortex® M0+ core.»
В общем, эту платформу Интел толкал-толкал, да утомился и бросил на фиг.
Но у меня остался экземпляр для музея.
habr.com/post/256089
а с другой — кривоватая и неполная документация (скажем, найти документ, где было бы описано назначение джамперов на Kit for Arduino — задача нетривиальная).
Могу сказать, что причина, по которой Ардуионо будет еще жить десятилетия — это библиотеки. Хочешь подлючить датчик — нашел библиотеку на Github и через 5 мин все работает.
А потом попробуйте подключить тот же bme280 к nrf52 в рамках SDK
Но есть компромисс: nrf52 с Arduino core :-)
Точно так же было с esp8266: он не взлетел, пока Иван не написал для него arduino core
А с какой конкретно целью это надо делать именно в рамках SDK? ОС использовать религия не велит?
Например, мой прибор управления обогревом и освещением домашнего птичника собран на коленке на базе ардуины, перемотан скотчем и успешно трудится третий год без моего вмешательства. Пока будет ардуины хватать для небольших задач — буду пользоваться ей, т.к. накоплен некоторый опыт, и для бытовых мелочей так мне проще и удобнее. Но если я займусь более сложной задачей, то да, я открою Вашу статью, или что-то более новое и актуальное на тот момент, и начну осваивать 32-разрадные чипы, добровольно, осознано, и с благодарностью к тем людям, которые облегчили мою миграцию на новую платформу.
С уважением.
Потому что плодит толпы быдлокодеров, железобетонно уверенных в своей правоте.
Поэтому ардуине как массовой платформе надо умереть и уступить место платформам более нормальным.
… толпы быдлокодеров, железобетонно уверенных в своей правоте.
Боже, вы так точно себя характеризуете! Заметим, что ардуинщики с пеной у рта, так как вы тут не доказываете единственность пути. Они лишь использует тот инструмент который им удобен.
Если сравнивать стамеску, фрезер ручной, и фрезерный станок, то эти инструменты могут выполнять похожие задачи, но фрезерный станок делает быстрее и чище. Однако с появлением станков достаточно много людей продолжают пользоваться ручными пилами, стамесками, рубанками. И ничего в этом плохого нет.
Поэтому ардуине как массовой платформе надо умереть и уступить место платформам более нормальным.
А ардуинщиков на лесоповал. А тех кто еще и быдлокодеры — на костер.
— Наверное это человек с профессией программист ведущий себя по хамски!?
Но (!) я всё-таки встретил на своём пути эталонный образец подобного существа:
— Полное отсутствие желания вникать в проект. Отсюда — что скажете, то и напишу. Была где-то максима, что программиста следует оценивать по числу предусмотренным им ситуаций. Так вот, так как вникать в проект не планировалось, то и ситуации будут реализованы только те, которые ему написали. Остальное не его дело.
— Программа абсолютно нечитаема. Она написана без форматирования вообще, в ней сплошные магические числа. Редкие комментарии. Функции на 400-1000 строк. Если надо сделать одно и то же действие, но над разными элементами массива — делается столько одинаковых функций, сколько массивов. Инкапсуляцию не применяем вообще. Глобальные переменные легко и просто определяются внутри 5000 строчного файла в любом месте. Имена этих переменных могут быть a1,a2,a3. Вся огромная (да-да, программа нужна очень сложная) программа в одном или двух файлах. Язык понимается плохо. Структуры не используются из идеологических соображений («я их не люблю» было мне сказано).
попробуйте подключить тот же bme280 к nrf52
За час переписать read()/write() adafruit'овской библиотеки?
Или за день раскурить даташит bme и построить очередной велосипед?
P.S. Вообще для более-менее серьёзной разработки Mbed всегда утаскивают локально — там будет сильно больше настроек, чем в онлайне. Ту же скорость stdout'а можно просто в JSON-описании проекта указать сразу.
Подписался, пишите исчо :)
Вариант два: https://habr.com/post/358682/
Любой код добавляется локально через mbed-cli add, во всех проектах на mbed.com в кнопочке Import есть два пункта — в Compiler или в mbed-cli
P.S. С mbed-cli есть две засады — во-первых, очень долгая начальная сборка и просто долгая пересборка проекта, во-вторых, у меня он иногда отвалился с сообщением, что хедер какой-то где-то там в глубине не найден, помогало просто запустить его второй раз.
Один человек ковыряет нижний уровень, и ему не надо знать ничего про верхний, кроме каких-то прилетающих оттуда хотелок типа «а можно с медленного таймера в L1 получить не секунды, а миллисекунды?».
Другой пишет верхний — и ему в общем ничего не надо знать про нижний, кроме ответа на предыдущую хотелку.
Я недавно поработал с ССS в плане EasyLink, потратил дня два, чтобы разобраться с работой SD карточки в этой библиотеке, проклял TI несколько раз (как правило, по делу) но в конце концов убедился, что у них все хорошо и вряд ли я сделаю лучше (а такое заявление от меня дорогого стоит).
А в том же RIOT мы довольно много в своё время на низком уровне написали, в том числе такую вещь, как миллисекундный RTC-таймер на STM32 — который основные разработчики ОС вряд ли сами будут реализовывать, потому что это такой костыль для тех, у кого LPTIMER'ов нет, и не на всех STM32 он работает.
Но опять же, у меня сидит программист верхнего уровня, пишущий вещи типа поддержки электросчётчиков или протоколов NFC-карт, и всё, что он знает про rtctimers-millis — это тезис «на задержках от 10 мс используй только его».
Сейчас TI их пробует придавить немного, уже месяца три целенаправленно рекламируя младший MSP430 (25 центов штука, и это каталожная цена) в качестве альтернативы мелкой логике — при том, что TI сам является крупнейшим производителем этой логики.
ARM'ы у Atmel, кстати, интересные, у нас ATSAMD51 довольно много лежит — пока не пригодились, в проекте, под который их взяли, в итоге оказалось по мощности достаточно более отработанного STM32L4, но в принципе интересная штука. Что-то типа $4,50 было за контроллер на 120 МГц и с развитой периферией.
На мой взгляд это МК, не для замены мелкой логики=)
Хотя не спорю, у всех задачи в плане разработки стоят разные. И понятие мелкая логика у каждого в плане масштабности несет разный характер в зависимости от уровня знаний и размеров схем, в которыми он работает.
Ви таки будете смеяться, но Adafruit их как раз сейчас активно продвигает. Через CircuitPython
Вместо Xmega и ARM есть серия SAM.
причём она делилась как минимум на три семейства: AVR, PIC и STM8
Это популярные в массах.
В автомобильном транспорте, например NEC. Теперь renesas очень много поставляет.
• 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 и.т.д. Все это требует полноценного чтения документации.
В случае использования готовых модулей(конструкторов) это возможно еще все прокатит, но при попытке сделать шаг в сторону обязательно споткнешься и начнешь изучать все более углубленно.
скорость работы UART
Вызов pc.baud(int baudrate) требует полноценного чтения документации? Что именно вы в ней планируете прочитать?..
К тому же изучение Reference Manual на тот же FreeRTOS(с которым я более менее знаком) займет не на много меньше времени, чем изучение документации на HAL.
Но это опять же, сугубо мое мнение.
По факту, если взять тот же HAL для STM32 и раскрыть любую его функцию то можно охренеть от всей той кучи всевозможных проверок которые там расписаны. Все это замедляет работу МК, увеличивает вес прошивки. В своих проектах, где использую HAL, я в большинстве случаев я вырезаю все эти не нужные участки, для оптимизации кода.
А можно убрать один флаг при компиляции и они сами уберутся :-/
Ну и я знаю несколько уже проектов «более-менее серьёзных вещей», которые отлично написали на низком уровне, а потом пришёл отдел продаж и принёс в клювике список пожеланий к функционалу следующей версии.
Функционалу, который в прошивку на RTOS добавить — дело ну максимум недели.
А в прошивку, представлящую собой винегрет из доступа к регистрам и обработки данных — минимум пары месяцев.
А когда ещё отдел закупок в своём клювике принёс пожелание скорейшего переезда на другую линейку процессоров, которая на доллар дешевле…
В общем, половина таких проектов ныне мертва, другая половина окуклилась в состоянии «мы заказов на новый функционал не берём».
И это всё коммерческие проекты коммерческих компаний.
Задач, в которых в контроллере вот именно ядро вот именно вычислениями загружено настолько, что у него лишней микросекунды нет, ещё меньше.
Во всех остальных случаях, собственно, HAL только помогает не иметь в коде лишней требухи.
А еще интереснее, когда нужно поработать с датчиком, критичным ко времени между импульсами
Во-во. У меня была игрушка с энкодером ЛИР-120. Частота импульсов — до десятков МГц (до 10000 об/мин ).
Видите эту страшную инициализацию процессора?
Нет. Не вижу. Я НЕ вижу на какой частоте работает ядро, на какой USB, что идет на таймеры и АЦП. По этому коду нельзя установить ничего.
Всё остальное можно посмотреть в описании платы на гитхабе, если эти параметры вам настолько важны.
В проекте с HAL и с нормальной структурой этого проекта есть три отдельных уровня:
- Взаимодействие с процессором (работа с его регистрами)
- Описание платы (модель процессора, его базовые настройки, используемая периферия и её настройки)
- Пользовательский код
В рамках индусской простыни, конечно, можно это всё смешать в одну кучу, чтобы пользовательский код настраивал частоту USB.
Но только в рамках индусской простыни.
В нормальном проекте это разные его части.
Кто выбирает источник тактирования, частоту, делители?
Что будет делать контроллер при ошибке пуска внешнего кварца? И прочее…
А с какой скоростью будет передавать UART?
Ах, это все равно НАДО прописывать отдельно на другом уровне абстракции?..
Или все решил проектировщик ОС? А откуда он знает, что мне надо? Все равно переписывать…
Кто выбирает источник тактирования, частоту, делители?
Параметры указаны в описании платы.
Что будет делать контроллер при ошибке пуска внешнего кварца? И прочее…
Логика определена в драйвере этого процессора.
А с какой скоростью будет передавать UART?
Параметры указаны в описании платы.
Ах, это все равно НАДО прописывать отдельно на другом уровне абстракции?
Кому-то надо, кому-то не надо. У вас каждое из разрабатываемых вами устройств имеет свою, уникальную и неповторимую, частоту процессора? Если нет, то я облегчу вам жизнь — можно каждый раз её заново не прописывать.
То же самое, что интересно, касается где-то так 90 % параметров, которые между разными устройствами меняются крайне редко.
P.S. И всё-таки не очень ясно, как вы миритесь с существованием языка C и компиляторов — откуда их авторы знают, какой ассемблерный код вы хотите получить?
Что будет делать контроллер при ошибке пуска внешнего кварца?Ничего подобного. У STM есть ветка (по-умолчанию пустая), куда переходит программа при сбое HSE.
Логика определена в драйвере этого процессора
А с какой скоростью будет передавать UART?В описании платы? То есть ТОЛЬКО ГОТОВЫЕ платы? А не ардуинщик ли вы?
Параметры указаны в описании платы.
Я говорю про UART контроллера. Который НАДО настраивать.
У вас каждое из разрабатываемых вами устройств имеет свою, уникальную и неповторимую, частоту процессора?У нас устройства могут иметь одинаковую частоту, но кто вам сказал, что она должна совпадать с «указанной в описании платы»?
А разве это не определенная в драйвере конкретного MCU логика? У STM32 так, у какого-нибудь LPC17xx — иначе.
> В описании платы? То есть ТОЛЬКО ГОТОВЫЕ платы?
Описание платы — в Mbed это несколько файлов типа таких: github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM/TARGET_STM32F1/TARGET_BLUEPILL_F103C8 — можно (нужно) сделать самостоятельно под любое новое устройство, и указать там те параметры, которые хочется.
Собственно, даже в ардуино есть нечто подобное, только там описания плат спрятаны «куда подальше» и толком не документированы.
ЧТО? Нет возможности динамически менять скорость UART???А с какой скоростью будет передавать UART?Параметры указаны в описании платы.
Если это правда, то получается, что значительную часть работы с устройствами надо будет писать самостоятельно.
С портом всё просто: надо создать свой экземпляр класса Serial, указать ему нужную скорость, а потом печатать через него.
Serial pc(SERIAL_TX, SERIAL_RX);
pc.baud(115200);
Но если в 90% проектов на конкретной плате UART используется для печати диагностических сообщений — не проще ли перенести эту инициализацию в «конфигурационный» файл?
Ну и желаемое качество драйвера UART — 1 сбой на 10^7 байт.
Ну да дело не в этом. Основная преграда для использования MBed — поддержка только Cortex-M. Поэтому переносимый куда угодно (включая MIPS) FreeRTOS и свои драйверы.
А если интернет пропал — все, кина не будет?
Есть масса маленьких контроллеров, например, с 2 КБ и меньше памяти. Есть специфические проекты разные, где проще написать сразу руками.
Но с другой стороны, я вижу довольно много проектов, которые начинались с «проще написать всё руками», а потом резко забуксовали, когда от заказчиков/продажников начали приходить пачки требований на новый функционал — и быстро выяснилось, что в bare metal проект его добавлять-то на порядок сложнее, чем в проект на RTOS.
Например, есть ли потребность в асинхронном вводе-выводе с максимальным использованием DMA
В Mbed ввод-вывод асинхронный уже давно из коробки. В остальных RTOS — где как, в основном это определяется тем, дошли ли у разработчиков руки. В RIOT последнем, например, DMA к UART уже прикрутили, но по факту пока не используют, чтобы не менять API (и, по-моему, зря).
Или ещё ситуации, когда именно нужно взять мануалы, чистый HAL (опять же, я говорю про STM32), и писать вот эти все ЕventHandlers, таймеры, асинхронный на прерываниях самому?
Довольно мало, они экзотические и их стоит по возможности избегать.
Потому что написание кода для готовых плат — это хорошо для домашней разработки, не более. За сколько времени будет портирован FreeRTOS и наши драйверы — я знаю. А за сколько MBed?
Довольно мало, они экзотические и их стоит по возможности избегать.Ну не особенно это экзотика — делать примерно одно и то же, но на той плате, которую хочет заказчик и теми фишками, что заказчик хочет.
Ну как пример: импортозамещение. То есть все то же самое, но на российских или почти российских ARM. Думаете это экзотика?
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 пишется. но не более того.
FreeRTOS — отлично, особенно — если под нее уже есть драйверы, желательно — более-менее грамотно написанные и переносимые. В RIOT или Mbed драйверы периферии под всякую экзотику (1879ВЯ1Я, наверное, немного не для них, а вот Миландровская продукция — в самый раз), конечно, придется писать самому — а вот для внешних устройств они будут «в комплекте» (хотя толку от этого, с «импортозамещением»?).
А драйвер ком-порта на 1879ВЯ1Я мы написали за 3 дня. Там что-то очень похожее 16550, так что вспомнил юность и написал.
Переносимость… ну даже для STM32 это фикция. F4/F7/H7 — имеют немного разные порты. Приходится #ifdef в драйвере писать.
Писать 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 не зажаты.
Что касается правок в master — пусть olartamonov про них в следующих сериях рассказывает :)
В любом случае, хуже, чем Windows API для работы с ком-портом, написать сложно. Там всего один способ не терять байты на 115200 и выше и куча способов их потерять.
Главное, что нужно от UART API — это отсутствие потери байт. А красота… Одному нравятся блондинки, а другому — брюнетки.
Независимость. Независимость от ОС (Windows, POSIX, FreeRTOS, MS-DOS и так далее). Независимость от железе (UART, файл, TCP, UDP, SPI...), кроме функции связи порта с устройством.
Ортогональность — то есть основной код не меняется при смене устройства или ОС.
Функциональность. Тут есть много хитрых требований. Например — возможность узнать, закончилась ли передача (нужно для корректной смены скорости). Возможность узнать, сколько свободного места есть в буфере передачи. Возможность узнать, сколько байт в буфере чтения до начала вычитки.
Производительность. Ну тут все просто. На 4800 мы должны передать 480 байт ± пара процентов на отличие тактовой частоты UART. Если у нас пауза длиной байт означает конец пакета (примерно как в ModBus RTU) — значит мы должны уметь передавать без пауз.
Асинхронность. Все вызовы (кроме write flush) — с нулевым ожиданием. Write flush — исключение, используется на перезапусках аппаратуры, где нужна синхронизация работы UART и GPIO.
Простота. Прежде всего простота отладки. Всякие callback — зло, ибо отлаживаются хуже.
А архитектурные красоты не волнуют. Пусть ими студентики маятся. Красиво то, что работает.
Есть вызов CHAN_Getc(), он дает байт. А откуда этот байт прилетел…
2) в ожидании не передаются параметры, в коллбэке — сколько угодно
3) таймауты в ожидании реализуются существенно менее изящно, чем в коллбэках
Понятно, что на коллбэках писать сложнее, это другая архитектура. Но они сильно гибче.
Понятно, что на коллбэках писать сложнее, это другая архитектура. Но они сильно гибче.Ну что же, жду от вас рассказа, зачем вам эта гибкость. Ну да, ускорение на пару мс там, где оно не нужно (на ком-портовых скоростях). А что ещё?
1) ожидание блокирует данную задачу, коллбэк — нет
Такое впечатление, что про non-blocking IO вы не слышали. Калбэк, между прочим, означает блокировку буфера, в который вы читаете. А иногда — и блокировку буфера на отправку.
2) в ожидании не передаются параметры, в коллбэке — сколько угодноВ неблокирующем вводе-выводе у нас есть контекст. Мы не ограничены парой параметров калбэка.
3) таймауты в ожидании реализуются существенно менее изящно, чем в коллбэках
В каллбэках с таймаутами все плохо. Запустили операцию, выставили таймаут — а потом условия изменились и надо таймаут изменить. Например: укоротить. И начинаются пляски с бубном.
В неблокирующем вводе-выводе тайматуы динамические. Мы их можем менять в любой момент.
Вообще, у меня один вопрос.
Вы всем этим сказать-то что хотите?
Сформулируйте, пожалуйста, законченное утверждение не длиннее 200 символов.
Господи, в вашей FreeRTOS есть какие-то проблемы с тем, чтобы таймеры на ходу перенастраивать?..Ох уж эта молодежь. Вы что, реально думаете, что при перенастройке таймеров вы избежите гонки? Про прерывания, DMA и переключение нитей, не слышали?
Давайте поговорим через пару лет, когда вы сами набьете себе шишек.
Суть в том, что бывает передача дейтаграмм (как в UDP) и передача потока (как в TCP). И для потока неблокирующий ввод-вывод — самое то. А UART — это 99.99% — передача потока. То есть делить на пакеты нужно самому, и длина пакетов — переменная.
Исключение сейчас вспоминается одно - MODBUS-RTU, его можно и как дейтаграммы принимать и как поток.
Другой момент, что на всяких иных устройствах — больше дейтаграммы. Ну так я только про UART и его удлинители говорю.
Ну вот пример:
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 в момент обработки таймаута?
Особенно забавно, как в этом потоке вы умудряетесь сначала тезис сформулировать от своего имени, а потом его же мне в вину поставить.
Асинхронность же, на уровне головного мозга.
Вот только сильно боюсь, что вы из тех программистов, которые гонки считают «таинственным сбоем». Те, кто умеет с гонками бороться — проблемы видит заранее.
Собственно на любом российском чипе — в лучшем случае linux и FreeRTOS без драйверов. Хотите избавится от монстра под названием linux — значит ввод-вывод пишете свой.
А linux — это огромный монстр. 12мегов ПЗУ, 16 мегов ОЗУ — это примерно минимум. На голом железе хватает STM32F7 — мег ПЗУ, полмега ОЗУ.
Или метод call ставит вызов в очередь, а осуществляется этот вызов в dispath? Из статьи как-то не просматривается…
Как обычно, мнения разделились.
Кто-то с криками за Фродо Ардуино, бросился отстаивать честь любимого IDE, кто-то говорит — старье.
BMW, ВАЗ… молоток, он не менялся столетиями.
Для многих первый и последний подход к микроконтроллерам заканчивается миганием лампочками.
Некоторые задачи требуют минимального набора функций за минимальные-же деньги.
STM8 — отличная альтернатива раскрученной ардуине — плата разработки за 1$!!!
О вкусах не спорят, а пиво я люблю "резаное" ;-)
В мире мк у всякого направления есть своя колея, если в неё попасть — то выбраться уже почти невозможно. Колея настолько глубокая — что двигаться можно только в одном направлении, вперёд. Шаг в торону — и вас затопчут свои-же.
А мне пофиг.
Беру то что требуется в данный момент и переделываю под себя.
(но так как я тут первый, кто про FreeRTOS упоминает, а адепты ардуино, похоже, немного не в курсе, то момент немного упущен)
Есть группы людей, пытающихся убедить окружающих, что писать индусский быдлокод — это хорошо и правильно.
Я видел только откровенные нааезды от вас, но не виел ни одного выпада в вашу сторону от них. Хотя вы их обвиняете, что они пытаются в чём-то убедить. Можно конкретные ссылки?
То что люди используют свой инструмент так как хотят и как умеют — это их дело. И уж тем более, совершенно не обязательно быть всем программистами экстра-класса.
Не отвечай глупому по глупости его, чтобы и тебе не сделаться подобным ему;
не отвечай глупому по глупости его, чтобы он не стал мудрецом в глазах своих.
— Книга притчей Соломоновых, 26:4
Это касается всех возможных перспектив моего общения персонально с вами. Обсуждать, что и как вы переврали в моих словах, а также чего ещё в мире вы не знаете и не понимаете, мне категорически неинтересно.
И плюс откровенны переходите на личности (чем отменно себя характеризуете).
Что касается ардуины в целом, как явления, то это замечательная штука, приобщившая к электронике множество людей. Ваша попытка сказать людям, что 32битные контроллеры классно подходят для начинающих, очевидно, совершенно некорректна. Новичок закроет вашу(без сомнения классную) статью еще на этапе таких слов, как HAL и IPC. А если даже пролистает эту часть до собственно инструкции, то упадет вот тут:
make BOARD=nucleo-l152re
просто не поняв, куда это вообще надо вводить и что это за магия. По сравнению с вашей инструкцией скачать ардуино IDE и нажать «аплоад» первого сектча — элементарно. И это будет реально быстрый старт.Те же, для кого это — работа, имеют достаточно веские причины для работы на том или ином мк.
Так что остается прослойка тех, кто перерос ардуину, и хочет познать новое, имея за плечами неплохой багаж программирования. Этот человек априори будет с вами согласен, а потому ему ваши наезды на ардуину тоже, в общем то, не интересны…
Я вот считаю, что средний пользователь ардуины может легко научиться пользоваться хорошими инструментами, если ему эти инструменты показать, а также перестать рассказывать, что индусский код — это хорошо, лишь бы работал, а за его пределами всё страшно, неизвестно, ты сломаешь свой бедный мозг чтением даташитов.
А вы считаете, что он настолько туп, что даже статью дочитать не сможет, максимум, на что у него мозгов хватает — бездумно жать кнопку «аплоад».
Скажите, вы на основании чего так лихо оскорбляете такое количество людей?
Школьники так вообще жаждут быстрого результата прямо сейчас, а потому вряд ли будут читать вашу статью.
Не надо присваивать мне чужие слова, а потом за них же спрашивать, это таки не вежливо.
Интересные выводы.
Только на самом деле человек может не копать глубже не потому, что не может, а потому, что ему некогда. Он занят другими делами, и тратит крохи свободного времени на увлеченме, силясь малыми затратами времени и усилий получить зримый результат.
Есть еще и другой вариант. Чтобы человек занялся соответствующим делом, часто его нужно просто заинтересовать. Если вы сразу забьете ему мозг высокими материями, то ему станет скучно, и он забьет. А если ему подсунуть нечто более простое, что небольшими усилиями позволит получить сравнительно сложный результат (не просто помигать светодиодом, а сбацать нечто с экранчиком, датчиками и т.п.), то он заинтересуется и, может быть, дальше будет заниматься всеми этими скучными вещами, чтобы получать интересные результаты уже на другом уровне. Причем для некоторых даже С/С++ сложно. И они начинают с графических конструкторов для программ. И только потом, заинтересовавшись, они переходят на реальное написание программ.
Что интересно эти моменты в той или иной степени применимы и для других областей человеческой деятельности.
Подозреваю, что могут найтись и другие причины для выбора в пользу ардуины, пока не создано другой платформы с подобной экосистемой.
Только что-то мне подсказывает, что даже если эта гипотетическая платформа будет основана на самом пальцованном ARM, она будет ардуиноподобной, простой, с максимальным сокрытием от простого пользователя (заметьте, не разработчика, а именно простого пользователя) всех нюансов и тонкостей.
Подозреваю, что могут найтись и другие причины для выбора в пользу ардуины, пока не создано другой платформы с подобной экосистемой
(щёлкая счётчиком) Тридцать пятый любитель ардуины, считающий, что последние десять лет в мире ничего не происходило.
(щёлкая счётчиком) Тридцать пятый любитель ардуины, считающий, что последние десять лет в мире ничего не происходило.
Назовите платформу с подобной экосистемой: имеющей сравнимое количество модулей с готовыми библиотеками, разнообразие средств разработки с принципиально разными подходами, имеющую в составе принципиально разные платы, которые можно программировать одинаково, позволяющая включать в экосистему совершенно посторонние платы, имеющую кучу не особенно саязанных непосредственно с экосистемой вещей, но ассоциирующихся у обывателя с этой экосистемой и т.д.
Причем чтобы все это сразу.
Пока что экосистемы конкурентов занимаются заимствованиями из экосистемы ардуино (стандартные колодки ардуино на нуклео, использование части модулей из экосистемы ардуино). И что интересно, никто даже не пытается всерьез вытеснить ардуину из занятой ею ниши. Наоборот, порой просто присоединяют свои продукты к экосистеме ардуино.
Добавлю еще немного.
На самом деле мне не очень нравится ардуино.
Во-первых, у стандартной ардуины, которая самая модульная, неудачный формфактор. В результате при посадке шилдов у них часто гнутся ноги. Да и поменьше хотелось бы. А к маленьким (всякие мини, микро и нано) только проводами.
Во-вторых, хотелось бы таки помощнее что-нибудь на самом базовом уровне, но без потери доступности большого количества модулей (те же ардуины, которые именно ардуины, на ARM не толерантны входами к 5В совсем).
Но конкуренты не спешат на это поле, и потому альтернативы в некоторых проектах для себя просто не вижу.
средний пользователь ардуины может легко научиться пользоваться хорошими инструментами, если ему эти инструменты показать
этот пользователь ещё должен изучить и другую «операционку»?
Например, с RIOT OS «высокий входной порог» от нулевого знакомства с микроконтроллерами до запуска первой программы выглядит так:
Скачать и поставить MinGW, arm-none-eabi-gcc и GNU make (для пользователей Windows 10 первый пункт не нужен, достаточно из Магазина поставить свежую Ubuntu)
Я и от 10-ки не в восторге(но на домашнем ноуте Arduino IDE под ней работает неплохо, а Магазин откючён), а уж 'nix-ы для меня — …
Но это же не значит, что все, кто не пишут на vhdl дураки?
Так что мир это такая многоликая штука, и у ардуино есть отличное место под солнцем на поляне школьников и всякого рода энтузиастов. Топикстартер всего лишь вносит свой вклад в отодвигании ардуины от вкусного многомиллиардного рынка.
Скажем ему за это спасибо и прекратим ненужный хейтинг в комментариях, аминь;)
Для мелких задач у меня горсть Tiny85
Для средних, не требовательных, Mega328
Это для ардуиновских поделок.
Ну а где надо быстрее-мощнее-больше прерываний — уже STM32. И вот тут уже вправду можно попробовать задуматься об ОС. Но таких задач у меня не много. Из десятка F103-их использовал пока только 4.
Ну… это со стороны самодельщика.
А по поводу похорон ардуины… Я это воспринимаю как очередные похороны айфона. Его всё хоронят и хоронят, а он как был, так и есть.
Работающий продукт на ардуино я делать конечно же не буду, но прототип получился годным, так что всему свое применение найдется в этом мире;) ИЧСХ не тратил время на разработку устройства, купил втупую готовую ардуино compatible за 100 евро, да дорого, но зато быстро.
Тот самый DIHALT?
Удачи тебе с землёй, а я блин + с — ом перепутал на плате, теперь сижу тоже переделываю на 4000 штук платах, ибо заново заказывать Дорохо.
Одну девайсину, которая должна была что-то уметь и быть себе USB Device, я начал писать на STM32F1xx, кое-как отладил, прилетело желание «и в хвост и в девайс», окей, проектик быстро переехал на F2xx (тот, который о двух USB), далее прилетело пожелание «хватит и одного, но быстрого и вообще», проект перелетел на F4xx.
Во сколько человеко-часов вы оцениваете эти два переезда, если мы не используем SPL/HAL?
Ещё тогда вопрос, про нелюбимый вами куб — сколько времени у вас займет выбор камня, удовлетворяющего условиям ТЗ и имеющего минимальную стоимость, плюс вычада распиновки для разработчика печатной платы.
— есть эндпоинты и потоки
— эндпоинты разные, выбирать их надо в зависимости от назначения
— общаться можно просто стучась в эндпоинт и через feature
— …
Т.е. всяко прочитать минимум USB in a nutshell придётся.
Как верно заметили, никакая, самая лучшая среда, не спасет от криворукого программиста.
Честно говоря, я совсем не в восторге от mbed (и здесь я солидарен с ТИ), но его нельзя назвать совсем уж плохим, но открываем раздел CODE на сайте, видим в наиболее популярных os.mbed.com/users/simon/code/TextLCD, открываем сырки и видим… все тот же Ардуино (без delay, блин) стиль во всей его красе.
Ну и на фига тогда было от Ардуино уходить?
А поскольку он так себя ведёт постоянно, то везде, где он появляется, он набирает новых противников и тут же подтягиваются старые, которым он уже успел насолить раньше. Ну и результат мы видим тут.
Причём, что интересно, с ним никто не спорит что STM32 и операционные системы это хорошо и никто не ставит под сомнение его квалификацию как специалиста. Речь идёт только о том, что Олег являет собой яркий пример «узкого специалиста, подобного флюсу» по меткому выражению Козьмы Пруткова или, другими словами, техно-гоблена, по не менее меткому выражению Сергея Голубицкого. То есть человека с мировоззрением с ноготок и не желающего ничего видеть и понимать в жизни, кроме даташита на STM32.
Сейчас вот, потихоньку, ковыряю книги по Си и статьи по FreeRTOS, ибо мне показалось что без планировщика не получится.
А всего-то, хочу ESP к древней Roomba-е прикрутить. Можно пинать.:)
— Я вот тут взял либу, вот тут соеденил как вот там вот советовали, а оно ни работаеееттт!!1 Памагите, че исправить, а лучше дайте готовый скетч, пасиба!
https://habr.com/post/413779/
А автор к такому не привык. А то, что на его ляпы ему указал (посмел указать) какой-то «ардуинщик» автор воспринял как личное оскорбление. И понеслось… У той статьи 286 комментариев. :)
А новичкам всё равно только ардуино. Так как у RTOS, как ни крути порядок вхождения выше невероятно
Сама статья для расширения кругозора была полезна, хотя сам вряд ли когда-то притронусь к mbed, т.к. полностью согласен с комментарием
Нет. Не вижу. Я НЕ вижу на какой частоте работает ядро, на какой USB, что идет на таймеры и АЦП. По этому коду нельзя установить ничего.
Автор напирает на энергоэффективность, а сам приводит в пример код, который полностью прячет важные параметры настройки системы.
Поэтому даже не лезу в полемику с такими людьми, не хочу зря время тратить.
Золотые слова. Проблема только в том, что наш Д'Артаньян имеет замашки Портоса и с клинком наголо влезает в комменты не только к своим статьям, но и к чужим (и изрядно гадит там). А комменты к текущей статье хорошая иллюстрация того, что Олега не могут унять всем Хабром. :)
А комменты к текущей статье хорошая иллюстрация того, что Олега не могут унять всем Хабром. :)
Нас спасает только то, что он не может нам отвечать. Думаю когда режим ro кончится, начнётся бомбическое метание :)
Думаю, что вы правы, когда Олега выпустят из… бана, то он не будет себя хорошо вести. :) Может не стоит его развязывать? :)
А какой самый дешевый модуль на АРМ, доступный в широкой продаже, на котором можно разрабатывать описанным вами способом?
БЭВМ. С другой стороны — почти ничего не мешает накатить на STM нормальную ОС, и будет вам и многозадачность, и межмашинное взаимодействие, и файловые и графические подсистемы как «у взрослых». Вопрос — а не дороговато ли для чипа в $1? может пусть большие ОС останутся для больших комплексов и больших проектов, а тут для школьников — не стоит огород городить.
Моя задача сбор данных с нескольких датчиков в автономном режиме, разовые задачи. Физически датчики всегда разные. Нужно быстро и по минимальной цене и в минимальном размере сделать такой «черный ящик». Пока юзаю Arduino nano + sd карта.
Главное чтобы был достигнут необходимый результат. И не важно что применялось

Мне как-то понадобился тач-сенсор оси 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-х людей место одного (увеличение трудозатрат).
Ардуино требует, напротив, меньше затрат и ничуть не опаснее любого иного микроконтроллера. )))
Лестница на картинке установлена небезопасно и требует 2-х людей место одного
Во-первых, лестница имеет надёжный упор в стену и пол, не допускающий её проскальзывания. Во-вторых, два человека — это, разумеется, обычное требование техники безопасности при выполнении работ с приставными лестницами. В-третьих, я, конечно, представляю, как вы сможете заменить эту лестницу ардуиной, но с учётом высоты лестничного пролёта, ардуин потребуется очень много.
А вообще забавно, как в абсолютно одинаковых случаях — люди воспользовались в бытовой ситуации подручными средствами, достаточными для решения данной задачи — у вас такая разная реакция: вы оправдываете себя, но при этом осуждаете других.
А что мешало в ответ на картинку сказать «ну да, если надо одну стену покрасить, то в чём проблема»?
Вообще, если говорить по делу, а не плодить флуд — Ответе, что бы Вы использовали для оперативного создания тач-сенсора оси Z?
Заранее спасибо.
(Я уложился в пару баксов и 10 часов — ваш выход ;) )
Что такое «тач сенсор» в этом контексте? Датчик касания? Ну, в смысле, металлический щуп касается металлического же корпуса (основы, подставки или что у вас там)?
Взял бы ближайшую плату на мелком STM32 за три бакса и за пятнадцать минут набросал бы туда прошивку.
Взял бы ближайшую плату на мелком STM32 за три бакса
А почему не Intel i7?
Если уж палить из пушки по воробьям, так со всех орудий… )))
(Зачем STM32 для такой примитивной приблуды то?)
Это три разные задачи.
Плохого тут только то, что если всё же навернёшься — лететь очень далеко; но шансы навернуться, если не быть совсем дебилом, невелики.
Ну и то, что это кривое, сиюминутное, неудобное при необходимости масштабирования решение. Хотя в данном случае и работает. Как и ардуина.
Ну чтобы знать что красиво, а что нет…
Мне просто всегда казалось, что важны характеристики девайса, а не маркировка микроконтроллера. )))
(очень печально, если для кого-то самоцель инструмент, а не результат)
Шучу.
Но стремление людей во что бы то ни стало пользоваться неудобным инструментом удивляет.
Было бы любопытно глянуть подобное евангелие. )))
Что, впрочем, мне ничуть не мешает для простых поделок юзать и Ардуину — не вижу в этом никакой проблемы.
А что касается убеждений: Я интересовался не ими, а аргументацией.
Но, как вижу, как раз таки аргументов у вас и нет. Посему пошла чистой воды демагогия. )))
Для простых проектов (для которых и существует Ардуина) никаких существенных преимуществ другая среда не даст.
Как я уже много раз говорил — Всё зависит от преследуемой цели.
Обсуждаемый тут Mbed — это та же ардуина, только сделанная головой, а не жопой (ну и в целом приближенная к реалиям 2018 года).
Людей прямо закорачивает «я пишу на этом, значит это самое удобное и все должны на этом писать!»
Даже с медицинской точки зрения, не очень здоровый подход. ;-)
ну и если есть выбор — имхо, не стоит выбирать старое решение без существенных причин.
во-вторых, если у вас есть серьезные и несерьезные проекты — не проще и логичней ли использовать для них один инструментарий? тем более, что стоимость одинакова?
(впрочем, есть и коммерчески удачные проекты)
По второму: Шут его знает, разнообразие же.
2.разнообразие… вот представьте, что у вас три клавиатуры — для форумов, для программирования и для работы с офисом. большой в этом смысл?
2. У меня долгое время было 3 клавиатуры: для текста, для графики и для игр. (последние 10 лет одна, после того как на Mac перешёл и постарел для игр )))
понятие «красоты», конечно, субьективно — но оно есть. как есть оно и в математике, и в физике.
и да, складывается ощущение, что для очень многих (в т.ч. в этой ветке) самоцель — именно инструмент. ардуина. сделать обязательно на ней. хотя есть аналогичные инструменты, где не нужно чесать пяткой ухо.
Или это как-то на уровне святого духа проникает в самую глубь сознания? ;)
Дайте определение вашей «красоте», если не затруднит.
Описываемый способ реализации многозадачности можно охарактеризовать как «soft-realtime», типовое время задержки в системе составляет 10 мс (но пиковые задержки могут быть значительно больше и не нормируются). Это накладывает известные ограничения на спектр применения данного решения, но для большинства «бытовых» задач (и не только) он прекрасно подходит, см. пример выше.
Если требуется управление в более жёстком реальном времени, то это требует специальной оптимизации кода под конкретную задачу, перестройки архитектуры или, в совсем крайних случаях, выделения отдельного контроллера под специфические функции.
Типичное описание работы написанной через пень-колоду ардуиновской программы, крутящейся в loop().
(В конце-концов, для каждого контроллера и для каждой среды разработки есть свои ограничения. Главное их знать и подобрать соотвествующий поставленной задаче. Не так ли?)
Типичное описание работы написанной через пень-колоду ардуиновской программы, крутящейся в loop().
А многие миллионы устройств разработанных под Ардуино годами успешно работают и справляются со своими функциями, несмотря ни на что. Как с этим быть? ))
Возникает только один вопрос: зачем, если не просто человечество давно уже изобрело шуруповёрт, а ещё и вкрутить шуруп им — проще и быстрее, чем забивать его молотком? И держаться он при этом будет лучше.
Все эти ардуиновские страдания, которые приходится преодолевать «для построения необходимого девайса», в современном мире просто не нужны. Миллионы людей счастливо живут без них.
Но мне интересен ответ на вопрос, зачем в 2018 году н.э. писать код под весь вот этот кошмар с ардуиновским loop(), когда можно взять нормальную систему и сделать в ней всё то же самое, только быстрее и лучше?
Ответ, кроме «а мне лучше не надо, я шуруп молотком вогнал, картина со стены не падает», существует?
Согласитесь, странное поведение… Говорите за себя, пожалуйста. К чему эти обобщения?
Очень просто: в 2018 году нет пока ещё диктатуры «писать только на чём-то одном». Каждый выбирает что ему больше нравится.
Вы же похожи на религиозного фанатика — «Я пишу на этом, значит все должны писать на этом, и только это самое удобное для всех!»
Ещё раз повторю: Важен конечный результат, а не процесс. (это ж вам не секс, в конце-то концов ;-)
Ну ОК, а что б тогда на ассемблере сразу не писать?
Зачем все эти костыли типа Си, Mbed и прочая гадость?
Вы же сами понимаете, что тру-программист должен говорить на языке процессора! ))))))
Было бы всё равно — комментариев к статье раз так в 5 было бы меньше.
Я вот, честно говоря, теперь не понимаю — вы статью писали то зачем — делиться знаниями или религией?
И продолжу, кстати, работать в этом же направлении.
Сами адепты меня при этом интересуют слабо, что при ардуинщике нельзя упоминать, что из его божества песок сыпется — так то не новость.
На этот вопрос вы так и не дали ответа. Ни в статье ни в нескончаемых дискуссиях.Только перенос личного восприятия и мирощущения на аналогии про шурупы с молотками и
Таким подходом вы отталкиваете людей от вашей изначально благородной цели. Заметьте, я даже не собираюсь отстаивать ардуину.
Так что статью бы неплохо в черновик, выкинуть неуместные нападки и аналогии и дополнить живыми примерами, как по мне. И тогда люди потянуться)
PS в идеале со сравнением того ардуиновского кода на типичных задачах.
Ребята, вы на это не заработали.
И с таким подходом — не заработаете никогда.
Это не мироощущение. Это объективная реальность. Живите с этим, продолжайте убаюкивать друг друга.
Вам жить со своими экстраопляциями многообразия жизни на говно. Могу только соболезновать.
Вы можете:
1) Убедительно доказать несостоятельность моей позиции, показав красивые, современные и изящные проекты на Arduino, возможно, даже написав про это отдельный пост. Правда, тут вас ждёт ряд трудностей, которые будет трудно списать на моё мироощущение.
2) Попросить администрацию Хабра сделать safe zone, где нельзя будет говорить авторам говнокода, что они пишут говнокод. Правда, тут есть опасность оказаться в компании самых интересных людей, от авторов игр про корованы до разработчиков национального поисковика, национального мессенджера и других отличных сервисов, которым вы не сможете сказать ничего плохого про их продукты.
3) Стоять и выслушивать. Правда, вам это не нравится.
Выбор за вами.
Ничего, что я сетовал лишь на подачу материала и не защищал ардуину? Опять мимо ушей…
Вот и выслушивайте дальше, что ваш стиль подачи материала — говно.
Ничего, что я сетовал лишь на подачу материала и не защищал ардуину?
Поясню: это вы в safe zone хотели. Где нельзя дрянь называть дрянью, потому что дрянь может обидеться.
Вот и выслушивайте дальше, что ваш стиль подачи материала — говно
С моим стажем написания разного более 15 лет и с десятками тысяч читателей на один материал — вы меня очень сильно сейчас напугали.
Да на этом ресурсе таких как вы каждый если не второй, то пятый. И что то бить пяткой в грудь себя никто не спешит. По умерьте пыл и уймите гонор. Всем плевать по большому счёту. Но ваша слепая упёртость и правда забавна.
(так что вполне себе для заработка платформа ;-)
Ну пусть теребят своё эго, нам не жалко. )))
Ну а дальше, да, как пойдёт и насколько лежит душа во всём этом копаться. (да и надо ли вообще).
Давайте вернёмся к чистым регистрам и тд тп, к чему эти посредники? )))
2, 3 — да при том, что ардуина, с ее диалектом C (как он там называется? Processing или Wiring? не суть важно) пригодна только для достаточно мотивированных школьников этак из 8 класса, по нашим меркам. Вокруг более свежих платформ можно построить «сквозной» курс.
4. Профессор кислых щей, ага. Ты тут хоть где-то слово professore видишь? it.wikipedia.org/wiki/Massimo_Banzi
И да, развесистые простыни говнокода на ардуине получаются сами собой.
Ардуина занимает свою нишу не потому, что она такая очень хорошая, а потому, что другие эту нишу занять даже не пытаются.
Видел я этот ваш micro:bit. Для "помигать светодиодиком" — отличная платформа. Что-то с видимым, относительно сложным и выглядящим полезным результатом малой кровью — шиш вам, он просто неудобен, в отличие от ардуины, которая тоже не верх удобства, но поудобнее будет в механическом плане. И продвижение его практически никакое в отличие от.
Другие альтернативы, вроде того же нуклео, пытаются паразитировать на ардуине (колодки ардуиновского формата). А реальных действий по продвижению и популяризации, по созданию развитой экосистемы совместимых модулей — почти ноль в отличие от (типа пусть ардуинщики клепают свои пятивольтовые модули, гладишь, что и у нас заработает).
2. Ошибки пропускают всегда и везде, даже в НАСА. Это неизбежно в принципе.
3. Не всегда такая возможность нужна. Особенно когда делается для собственных нужд.
4. Адекватность понятие растяжимое. Особенно если его помножить на «Расширяемость». Какое-то время назад г-н Гейтс считал что 640K ought to be enough for anybody ))
5. Порой самописные решения совершеннее сторонних. (да и сторонние не даны нам свыше, их ведь тоже кто-то писал)
6. …ну это очевидно вроде. Без комментариев.
7. …зависит от проекта. (Если это «метиостанция» на батарейке, то плевать. Но если это управление котлами пивоварни, то даже не «стремление», а обязательное соответствие.)
8. Согласен. Но тоже зависит от проекта.
И да, грамотная архитектура позволяет в том числе легко добавить ресурсы.
При грамотном планировании как раз и становится очевидным требуется ли вообще дальнейшая масштабируемость или нет.
Вернёмся к моему датчику оси — мне никогда не потребуется его как-то «масштабировать», играть на нем в Doom или управлять вертолётом.
Поэтому и была выбрана первая попавшаяся в хламе платка. )))
А на живом проекте у вас всегда будет развитие и всегда будут новые задачи, в т.ч. по функционалу.
Блин, вы странно рассуждаете: Вот у вас есть пульт от телевизора, законченный девайс.
Как часто вам хочется его сделать точнее, быстрее, добавить новых команд, поддержку других систем и прочей чепухи?
Ну ерунду же несёте, ей богу )))
Я пока только одного не понял: зачем вам так надо доказать окружающим, что вот этот ваш глубоко персональный шуруп, который вообще никого, кроме вас, не волнует и волновать никогда не будет, был забит правильным образом.
Никто же вас не заставляет её продолжать, не так ли?
Но нет, вы продолжаете доказывать, что Ардуино это шуруп и молоток. )))
2. если есть средства разработки, включающие средсва контроля/отладки — наверное, лучше пользоваться ими?
3.даже если «делается для собственных нужд» — это не повод злобно говнокодить. кроме всего прочего, даже сам можешь что-нибудь забыть.
4. в плане адекватности — иногда обидно, что на камне столько неиспользуемой периферии. но вся эта периферия есть за цену той же дуйни.
5. порой — да. но чаще всего сторонние решения обкатаны и оттестированы бОльшим количеством пользователей. свое самописное решение еще нужно оттестировать. это касается и дуйни, и стм.
2. Несомненно лучше.
3. Культура кода не зависит от среды или языка, она либо есть, либо её нет. Все свои проекты (любого объема и назначения) лично я всегда снабжаю комментами, хотя бы минимальным планом, описанием и тд тп. Просто привычка.
4. За содержимое кристалла кремния мне совершенно не обидно. Иначе давно бы покончил с собой от осознания того, что процессор iPhone в разы мощнее бортовых систем Шатлов, а я просто по нему звоню и СМСки отправляю. ))
5. Все «отточенные» теперь решения когда-то были сырыми — это дело времени и востребованности компонента. Сделаешь потенциально полезное и оно будет жить и шлифоваться.
2. ну и зачем тогда дуйня?
3. культура — она в том числе создается окружением. той самой средой.
4. мне, начинавшему с «рассыпухи», иногда обидно. жадность совковая.
5. естественно. но в момент написания оно еще только «потенциально полезное», зато уже «потенциально глючное».
А почему люди выращивают помидоры в горшках? Проще же купить в магазине — Для удовольствия. ))
2. Смотрите ответ №1
3. Это человек вокруг себя создаёт культурную среду, а не среда человека. (если человек разумный, конечно, а не просто ****)
4. Ну я тоже начинал с рассыпухи. Хотя и тогда её было уже не жаль.
5. На момент создания всё глючное, хоть на Си пишите, хоть на Клингонском. (Ведущие софтверные конторы не могут порой годами пофиксить даже критичные моменты, что уж говорить о любительском программировании.)
не вот так. habr.com/post/419445/#comment_18998655
понимаете, ходить в рваных носках и дырявых трусах — неприятно. мне неприятно, самому. хотя, казалось бы, никто не видит…
Это не от среды зависит, а от навыков разраба.
Напротив, если человек неряшливо пишет на одном, то и на всех других у него будет такая же каша.
Код — проекция содержимого головы. Только и всего.
Ошибка: 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.
Например никак не ожидал проблем с DS18B20 (датчик температуры), а оказалось что через медленную реализацию IO на STM32 «Blue Pill» ничего не работает (имею в виду существующие библиотеки).
Быстрый старт с ARM Mbed: разработка на современных микроконтроллерах для начинающих