[k155la3 26]

18 minutes ago, jcxz said:

. . . . С этим согласен. Тоже разрабатывал по мануалам TI DSP 5000-го и 6000-го семейств (да и Tiva тоже). STM (да и не только им) действительно следовало бы поучиться детальности и логичности описания TI.

Tiva у меня идет намного "резвее", чем STM. Документация у STM сделана по "облачной" технологии, такое большое серое-мутное облако.

[Lagman 1]

9 hours ago, jcxz said:

Тут все пугают "тысячами страниц" даташитов. Да не нужно читать их "от корки до корки"! Читать только нужное. Для старта нужна система тактирования - читаем про неё, нужны режимы загрузки - читаем про них, нужно описание GPIO - читаем про него, ну и т.п. А для многих проектов из имеющейся периферии нужно от силы 1-2 блока (кроме базовых). И "тысячи страниц" превращаются в пару десятков 

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

P.S. Для проверки возьмите камушек от Renesas RX210 и попробуйте сразу реализовать там DTC и при этом запустить его нужной частоте просто прочитав даташит.

P.S.S. По моим наблюдениям переход от стиля написания документации одного производителя на стиль другого производителя уходит очень много времени.

[jcxz 184]

29 минут назад, Lagman сказал:

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

Невнимательно читаете. Я писал об освоении нового МК. Ранее не известного.

А "людям которые уже давно работают с данным типом контроллеров" - им что изучать? Они уже должны знать.

29 минут назад, Lagman сказал:

P.S. Для проверки возьмите камушек от Renesas RX210 и попробуйте сразу реализовать там DTC и при этом запустить его нужной частоте просто прочитав даташит.

Я за свою практику брал и запускал пару десятков разных "камушков" разных производителей с разнообразной периферией. И всегда - по мануалам.

[Lagman 1]

7 minutes ago, jcxz said:

Я за свою практику брал и запускал пару десятков разных "камушков" разных производителей с разнообразной периферией. И всегда - по мануалам.

Разница в стиле написания больше зависит от континента где находится производитель и кем написана документация.

7 minutes ago, jcxz said:

А "людям которые уже давно работают с данным типом контроллеров" - им что изучать? Они уже должны знать.

Хотя бы периферию надо изучить.

[dimka76 42]

23 hours ago, Aleх said:

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

Через регистр совпадения. Есть несколько режимов PWM.

[Allregia 9]

Думаю что все-же стоит разделить Cube и HAL, поскольку никто не запрещает пользоваться ими по отдельности.

В HAL полно глюков, и сделать что-то чуть менее стандартное иногда просто невозможно, или оно не укладывается в требования (например по скорости).

 

Но сам CubeMX это совсем другое, это наследник MicroExplorer, и сам по себе весьма полезная штука и без всяких калов.

Во 1-х - это удобный выбор процессора, по наличию требумой периферии памяти, корпусу и т.п.

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

В 3-х - калом и генерацией исходников кубом можно не пользоваться совсем или пользоваться частично. В последнем случае, например можно по крайней мере, использовать сгенерированный им main.h  с определениями пинов и их названий. Просто что бы не терять на это время. Названия регистров и их биты тоже проще взять из CMSIS а не писать самому.

 

 

[SapegoAL 0]

А я согласен с Jcxz.
Всё прозаично, на самом деле: 

По крайней мере HAL и тп - это драйвера. Причём написанные универсально. Собственно к ним нет претензий.. Но, как правило в текущем проекте требуется не универсальность, а конкретика. Иными словами либо приходится править сам HAL (что явно не лучший вариант), либо писать промежуточный слой - переходной от фирменного к своей задаче. При этом надо ознакомится с построением их библиотек, принципами их организации, подходами и т.д. И тут я ещё раз хочу подчеркнуть мысль Jcxz. Как правило, драйвера, составляют от 1 до 10% объёма от реального проекта. Пишутся и вылизываются довольно быстро. Поэтому преимуществ их использования я не вижу. Вот Вы уже поработали с AVR и теперь на STM перешли. Где гарантия что завтра MSP не будет? Или NXP?
 

Но в целом, я претензий к ST не вижу. Порой можно "подсмотреть" их библиотеку. Порой можно воспользоваться их плюшками (например CubeMX).
Короче ребятам респект. 

[rkit 1]

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

[pyroman 2]

Мне Cube удобно использовать при изучении неосвоенной ещё мною периферии STM32. Когда собираешь макетку с необходимой обвязкой, создаешь кубом готовый проект и можно проверить, что макет собран правильно и работает, как нужно.
После я постепенно ухожу от куба и пишу свой код. Где непонятно, смотрю порядок действий и состояние регистров периферии, настроенной кубом, сравниваю со своим кодом. Так освоил Ethernet и USB.

Изменено 5 мая, 2020 пользователем piroman