STM32 новичку в ARM что к чему

[dosikus]

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

http://mcu.goodboard.ru/viewtopic.php?id=31

[jcxz]

[uquote="Oxford",url="/forum/viewtopic.php?p=3457482#p3457482"]Потому что это не влияет на производительность, не об этом вам думать надо. Читаемость кода в варианте Досикуса лучше.
Конфигурация DMA это разовая операция. Переведите свой фокус на другое.[/uquote]
И чем хуже читаемость: CCR = 1 << bit0 | 1 << bit1 | ...;
по сравнению с: CCR |= 1 << bit0; CCR |= 1 << bit1; ...
??
В читаемости нет никакой разницы.
А вот человек, сделавший так в одном месте и во всех остальных лепит то же самое. Даже не обращая внимание, что в регистре могут быть write-only-поля битов. Видел это многократно.

Добавлено after 1 minute 53 seconds:
[uquote="Мурик",url="/forum/viewtopic.php?p=3457473#p3457473"]Было бы лучше написать таким образом этот пример.[/uquote]
Я вообще-то писал что операция |= там совсем не нужна. Зачем все начинающие лепят это |= когда нужна только запись???

Добавлено after 2 minutes 54 seconds:
[uquote="dosikus",url="/forum/viewtopic.php?p=3457484#p3457484"]Да и господа, дело то не в стиле , самое главное так никто и не понял.[/uquote]
Так разъясните

[VladislavS]

[uquote="jcxz",url="/forum/viewtopic.php?p=3457489#p3457489"]Зачем все начинающие лепят это |= когда нужна только запись???[/uquote]Да если бы только начинающие, у сепербизонов это тоже сплошь и рядом.

[dosikus]

jcxz, ко мне лучше на ты.
И так ты прицепился к записи, а то что вопрошающий даже не вник, что инит DMA и таймера напрямую , и проще и универсальней , пролетело мимо тебя .
Давайте еще здесь устроим срач, на потеху ARV.
Он уже прямо кипит, поднотавливая опус как все грызутся из-мелочей так и неудосужевшись помочь...

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3457524#p3457524"]И так ты прицепился к записи, а то что вопрошающий даже не вник, что инит DMA и таймера напрямую , и проще и универсальней , пролетело мимо тебя.[/uquote]
Без калокуба? А что тут обсуждать? Это же очевидная вещь.
Калокубокодеру никогда не стать программистом. Да и вообще - не создать ничего стоящего. Сможет только чужие решения тырить и кое-как костылить.

[a5021]

На сайте апача есть проект "mynewt" -- типа операционной системы для интернета вещей. Помимо прочего, поддерживаются и STM32. Пилящие поддержку STM32 используют CubeMX. Та же фигня с микропитоном. Оба проекта не имеют аналогов и как-то с натугой верится, что их девелоперам "никогда не стать программистами".

[AndTer]

[uquote="jcxz",url="/forum/viewtopic.php?p=3457561#p3457561"]Калокубокодеру никогда не стать программистом. Да и вообще - не создать ничего стоящего. Сможет только чужие решения тырить и кое-как костылить.[/uquote]
Нашли друг друга... кубохейтеры... Если не хватает умений использовать достижения во благо, это скорей ваш недостаток.
И интересно, что ТЫ ЛИЧНО создал стоящего? Расскажи! Очень интересно послушать!
Или ты часть стада, которое только и повторяет за своим хозяином "калокуб" "не программист" "тырить костылить"... А сам на деле пшик? Право смешно!

[a5021]

[uquote="Oxford",url="/forum/viewtopic.php?p=3457482#p3457482"]Конфигурация DMA это разовая операция.[/uquote]
Точно. Один раз записал вот так и теперь просто копирую.

Код: Выделить всё

  DMA1_Channel3->CCR = (
    1 * DMA_CCR_EN        | // Channel enable
    1 * DMA_CCR_TCIE      | // Transfer complete interrupt enable
    0 * DMA_CCR_HTIE      | // Half Transfer interrupt enable
    1 * DMA_CCR_TEIE      | // Transfer error interrupt enable
    0 * DMA_CCR_DIR       | // Data transfer direction
    0 * DMA_CCR_CIRC      | // Circular mode
    0 * DMA_CCR_PINC      | // Peripheral increment mode
    1 * DMA_CCR_MINC      | // Memory increment mode
    // PSIZE[1:0] bits (Peripheral size)
    //    00: 8-bits
    //    01: 16-bits
    //    10: 32-bits
    //    11: Reserved
    0 * DMA_CCR_PSIZE_1   | // Bit 1
    0 * DMA_CCR_PSIZE_0   | // Bit 0
    // MSIZE[1:0] bits (Memory size)
    //    00: 8-bits
    //    01: 16-bits
    //    10: 32-bits
    //    11: Reserved
    0 * DMA_CCR_MSIZE_0   | // Bit 0
    0 * DMA_CCR_MSIZE_1   | // Bit 1
    // PL[1:0] bits(Channel Priority level)
    //    00: Low
    //    01: Medium
    //    10: High
    //    11: Very high
    0 * DMA_CCR_PL_0      | // Bit 0
    1 * DMA_CCR_PL_1      | // Bit 1
    0 * DMA_CCR_MEM2MEM     // Memory to memory mode
  );

[dosikus]

[uquote="AndTer",url="/forum/viewtopic.php?p=3457665#p3457665"]И интересно, что ТЫ ЛИЧНО создал стоящего? Расскажи! Очень интересно послушать![/uquote]


Сказано так будто это ты родитель калокуба, продолжай не стесняйся ...

[AndTer]

[uquote="dosikus",url="/forum/viewtopic.php?p=3457740#p3457740"]...[/uquote]

Я задавал вопрос не тебе, но ответ хороший = ничего не сделали своего, только критикуют!
А с кубом делают многие и делают реальные вещи. Если вам он не нравится, если не хвататет знаний и умений его освоить и использовать во благо, то просто проходите мимо.

Куб снижает уровень вхождения в стм32, если его использовать для первоначальной настройки и инициализации, это не сильно вредит коду.
Далее человек научившись мигать светодиодом с его помощью(и не только мигать, ибо большинство радиогубительских задач не требуют глубоких познаний МК, даже если речь идёт о коммерческих устройствах, а первое устройство с помощью куба можно собрать с нуля, перейдя с авр например, буквально за один день), при необходимости, при потребности, начнёт читать документацию и изучать МК глубже.

И да, досикус, ты так не ответил на вопрос, когда у тебя стала карма -2 (кстати за хамское отношение к людям использующим куб в том числе), внезапно, на следующий день она стала +14. У тебя за ночь пропали АБСОЛЮТНО все минусы. Как так получилось то? Что за волшебство?

[jcxz]

[uquote="AndTer",url="/forum/viewtopic.php?p=3457665#p3457665"]И интересно, что ТЫ ЛИЧНО создал стоящего? Расскажи! Очень интересно послушать![/uquote]
Боюсь, что представитель стада калокубокодеров не сможет даже строчки понять.
[uquote="AndTer",url="/forum/viewtopic.php?p=3457665#p3457665"]Или ты часть стада, которое только и повторяет за своим хозяином "калокуб" "не программист" "тырить костылить"... А сам на деле пшик? Право смешно![/uquote]
Есть мудрая поговорка: "Не мечите бисер перед ...". Я последую ей....

Добавлено after 10 minutes 11 seconds:
[uquote="AndTer",url="/forum/viewtopic.php?p=3457768#p3457768"]Куб снижает уровень вхождения в стм32, если его использовать для первоначальной настройки и инициализации, это не сильно вредит коду.[/uquote]
Согласен с этим - снижает уровень требований к умственным способностям юзера. И там и оставляет их на том же уровне.

[uquote="AndTer",url="/forum/viewtopic.php?p=3457768#p3457768"]А с кубом делают многие и делают реальные вещи.[/uquote]
Конечно! Реальную моргалку лампочками.
Если посмотреть по форумам, то все они наполнены стонами калокодеров о том, что "вот нашёл такой код в нете и вставил сюда, но почему-то не работает. Помогите! месяц уже SPI/I2C/... не могу запустить...". И все такие сообщения касаются самых примитивных вещей как правило.
А вот от тех, кто читает доки и по ним делает, от тех почти нет таких примитивных вопросов. Вопросов от них гораздо меньше и по более серьёзным темам.

[uquote="AndTer",url="/forum/viewtopic.php?p=3457768#p3457768"]Далее человек научившись мигать светодиодом с его помощью, при необходимости, при потребности, начнёт читать документацию и изучать МК глубже.[/uquote]
....это в розовых фантазиях. А на практике: пытается костылить калокуб-говнокод (или искать в нете такие же потуги других калокодеров), даже не задумываясь открыть доку, так как приучен уже кубом не напрягать извилины.
Подтверждений этому - масса в разных форумах. Да собственно эта тема - тоже яркий пример тому.

[VladislavS]

Интересно, как люди программировали(ют) микроконтроллеры на которые никаких кубов не было, нет и не будет? В лучшем случае файл с дефайнами периферии.

[ARV]

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

[dosikus]

[uquote="ARV",url="/forum/viewtopic.php?p=3457783#p3457783"]рискну высказать своё мнение: на системах с явным избытком ресурсов нет никакого смысла заниматься ловлей блох в виде изучения всяких там битов[/uquote]

Это однобокий взгляд адепта софтового ногодрыга.
И вотЪ когда ты осознаешь что PC не МК , может быть тогда толк с тебя и выйдет..

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3457783#p3457783"]так и на МК, похоже, это грядет. и производители это отлично понимают, создавая всякие Кубы и т.п. слои абстракций в виде библиотек, максимально абстрагированных от аппаратуры. очевидно, что вскоре вся аппаратура в МК с общирными ресурсами будет упрятана в драйвера по принципу IOCTL[/uquote]
Вы не поверите - это давно уже есть в линух-системах. Уже много лет. А теперь вспомним и подумаем: чего такого ответственного с реалтайм управлением делается на таких системах? Именно на них, без дополнительного безлинухового МК (прослойки между линух-МК и железом)? И увидим что - практически ничего. Как только возникает необходимость сделать что-то нестандартное по работе с внешними сигналами, не заложенное сразу писателями драйверов для них (или реализованное криво), так почему-то мощные гигагерцовые CPU под линухами с кучей API перестают с этим справляться. И нужен простенький Cortex-M хотя бы на несколько десятков МГц.

И когда появятся "МК с общирными ресурсами", то эти их ресурсы тут же будут полностью вычерпаны очередным калокубом на конфигурирование пинов и мигание несколькими лампочками. Сейчас аналогичное можно наблюдать на ПК: есть у меня проект под Visual Studio - компилю его на VS2005 - размер exe-шника около 800КБ, компилю тот же самый проект на VS2017 - размер уже более 8МБ! Хотя в исходнике ни байта не изменилось....

[Oxford]

[uquote="ARV",url="/forum/viewtopic.php?p=3457783#p3457783"]рискну высказать своё мнение: на системах с явным избытком ресурсов нет никакого смысла заниматься ловлей блох в виде изучения всяких там битов и т.п. как на PC прошла эпоха программирования на ассемблере, так и на МК, похоже, это грядет. и производители это отлично понимают, создавая всякие Кубы и т.п. слои абстракций в виде библиотек, максимально абстрагированных от аппаратуры. очевидно, что вскоре вся аппаратура в МК с общирными ресурсами будет упрятана в драйвера по принципу IOCTL - открыл и пиши/читай, потом закрыл и радуйся, а как там оно внутре устроено, никого интересовать не будет. необходимость изучения периферии по даташитам пока имеет актуальность только из-за отсутствия достаточно абстрагированной модели взаимодействия с нею, но это не надолго.[/uquote]

Бредятина. Что курнули? На PC программируете, зачем вам в embedded лезть, ведь не понимаете в этом ничего.

[AndTer]

[uquote="ARV",url="/forum/viewtopic.php?p=3457783#p3457783"]рискну[/uquote]
Абсолютно с этим согласен.
Они и под винду на ассемблере пишут! До сих пор...
А что? Нет?
Как так нет?
Калосиплюсплюс используете? А критикуете куб?
Быстро на ассемблер перешли!

Добавлено after 3 minutes 13 seconds:
[uquote="dosikus",url="/forum/viewtopic.php?p=3457788#p3457788"]И вотЪ когда ты осознаешь что PC не МК[/uquote]
Двадцать лет назад PC были слабее нынешних стм32.
Через 20 лет МК будут ещё производительней. И ты будешь тратить годы на изучение регистров только одного семейства!
Когда другие будут пользовать и кубы и либы:
[uquote="ARV",url="/forum/viewtopic.php?p=3457783#p3457783"]вскоре вся аппаратура в МК с общирными ресурсами будет упрятана в драйвера по принципу IOCTL - открыл и пиши/читай, потом закрыл и радуйся, а как там оно внутре устроено, никого интересовать не будет. необходимость изучения периферии по даташитам пока имеет актуальность только из-за отсутствия достаточно абстрагированной модели взаимодействия с нею, но это не надолго.[/uquote]

[ARV]

Бредятина или нет, покажет время.
Я просто приведу несколько примеров из жизни, показывающих, как развивались системы.
Автомобиль. Сначала - удел избранных "механиков", подумать, что можно управлять автомобилем, не понимая, откуда там искра и зачем, никто не смел. Сейчас автомобиль стал утилитарным средством передвижения, им управляют даже те, кто не знает, зачем туда заливать бензин. Вся техника скрыта за слоем автоматики и профессиональным сервисом.
Компьютер. Сначала - удел избранных программистов. Сказать, что каждая кухарка может управляться компьютером, могли только фантасты. Сейчас чуть ли не любая игрушка для ребенка 5 лет содержит в себе компьютер, помощнее того, которым управлялся Апполон. При этом настольные компьютеры благодаря ОС стали настолько дружеблюдными, что с ними работать можно, не отличая бит от килограмма. Все проблемы скрыты в ОС и ПО, как там на самом деле все работает, где там южный мост и между какими берегами он, знать не нужно.
То есть повсеместно происходит отдаление "железных" проблем от конечного потребителя. Небольшой круг профессионалов, которые понимают, какие фронты на какие триггеры воздействуют, сохраняется, как круг автомехаников и программистов, но конечному потребителю эти круги настолько неинтересны и далеки, насколько хорошо они со своими обязанностями справляются.
И эту тенденцию понимают даже сами автомеханики: вчера от них требовалось умение отличать правую резьбу от левой, а сейчас - умение при помощи софта определить неисправную запчасть и при помощи интернета заказать её у поставщика. Эту тенденцию понимают и разработчики ПО: вчера от них требовалось уложиться в имеющиеся килобайты и на имеющихся мегагерцах решить за разумное ремя задачу, а сегодня от них требуется создать софт, который имеет одну кнопку посреди экрана "сделай по моему хотению". Сейчас современный софт может поставить в тупик любого "старичка", который еще помнит, как надо настраивать сеть в Windows 3.11, потому что 99% проблем настроек закопаны так глубоко (потому что никому не нужны), что без google их и найти проблематично.

При этом всем ни автомобили, ни самолеты, ни компьютеры не стали проще - они стали неимоверно сложнее! И если бы не было этих самых ОС, автоматики и т.п. "слоя абстракции", ни один самый гениальнй программист, ни один самый гениавльный автомеханик не смог бы в разумное время что-то сделать с ними. Вы представьте себе ситуацию, когда для подключения к сети вам надо вспомнить о том, что на материнке есть сетевой контроллер, у которого есть какие-то регистры управления, которые надо как-то инициализировать... ну понятно, что в этом случае разработка стала бы просто непомерно сложной.

Очевидно, что микроконтроллеры уже давно не такие уж "микро". И чем сложнее они становятся, тем ближе ситуация с ними к вышеописанной. Сегодня еще можно в разумное врем что-то разработать на паре похожих МК, но по мере того, как сложность даже похожих МК станет еще больше, работать сними без слоя абстракции станет невозможно. Понятное дело, все эти абстракции будут мешать "быстро мигать", но так компенсировать это будут не требованием лучше изучать периферию, а ростом тактовой частоты - экстенсивным способом. Раньше меандр частотой в 1 МГц генерировался только ассемблерным циклом, завтра он будет генерироваться скриптом на питоне из 100 строк - и кому будет интересно, что там миллиарды операций выполняются между каждыми фронтами сигнала? главное - задача решена в указанные сроки, и нужное быстродействие обеспечено.

и так будет обязательно. уже сегодня никому не интересны какие-то промышленные контроллеры с какими-то проприетарными системами - подавай унифицированные варианты линуха или там чего-то аналогичного, лишь бы подальше от битов и байтов! и как бы местные профессионалы не называли это бредом, так будет. как только им руководство поставит задачу перестать копаться в битах и байтах - больших сторонников Кубов и Параллелепипедов вы не найдете. Это пока у них вольница, а жизнь яйца прищимет - будут как миленькие выдавать на-гора по 100500 приложений, в которых лишь 10% кода будет набрано ручками, а остальное будет натыкиваться мышкой...

Индусы тоже не стоят (или не сидят) на месте: сегодня их "кубы" создают не красивый код, а завтра будет красивый. или завтра просто никому станет не интересно, красивый он или нет - лишь бы работал. и что тогда можно будет возразить?

будущее - оно такое. и айфон тому яркий пример

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3457820#p3457820"]как только им руководство поставит задачу перестать копаться в битах и байтах - больших сторонников Кубов и Параллелепипедов вы не найдете. Это пока у них вольница, а жизнь яйца прищимет - будут как миленькие выдавать на-гора по 100500 приложений, в которых лишь 10% кода будет набрано ручками, а остальное будет натыкиваться мышкой[/uquote]
Да ладно!! А Вы когда-нить занимались разработкой профессионально? работали в конторах по разработке на МК? Сразу видно, что - нет и никогда. И всё написанное - высосали из пальца. Нигде, где я работал и работаю (в десятках проектов), никаких калокубов не использовали и не используют. В профессиональных коммерческих проектах. Калокубы и абдурины - это удел любителей-чайников, а их использование - яркий признак непрофессионализма.
И уж такого быдлокода я повидал немало на куче собеседований когда к нам на вакансии приходили соискатели и в куче присланных с резюме примерах кода.
На многое из таких примеров даже смотреть противно.

PS: Писать серьёзный код на левых либах и кубах, это как если устройство, предназначенное для работы в ответственной области в режиме 24/7 в промышленном диапазоне температур, собирать на модулях для абдурины с алиэкспресса.

[Oxford]

Через 20 лет МК будут ещё производительней. И ты будешь тратить годы на изучение регистров только одного семейства!

У тебя что цель в жизни изучить все семейства STM32?