>> Хм, любопытно.
> Как ни странно, ксюша на этот раз не гонит. STM32 - отличные
> камешки. У них хорошее соотношение цена/качество, они распостранены, у них широчайший
> ассортимент на любые задачи, а также крутая периферия, которая всяким AVR
> и в проекте не снилась. И к тому же они замечательно
> програмятся из того же линуха, например.Да понятно, сами используем STM32.
>> Ну, я так вообще не embedd-овщик :), вот и любопытно как с
>> этим работают люди, которые как-то более опытны.
> Читают даташит и программируют. Никакой ракетной науки. У ARM правда с этим
> все хитрее. Если у AVR даташит описывает все, то у ARMов
> - только особенности реализации. А даташит на "процессорное ядро вообще", если
> он нужен - берется таки у ARM.
Это-то всё очевидно, а меня интересовала софтварная часть в рамках того вопроса. Например, пользуются ли нормальные люди CubeMX, или это лишь я по малоопытности его использую для генерации проектов?
>> В каком-то смысле mbed делает правильную вещь — заставляет пользователей upload-ить свои труды,
> Во первых, код бывает разный. В том числе и совсем задачеспецифичный.
Поэтому имеется множество библиотек со своими особенностями. А также можно плотно расставить #ifdef-ы на разные случаи жизни.
В любом случае, когда есть рабочий хорошо написанный код, который демонстрирует как что-то работает, то делать свой код становится намного проще.
> Во вторых, втюхивается вендорлок на один какой-то сайтик.
Это как раз уродство реализации.
> В третьих, зависимость всего процесса разработки от сетевой конективити как-то не есть
> совсем уж правильно.
Это тоже уродство реализации.
> В четвертых - я бы сто раз подумал до того как брать
> код от того кого ЗАСТАВИЛИ его выложить. Одно дело если кто
> добровольно опубликовал код, подготовившись к этому и понимая особенности процесса. И
> совсем другое - если это нечто вымученное клещами.
Ну вот пробуешь сам завести какую-то периферию -- не заводится. А если будет библиотечка, которая показывает proof of concept, то диагностировать станет сразу намного проще.
Вот GitHub -- значительно более хороший проект в этом смысле. Благодаря ему люди стали намного больше upload-ить, и он создаёт значительно меньше неудобств. Но, к сожалению, по embedded-у там фактически ничего и нет. Было бы здорово если бы появился проект, благодаря которому люди собрали бы коллекцию хороших библиотек для тех же stm-ок. А сейчас хаос и анархия. Каждый embedd-овщик живёт в своём маленьком мире из-за чего качество кода значительно хуже и производится огромная дупликация труда.
>> бажность — это действительно очень плохо. А можно пример бага для
>> понимания о чём речь?
> В мк обычно вылиывается в непредсказуемое поведение которого по документации быть не
> должно. Может варьироваться от малозначительных мелочей типа досадного несоответствия
> документации до весьма фатальных вещей навроде внезапного зависания процессорного ядра
> без причин (т.е. все сделано все по документации, etc).
Да, мы с таким сталкивались даже на STM32 (либо мы сами идиоты, но мы много раз всё перепроверили), проблема решалась дополнительным ограничением, о котором в datasheet не сказано. Но меня сейчас интересует конкретно Миландр, чтобы понять есть ли смысл на него вообще время тратить.
Вообще говоря, если неполадка постоянная (вроде тех, с которыми столкнулись мы), то это не страшно. Один раз исправил (потратив дохрена времени на выяснение причин) и далее надёжно работает. Меня-то пугает возможность плавующих багов. Их у Миландра нет?
