Компания ARM представила (http://community.arm.com/groups/internet-of-things/blog/2015... бета-выпуск новой встраиваемой операционной системы mbed OS (http://mbed.org/), развиваемой для оснащения потребительских устройств, соответствующих концепции "Интернет вещей (https://ru.wikipedia.org/wiki/%D0%98%D0%... (IoT, Internet of Things). Код (https://github.com/ARMmbed/) операционной системы распространяется (http://www.mbed.com/en/development/getting-started/get-code/) под лицензией Apache 2.0. Одновременно доступны для тестирования такие сопутствующие компоненты, как облачный сервис mbed Device Connector (http://www.mbed.com/en/development/cloud/mbed-device-connect... клиент для подключения сторонних решений mbed Client (http://www.mbed.com/en/development/software/mbed-client/), прослойка для связывания устройств с web-приложениями mbed Device Server (http://www.mbed.com/en/development/cloud/mbed-device-server/) и реализация (http://www.mbed.com/en/technologies/security/mbed-tls/) протокола TLS для mbed OS.
<center><a href="http://www.mbed.com/en/development/cloud/mbed-device-connect... src="http://www.opennet.me/opennews/pics_base/0_1441745506.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>В качестве ключевых целей проекта называется поддержка коммуникационных возможностей, соответствующих стандартам, низкое энергопотребление и обеспечение высокой безопасности. Система рассчитана (https://www.mbed.com/en/about-mbed/what-mbed/) на оснащение продуктов, основанных на микроконтроллере
ARM Cortex-M, и предоставляет средства для создания приложений для умных домов, умных городов и носимых устройств. Для проектирования новых устройств предоставляется среда разработки и инструментарий для быстрого создания прототипов устройств. В качестве основы для построения устройств предлагается использовать типовые платы (https://www.mbed.com/en/development/hardware/boards/) и модули-расширения (https://www.mbed.com/en/development/hardware/component/) с реализацией различных сенсоров, технологий беспроводной связи, двигателей, экранов и т.п.Каждое устройств тесно взавимодействует с облачным сервисом, через который осуществляется координация их работы и взаимодействие. Система имеет событийно-ориентированную архитектуру (Event Driven Architecture) и обеспечивает однопоточное выполнение, что позволяет применять mbed OS для наиболее простых, компактных и дешёвых аппаратных систем на базе микроконтроллеров, а также реализовать эффективные схемы снижения энергопотребления. Для обработки системных и пользовательских событий в mbed OS реализован простой планировщик. Для взаимодействия с оборудованием предоставляется абстрактный слой HAL и набор драйверов для типовых перифирийных устройств, таких как порты SPI и I2C ports, слоты GPIO и таймеры.
Для защиты на уровне системы применяются похожая на гипервизор низкоуровневая прослойка uVisor (http://www.mbed.com/en/technologies/security/uvisor/), использующая аппаратные механизмы микроконтроллеров ARMv7M для изоляции выполнения компонентов системы. Кроме того, в mbed OS реализован механизм верификации устанавливаемых обновлений и процесса загрузки. Для каналов связи применяется TLS-шифрование. Мониторинг и управление устройством осуществляются при помощи протокола OMA Lightweight M2M (https://en.wikipedia.org/wiki/OMA_LWM2M) (LWM2M). Взаимодействие с другими устройствами и сервисами осуществляется с использованием протокола CoAP (https://en.wikipedia.org/wiki/Constrained_Application_Protocol) (Constrained Application Protocol).
<center><img src="http://www.opennet.me/opennews/pics_base/0_1441745638.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>
URL: http://community.arm.com/groups/internet-of-things/blog/2015...
Новость: http://www.opennet.me/opennews/art.shtml?num=42932
Это они так намекают что мы должны резко вляпаться в их облака, чтобы они потом нас могли доить и иметь? Дорогой арм, держи карман шире! :)
>операционной системы mbed OSЯ не спец в миниОС, но никогда о такой штуке даже не слышал.
>лицензией Apache 2.0.Насколько знаю она совместима с ЖПЛ. Ну ок. Хорошо. Хотя ЖПЛ 3+ было бы лучше.
Интересно, есть здесь "эмбедщики"? Это "на тобi, боже" или что-то полезное хотя бы в терминах кусков кода?
зачем GPLv3 лицензия нужна в этом проекте? в нее никто не вложится из коммерческого сектора и будет проект на добровольной основе тихо помирать и не развиваться.Apache 2.0 лицензия либеральная что делает проект привликательным для открытых и закрытых проектах
Ну тут я не соглашусь. RedHat и прочие шляпы вкладываются же.>>тихо помирать и не развиваться.
Как будто коммерческие проекты не помирают. Если это кому-то будет нужно, он будет это поддерживать, или сделает форк.
http://www.freertos.org/Двойное лицензирование например.
> Интересно, есть здесь "эмбедщики"? Это "на тобi, боже" или что-то полезное хотя бы в терминах кусков кода?Не считаю себя "эмбедщиком", и не знаю, что это за mbed OS, но я как-то пару раз пользоваться IDE на mbed.org для некоторых тестов своих STM32-железок. Так вот вариант с STM32CubeMX + CubeMX2Makefile оказался намного приятнее, а тот IDE (на mbed.org) создал впечатление убогой lock-in-овой хери для идиотов... С другой стороны там собрано много полезной информации об ARM-овых железках и всяких библиотек.
Сейчас когда проснусь, как следует, нужно будет почитать про этот mbed OS из любопытства.
UPD:
На странице [1] ссылка "mbed OS" [2] битая. А так я пока правильно понимаю, что под "mbed OS" они имеют в виду набор утилит для долгожданной работы в offline-е? Если так, то не очень понятно, причём тут термин "OS".[1] https://docs.mbed.org/docs/getting-started-mbed-os/en/latest.../
[2] https://www.mbed.com/en/technologies/technology-mbed-os/
По сравнению с FreeRTOS, например, код у низх написан хорошо(те части, которые я видел). Разбираться с mbed по сравнению с FreeRTOS одно удовольствие. Другое дело, что пока поддерживаемых TARGET-ов не так много, но они активно пополняются, компании подтягиваются. Лично меня интересует Atmel-овские M4, пока они только сподобились добваить M0+. В общем, когда эта штука окрепнет, будет хорошая вещь.
> Разбираться с mbed по сравнению с FreeRTOS одно удовольствие.Само собой. Сравнили, тоже мне, планировщик событий (не задач!) и полноценный real-time планировщик задач с вытесняющим режимом многозадачности (это про FreeRTOS, если что). "События" (в их термилоногии) не прерываемы, а это упрощает (ну или как минимум должно упрощать) код минимум на пару порядков! Следует понимать, что такое капитальное упрощение ОС, само собой, усложняет пользовательский код (кроме ограниченного подмножества задач) - по сути, вы не можете писать последовательный сложный (сложный по времянке в первую очередь) код - вам придется ручками ваять state-machine на каждый чих. Для ограниченного применения, то есть задач, где этого не требуется (что можно сделать при помощи простых callback'ов) может код и будет сопоставим по сложности.
Они это все выставляют за преимущества, кстати. Типа вам не придется вникать в "сложные" вещи типа синхронизаций потоков выполнения и всё такое. Про недостатки такого подхода, правда, поскоромней выразились: "not a real time scheduler".
https://github.com/ARMmbed/minar
Драйвера не смотрел, но сам планировщик, похоже, платформонезависим (что логично, учитывая его ограничения).
P. S. И да, по кой-то фиг оно на C++. Там C++ не дает вообще ничего по сравнению с чистым C - не та это задача-то, но то ли "мода", то ли просто захотелось побольше двоеточий и поветвистее namespace в коде...
> Интересно, есть здесь "эмбедщики"? Это "на тобi, боже" или что-то полезное хотя
> бы в терминах кусков кода?Для меня, как любителя эмбедовки, вещи с выходом в сеть сильно проще запиливать на апликушных ARM и полноценном линухе. Благо, нынче на это ресурсов хватает у микро модуля размером с SD-карточку.
Это имеет свои ограничения, но связываться с экзотикой от ARM где они активно пытаются втулить какой-то свой облачный сервис - спасибо, что-то не хочется.
"mbed OS для наиболее простых, компактных и дешёвых аппаратных систем на базе микроконтроллеров"
Для простых и компактны все делается но голом железе.
>Для простых и компактны все делается но голом железе.Если для вас, "простая система" - это лампочка, проводок и батарейка, то да, вы правы.
Да тут уже светодиодные лампы на микроконтроллерах. :)
Да разберитесь наконец в EDF, RMA и LLF алгоритмах. Все, что не требует графики и сетевого стека в 99% случаев решается на голом железе при умеренных затратах.
> Да разберитесь наконец в EDF, RMA и LLF алгоритмах. Все,
> что не требует графики и сетевого стека в 99% случаев решается
> на голом железе при умеренных затратах.сначала определись что такое "голое железо".
> сначала определись что такое "голое железо".Идеально - это ДВС (двигатель внутреннего сгорания) без ремней, топлива, масла и всего того что не является "железом" (возможно металлом). Что-то иное пока в голову не приходит.
Если ты не заметил, сфера применения - "интернет вещей" - сетевой стек подразумевает.
> Все, что не требует графики и сетевого стека в 99% случаев решается на голом железе при умеренных затратах.А если не с нуля разрабатывать графику и сетевой стек, то и с ними можно на голом железе при тех же умеренных затратах. Например, lwip, который, есть такое подозрение (но плотно копаться в исходниках пока лень), и выступает в качестве одного из вариантов сетевого стека этой mbedOS - их планировщик событий мало чем отличается от голого железа с точки зрения "многопоточности".
> на голом железе при умеренных затратах.А ты сколько времени будешь на голом железе выписывать допустим соединение по протоколу PTTP?
>> Для простых и компактны все делается но голом железе.Смешно. Особенно, когда нужны будут сложные операции, ага, "голое железо". Микроконтроллеры более чем универсальны и довольно просты. "Голое железо" вам может обойтись дороже одного микроконтроллера.
А микроконтроллер - не "голое железо", что ли?
> А микроконтроллер - не "голое железо", что ли?Он ничто без кода. Как правило, загружается при сборке устройства. Память унутри или снаружи кристалла.
См. пример под носом https://en.wikipedia.org/wiki/Smart_card
> Он ничто без кода. Как правило, загружается при сборке устройства.Ну разумеется. А зачем кому-то устройство которое вроде спаяно, но - не работает? Собственно поэтому многие и не жмутся на схемы с МК - без прошивки они не особо какой секрет :)
Это вы даёте ссылку уже на _изделие_, а не на МК, который использован в основе этого изделия. Сами МК обычно поставляются производителями без какого-либо кода, за исключением м.б. загрузчика. То есть, это именно что голое железо.
>>> Для простых и компактны все делается но голом железе.
> Смешно. Особенно, когда нужны будут сложные операции, ага, "голое железо". Микроконтроллеры
> более чем универсальны и довольно просты. "Голое железо" вам может обойтись
> дороже одного микроконтроллера.Пока ваш взаимный стёб не перешел в личные оскорбления поясню: "голое железо" подразумевает просто "низкоуровневый" (bare metal исходно).
Значений масса у термина: в схемотехнике может подразумевать "на рассыпухе, без 'умных' чипов" (видимо вы в этом значении имели ввиду), в embedded-программировании чаще всего подразумевает программирование под "голый процессор" - без использования уже разработанной операционной системы (в этом значении использовал ваш оппонент), в виртуализациях вообще может употребляться в смысле гипервизора по сравнению с гостевыми (типа он, хоть и имеет ОС, но работает непосредственно с железом, в отличии от гостевых).
Ну вот, пришёл и всё толково объяснил. Такой матч калового волейбола сорвал!Если делать на рассыпухе, то действительно несложные вещи, а то гемора не оберёшься со схемотехникой. Проще накатать основной алгоритм на C, используя какой-нибудь копеечный STM32F0 с минимальным обвязом, используя прерывания для работы с железом и режима сна, тестировать это потом тоже куда приятнее. А с рассыпухой проще разве что накосячить и спалить микрухи, а потом уснуть лицом на осциллографе. Знать схемотехнику полезно, но не для всех задач нужен такой уровень погружения, благо всякие датчики-передатчики всё равно работают обычно по SPI или I2C, а машины состояний удобнее кодить, нежели разводить.
А в чём проблема? Хочешь - пишешь на голом железе, хочешь - сначала ставишь на это голое железо mbed OS или что-то подобное и пишешь уже под него. Зависит от задачи и возможностей "голого железа" :)
дада, все выбирают линукс
> дада, все выбирают линуксПросто с 4КБ ОЗУ много линуксов не запустишь.
> Просто с 4КБ ОЗУ много линуксов не запустишь.про внешнюю ОЗУ не слыхали
>> Просто с 4КБ ОЗУ много линуксов не запустишь.
> про внешнюю ОЗУ не слыхалиДа, давайте на каждый чих напаивать внешнее ОЗУ (которое стóит в разы дороже самого микроконтроллера), ради того, чтобы ставить Linux из принципа, даже когда он не нужен. Ещё для этого прикрутим SD-карту (которая стóит в разы дороже самого микроконтроллера), чтобы уместить образ линухи. Да и перепилим линуху как-нибудь, чтобы она начала на этом всём работать… Потом организуем всякие различные интерфейсы (а-ля usb, ethernet и пр., каждый из которых в отдельности тоже в разы дороже самого микроконтроллера) и будем так делать до тех пор, пока не получим какой-нибудь низкокачественный дорогущий RPi (только с АЦП), в то время как требовалось просто клацать релюшкой на основании данных с АЦП. Замечательная трата человекочасов.
Ага. Такие умные...
> Да, давайте на каждый чих напаивать внешнее ОЗУ (которое стóит в разы
> дороже самого микроконтроллера), ради того, чтобы ставить Linux из принципа,Кроме принципа есть еще:
- Богатая функциональность. Сетевые протоколы, etc.
- Стандартный софт.
- Туева хуча библиотек.
- Удобство и скорость разработки.
- Поддержка большой и сложной писюкообразной периферии.Ну вот за сколько ты, такой умный, например конект к билайновскому PPTP на МК забахаешь? А сможешь ввод с usb-клавиатуры на МК? А произвольно взятый usb 3G modem у тебя заработает? Индустриальные модули - стоят дороже а умеют обычно только GPRS. Цены на HSPA модули и тем более LTE - конские, если что.
А если учесть что рабочее время денег стоит - удешевление железяки vs увеличение времени разработки себя окупит только если ты их будешь делать тысячами. А ты будешь? Именно тысячами? В России? Может ты и китайцев, паяющих в подвале заткнешь по цене железок? В смысле, а ты будешь паять за 2 плошки риса в день, по 12 часов и без выходных, как китайцы?
> даже когда он не нужен.
Ну разумеется, использовать линукс для переключения режимов фонарика - как-то избыточно.
> Ещё для этого прикрутим SD-карту (которая стóит в разы дороже самого микроконтроллера),
> чтобы уместить образ линухи.Знаешь, если железка делается в 1 экземпляре, и даже в 20 - относительно пофиг, будет она 10 баксов стоить или 20. Экономия 20 * 10 = 200 баксов легко проcpeтся на времени разработки.
> Да и перепилим линуху как-нибудь, чтобы она начала на этом всём работать…
А это как раз не сильно сложно. А стоит ли этим заниматься - определяется задачей. Ну вот моя линуха без проблем хапнет картинку с первой попавшейся вебки и даже движение засечет. И скинет видео на емыло. И все это даже почти и не програмингом будет, а стыковкой компонентов. Дешево и сердито. А ты сколько нечто сравнимое на МК будешь выписывать? В 20 раз дольше, да? Ну извини, если твое время совсем бесплатное или у тебя тираж на миллион юнитов... да и то - кремний нынче дешевый, китайский апликушный ARM вместе с менеджером питания стоит 5 баксов. Ну и весь модуль может обойтись в двадцатку. Для нестандартных малотиражных штук - вполне катит.
> Потом организуем всякие различные интерфейсы (а-ля usb, ethernet и пр.,
А чего их организовывать, они из SoC торчат. Можно пойти и пользоваться.
> каждый из которых в отдельности тоже в разы дороже самого микроконтроллера)
Простите, вывести из SoC дорожки на usb-разъем - бесплатно. И с эзернетом почти такая же фигня. Ну может потребоваться чип phy иногда (он дешевый) и трансформатор (часто встроен в гнездо, которое всяко потребуется).
> так делать до тех пор, пока не получим какой-нибудь низкокачественный дорогущий
> RPi (только с АЦП),К тому же Pi можно по i2c или spi прицепить чип АЦП, если надо. Правда реалтаймность будет хуже чем на МК и если отсчеты в жестком реалтайме, МК будет лучше.
С другой стороны, апликушному процу, 10 мегабайтов данных - не объем. Их можно целиком погрузить в оперативу, а на паре ядер на гигагерц - сделать неслабый процессинг. Попробуй на мк утащить картинку с вебкамеры и пожать ее приличным кодеком, а потмо в сеть...
> в то время как требовалось просто клацать
> релюшкой на основании данных с АЦП. Замечательная трата человекочасов.Тут еще очень зависит от того какой обсчет этих данных требовался. А так - извини, чувак, но прицепить релюху через полевик к GPIO борды и вкатить туда систему займет ну может часа два самый край. Какие, ..., человекочасы?
Но вот оптимальность такого решения будет под вопросом. По размерам, цене и потреблению. На самом деле МК и апликушные процы - не особо конкурируют: слишком разные.
>> Да, давайте на каждый чих напаивать внешнее ОЗУ (которое стóит в разы
>> дороже самого микроконтроллера), ради того, чтобы ставить Linux из принципа,
> Кроме принципа есть еще:
> - Богатая функциональность. Сетевые протоколы, etc.
> - Стандартный софт.
> - Туева хуча библиотек.
> - Поддержка большой и сложной писюкообразной периферии.Притом всё это не требовалось для решения задачи, а стоимость -- 3000р. вместо 40р. А если начальство хочет 100 устройств, то это уже начинает нехило значить.
> - Удобство и скорость разработки.
Зависит от задачи.
> Ну вот за сколько ты, такой умный, например конект к билайновскому PPTP
> на МК забахаешь? А сможешь ввод с usb-клавиатуры на МК? А
> произвольно взятый usb 3G modem у тебя заработает? Индустриальные модули -
> стоят дороже а умеют обычно только GPRS. Цены на HSPA модули
> и тем более LTE - конские, если что.Я буду идти по пути наименьшего сопротивления. Например, зачем мне USB-клавиатура на MK, если я могу тупо приделать нужные мне кнопки без всякой клавиатуры?
> А если учесть что рабочее время денег стоит - удешевление железяки vs
> увеличение времени разработки себя окупит только если ты их будешь делать
> тысячами. А ты будешь? Именно тысячами? В России? Может ты и
> китайцев, паяющих в подвале заткнешь по цене железок? В смысле, а
> ты будешь паять за 2 плошки риса в день, по 12
> часов и без выходных, как китайцы?Бред какой-то. Я происто исхожу из конкретной задачи. Если задача требует RPi-like, то там будет RPi-like. Если задача требует какой-нибудь STM-ки, то будет STM-ка. В чём вопрос вообще? Например нужно мне сделать логировалку напряжения на подстанции (элементарная задача вроде бы), но зачем тут вообще Linux? Просто поставил туда STM-ку и пишешь спокойно на SD-карту с АЦП после делителя.
>> даже когда он не нужен.
> Ну разумеется, использовать линукс для переключения режимов фонарика - как-то избыточно.И не только для данной задачи.
>> Ещё для этого прикрутим SD-карту (которая стóит в разы дороже самого микроконтроллера),
>> чтобы уместить образ линухи.
> Знаешь, если железка делается в 1 экземпляре, и даже в 20 -
> относительно пофиг, будет она 10 баксов стоить или 20. Экономия 20
> * 10 = 200 баксов легко проcpeтся на времени разработки.RPi стоит порядка 2-3 тыс. р. В 20 экземплярах -- это уже 40-60 тыс. р.
И ещё раз. Машинки вроде RPi зачастую тупо _хуже_ будут выполнять задачу. АЦП, realtime, питание, компактность и пр.
>> Да и перепилим линуху как-нибудь, чтобы она начала на этом всём работать…
> А это как раз не сильно сложно. А стоит ли этим заниматься
> - определяется задачей. Ну вот моя линуха без проблем хапнет картинку
> с первой попавшейся вебки и даже движение засечет.Причём тут web-ка? Вы вообще видели, чтобы Linux хоть раз запускали на stm32? Это другие интерфейсы, другое железо, всё другое. Вам придётся потратить человекогоды, чтобы это всё нормально работало.
Да и вообще, вы как себе представляете, например, внешнюю память у stm32?
> И скинет видео
> на емыло. И все это даже почти и не програмингом будет,
> а стыковкой компонентов. Дешево и сердито. А ты сколько нечто сравнимое
> на МК будешь выписывать? В 20 раз дольше, да?Я МК использую в качестве МК. Если нужно делать сложные вычислительные задачи по событиям с МК, то он просто сигнализирует об этом более умной машине (уже с Linux).
Я просто иду по путям наименьшего сопротивления, учитывая ка ки своё время, так и стоимость, так и надёжность, так и много других факторов.
>> Потом организуем всякие различные интерфейсы (а-ля usb, ethernet и пр.,
> А чего их организовывать, они из SoC торчат. Можно пойти и пользоваться.Посмотрите на цену stm32f0.
>> каждый из которых в отдельности тоже в разы дороже самого микроконтроллера)
> Простите, вывести из SoC дорожки на usb-разъем - бесплатно. И с эзернетом
> почти такая же фигня. Ну может потребоваться чип phy иногда (он
> дешевый) и трансформатор (часто встроен в гнездо, которое всяко потребуется).Мы сейчас про что говорим? Я говорю про микроконтроллеры (ибо subj о "mbed"-е). Опять же, посмотрите на stm32f0 и на наличие/отсутствие ethernet у него.
>> так делать до тех пор, пока не получим какой-нибудь низкокачественный дорогущий
>> RPi (только с АЦП),
> К тому же Pi можно по i2c или spi прицепить чип АЦП,
> если надо. Правда реалтаймность будет хуже чем на МК и если
> отсчеты в жестком реалтайме, МК будет лучше.Кэп.
> С другой стороны, апликушному процу, 10 мегабайтов данных - не объем. Их
> можно целиком погрузить в оперативу, а на паре ядер на гигагерц
> - сделать неслабый процессинг. Попробуй на мк утащить картинку с вебкамеры
> и пожать ее приличным кодеком, а потмо в сеть...Просто задачи нужно решать соответствующими инструментами. Не нужно цеплять по RPi к каждой простой задаче, где и МК достаточно легко справится (а то и лучше).
>> в то время как требовалось просто клацать
>> релюшкой на основании данных с АЦП. Замечательная трата человекочасов.
> Тут еще очень зависит от того какой обсчет этих данных требовался. А
> так - извини, чувак, но прицепить релюху через полевик к GPIO
> борды и вкатить туда систему займет ну может часа два самый
> край. Какие, ..., человекочасы?Мы говорили про микроконтроллеры (а-ля stm32f0). Чтобы запустить на нём linux потребуется много человеколет.
Но если забить на микроконтроллеры (а-ля stm32f0) и взять SoC, то да, это уже другой разговор. Но это даст гораздо менее качественное и более дорогое решение.
А по человекочасам прошу сравнить:
- У SoC: устанавливать систему, подключать АЦП к RPi, согласовывать работу по SPI, писать программу для нужного управления (самое простое), настроить систему в read only (чтобы не убилась при перезагрузках) и т.п., после чего тиражируешь.
- У микроконтроллера: сгенерировал пустой проект в CubeMX и с использованием developer board написал, грубо говоря, 10 строчек (вуаля), распечатал и спаял тестовый образец (быстренько, ибо на основе уже готовых ранее заготовок, ибо это не перый проект), проверил, после чего отдал низкоквалифицированным рабочим (и вообще в другой отдел) на печать и пайку нужного количества устройств.> Но вот оптимальность такого решения будет под вопросом. По размерам, цене и
> потреблению. На самом деле МК и апликушные процы - не особо
> конкурируют: слишком разные.Вот именно. А subj про микроконтроллеры. И устанавливать Linux на МК -- это извращение... очень мягко говоря.
> Притом всё это не требовалось для решения задачи, а стоимость -- 3000р. вместо 40р.Как получена стоимость юнита в 40р? Сделать кастомную плату на фабрике - будет стоить не менее штукаря за только подготовку в производство, в самом поганом виде. Нормальная двухслойка с масками и прочим - обойдется дороже раза в 2-3. А еще и собрать ее - и вовсе. В большом количестве - это автоматиеская сборка или как минимум заказ монтажа. Одна подготовка будет стоить с десятку, если не больше. Если факапов нигде не случится и не придется ничего серьезно переделывать. При тираже в 100 штук - рублей 100 на юнит. Сразу, на старте: материалы и людское время с вашей стороын - считать даже не начинали. А чтобы вышло 40 рублей за юнит при тираже в 100 штук - я не знаю что надо сделать. Поработать себе в убыток, ЛУТанув 100 плат как маньяк и лично запаяв их, за плошку риса?
Это не говоря о приличном времени на подготовку техдокументации на все это (время разработчика что, бесплатное?) и риске грабель и факапов всех мастей. В случае готовой борды - это как бы не ваши проблемы были, в случае модуля - наполовину ваши, а если все самому - ну вы в курсе, да? :)
Для себя прототип я могу еще ЛУТом откатать и запаять сам. Тогда цена материалов в железке на мк еще может быть со скрипом 40 р. Но будет потрачено несколько часов времени (что, впрочем, быстрее чем даже срочное производство на фабе). И это уже в результате не в 40 рублей оценивается.
А потом окажется что надо еще корпус, допустим. Весьма отдельные грабли. С отдельной ценой. Не отдадите же вы заказчику месиво из проводоа? А это еще деньги и для мелких партий варианты оказываются весьма компромиссным решением. А для тиража в 100 девайсов - еще и закупка комплектухи отдельным действом. Не то чтобы сложным, но людское время на это потратится. А оно не бесплатное.
> А если начальство хочет 100 устройств, то это уже начинает нехило значить.
Для именно 100 девайсов это очень варьируется. В плане того что хотел заказчик, какие сроки разработки приемлимы, какие вообще требования в задаче и прочая. И покрывает ли экономия увеличение затрат на разработку - надо очень отдельно смотреть.
Но да, у мк есть свои ниши где они смотрятся разумно, хорошо и правильно. Просто у мк есть куча своих ограничений и если излишне фанатеть (пытаться явно компьютерные задачи на мк сбагрить) - с решением и граблями всех мастей можно встрять надолго, а параметры решения будут дрянь.
>> - Удобство и скорость разработки.
> Зависит от задачи.Ну естественно. Ставить Pi-образное нечто чтобы только пощелкать релюшкой без иных требований все-таки в общем случае глупо. Особенно если 100 девайсов надо. К тому же МК может кардинально меньше кушать. Апликушный проц не больно от CR2032 заведется, по крайней мере на данном этапе эволюции...
> MK, если я могу тупо приделать нужные мне кнопки без всякой клавиатуры?
А тут может быть вот какая засада: usb-клавиатура - готовый девайс, с приличным качеством и не вызывающий нареканий. А вот сколько у вас займет времени, сил и денег сделать свой кастомный корпус с клавиатурой, чтобы это не выглядело как блeвота и работало прилично - отдельный вопрос, ответ на который варьируется.
> то там будет RPi-like. Если задача требует какой-нибудь STM-ки, то будет
> STM-ка. В чём вопрос вообще?Ну так я тоже за такой подход. Я вообще не понимаю чего народ так уж эти полюса противопоставляет - они сильно разные и мест где они реально пересекаются и конкурируют - не так уж много. Хотя в порядке трэша и угара, в линух недавно комитнули поддержку для именно старших моделей STM32. Кому-то вот надо оказалось. Сюрприз!
> на подстанции (элементарная задача вроде бы), но зачем тут вообще Linux?
В общем случае - скорее всего не потребуется.
> Просто поставил туда STM-ку и пишешь спокойно на SD-карту с АЦП после делителя.
Единственное что нынче люди любят чтобы подобные вещи не требовали внимания. Ну там сами скидывали периодически все это куда-то еще, по сети. Избавив чувака от похода к девайсу и тасовки карты. Этот чувак в общем случае денег стоит, и все такое. А сделать нормальный нетворкинг, а чтобы еще и с шифрованием нормальным и авторизацией, и чтоб настройка не рокетсайнс - на мк уже может начать становиться несколько напряжно. Хотя тоже варьируется.
> И не только для данной задачи.
Несомненно.
> RPi стоит порядка 2-3 тыс. р. В 20 экземплярах -- это уже 40-60 тыс. р.
И? Это 2-3 недели работы разработчика, плюс-минус всякая мелочь. И вопрос сведется к тому - сэкономится ли 2 эти недели долботни или нет. В допущении что по остальным параметрам оба варианта хорошо подошли. Что совсем не факт в общем случае - stm32 и толстые апликущные процы имеют довольно мало общего.
> И ещё раз. Машинки вроде RPi зачастую тyпо _хуже_ будут выполнять задачу.
Ну да. Они больше числодробилки + богатая писюкообразная периферия и меньше - глупые управлялки и клацалки.
> АЦП, realtime, питание, компактность и пр.Совершенно согласен. Если интересовал серьезный реалтайм, однозадачная прошивка целиком занятая своей задачей - куда как предсказуемее.
> Причём тут web-ка?
Ну мало ли, хочется вот кому-то с дешевых камер картинки гнать, записывать и в сеть транслировать, например. Обычное желание. Случаи разные бывают. На мк такое делать - нафиг надо. А тут кто-то предлагал :). Грубо говоря - обратный вариант инженерных извращений - попытаться сделаьт из мк почти писюк.
> Вы вообще видели, чтобы Linux хоть раз запускали на stm32?
См. выше - на старшие STM32 недавно как раз комитнули поддержку в майнлайн.
> Это другие интерфейсы, другое железо, всё другое.
На самом деле это не так. У апликушников обычно есть как "писючные" интерфейсы типа usb, так и относительно простая периферия, более характерная для мк. Как то довольно шустрое GPIO. На нем делают софтварный I2C, SPI, MMC, 1-wire, и в лине даже для этого стандартные решения есть, так что самому ни бита кода писать не придется. И оно довольно прилично пашет. Может быть ADC, хардварные SPI, I2C, несколько UART, и что там еще. По периферии мелкие одноплатники посередине между писюками и мк, это гибрид обоих миров.
> Вам придётся потратить человекогоды, чтобы это всё нормально работало.
Кто-то вот потратил. Удивительно, но факт.
> Да и вообще, вы как себе представляете, например, внешнюю память у stm32?
Так вот и представляю: у старших STM32 есть контроллер памяти и шина наружу.
> по событиям с МК, то он просто сигнализирует об этом более
> умной машине (уже с Linux).Это тоже валидный вариант. Если нужда в МК реально есть. Тем не менее, обработать нажатие кнопки и клацнуть релюшкой до кучи может и апликушный проц, если уж он в задаче есть. И МК при этом может и не быть обязательным компонентом системы.
> Я просто иду по путям наименьшего сопротивления, учитывая ка ки своё время,
> так и стоимость, так и надёжность, так и много других факторов.И правильно делаете. Гвоздить везде одним размером - занятие глупое.
> Посмотрите на цену stm32f0.
Уже давно, только F10x. Мне M3 по $0.8 показался столь халявным предложением что я их себе для своих нужд мелкооптово аж отхватил. Забавно когда M3 с кучей периферии - по цене чуть ли не одного триггера.
> Мы сейчас про что говорим? Я говорю про микроконтроллеры (ибо subj о "mbed"-е).
А сабж вообще хз о чем. Видимо, о том что ARM хочет денег и всех завендорлочить на свое облако, если по большому счету.
> Опять же, посмотрите на stm32f0 и на наличие/отсутствие ethernet у него.
Кроме F0 даже у того же STM есть и другие чипы. В том числе и с эзернетом, если уж на то пошло. Прикиньте, STM32 очень разлапистое семейство и там много чего есть. Вплоть до M4 на пару сотен МГц с аппаратной плавучкой. Собственно на чем-то таком линух и запустили. А что, тоже STM32 и нии...т!
> Просто задачи нужно решать соответствующими инструментами.
Да я с этим и не спорю.
> Не нyжно цеплять по RPi к каждой простой задаче, где и МК достаточно легко справится
Если легко - тогда да.
> Мы говорили про микроконтроллеры (а-ля stm32f0).
Ну знаете, STM32F4 как бы тоже микроконтроллер. А на нем как бы линух запустили и даже в майнлайн комитнули.
> Чтобы запустить на нём linux потребуется много человеколет.
Для F4 с внешней памятью - достаточно будет просто компильнуть ядро. За человеко-полчаса какие-нибудь.
> Но если забить на микроконтроллеры (а-ля stm32f0) и взять SoC, то да, это уже другой разговор.
Да вон некоторые и SMT32F4xx берут. И таки запустили там линь и даже комитнули в майнлайн. Я не знаю зачем они это делали, но так - можно.
> Но это даст гораздо менее качественное и более дорогое решение.
А вот это весьма зависит от задачи.
> А по человекочасам прошу сравнить:
Да, идем, берем STM32F4, компилим ядро. А драйвера там уже понаписали.
> - У SoC: устанавливать систему,
Установка сводится к раскатыванию образа. Это просто и не так уж долго.
> подключать АЦП к RPi, согласовывать работу по SPI, писать программу для нужного управления (самое простое),
Все это будет не сложнее чем в случае с мк.
> - У микроконтроллера: сгенерировал пустой проект в CubeMX
Я не знаю кто такой CubeMX. Я geany + gcc использую. Для STM32, ога. Потому что их я знаю и умею ими пользоваться. Я Linux предпочитаю как рабочую среду. Такой вот я фрукт - люблю когда в системе автоматизация на уровне и можно сделать удобно себе а не кому-то еще.
> и с использованием developer board написал, грубо говоря, 10 строчек (вуаля),
В линухе я, пожалуй, по именно строчкам могу и меньше написать. Там можно и софтварный 1-wire какой-нибудь получить, не написав ни строки кода как таковой.
> в другой отдел) на печать и пайку нужного количества устройств.
А в случае Pi-образного паять вообще ничего не придется, или совсем уж простой и мелкий "аддон".
> это извращение... очень мягко говоря.
Ну так вот, недавно (в ядре 4.1 или 4.2, чтоли) в майнлайн закомитили извращенцы с STM32F4 :)
>> Просто с 4КБ ОЗУ много линуксов не запустишь.
> про внешнюю ОЗУ не слыхалиПокажете как подключить и использовать внешнее ОЗУ в простом контроллере, не имеющем внешних шин адреса/данных и/или контроллеров для них и/или вообще такого адресного пространства?
Угу. Далёкие от железа люди, видимо, думают, будто платы не нужно отлаживать, в отличие от софта. С рассыпухой-то порой бывает натуральный brainfuck, а тут предлагают высокочастотные микрухи ставить и Linux, будто это так же просто и приятно, как клонировать проект на GitHub. А драйвера за них Линус писать будет?
> А драйвера за них Линус писать будет?На какой-нибудь sunxi, codename "дешево и сердито" - уже понаписали. Для более брутально индустриальных (но дорогих) применений - есть Ti OMAP/SITARA. Тоже понаписали. Сами же техасцы в основном. Так что остается только прикрутить процессорный модуль к своей задаче, собрать и вкатить систему. Ну и все, "ready to rock-n-roll" (c).
Ессно с ноля никто в здравом уме писать драйверы не станет. Если SoC плохо поддерживает линух - она идет в пень. Хороший стимул для производителя озаботиться вопросом. Хотя иногда и комьюнити зажигает. Как у Sunxi/Rockchip.
Эти далекие от железа люди предлагают прям процы ставить и linux громоздить даже если задача всего лишь, условно, опрашивать кнопки и мигать лампочками. Мотивируют исключительно тем, что "а чё, проц стоит не особо дороже простейшего микроконтроллера". Правда вон чуть выше уже пошло про внешнее ОЗУ (чтоб поставить linux ради того чтобы поставить linux видимо). Ну не оценивают/не рассматривают некоторые люди "далекие от железа" некоторые классы задач целиком.Например, задача включает следующие требования:
- работа в сетях (хренового) питания с заданными длительностями его отключения
- время готовности к работе, скажем, не более 200 мс после подачи питания (да, да система с linux не успеет загрузиться - придется держать всё время под питанием)
- условия эксплуатации и время работы без технического обслуживания не позволяют поставить простенький дешевый аккумулятор
- optional: суровые ограничения по массе/габаритамТупая плата на примитивном контроллере решает задачу. Для проца (с linux на борту) стоимость только вторичного источника питания в разы перекроет стоимость всего железа на мк. Процы тоже многие подойдут (из тех же stm можно подобрать подходящий), но про внешнее ОЗУ и linux можно забыть сразу. И это ещё не самые экзотические условия, которые бывают (а еще бывают и нетехнические ограничения).
P. S. Это я не к тому, что мк - хорошо, процы и linux - плохо, нет. Сам-то применяю и то и другое (да и ПЛИСами не брезгую если задача подходящая). Просто убеждения что "проц+linux" решение всех-всех-всех микроконтроллерных проблем (да ещё и якобы за ту же цену) - мягко говоря, некорректны.
> Эти далекие от железа люди предлагают прям процы ставить и linux громоздить
> даже если задача всего лишь, условно, опрашивать кнопки и мигать лампочками.Такое бывает, увы. Этим в основном грешат "совсем прикладники". Но их в эмбедовке ждет много клевых грабель из-за незнания физики, особенностей CMOS и много чего еще.
> простейшего микроконтроллера". Правда вон чуть выше уже пошло про внешнее ОЗУ
> (чтоб поставить linux ради того чтобы поставить linux видимо).А кто-то ставит - в майнлайн закомитили для STM32F4xx :)
> - работа в сетях (хренового) питания с заданными длительностями его отключения
Вообще не проблема. Можно хоть литий-ионник поставить, менеджер питания у апликушных процов даже умеет его заряжать в нормальных железках. В планшетах часто требуется автономность питания, все дела. Кроме всего прочего это позволяет решить вопрос с питанием путем "прицепили банку лития к менеджеру питания". Для МК качественное питание ессно сделать проще и несколько дешевле. Но вообще - грабель там можно хлебнуть очень даже. Аврщики до сих пор сцyт нулевую ячейку еепрома использовать :)
> - время готовности к работе, скажем, не более 200 мс после подачи
> питания (да, да система с linux не успеет загрузиться - придется
> держать всё время под питанием)Кстати говоря, рекордсмены довольно близко подобрались - загрузку линя и на нем программы, гонящей картинку с видеокамеры на экран на Ti OMAP за 300 миллисекунд можно найти на ютубе. Это конечно нишевое развлечение, но профессионалы могут и позажигать.
> - условия эксплуатации и время работы без технического обслуживания не позволяют
> поставить простенький дешевый аккумуляторЧувак, планшеты и смарты - ГОДАМИ пашут без вскрытия. Там аккумулятор наглухо необслуживаемый, зачастую припаян к плате намертво и меняется только в СЦ. И предъявы с отказами там никто не любит. Уважающий себя чип менеджера питания умеет делать безопасную зарядку лития и прочее. И да, этот красавец идет в комплекте с тем апликушным процом за те 5 баксов как дармовый довесок. Ну как минимум у allwinner.
> - optional: суровые ограничения по массе/габаритамОчень не конкретно. Железка размерами с SD карту нынче может легко забутявить линукс.
> борту) стоимость только вторичного источника питания в разы перекроет стоимость всего
> железа на мк.Шутить изволишь? USB-зарядка для мобилы может "просто валяться" где-нибудь. Вообще условно нахаляву. Ну или там usb-порт какой-нибудь под рукой есть. В порядке лулзов - запитывал одноплатник от "power bank" для зарядки мобил. Ему такого на несколько часов. Можно и очень круто заоптимизить: планшет от литийона валяется несколько дней с живым процом, но правда на совсем мизерной частоте, типа 20МГц. При этом он живой и таки может какой-нибудь пакет по сети получить, или там что еще. И будет разогнан на свой гигагерц, если это станет надо по нагрузке.
> Процы тоже многие подойдут (из тех же stm можно подобрать подходящий),
Они МК а не процы.
> "проц+linux" решение всех-всех-всех микроконтроллерных проблем
Это булшит. Микроконтроллеры сильно лучше в плане жесткого реалтайма, например. Однозадачная фирмварь посвященная своей задаче - может добиться латенси и джиттера недостижимых для многозадачек.
> (да ещё и якобы за ту же цену) - мягко говоря, некорректны.
А цена - штука своеобразная. Для МК дешево при тираже в несколько юнитов только если вы это на коленке спаяли. А если хочется нечто заводское - цена запросто будет сравнимой с Pi и сотоварищи. Более того - даже достаточно серийные модули на МК не поражают воображение своей низкой ценой.
> Вообще не проблема. Можно хоть литий-ионник поставить, менеджер питания у апликушных процов
> даже умеет его заряжать в нормальных железках. В планшетах часто требуется
> автономность питания, все дела. Кроме всего прочего это позволяет решить вопрос
> с питанием путем "прицепили банку лития к менеджеру питания".И как оно будет работать в климатике и механике? А обеспечить зарядку из хренового первичного питания тоже не вот два пальца об асфальт.
> Для МК качественное питание ессно сделать проще и несколько дешевле.
А иногда и в разы и на порядки!
>> - время готовности к работе, скажем, не более 200 мс после подачи
>> питания (да, да система с linux не успеет загрузиться - придется
>> держать всё время под питанием)
> Кстати говоря, рекордсмены довольно близко подобрались - загрузку линя и на нем
> программы, гонящей картинку с видеокамеры на экран на Ti OMAP за
> 300 миллисекунд можно найти на ютубе. Это конечно нишевое развлечение, но
> профессионалы могут и позажигать.А как надо разогнать тактовую чтоб получить такие времена? Проц на 20-30 МГц так сможет? И как же начальная загрузка в память самого ядра? А если без начальной загрузки, значит мы говорим о прямом выполнении с параллельной flash? И это дёшево? Автоматом получаем удорожание за счет: проца, на порядок более сложной печатной платы, компонентов обвеса, того же вторичного источника. В разы удорожать все это вместе может-то.
>> - условия эксплуатации и время работы без технического обслуживания не позволяют
>> поставить простенький дешевый аккумулятор
> Чувак, планшеты и смарты - ГОДАМИ пашут без вскрытия. Там аккумулятор наглухо
> необслуживаемый, зачастую припаян к плате намертво и меняется только в СЦ. И предъявы с отказами там никто не любит.Смартам как-то не надо выдерживать, например, удары по 50 g, обычно. Работать при минус 60. Не дохнуть в соляном тумане. Например. Аккумуляторам (дешевым) обычно тоже это не требуется. Поэтому для обычных нетепличных условий эксплуатации попаритесь искать подходящий и разрабатывать к нему источник и зарядку от хреновой сети питания. Если вообще удастся разумно решить задачу - цену посчитаете, прослезитесь.
А если вы в СЦ на отказ дешевого аккумулятора укажете подобные условия эксплуатации, то там это даже за предъяву не посчитают. Поржут разве что.
>> - optional: суровые ограничения по массе/габаритам
> Очень не конкретно. Железка размерами с SD карту нынче может легко забутявить
> линукс.Я не имел ввиду - "возьми любое из предложенных требований". Все сразу, одновременно. Не помню что-то ни одного железячного ТЗ где были б требования на выбор (кроме, очень-очень редко, чисто конструктивных).
>> борту) стоимость только вторичного источника питания в разы перекроет стоимость всего
>> железа на мк.
> Шутить изволишь? USB-зарядка для мобилы может "просто валяться" где-нибудь. Вообще условно нахаляву. Ну или там usb-порт какой-нибудь под рукой есть.usb-порт? Наличие usb-порта говорит о том, что вторичный источник питания кто-то уже разработал, сделал и установил - это совсем другие условия, означающие, что требования по питанию уже "тепличные" и говорить о них бессмысленно. То ли вы не поняли, то ли я не так объяснил, сеть питания это нечасто розетка 220 В в помещении, да еще и с натыкаными устройствами со своими источниками - отсюда, видимо, вы сильно недооцениваете колоссальные проблемы вторичных источников питания (и их цены, сложность, массы и габариты).
Смеха ради - почитайте ГОСТ, например, на автомобильную бортсеть (я сталкивался лет 15 назад, может, конечно вышел новый, помягче, в этом случае почитайте предыдущий). А потом разработайте (прикидочно хотя бы) надежный вторичный источник питания для процессорной платы, который можно в эту бортсеть втыкать (в соответствии с ГОСТ, а не с соображениями типа "работает же как-то китайская дешевая магнитола и не сгорает обычно") - только без читерства типа "а вот таких импульсов у нас не будет". А бывает по питанию и сильно-сильно пожестче - и в цене и сложности источника тут огромная разница от ответа на вопрос "можно отключаться временно (вариант тупого мк) или держать и не проваливать питание никогда (вариант проца+linux)".>> (да ещё и якобы за ту же цену) - мягко говоря, некорректны.
> А цена - штука своеобразная. Для МК дешево при тираже в несколько
> юнитов только если вы это на коленке спаяли. А если хочется
> нечто заводское - цена запросто будет сравнимой с Pi и сотоварищи.
> Более того - даже достаточно серийные модули на МК не поражают
> воображение своей низкой ценой.Так вся моя речь и была, что некорректно мерять ценой лишь МК-модуля. Надо смотреть задачу целиком. Что толку от более дешевой платы с крутым процом, если обвес и источник к ней перевесят всё (да ещё и все равно могут не позволить выполнить задачу)?
P. S.
> Но вообще - грабель там можно хлебнуть очень даже. Аврщики до сих пор сцyт нулевую ячейку еепрома использовать :)
У avr проблемы со сбросом при определенном питании гораздо веселей чем нулевая ячейка еепрома (с еепромом хоть workaround очевидный). А там лечится (да и то не очень) только усложнением вторичного источника (с неизбежным увеличением потребления, по которому avr и без того далеко не рекордсмен). В общем, простые схемы по питанию с avr работают как китайские магнитолы в автомобильной бортсети - все хорошо только пока не наступили определенные условия и все идет только потому, что эти условия не настолько часты и повсеместны.
А ещё бывают разные требования к ЭМС и они одни уже могут перевесить всё в пользу примитивного мк. Для выполнения их могут, например, потребоваться такие изменения и такое удорожание всего что с связано с "крутой" системой по сравнению с примитивным мк, что сравнивать цены чипов бессмысленно совершенно (у проца даже задаром и даже с небольшой доплатой шансов "победить" может не быть совсем).
> Просто с 4КБ ОЗУ много линуксов не запустишь.А на pic16 еще и глубина стека сильно лимитирована - удачи вам делать на этом сложные сетевые протоколы.
Жду опять уникума, который будет говорить, что кроме AVR и PIC ничего больше не надо.
А так, отличная новость, только среда разработки, точнее вся инфраструктура mbed.com на мой взгляд несколько неполноценная.
> Жду опять уникума, который будет говорить, что кроме AVR и PIC ничего больше не надо.Этому «уникому» достаточно будет просто взглянуть на характеристики ARM-овых железок и на их цены, IMHO.
> А так, отличная новость, только среда разработки, точнее вся инфраструктура mbed.com на мой взгляд несколько неполноценная.
А вы пользуетесь этим mbed? Я вот пробовал — тоже не понравилось. Да и по сути меня в mbed интересует лишь база библиотек. Не пробовали их использовать без их online IDE?
И какие железки вы используете?
> Этому «уникому» достаточно будет просто взглянуть на характеристики ARM-овых
> железок и на их цены, IMHO.да, STM32 и LPC нынче рвут всех, как и радиолюбительстве, так и в промышленном применении. Хотя насчёт последнего, то очень часто вижу там процы от Renesas.
> А вы пользуетесь этим mbed? Я вот пробовал — тоже не понравилось.
> Да и по сути меня в mbed интересует лишь база библиотек.
> Не пробовали их использовать без их online IDE?mbed - с моей точки зрения, это "как научиться программировать микроконроллеры дегенерату", и аудитория такая же, как и ардуино. Только к пользователям ардуины нужна приставка "лох", т.к. только "лоху-дегенерату" можно втюхать инскременты, в виде AVR-контроллеров по заоблачным ценам.
А библиотеками без этой чудной онлайн среды не пользовалась, да и не собираюсь. Стандартная библиотека периферии позволяет делать тоже самое, и так же быстро.
> И какие железки вы используете?
Обычно это STM32, ещё немного использую отечественные, от Миландра (также на Cortex-M)
>> Этому «уникому» достаточно будет просто взглянуть на характеристики ARM-овых
>> железок и на их цены, IMHO.
> да, STM32 и LPC нынче рвут всех, как и радиолюбительстве, так и
> в промышленном применении. Хотя насчёт последнего, то очень часто вижу там
> процы от Renesas.Ну да, мы тоже любим STM32, но LPC не пробовали. STM32 более чем хватает, вроде.
>> А вы пользуетесь этим mbed? Я вот пробовал — тоже не понравилось.
>> Да и по сути меня в mbed интересует лишь база библиотек.
>> Не пробовали их использовать без их online IDE?
> mbed - с моей точки зрения, это "как научиться программировать микроконроллеры дегенерату",
> и аудитория такая же, как и ардуино.Такого же мнения.
> А библиотеками без этой чудной онлайн среды не пользовалась, да и не
> собираюсь.Просто там есть поддержка out-of-box всякой экзотической переферии вроде Wiznet5500, что когда-нибудь может и понадобиться.
Если их код когда-нибудь можно будет начать использовать в проектах, получаемых из STM32CubeMX, то, IMHO, было бы здорово. Вы, кстати, пустой проект в чём создаёте? Или совсем ручками? :)
> Стандартная библиотека периферии позволяет делать тоже самое, и так же
> быстро.Мне кажется, что в mbed есть огромное количество того, что нет в стандартной библиотеке. Просто сам проект (mbed) ориентирован на постоянный upload библиотек со стороны комьюнити.
>> И какие железки вы используете?
> Обычно это STM32, ещё немного использую отечественные, от Миландра (также на Cortex-M)Понятно. Эти Миландры оказались очень дорогими (совершенно неподъёмные цены для нас). Мы — всего лишь маленький IT-шный отдельчик при институте :)
> Ну да, мы тоже любим STM32, но LPC не пробовали. STM32 более
> чем хватает, вроде.LPC более производительные по сравнению с STM32, вот довольно интересное сравнение http://www.russianelectronics.ru/developer-r/review/2192/doc.../
процы от Renesas более энергоэффективны, в итоге STM32 - золотая середина :)
> Вы, кстати, пустой проект в чём создаёте? Или совсем ручками? :)
Eclipse + OpenOCD + ARM-плагин.
Я не совсем задротка, чтобы чисто ручками всякие штуки, типа makefile писать :)> Мне кажется, что в mbed есть огромное количество того, что нет в
> стандартной библиотеке. Просто сам проект (mbed) ориентирован на постоянный upload библиотек
> со стороны комьюнити.ну если есть возможность дёргать исходные тексты этих библиотек, то это отлично, просто сама так и не проверяла.
Ну а так, то у каждого эмбедерра есть свой набор написанных велосипедов, и использовать чужой код не всегда проще, чем написать свой.> Понятно. Эти Миландры оказались очень дорогими (совершенно неподъёмные цены для нас). Мы
> — всего лишь маленький IT-шный отдельчик при институте :)если в металлокерамике, то да. А так, у них есть ещё и в пластике, для гражданки, например 1986ВЕ92 (Cortex-M3, 80 МГц, в LQFP-64), по цене около 200 руб/шт., есть ещё варианты, вроде как 1986ВЕ1Т (Cortex-M1, 144 МГц), вообщем что-то у них есть:)
Но в целом, миландровские процы, это содранные STM32, что они и не отрицают (для 1986ВЕ91 был прототипом STM32F103)
Причём багов в них довольно много, и медленная периферия. Одним словом отечественный производитель :)
>> Ну да, мы тоже любим STM32, но LPC не пробовали. STM32 более
>> чем хватает, вроде.
> LPC более производительные по сравнению с STM32, вот довольно интересное сравнение http://www.russianelectronics.ru/developer-r/review/2192/doc.../
> процы от Renesas более энергоэффективны, в итоге STM32 - золотая середина :)Хм, любопытно.
>> Вы, кстати, пустой проект в чём создаёте? Или совсем ручками? :)
> Eclipse + OpenOCD + ARM-плагин.
> Я не совсем задротка, чтобы чисто ручками всякие штуки, типа makefile писать
> :)Ну, я так вообще не embedd-овщик :), вот и любопытно как с этим работают люди, которые как-то более опытны.
>> Мне кажется, что в mbed есть огромное количество того, что нет в
>> стандартной библиотеке. Просто сам проект (mbed) ориентирован на постоянный upload библиотек
>> со стороны комьюнити.
> ну если есть возможность дёргать исходные тексты этих библиотек, то это отлично,
> просто сама так и не проверяла.
> Ну а так, то у каждого эмбедерра есть свой набор написанных велосипедов,
> и использовать чужой код не всегда проще, чем написать свой.Это понятно, но это не правильно. В каком-то смысле mbed делает правильную вещь — заставляет пользователей upload-ить свои труды, чтобы они там накопили какую-то базу удачных библиотек (out of box и best practice одним выстрелом), чтобы избегать велосипедизма. Но реализация идеи просто отвратительная на мой взгляд.
>> Понятно. Эти Миландры оказались очень дорогими (совершенно неподъёмные цены для нас). Мы
>> — всего лишь маленький IT-шный отдельчик при институте :)
> если в металлокерамике, то да. А так, у них есть ещё и
> в пластике, для гражданки, например 1986ВЕ92 (Cortex-M3, 80 МГц, в LQFP-64),
> по цене около 200 руб/шт., есть ещё варианты, вроде как 1986ВЕ1Т
> (Cortex-M1, 144 МГц), вообщем что-то у них есть:)
> Но в целом, миландровские процы, это содранные STM32, что они и не
> отрицают (для 1986ВЕ91 был прототипом STM32F103)
> Причём багов в них довольно много, и медленная периферия. Одним словом отечественный
> производитель :)Хм-м… Нам для некоторых задач и одного мегагерца будет много. А вот бажность — это действительно очень плохо. А можно пример бага для понимания о чём речь?
И ещё вопрос, не подскажите где можно их (1986ВЕ92/1986ВЕ1Т) найти в свободной продаже? Видать мои гуглонавыки слишком хреновы (как-то быстро не ищется). Продаются лишь навороченные developer board, но стоят они… много…
> А можно пример бага для понимания о чём речь?Вас интересуют именно Миландровские баги или вообще баги в чипах? За первые не скажу, не в курсе, а так в чипах (особенно в сложных чипах первых ревизий) их ещё как есть. Выглядят примерно так (выдуманный пример, но по мотивам реальных событий):
при принудительном сбросе второго таймера при включенном на запись канале DMA3 происходит сбой в конвейере, что может привести к пропуску выполнения команды, следующей за командой записи в регистр таймера. Рекомендуемый workaround - добавлять две команды NOP непосредственно после команды записи в регистр таймера. Устранено в ревизиях чипа, начиная с 3.
Некоторые учитываются прямо компилятором и программисту мозг не парят. Некоторые пострашней примера (не такие вычурные условия для воспроизведения да и посложней workaround'ы, если вообще есть).
>> А можно пример бага для понимания о чём речь?
> Вас интересуют именно Миландровские баги или вообще баги в чипах?Миландровские.
Как-то читал errata на какой-то их Cortex-M3 - они там CAN не на те ноги развели (facepalm.vhdl).
> Как-то читал errata на какой-то их Cortex-M3 - они там CAN не
> на те ноги развели (facepalm.vhdl).мдя-я-я… Представляю сколько человекочасов было напрасно убито :)
> Хм, любопытно.Как ни странно, ксюша на этот раз не гонит. STM32 - отличные камешки. У них хорошее соотношение цена/качество, они распостранены, у них широчайший ассортимент на любые задачи, а также крутая периферия, которая всяким AVR и в проекте не снилась. И к тому же они замечательно програмятся из того же линуха, например.
> Ну, я так вообще не embedd-овщик :), вот и любопытно как с
> этим работают люди, которые как-то более опытны.Читают даташит и программируют. Никакой ракетной науки. У ARM правда с этим все хитрее. Если у AVR даташит описывает все, то у ARMов - только особенности реализации. А даташит на "процессорное ядро вообще", если он нужен - берется таки у ARM.
> Это понятно, но это не правильно.
А ты знаешь, серебряных пуль
> В каком-то смысле mbed делает правильную вещь — заставляет пользователей upload-ить свои труды,
Во первых, код бывает разный. В том числе и совсем задачеспецифичный.
Во вторых, втюхивается вендорлок на один какой-то сайтик.
В третьих, зависимость всего процесса разработки от сетевой конективити как-то не есть совсем уж правильно.
В четвертых - я бы сто раз подумал до того как брать код от того кого ЗАСТАВИЛИ его выложить. Одно дело если кто добровольно опубликовал код, подготовившись к этому и понимая особенности процесса. И совсем другое - если это нечто вымученное клещами.> бажность — это действительно очень плохо. А можно пример бага для
> понимания о чём речь?В мк обычно вылиывается в непредсказуемое поведение которого по документации быть не должно. Может варьироваться от малозначительных мелочей типа досадного несоответствия документации до весьма фатальных вещей навроде внезапного зависания процессорного ядра без причин (т.е. все сделано все по документации, etc).
>> Хм, любопытно.
> Как ни странно, ксюша на этот раз не гонит. STM32 - отличные
> камешки. У них хорошее соотношение цена/качество, они распостранены, у них широчайший
> ассортимент на любые задачи, а также крутая периферия, которая всяким AVR
> и в проекте не снилась. И к тому же они замечательно
> програмятся из того же линуха, например.Да понятно, сами используем STM32.
>> Ну, я так вообще не embedd-овщик :), вот и любопытно как с
>> этим работают люди, которые как-то более опытны.
> Читают даташит и программируют. Никакой ракетной науки. У ARM правда с этим
> все хитрее. Если у AVR даташит описывает все, то у ARMов
> - только особенности реализации. А даташит на "процессорное ядро вообще", если
> он нужен - берется таки у ARM.Это-то всё очевидно, а меня интересовала софтварная часть в рамках того вопроса. Например, пользуются ли нормальные люди CubeMX, или это лишь я по малоопытности его использую для генерации проектов?
>> В каком-то смысле mbed делает правильную вещь — заставляет пользователей upload-ить свои труды,
> Во первых, код бывает разный. В том числе и совсем задачеспецифичный.Поэтому имеется множество библиотек со своими особенностями. А также можно плотно расставить #ifdef-ы на разные случаи жизни.
В любом случае, когда есть рабочий хорошо написанный код, который демонстрирует как что-то работает, то делать свой код становится намного проще.
> Во вторых, втюхивается вендорлок на один какой-то сайтик.
Это как раз уродство реализации.
> В третьих, зависимость всего процесса разработки от сетевой конективити как-то не есть
> совсем уж правильно.Это тоже уродство реализации.
> В четвертых - я бы сто раз подумал до того как брать
> код от того кого ЗАСТАВИЛИ его выложить. Одно дело если кто
> добровольно опубликовал код, подготовившись к этому и понимая особенности процесса. И
> совсем другое - если это нечто вымученное клещами.Ну вот пробуешь сам завести какую-то периферию -- не заводится. А если будет библиотечка, которая показывает proof of concept, то диагностировать станет сразу намного проще.
Вот GitHub -- значительно более хороший проект в этом смысле. Благодаря ему люди стали намного больше upload-ить, и он создаёт значительно меньше неудобств. Но, к сожалению, по embedded-у там фактически ничего и нет. Было бы здорово если бы появился проект, благодаря которому люди собрали бы коллекцию хороших библиотек для тех же stm-ок. А сейчас хаос и анархия. Каждый embedd-овщик живёт в своём маленьком мире из-за чего качество кода значительно хуже и производится огромная дупликация труда.
>> бажность — это действительно очень плохо. А можно пример бага для
>> понимания о чём речь?
> В мк обычно вылиывается в непредсказуемое поведение которого по документации быть не
> должно. Может варьироваться от малозначительных мелочей типа досадного несоответствия
> документации до весьма фатальных вещей навроде внезапного зависания процессорного ядра
> без причин (т.е. все сделано все по документации, etc).Да, мы с таким сталкивались даже на STM32 (либо мы сами идиоты, но мы много раз всё перепроверили), проблема решалась дополнительным ограничением, о котором в datasheet не сказано. Но меня сейчас интересует конкретно Миландр, чтобы понять есть ли смысл на него вообще время тратить.
Вообще говоря, если неполадка постоянная (вроде тех, с которыми столкнулись мы), то это не страшно. Один раз исправил (потратив дохрена времени на выяснение причин) и далее надёжно работает. Меня-то пугает возможность плавующих багов. Их у Миландра нет?
> Да понятно, сами используем STM32.На их фоне, аврки - мк для фонариков и некрофилов.
> Например, пользуются ли нормальные люди CubeMX,
Я gcc пользуюсь. И geany. Из линуха. А вы думали, я буду изучать тулчейн и ОС чисто для прикола? Так не пойдет.
И да, погодь, я поискал что это. Как работу работать - значит, винды. А сказки про сборку всего и вся из сорцов - быстренько идут лесом с интересом. Так и запишем. Впрочем, было ожидаемо.
> или это лишь я по малоопытности его использую для генерации проектов?
Честно говоря не очень понимаю что такое "генерация проекта".
> #ifdef-ы на разные случаи жизни.
Увлечение этим - делает код уродским, нечитабельным и трудным в майнтенансе и понимании. Существуют варианты как это относительно культурно делать, но у большинства тех кто этим пользуется, получается уродизация программы, так что потом в ней вообще сложно разобраться.
Знаешь, я - не препроцессор. Мне не очень хочется держать в мозгу большой state из всякой дряни котрая вообще к решению задачи относится довольно косвенно. Поэтому ifdef - это крайний случай, а не повод для гордости.
> В любом случае, когда есть рабочий хорошо написанный код, который демонстрирует как
> что-то работает, то делать свой код становится намного проще.Вот тут я совершено согласен - зачастую проще всего вообще взять нечто максимально похожее на решение своей задачи и немного допатчить. В этом, собственно, пойнт опенсорса и состоит: там это получается круто и естественно.
> Это как раз уродство реализации.
Ну это ж ARM, им денег хочется. А как они к опенсорсу относятся, они показали с своими Mali, на которые документации нет. Хотя GPU с архаичной и совершенно безблагодатной архитектурой, отстающей поколения на 3 от десктопных. Документированных. Это называется "бессмысленно и беспощадно".
> Это тоже уродство реализации.
Ну так ARM видимо хочет завендорлочить всех посильнее. Там вон imagination с мипсами трепыхаться начал, openrisc-и всякие развиваются. По-моему они хотят встать на те же грабли что и MS.
> Ну вот пробуешь сам завести какую-то периферию -- не заводится. А если
> будет библиотечка, которая показывает proof of concept,Я как-то насмотрелся на код, который вывалили абы как. И знаешь, я пришел к выводу что я предпочитаю код в сорцах от тех кто понимает как работает опенсорс и следует определенным практикам. "Библиотечка" от абы кого - окажется прибитой гвоздями к вон тому конкретному юзкейсу, без намека на то чтобы это было generic и удобным для применения в пласте похожих по смыслу программ. В результате оказывается проще с ноля написать чем иметь дело с таким кодом. И совсем не круто, если такого кода разведется навалом и среди него будет сложно находить нечто реально юзабельное.
> то диагностировать станет сразу намного проще.
А решать задачи - сложнее. Реюз кода может профакапиться. А выложить какой-то трэш по принципу "можете посмотреть, но руками не трогать, и уж упаси вас боже это в свою задачу привинтить, сэкономив себе время!" - ну, знаете ли, это очень в духе проприетарщиков. И у фирмы ARM все очень может прийти к именно такому формату.
> Вот GitHub -- значительно более хороший проект в этом смысле.
Но тоже со своими недостатками. Скажем есть много мусора без явного указания лицензий. Последнее что я хочу - на лицензионные разборки попасть.
> люди стали намного больше upload-ить, и он создаёт значительно меньше неудобств.
С одной стороны это так. С другой, он довольно сильно замусорен каким-то трэшом, от hello world-ов замусоривающих выдачу до крапа без лицензии. И не то чтобы это здорово, искать реально полезный код довольно утомительно.
> Но, к сожалению, по embedded-у там фактически ничего и нет.
Смотря что хотелось найти. Ну вон например, https://github.com/libopencm3/libopencm3 - явно для embedded.
> коллекцию хороших библиотек для тех же stm-ок.
Я скорее поверю в то что мне удастся найти хороший код на гитхабе, чем в то что ARM может что-то такое в нормальном виде. Тем более что у эмбедеров культура обмена исходниками не развита. Вывалят они тебе суперкод. Собираемый одной версией какой-нибудь "кайлы". У них работает - код хороший. Такая логика. А при попытке его например собрать gcc, да под линем... да что там, даже "неправильная" версия кайлы облажается. А в ответ на багрепорт - последует какая-нибудь "умная" мысль "но вы можете скачать крякнутую кайлу там".
> А сейчас хаос и анархия.
Не там. Эмбедовщики зачастую жлобские и виндообразные. У них нет культуры реюза кода, и уж тем более они не в курсе кроссплатформенности и портабельности лишний раз. Для половины из них нормально написать код под "иар три-хренадцать" и искренне недоумевать чего остальным в таком требовании может не нравиться. Ну подумаешь, проблема - взять именно иар, именно три-хренадцать, как у Автора Кода. И все это по рацоинальной причине "я так привык".
И знаешь, сама по себе насильная выжимка из таких кадров кода клещами - ни разу не изменит их mindset и подходы к делу. И будет только поисковую выдачу замусоривать.
> Каждый embedd-овщик живёт в своём маленьком мире из-за чего качество
> кода значительно хуже и производится огромная дупликация труда.Именно так. А ты больше пользуйся всякими кульными виндовыми утилитами, под EULA. И этот мирок так и останется маленьким и опроприетареным. А если ты не этого хотел... ...тогда с гуя ли ты сам выбрал такие подходы, для начала?
С таким же успехом можешь надеяться на ломовые коммиты в опенсорс от юзеров MSVS и недоумевать что codeplex не очень хорошо развивается, "а ведь было бы логично вываливать наработки на дотнете для других, блаблабла".
> Да, мы с таким сталкивались даже на STM32
У них тоже бывают errata, поэтому не лишне перекачивать errata с сайта STM и просто гуглить (в errata может быть и не все). Если совсем лыжи не едут, в errata пусто, гугл молчит - идешь куда-нибудь в район electronix'а и спрашиваешь там. Там обитает толпа матерых эмбедеров, если грабли есть - их с хорошей вероятностью припомнят. Еще не лишне проверять например какой код нагенерил компилер, etc. В компилерах тоже бывают баги. А где-нибудь можно забыть подсказать компилеру что это "volatile", например.
> котором в datasheet не сказано. Но меня сейчас интересует конкретно Миландр,
> чтобы понять есть ли смысл на него вообще время тратить.Если у тебя импортозамещение актуально - тогда да. Иначе - какие к тому предпосылки? В пользу STM32 из очевидного - большое комьюнити, обтоптавшее грабли (основная жесть была несколько лет назад, когда народ начал с авров валить), разумные цены, эпичный ассортимент на все оказии (освоить представителя знакомого семейства - проще чем совсем иной чип).
> Вообще говоря, если неполадка постоянная (вроде тех, с которыми столкнулись мы), то
> это не страшно.Баги бывают самые разные. И вероятностные, и 100% воспроизводимые. Множество грабель может быть по иным причинам - физическим и электрическим. Если у тебя есть сильноточные цепи или цепи с частотой более 100кГц - разводка платы под это является сложным начинанием. Наводки могут вызывать кучу приколов. Как и некачественная разводка цепей питания.
До того как уверенно выдвигать предъявы насчет errata в именно чипе - в вещах от кодогенерации до питания и EMI должна быть крепкая уверенность. Если оно сбоит с разными компилерами, на разных платах, у разного народа - ок, попался баг. По хорошему его надо производителю сообщить, если в errata его еще нет.
> Один раз исправил (потратив дохрена времени на выяснение причин)
Да вообще это "обычное" дело в эмбедовке. В том плане что даже матерый волк может нарваться на странности, достойные написания детектива. Можешь почитать например как DiHalt матрицу клавиатуры разок безбашенно посканировал с высокой частотой "потому что так удобнее в софте" было. В результате получился целый детектив, потянувший на заметку в его бложике.
> и далее надёжно работает. Меня-то пугает возможность плавующих багов. Их у Миландра нет?
Когда я видел список косяков миландров (кто-то вываливал их errata, несколько месяцев назад) - они были очень жосскими и невкусными. А половина этой жести еще без воркэраундов. Стало ли у них лучше с тех пор - честно говоря не в курсе.
Честно говоря, сейчас совершенно нет времени отвечать, поэтому прочёл пока только часть данного комментария, а отвечу только на:> Я gcc пользуюсь. И geany. Из линуха. А вы думали, я буду
> изучать тулчейн и ОС чисто для прикола? Так не пойдет.И? Тоже gcc и linux (конечно же). Но только vim, а не geany. Не понимаю ваш вопрос. Та хрень нужна лишь для генерации пустого проекта (чтобы сгенерировать код под конкретный камешек или плату, не тратя время).
> И да, погодь, я поискал что это. Как работу работать - значит,
> винды.Причём тут винды? Это JAVA-вая хень (что тоже противно, но тем ни менее винда тут ни при чём).
> А сказки про сборку всего и вся из сорцов -
> быстренько идут лесом с интересом. Так и запишем. Впрочем, было ожидаемо.Это JAVA-вская херь, которая генерит полностью открытый код. Сам код проекта в результате полностью открыт, который в свою очередь потом компилится gcc по сценарию из автогенерённого (однократно) Makefile. В чём проблема?
Надеюсь сегодня вечером будет время прочесть остальное и ответить.
> пустого проекта (чтобы сгенерировать код под конкретный камешек или плату, не тратя время).Ну я видимо не настолько часто меняю камни, или не настолько часто делаю что-то, чтобы такими вещами заморочиться. Основное время занимает все-таки написание фирмвари и обпрыгивание грабель, а не что-то еще.
> Причём тут винды? Это JAVA-вая хень
А ставится из setup.exe oO.
> сценарию из автогенерённого (однократно) Makefile. В чём проблема?
Ну я встретил 2 упоминания этой хрени. Решил посмотреть что это. Предложение скачать вело на setup.exe с MZ PE файлом. Дальше не разбирался по этому поводу. В таком случае сорь за наезд, не по делу.
>[оверквотинг удален]
> Ну я видимо не настолько часто меняю камни, или не настолько часто
> делаю что-то, чтобы такими вещами заморочиться. Основное время занимает все-таки написание
> фирмвари и обпрыгивание грабель, а не что-то еще.
>> Причём тут винды? Это JAVA-вая хень
> А ставится из setup.exe oO.
>> сценарию из автогенерённого (однократно) Makefile. В чём проблема?
> Ну я встретил 2 упоминания этой хрени. Решил посмотреть что это. Предложение
> скачать вело на setup.exe с MZ PE файлом. Дальше не разбирался
> по этому поводу. В таком случае сорь за наезд, не по
> делу.Да, понимаю, меня точно так же сбило с толку, и я прошёл мимо. А чуть позже я на каком-то форуме, читая про проблемы с поиском корректного startup.s, нашёл упоминание про то, что CubeMX является кроссплатформенным. Дальнейший поиск показал, что он вполне запускается с помощью "java -jar Setup.exe". Похоже, что это самораспаковывающейся и самозапускающейся jar для windows, однако с возможностью запускать прямо с помощью "java -jar" -- честно сказать не разбирался, почему оно работает. Мне хватило факта, что оно работает. В виду его мутности запускаю в отдельном окружении. А самое главное, что весь этот геморрой -- это личные мои проблемы (а не тех, кто будет дальше с этим работать), ибо то, что будет публиковаться дальше -- это вполне читаемый код для gcc+make.
В будущем хотелось бы отказаться от CubeMX, поэтому я и задал тот вопрос Xenia. Хочется узнать, как другие люди работают, и найти более приятный для меня самого вариант.
>> #ifdef-ы на разные случаи жизни.
> Увлечение этим - делает код уродским, нечитабельным и трудным в майнтенансе и
> понимании. Существуют варианты как это относительно культурно делать, но у большинства
> тех кто этим пользуется, получается уродизация программы, так что потом в
> ней вообще сложно разобраться.
> Знаешь, я - не препроцессор. Мне не очень хочется держать в мозгу
> большой state из всякой дряни котрая вообще к решению задачи относится
> довольно косвенно. Поэтому ifdef - это крайний случай, а не повод
> для гордости.ifdef -- это не крайний случай, а инструмент для вполне конкретных целей. Да, он осложняет чтение кода, но лично для меня сильно ifdef-еный код (если это оправдано) остаётся обычно вполне читаемым. На крайний случай можно применить gcc -E.
>> Ну вот пробуешь сам завести какую-то периферию -- не заводится. А если
>> будет библиотечка, которая показывает proof of concept,
> Я как-то насмотрелся на код, который вывалили абы как. И знаешь, я
> пришел к выводу что я предпочитаю код в сорцах от тех
> кто понимает как работает опенсорс и следует определенным практикам.Ну так (почти) все предпочитают хороший свободный код.
> "Библиотечка" от
> абы кого - окажется прибитой гвоздями к вон тому конкретному юзкейсу,
> без намека на то чтобы это было generic и удобным для
> применения в пласте похожих по смыслу программ. В результате оказывается проще
> с ноля написать чем иметь дело с таким кодом. И совсем
> не круто, если такого кода разведется навалом и среди него будет
> сложно находить нечто реально юзабельное.Естественно проще написать с нуля, однако наличие такой библиотечки даёт возможность понять, почему в этом "решении с нуля" что-то не работает. Есть куда подглядеть, другими словами.
>> то диагностировать станет сразу намного проще.
> А решать задачи - сложнее. Реюз кода может профакапиться. А выложить какой-то
> трэш по принципу "можете посмотреть, но руками не трогать, и уж
> упаси вас боже это в свою задачу привинтить, сэкономив себе время!"
> - ну, знаете ли, это очень в духе проприетарщиков. И у
> фирмы ARM все очень может прийти к именно такому формату.Ну, мы иногда изучаем чужой треш-код, берём оттуда полезные кусочки, остальное дописываем сами.
>> Вот GitHub -- значительно более хороший проект в этом смысле.
> Но тоже со своими недостатками. Скажем есть много мусора без явного указания
> лицензий. Последнее что я хочу - на лицензионные разборки попасть.Согласен. Однако по поводу лицензий, авторы обычно быстро отвечают на просьбы разъяснить.
А GitHub мне скорее не нравится больше своими маленькими lock-in-ами. Например Gogs позволяет зеркалировать проект с других площадок (ЕМНИП), а вот GitHub не позволяет.. почему? Вероятно для того, чтобы основная копия мелких проектов была именно на GitHub.
Торвальдсу же, например, там не нравится их реализация Pull Requests, что тоже не безобоснованно.
Да и вообще, код GitHub-а закрыт и они могут в любой момент начать творить фактически всё что угодно.
Если же вернуться к качеству кода на GitHub, то да, там out of the box решений обычно нет. Но бывает экономит время использование чужих наработок в качестве подсказок, или даже в качестве основы для своего решения (если изначальный код более ли менее).
>> люди стали намного больше upload-ить, и он создаёт значительно меньше неудобств.
> С одной стороны это так. С другой, он довольно сильно замусорен каким-то
> трэшом, от hello world-ов замусоривающих выдачу до крапа без лицензии. И
> не то чтобы это здорово, искать реально полезный код довольно утомительно.Для этого там придумали Star-ы. Что обычно не помогает, но иногда помогает.
>> Но, к сожалению, по embedded-у там фактически ничего и нет.
> Смотря что хотелось найти. Ну вон например, https://github.com/libopencm3/libopencm3
> - явно для embedded.Допустим я хочу завести wiznet5500 на sm32f1 (как я уже упоминал где-то в других комментариях). На GitHub такие частные случаи хрен найдёшь, хотя я уверен, что люди это уже неоднократно делали.
>> коллекцию хороших библиотек для тех же stm-ок.
> Я скорее поверю в то что мне удастся найти хороший код на
> гитхабе, чем в то что ARM может что-то такое в нормальном
> виде. Тем более что у эмбедеров культура обмена исходниками не развита.
> Вывалят они тебе суперкод. Собираемый одной версией какой-нибудь "кайлы". У них
> работает - код хороший. Такая логика. А при попытке его например
> собрать gcc, да под линем... да что там, даже "неправильная" версия
> кайлы облажается. А в ответ на багрепорт - последует какая-нибудь "умная"
> мысль "но вы можете скачать крякнутую кайлу там".Значит либо просто забью на такой код, либо поизучаю как он работает (чтобы у себя в голове прояснить интересующие меня моменты), либо портирую под gcc+make и кину Pull Request.
>> А сейчас хаос и анархия.
> Не там. Эмбедовщики зачастую жлобские и виндообразные. У них нет культуры реюза
> кода, и уж тем более они не в курсе кроссплатформенности и
> портабельности лишний раз. Для половины из них нормально написать код под
> "иар три-хренадцать" и искренне недоумевать чего остальным в таком требовании может
> не нравиться. Ну подумаешь, проблема - взять именно иар, именно три-хренадцать,
> как у Автора Кода. И все это по рацоинальной причине "я
> так привык".Да это ясно, и, кстати, у меня научный руководитель (газодинамика/термодинамика/хим. кинетика) страдает походими проблемами :)
Но ведь нужно с этим обороться. Вот GitHub немножно изменил культуру программирования в мелких проектах, IMO. Вот нужно дальше работать над тем, чтобы люди занимались reusable своего кода.
> И знаешь, сама по себе насильная выжимка из таких кадров кода клещами
> - ни разу не изменит их mindset и подходы к делу.
> И будет только поисковую выдачу замусоривать.Насильная выжимка -- не изменит. А вот взаимодействие с людьми, которые увидят эту выжимку -- может быть и изменит.
>> Каждый embedd-овщик живёт в своём маленьком мире из-за чего качество
>> кода значительно хуже и производится огромная дупликация труда.
> Именно так. А ты больше пользуйся всякими кульными виндовыми утилитами, под EULA.
> И этот мирок так и останется маленьким и опроприетареным. А если
> ты не этого хотел... ...тогда с гуя ли ты сам выбрал
> такие подходы, для начала?Я -- любитель gcc+make. Если речь про CubeMX, то он не виндовый (а кроссплатформенный) и нужен лишь для генерации пустого проекта под нужный камешек. Результирующий код получается для gcc+make. И пользуюсь я им не потому, что он мне нравится, а потому что другие подходы приводили к трате тонны времени на нахождение корректного startup.s и прочих проблем. Когда стану опытнее в stm-ках, то найду способ работать и без CubeMX. Повторюсь, я ж вообще не embedd-овщик, поэтому воспользовался просто тем, что рекомендуется использовать в официальной документации.
>> Да, мы с таким сталкивались даже на STM32
> Еще не лишне проверять например какой код нагенерил компилер, etc. В
> компилерах тоже бывают баги. А где-нибудь можно забыть подсказать компилеру что
> это "volatile", например.Это-то всё очевидно.
>> котором в datasheet не сказано. Но меня сейчас интересует конкретно Миландр,
>> чтобы понять есть ли смысл на него вообще время тратить.
> Если у тебя импортозамещение актуально - тогда да. Иначе - какие к
> тому предпосылки?Импортозамещение действительно может нас коснуться. Но есть и более конкретная задача, о которой рассказать не могу, к сожалению.
>[оверквотинг удален]
>> Один раз исправил (потратив дохрена времени на выяснение причин)
> Да вообще это "обычное" дело в эмбедовке. В том плане что даже
> матерый волк может нарваться на странности, достойные написания детектива. Можешь почитать
> например как DiHalt матрицу клавиатуры разок безбашенно посканировал с высокой частотой
> "потому что так удобнее в софте" было. В результате получился целый
> детектив, потянувший на заметку в его бложике.
>> и далее надёжно работает. Меня-то пугает возможность плавующих багов. Их у Миландра нет?
> Когда я видел список косяков миландров (кто-то вываливал их errata, несколько месяцев
> назад) - они были очень жосскими и невкусными. А половина этой
> жести еще без воркэраундов.Понятно.
> ifdef -- это не крайний случай, а инструмент для вполне конкретных целей.При том чаще всего - знатный костыль. Загаживающий код.
> можно применить gcc -E.
Не очень хочется, если честно.
> Ну так (почти) все предпочитают хороший свободный код.
Не совсем так. Многие эмбедеры вообще очень слабо разбираются в лицензии, а иары и кайлы честно сперли с кряками, как обычно у юзерей винды, особенно в exUSSR. Ну и либы и прочее по такому же принципу делают.
> подглядеть, другими словами.
Тут соглашусь, пожалуй.
> Ну, мы иногда изучаем чужой треш-код, берём оттуда полезные кусочки,
> остальное дописываем сами.И в результате получается стремноватый код с непонятным лицензионным статусом?
> Согласен. Однако по поводу лицензий, авторы обычно быстро отвечают на просьбы разъяснить.
Но на все это надо тратить сильно отдельное время.
> GitHub не позволяет.. почему?
Я не знаю что он там не позволяет. Git pull с него работает. А если кто не умеет по протоколу git работать - наверное это уже не вина гитхаба.
> Вероятно для того, чтобы основная копия мелких проектов была именно на GitHub.
Не знаю. Но когда Торвальдсу потребовалось, он без проблем перекинулся на guthub а потом обратно на кернелорг. Кого-то завендорлочить при использовании git - это фантастика.
> Торвальдсу же, например, там не нравится их реализация Pull Requests, что тоже
> не безобоснованно.У него есть команда и там сложились совсем иные практики. Ну и логично что ему переобучаться всей толпой под это не резон. А зачем, если его практики и так работают? Я не фанат суперцентрализации на 1 сервис.
> Да и вообще, код GitHub-а закрыт и они могут в любой момент
> начать творить фактически всё что угодно.Они могут снести реп по DMCA кляузе, например. В этом плане свой сервер надежнее всего.
> чужих наработок в качестве подсказок, или даже в качестве основы для
> своего решения (если изначальный код более ли менее).ИМХО 50/50. Ну то-есть там есть как отличный код, так и просто мусор. И отсеивание одного от другого там достаточно трудоемкая затея на самом деле.
> Для этого там придумали Star-ы. Что обычно не помогает, но иногда помогает.
Реально это в половине случаев похоже на изучение мусорного бака. Хотя порой достаточно вознаграждающее. А у эмбедеров с относительно проприетарным складом ума и низкой культурой в вопросах лицензирования все будет еще жестче.
> Допустим я хочу завести wiznet5500 на sm32f1
А, ну я не фанат таких вещей. Я вообще в гробу видал черти-чей сетевой стек в абы какой фирмваре в общем случае. И если уж мы про вендорлок, то предъявы гитхабу на фоне жесткого вендорлока на конкретный модуль с уникальным "апи" - это вообще номер.
> я уверен, что люди это уже неоднократно делали.
Вероятно, но я таким не интересуюсь.
> Значит либо просто забью на такой код, либо поизучаю как он работает
> (чтобы у себя в голове прояснить интересующие меня моменты), либо портирую
> под gcc+make и кину Pull Request.Проблема в том что на это тратится время, а взаимодействие с таким автором легко оправдает самые пессимистичные ожидания, по типу искреннего непонимания "а чего б вам просто не поставить крякнутую кайлу?"
> Да это ясно, и, кстати, у меня научный руководитель (газодинамика/термодинамика/хим.
> кинетика) страдает походими проблемами :)Такими проблемами страдает большинство эмбедеров. И кой-как отучаться от таких замашек они начинают только сейчас, когда неумение использовать линух начинает икаться. А с линухом неудобно из винды работать, так что люди пошли разучивать пингвины и неожиданно для себя заметили что кроме виндовых подходов оказывается бывают и иные. Лицензионно чистые, простые, логичные и вообще. И я так смотрю - многим олдскульным волкам эти подходы пришлись по вкусу. Но сабж не про них.
> Но ведь нужно с этим обороться. Вот GitHub немножно изменил культуру программирования
Это да. Но с другой стороны, если нарваться на неопытного автора который програмить научился вчера и в вьюжлстудии - наесться можно по полной программе.
> Насильная выжимка -- не изменит. А вот взаимодействие с людьми, которые увидят
> эту выжимку -- может быть и изменит.Я думаю в этом плане гитхаб и то лучше. По крайней мере к нормальному инструменту взаимодействия приучает. Но ведь половина будет думать что гит == гитхаб...
> Я -- любитель gcc+make. Если речь про CubeMX, то он не виндовый
> (а кроссплатформенный) и нужен лишь для генерации пустого проектаА, ну я поискал что это. И нашел нечто с setup.exe, вот и решил что он виндовый.
p.s. я думаю что мое время на опеннете заканчивается. К сожалению я не могу и не буду обещать какие либо ответы после этого сообщения.
> Но в целом, миландровские процы, это содранные STM32,Вот только ERRATA у них - далеко не STMовские. В смысле, если кому Errata на STM казались бажными - в интернете можно найти список errata этих чудес природы. Знаете, STM на этом фоне очень безглючные и надежные мк.
AVR & PIC с OpenGL есть ?
> AVR & PIC с OpenGL есть ?Зачем в embedded-е OpenGL?
> Зачем в embedded-е OpenGL?есть же OpenGL ES ( Embedded System )- для дисплея больше
>> Зачем в embedded-е OpenGL?
> есть же OpenGL ES ( Embedded System )- для дисплея большеЭто уже совсем другой embedded. "mbed" в моём понимании ориентирован на МК. А вы уже говорите про всякие RPi-like/N900/etc, если я правильно понял. Я никогда не сталкивался с OpenGL ES, поэтому прошу простить, если я ошибаюсь.
> Я никогда не сталкивался с OpenGL ESв каждом анжроид телефоне, практически есть он
>> Я никогда не сталкивался с OpenGL ES
> в каждом анжроид телефоне, практически есть онНу так, как я сказал, это совсем другой embedded (на мой взгляд и не embedded вовсе). В subj-е-то речь про микроконтроллеры (во всяком случае по моему опыту общения с «mbed»).
Вообще я не очень считаю всякие телефоны/rpi и прочие embedded-ом, ибо это просто тупо полноценные компьютеры в малом форм-факторе. Я экономлю считанные байты на embedded, чтобы ОЗУ хватило, а в RPi2 ГБ ОЗУ.
> просто тупо полноценные компьютеры в малом форм-факторе.Прости, дяденька, даже обычный х86 писюк может быть эмбедовкой. Достаточно его привинтить в какой-нибудь банкомат или станок. И сразу появляются характерные для эмбедовки требования, как то автономная работа без вмешательства, всякие там безусловные выходы на режим под страхом нужды гнать технарей обслуживать это и прочее руление ввереной железякой, от и до. А у индустриалов есть PC-104 например.
> Я экономлю считанные байты на embedded, чтобы ОЗУ хватило, а в RPi2 ГБ ОЗУ.
А в PIC16 можно еще и с ограничениями на размер стека посношаться. Да еще всяких RETLW вкусить, вместо нормальных констант. Вообще, простор для мазохистов - большой. Можно например на брейнфаке программировать. Или, что примерно то же самое - ассемблировать программу на тетрадном листочке в машинный код.
>> просто тупо полноценные компьютеры в малом форм-факторе.
> Прости, дяденька, даже обычный х86 писюк может быть эмбедовкой. Достаточно его привинтить
> в какой-нибудь банкомат или станок. И сразу появляются характерные для эмбедовки
> требования, как то автономная работа без вмешательства, всякие там безусловные выходы
> на режим под страхом нужды гнать технарей обслуживать это и прочее
> руление ввереной железякой, от и до. А у индустриалов есть PC-104
> например.Это лишь 2% от embedded-а и 98% от обычного компьютера, IMHO. Да, это можно назвать embedded-ом, конечно, но нужно держать в уме, что это скорее просто компьютер с некоторыми особеностями embedded-а.
>> Я экономлю считанные байты на embedded, чтобы ОЗУ хватило, а в RPi2 ГБ ОЗУ.
> А в PIC16 можно еще и с ограничениями на размер стека посношаться.
> Да еще всяких RETLW вкусить, вместо нормальных констант. Вообще, простор для
> мазохистов - большой. Можно например на брейнфаке программировать. Или, что примерно
> то же самое - ассемблировать программу на тетрадном листочке в машинный
> код.Речь не про мазохизм, а про решение технических задач наиболее оптимальным с точки зрения затрат способом.
> Это лишь 2% от embedded-а и 98% от обычного компьютера, IMHO.Позволю себе не согласиться, у "апликушных ARM" есть куча периферии характерной для микроконтроллеров и не характерной для писюков. Ну там GPIO, ADC всякие, SPI/I2C/UART доступные юзеру и прочая. Это скорее ниша посередине.
> Да, это можно назвать embedded-ом, конечно,
Просто по определению. Embedded - то что встроено. Если встроили обычный писюк, как-то подогнав его под требования к эмбедовке - ну значит это эмбедовка, что тут скажешь. Ну да, писюкастая и на любителя
> но нужно держать в уме, что это скорее просто компьютер с некоторыми
> особеностями embedded-а.Это просто встроенный компьютер. Embedded computer. Эмбедовка - по определению.
> Речь не про мазохизм, а про решение технических задач наиболее оптимальным с
> точки зрения затрат способом.А оптимальность - штука весьма многофакторная :)
>[оверквотинг удален]
> Позволю себе не согласиться, у "апликушных ARM" есть куча периферии характерной для
> микроконтроллеров и не характерной для писюков. Ну там GPIO, ADC всякие,
> SPI/I2C/UART доступные юзеру и прочая. Это скорее ниша посередине.
>> Да, это можно назвать embedded-ом, конечно,
> Просто по определению. Embedded - то что встроено. Если встроили обычный писюк,
> как-то подогнав его под требования к эмбедовке - ну значит это
> эмбедовка, что тут скажешь. Ну да, писюкастая и на любителя
>> но нужно держать в уме, что это скорее просто компьютер с некоторыми
>> особеностями embedded-а.
> Это просто встроенный компьютер. Embedded computer. Эмбедовка - по определению.IMHO:
Слово embedded -- слегка многозначное. Можно понимать в прямом значении ("встроенный"), а можно и в переносном (с технологиями характерными для встраиваемых решений).
Например обычные PC-шники тоже встраивают в терминалы. Тоже embedded? Да, embedded, но только в прямом значении, так как кроме того, что его обернули в вандалоустойчивый огромный корпус, он ничем не отличается от обычного PC-шника и не обладает никакими особенностями, характерными для embedded-решений.Спорить не буду, так как знаю что общепринято понимать этот термин немного по-другому (именно так, как говорите вы). Именно поэтому я постоянно говорил, что это лишь _на мой взгляд_.
Аналогичная проблема у меня с тем, что люди называют контейнер виртуальной машиной. Так как мой взгляд контейнер -- это просто набор ресурсов в рамках конкретных namespace-ов (chroot на огромных стероидах) и к виртуализации не имеет отношения.
>> Речь не про мазохизм, а про решение технических задач наиболее оптимальным с
>> точки зрения затрат способом.
> А оптимальность - штука весьма многофакторная :)Согласен.
> Зачем в embedded-е OpenGL?Например, чтобы графику отрисовать. Морда управления к какой-нибудь железяке - это тоже в общем то embedded. Даже обычный писюк в банкомате - и тот в некотором роде эмбедовка. Со своими характерными требованиями.
>> Зачем в embedded-е OpenGL?
> Например, чтобы графику отрисовать. Морда управления к какой-нибудь железяке - это тоже
> в общем то embedded. Даже обычный писюк в банкомате - и
> тот в некотором роде эмбедовка. Со своими характерными требованиями.http://www.opennet.me/openforum/vsluhforumID3/104640.html#26
> http://www.opennet.me/openforum/vsluhforumID3/104640.html#26ИМХО там булшит. Реально графику рисуют самые разные железяки. И мелкие МК, и среднекалиберные апликушники, и полновесные писюки. Задачи бывают разные. И требования тоже. И право на жизнь имеют все эти варианты.
>> http://www.opennet.me/openforum/vsluhforumID3/104640.html#26
> ИМХО там булшит. Реально графику рисуют самые разные железяки. И мелкие МК,
> и среднекалиберные апликушники, и полновесные писюки. Задачи бывают разные. И требования
> тоже. И право на жизнь имеют все эти варианты.Серьёзно? Мелким МК нужен OpenGL? Не могли бы вы кинуть ссылку, где рассказывается о том, где кто-то сделал готовое решение в такой связке? Вопрос не риторический, мне действительно интересно.
> AVR & PIC с OpenGL есть ?AVR & PIC давно пора на свалку, или в музеи.
Cortex-M0 в QFN-корпусах им не оставляют шансов.
А как насчёт PIC-32 (архитектура MIPS 4k) ?
> А как насчёт PIC-32 (архитектура MIPS 4k) ?Можете порекомендовать какой-то конкретный МК в свободной продаже? Чтобы тупо можно было взять и сравнить характеристики/цены. Судя по первым попавшимся чипам на aliexpress и chipdip, PIC32 дороговат.
Например чем PIC32MX250F128D настолько лучше STM32F103? По-моему так наоборот существенно хуже, а стóит намного дороже [1, 2]. Да и судя по всему комьюнити намного меньше, а значит разработку вести сложнее.
[1] http://www.chipdip.ru/product1/8296765428/
[2] http://www.chipdip.ru/product/stm32f103c8t6/
> А как насчёт PIC-32 (архитектура MIPS 4k) ?А никак: PIC прощелкал клювом напрвление и нишу занял ARM. У ARM все нормально продумано, есть неплохие тулзы, в том числе и опенсорсные (да, под STM32 можно собрать код gcc и влить в флеш опенсорсной прогой, openocd с ними работать умеет, если кому хардварный дебаг надо, etc).
А еще - ассортимент ARMов явно лучше. Те же STM32 есть на все вкусы, от какой-то совсем мелочи в SO корпусах и прочих QFN, размером с тетрадную клеточку, до разлапистых 100+ лапых монстриков или даже BGA, если лапок надо дофига, etc. И где все это у PIC-ов? А младшие ARM у STM стоят около бакса и даже меньше. Microchip в пролете. В смысле, не вижу у них 32-битных МК с крутой периферией за доллар...
> AVR & PIC давно пора на свалку, или в музеи.
> Cortex-M0 в QFN-корпусах им не оставляют шансов.Надо же, даже микрософтовский бот может выдать дельные мысли. Вот что-что, а на фоне STM32 всякие AVR выглядят архаикой.
Удел AVRок теперь - переключение режимов в фонарике! И то, только потому что напрямую выдерживают литиевый аккум, от 2.7 до 4.2 вольт. STM в этом плане понежнее будет, а лишний стаб и прочая - там ну совсем не в кассу...
> Жду опять уникума, который будет говорить, что кроме AVR и PICНу надо же на чем-то делать пятирежимные фонарики?! STM для этого больно нежный - 4.2 или даже 4.3 вольта от свежего лития напрямую не держит, согласно даташиту. Горячие головы конечно так делают, но это не по фэншую.
