> Да понятно, сами используем 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, несколько месяцев назад) - они были очень жосскими и невкусными. А половина этой жести еще без воркэраундов. Стало ли у них лучше с тех пор - честно говоря не в курсе.
Вариант для распечатки
