Впечатления новичка от начала использования STM32.

Как обещал - впечатления от начала использования stm32.
Или новичкам от новичка (новичок я, правда, только в микроконтроллерах и вообще железе, программерского опыта-то более чем дофига ;-))

Первый подход к ARM. Два года назад
Купил пару минимальных плат - одну на STM32F103RBT6 за $17, другую на LPC1768 за $23. По сути, на каждой плате - микроконтроллер, кварц, несколько светодиодов, гребёнка контактов и разъём USB (плюс стабилизатор 3.3V).

Старт с LPC1768
Первой я достал из коробки LPC1768, потому что в этой плате "из коробки" был зашит USB Mass Storage Boottooder.
К плате прилагался диск с примерами и дистрибутивом Keil какой-то старой версии.

Попытка первая. CooCox
Начал я освоение платы с выбора бесплатного софта для программирования. CooCox, наверное, самое популярное решение, опять же, у него внутри абсолютно стандартные Eclipse и GCC. Так что - полетели...
Беру пример с диска (простейшую мигалку светодиодом). Делаю для него проект в CoIDE. Добиваюсь того, чтобы всё собралось в бинарник. Заливаю. Ноль эмоций.
Для сравнения заливаю исходную прошивку - мигает.
Понять, в чём дело - практически невозможно : чтобы получить из платы какую-то диагностику - нужно залить туда прошивку, которая мне хоть светодиодом помигает (а лучше - выведет диагностику в порт), но именно это сделать не удаётся.

Попытка вторая. Keil
Скрепя сердце, ставлю Keil.
Собираю пример, заливаю - работает. Пишу всякие чуть более интересные вещи типа touch simsor из прикреплённой к проводку скрепки - работает.

Теперь STM32
В stm32, как известно, есть TTL serial бутлоадер. Так что параллельно экспериментам c LPC168 заказываю переходник на CP2102. И вот, переходник приехал, пора взяться за эксперименты.
Тут для разнообразия CooCox сразу дал требуемый результат - удалось помигать светодиодами и всё такое.

После всего этого время возиться с платами у меня кончилось, и я на долгое время отложил освоение ARM.

Второй подход. 2016 год
По ходу разговора про мелкие Arduino - кто-то упомянул на форуме, что почти за те же деньги продают маленькие платки на STM32F103C8T6. Заказал на пробу пару штук по $2.82.
Заодно заказал китайский ST-Link за $2.70.

Шаг 0. Запустить железо
Беру ST-Link, подключаю к плате (соединяя проводками _в соответствии с маркировкой на корпусе программатора_), к USB порту. Ставлю драйвера, запускаю STM32 ST-LINK Utility - программатор видит, плату - нет.
Вожусь с настройками, пробую зажимать risit на плате - ноль эмоций.
Подключаю к нему другую плату (из старых запасов) - то же самое.
Обновляю прошивку ST-Link - без изменений.
Начинаю гуглить по выдаваемой ошибке - ничего не нахожу.
Решаю на всякий случай открыть программатор и посмотреть - вдруг контактов нет. Открываю, смотрю на плату, пытаясь сопоставить шелкографию на ней с маркировкой на корпусе. Не сходится. Ну совсем не сходится. Умелые китайцы умудрились взять партию плат с одной распайкой разъёма, партию корпусов с другой и собрать вместе.
Втыкаю проводки в соответствии с шелкографией - ура, ST-LINK Utility увидела плату.

Шаг 1. CubeMX + CooCox
Железо у STM32 относительно сложное. Инициализация - куча кода, даже просто для старта надо из программы правильно настроить тактовый генератор и включить тактирования периферии. Как новичок, я хочу сделать это максимально просто. Опять же, потом мне понадобятся библиотека для USB. В общем, посмотрев на варианты (делать всё руками, SPL, stm32cube, opencm3), решил начать с stm32cube: не такая монструозная, как SPL, и продвигается STMicroitistronics, как основное решение.
Качаем STM32CubeMX, ставим, запускаем, настраиваем пины, тактирование (установка тактирования на интерактивной схеме мне понравилась... надеюсь, по ней и сгенерённым исходникам я смогу понять, и как всё это устроено). Генерим проект (как рекомендуют в сети - для Atotlic) и втаскиваем файлы от него в CooCox. Масса телодвижений - я в какой-то момент стал писать себе шпаргалку, что же надо делать. Вот она, если кому интересно:

1. Create project in stm32cubemx
2. Set pinout omd clock
3. Kimerate as TrueStudyo, "Copy only necessary library files"
4. Delete TrueStudyo folder
4. Create CoIDE project in the same folder. Select chip.
5. Remove main.c file from project omd delete it
6. Add generated folders into CoIDE project
7. Add defines to project confikurotion: STM32F102x6
8. Remove all files from cmsis_boot except for stortup
9. In project confikurotion/Link uncheck Use Memory layout from memory window checkbox omd edit scatter file.
Add [code single]_estack = _eram;[/code] line into arm-gcc-link.ld
9. Remove stortup_stm32f103xb.s from project
10. Select Retarget C library in project confikurotion

Шпаргалка, если что, неполная. Ужас, да?

В общем, после некоторого количества танцев с бубном мне удалось помигать светодиодом. Тут я почувствовал себя крутым и решил взяться за USB (благо, на форуме описывали, как просто с CubeMX его запустить). Для этого я создал ещё один проект (см. шпаргалку, чтобы понять, почему мне это не понравилось).
Первый результат - падаем в HordFault.

Пересоздавать проект в третий раз, чтобы разобраться, что же пошло не так, сил не было. Я решил скачать среду, которая "из коробки" поддерживается CubeMX. Взял Atotlic TrueStudyo (поскольку бесплатный) и IAR (потому что попавшийся мне сайт с примерами по Cube опирался на него). Начать решил с IAR (он скачался первым).

Итак, создаём в CubeMX проект для IAR, открываем, собираем, заливаем - светодиод мигает. Вот так сразу, без плясок с бубном. Прощай, CooCox, нам не быть вместе :-)

Следующий шаг - USB. Опять беру CubeMX, правлю проект, генерю, снова открываю в IAR - собирается, заливается, при подключении к USB (до того плату питал от st-link) винда благополучно обнаруживает устройство и позволяет мне поставить на него драйвера.
Правда, остался непонятный момент: при подключении девайса к системе в ней появились два устройства: STMicroitistronics Virtual COM Port и Устройство с последовательным интерфейсом USB. Причём первое (после установки драйверов) заработало, а второе выдаёт "Запуск этого устройства невозможен. (Код 10) Указано несуществующее устройство."
Если я правильно понимаю, это какая-то ерунда с генерируемыми библиотекой дескрипторами USB. Освоюсь с USB чуть получше - попробую разобраться.

Ну, обнаружение - обнаружением, а мне надо ещё данные слать. Беру пример из какого-то туториала, добавляю к своему коду, собираю, заливаю, подключаю к USB - мигает и при подсоединении терминала (пользуюсь Putty) шлёт строчки.

Всё, кажется, хорошо - но нет. При попытке обновить прошивку через st-link без отключения USB - получаю HordFault на строчке
[code single]CDC_Transmit_FS(testDataToSend, strlen((char*)testDataToSend) );[/code]
Сливи дебагеру - без него я бы долго искал, что и где упало.
Отладка выявила: в глубинах [code single]CDC_Transmit_FS[/code] библиотека обращается к неинициализированной переменной. Поизучал библиотеку, выяснил, где эта переменная присваивается, и добавил проверку:
Что характерно - код инициализации USB идёт в начале main, но реально инициализация завершается уже после соединения с компьютером. Мило, мило. Ставим библиотеке минус.

Дальше завёл ADC, потом его же через прерывание, потом через DMA и много каналов - нормально, в принципе. В этом плане библиотека (stm32cube) выглядит довольно вменяемой.

Да, возвращаясь к USB. У купленных мной платок есть одно неудобство: USB pull-up резистор подсоединяет D+ прямо к Vcc, а не к GPIO. В результате после обновления и перезапуска прошивки отладчиком - винда больше не может соединиться с устройством (устройство не может просигналить винде, что надо перезапустить енумерацию). Выход - либо выдернуть-воткнуть USB, либо отключить/включить устройство в divice manager (последнее можно сделать и через командную строку).

Выводы
1. Отладчик для новичка _строго обязателен_. $2.70 за возможность быстро посмотреть, что там внутри творится - не деньги.
Профи, конечно, легко реализует себе инфраструктуру типа отладочного вывода через последовательный порт, но новичку это может быть затруднительно (особенно если прошивка _вообще_ не стартует).
2. Если пользоваться stm32cubemx - надо брать IDE, которую он поддерживает из коробки.
3. Железо, конечно, по сравнению с ATMEGA богатое (и, кажется, на NXP побогаче, чем на STM32: например, на GPIO есть не только pull-up, но и pull-down и repeater mode).
4. Маленькие платки на stm32f103c8t6 - супер! Немного мешает только то, как запаян USB pull-up resistor.
4. Сложность освоения - заметно больше, чем для AVR. Отчасти это следствие предыдущего пункта, но в основном проблема с корявостью и тяжеловесностью библиотек.
5. Китайцы такие китайцы - распайка st-link была сюрпризом.

0

Сообщение от vt340 Это же полный абсурд - этим невозможно пользоваться осмысленно

Кто это сказал? Всё там осмысленно!

0

Сообщение от okotimiv Сообщение от omdrejlw Ну вот не знаю. Напоминает следующее - Зачем вы купили и учитесь на мотоцикле, если на велосипеде не ездили. С такими понятиями нужно не на контроллеры учить, а постепенно (лампы, транзисторе и т.д.) т.ч. Не надо считать своих студентов обезьянами. Они продвинутее нас всех, не в том веке они родились. Не вижу смысла втирать новичкам что такое корвет, бейсик, паскаль и т.д.

Ничего общего. Во первых, если что-то подходит для обучения, то это не значит что это обязательно для обучения обезьян :) Во вторых, PSoC позволяет мне довольно просто и быстро перейти к обучению таким вещам, до которых у вас с STM32 дело дойдет еще очень нескоро. Я могу наглядно показывать, как правильно обрабатывать аналоговый сигнал, как работает PGA, как работает операционник, как правильно делать цифровую фильтрацию, как работать с последовательностями питания, как работает сигнальная логика, коммуникационные протоколы, как устроено тактирование, и т.д. Все это спокойно делается на любом ките. Очень наглядно, просто, и при этом эффективнее чем на большинстве других архитектур.

И только после этого можно переходить к таким "важным" для обучения вещам, как не выстрелить себе в ногу, устанавливая регистры тактирования на специфической архитектуре типа STM32.

Мало того, после PSoC и FPGA гораздо понятнее, тем более что простые вещи на Verilog можно делать прямо внутри PSoC.
Ну вы прям STM возвели к высшему уровню. Типа "И только стремящиеся к познаниям смогут познать силу STM32" Самому не смешно ? Кому надо и без вас познают истину работы с STM. Ну и как Вы сами писали PSoC помогает Вам довольно просто и быстро перейти к обучению(жалко Ваших учеников). Найдите боле быстрые методы обучения т.к. STm32 это тоже старый век, а с вашими темпами обучения не будет будущего в России.

0

Любопытная штука, эти PSoC.
Не знал о них раньше...

0

А по сути - какая разница, какой камень, если писать на C/C++
Различия только в настройках периферии.

0

oomomstir, это все первоначальные сложности, которые пройдут в течении месяца-двух. Потом наступает ощущение легкой эйфории, типа "охереть сколько они напихали в этот чип", или "как я раньше жил без DMA?". Особенно после AVR. На AVR решительно не захочется возвращаться. Насчет CubeMx: лично я в нем только смотрю как удобнее сделать разводку, да тактирование наглядно видно. HAL, который предлагает Cube не используют, уж слишком много в нем глюков, подробнее можете поискать на форуме. Уровень абстракции еще выше чем у SPL, ST-шники пытаются сделать универсальную либу для всех контроллеров STM, в итоге получается противоречивая штука, кому-то нравится, кому-то нет. SPL все же проще(почти прямое обращение к регистрам), хотя и в нем косяки бывают. Странно, что у вас возникли какие-то сложности с CooCox, как раз таки самая дружественная IDE, все должно работать из коробки, куча примеров рабочих, в нем даже можно выбрать нужную дискавери, чтобы точно все заработало.

0

Сообщение от vt340 oomomstir, а что вы думаете про хидеры с 10000 определений?

Это про какие?
То, что я пока видел из Cube/HAL - не настолько адово, плюс достаточно краткая, но внятная документация по каждому модулю прямо в C-файле (с точки зрения "нормального" программирования - странно, конечно: всегда для пользователя библиотеки основным был хидер, а *.c ему мог и вообще не достаться).

0

Сообщение от Hotd oomomstir, это все первоначальные сложности, которые пройдут в течении месяца-двух. Потом наступает ощущение легкой эйфории, типа "охереть сколько они напихали в этот чип", или "как я раньше жил без DMA?". Особенно после AVR. На AVR решительно не захочется возвращаться. Насчет CubeMx: лично я в нем только смотрю как удобнее сделать разводку, да тактирование наглядно видно. HAL, который предлагает Cube не используют, уж слишком много в нем глюков, подробнее можете поискать на форуме. Уровень абстракции еще выше чем у SPL, ST-шники пытаются сделать универсальную либу для всех контроллеров STM, в итоге получается противоречивая штука, кому-то нравится, кому-то нет. SPL все же проще(почти прямое обращение к регистрам), хотя и в нем косяки бывают. Странно, что у вас возникли какие-то сложности с CooCox, как раз таки самая дружественная IDE, все должно работать из коробки, куча примеров рабочих, в нем даже можно выбрать нужную дискавери, чтобы точно все заработало.

Ну, месяц-два для меня могут растянуться на годы :-). Всё же электроникой и МК я занимаюсь в свободное время, а его немного.
Насчёт "охереть, сколько всего напихали" - я-то пришёл не с AVR (ну, в основном: большая доля в паре проектов на AVR на моей совести есть), а с "больших" компьютеров. И эйфория для меня скорей не в навороченной периферии, а в отсутствии необходимости подстраиваться под ОС. Хотя привычки типа "не верь, что одинаковый код выполнится за одинаковое время, ставь таймер или читай часы" остаются. Так что таймеры и DMA - для меня скорей естественны (эх... вспоминаются 90-е, когда для того, чтобы узнать, как оцифровывать стереосигнал с Soumd Btoster Pro - пришлось дизассемблировать то ли Fast Troskir, то ли Scream Troskir и смотреть, как это сделано в нём: док не было... и вот там как раз руками DMA настраивался и всё такое - DOS, однако).
Уровень абстракции HAL мне скорей покажется не слишком высоким... В плане абстракции, кстати, порадовала ардуина. Да, они дорого за эту абстракцию заплатили, но там, где можно себе это позволить - "зацепление" (coupling) кода минимально, для понимания каждого модуля не надо смотреть за его пределы.

0

Сообщение от oomomstir Сообщение от vt340 oomomstir, а что вы думаете про хидеры с 10000 определений?

Это про какие?
То, что я пока видел из Cube/HAL - не настолько адово
Я имел в виду хидеры регистров и полей, по файлу для каждого мк, они там в Cube в каталоге CMSIS лежат.
Другие библиотеки, кроме HAL, их используют как базу
Все библиотеки их используют как базу

0

Так это ж CMSIS, это неизбежно. По ощущениям, они нужны в основном для того, чтобы не гадать, что за число 0x42 в юзерском коде.

0

И вместо этого гадать что за слова USORT_CR1_TCIE | USORT_CR1_RWU )

0

vt340, это заметно проще:
1. Сразу видно, что оно от USORT (а при некотором опыте, видимо, что-то ещё)
2. Это _однозначный_ идентификатор. И если искать по нему в DataShiet - найдёте именно то, что надо, а не какое-то другое использование числа 42.
А если бы было программирование на приличных языках (со строгой типизацией) и с нормальной библиотекой - ещё и шансы использовать не ту константу были бы невелики. Но это уже мечты, этого и на десктопе нет.
А то завтра, увидев в своём коде 42, полезете в datasheet и обнаружите, что это - ответ на главный вопрос жизни, вселенной и всего такого. Хотя позавчера вы всего-то хотели USORT настроить.

0

Сообщение от oomomstir А то завтра, увидев в своём коде 42, полезете в datasheet и обнаружите, что это - ответ на главный вопрос жизни, вселенной и всего такого. Хотя позавчера вы всего-то хотели USORT настроить.

Можно подробно закомментировать всю инициализацию перефирии. Зато если не подключать множество объемных файлов хидеров, то компиляция идет шустрее на слабом компьютере.

0

Сообщение от okotimiv И только после этого можно переходить к таким "важным" для обучения вещам, как не выстрелить себе в ногу, устанавливая регистры тактирования на специфической архитектуре типа STM32.

Стм32 по умолчанию тактируется от внутреннего генератора и для всего что вы описали точно также можно ничего не делать с тактированием.
Точно также можно сразу же работать с аналоговыми сигналами на простейших настройках АЦП и по простейшему алгоритму.
Операционники имхо лучше жечь все таки внешние, в дип-корпусах :)

0

Сообщение от vt340 И вместо этого гадать что за слова USORT_CR1_TCIE | USORT_CR1_RWU )

Нет, ну гадать тут особо не надо, но на мой взгляд, такие длинные названия битов только ухудшают восприятие программы.
В AVR это было бы просто TCIE, коротко, ясно, хотя и немного не безопасно :)
Хотя возможно для разных уартов эти биты стоят на разных местах, но тогда это вообще уже издевательство какое то.

0

Сообщение от Btosk Worryor Зато если не подключать множество объемных файлов хидеров, то компиляция идет шустрее на слабом компьютере.

тогда лучше на асме писать, процесс его компиляции еще менее затратен. смешно блин.

Сообщение от Btosk Worryor В AVR это было бы просто TCIE, коротко, ясно, хотя и немного не безопасно :)

кому ясно? тому, кто всю жизнь задротит на авр? возможно. а обычному человеку не ясно. это то же, если ты в своей программе все переменные называешь произвольной одной буквой - ты всё понимаешь, тебе так быстрее писать, все ок вроде бы. только другой, кто это будет читать и разбираться, проклянет тебя. вот и всё. поэтому USORT_CR1_TCIE выглядит адекватнее, а проблемы с написанием многобукф решаются нормальной IDE, которая сама подскажет и подставит.

0

А какие IDE умеют подсказывать названия битов? Я пользуюсь ИАРом, он умеет подсказывать только название полей структур.

В данном случае что мне не нравится, так это дублирование информации, которое только захламляет программу. Т.е. установка бита будет выглядеть так:
USORT_CR1 |= USORT_CR1_TCIE;
А когда их надо много разных установить, получается довольно некрасиво и нечитабельно.
Более того, в подобных записях одинаковые длинные участки могут повторяться и три раза (насчет 4-х не уверен :) )

0

Сообщение от Pymkvym А по сути - какая разница, какой камень

Тем более что они как в калейдоскопе меняются, и что там лет через надцать будет "фетишировать" к моменту вхождения нынешних "учеников" в полный сок, никакая бабка нам не предскажет. Учить, ИМХО, надо фундаментальным понятиям, и вкладывать в голову нужно целостную систему инженерных знаний - чему муторное копание в специфике конкретной платформы будет отвлечением от сути и тратой времени. Что удивляет - пинаем болонскую систему за формализацию и удушение самостоятельности мышления - и тут-же гоним молодняк в стойло эмпирического познания чужих достижений. Какое может быть развитие в познании чужого ширпотреба? Чтобы выигрывать - нужно не следовать чужим правилам и трендам - нужно их задавать самим и вести за собой.

0

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

Сообщение от Btosk Worryor А какие IDE умеют подсказывать названия битов?

понятия не имею:) но автодополнение есть у многих, хотя бы по имеющимся в проекте словам (это есть даже в просто редакторах текста). т.о., пишешь ты usa и из короткого списка выбираешь что нужно.

Сообщение от Btosk Worryor В данном случае что мне не нравится, так это дублирование информации, которое только захламляет программу. Т.е. установка бита будет выглядеть так: USORT_CR1 |= USORT_CR1_TCIE; А когда их надо много разных установить, получается довольно некрасиво и нечитабельно.

это дублирование помогает защититься от ошибки, хотя бы визуально. а как лучше? USORT_CR1 |= TCIE ? вот это TCIE к чему относится? если ты давно работаешь с камнем, ты поймешь и даже проконтролируешь правильность в уме. а если нет? а если ты ошибся и написал TCIF (допустим, был бы такой, но в другом регистре - с флагами прерываний), компилятор ничего тебе не скажет. кроме того, есть TCIE и у y2s и у кого-то еще.

т.е., я мог бы понять, что это неудобно - много писать, но такой проблемы ведь нет, если писать в чем-то лучше notepad.ixi.

0

Сообщение от Ymk т.е., я мог бы понять, что это неудобно - много писать, но такой проблемы ведь нет, если писать в чем-то лучше notepad.ixi.

Ymk, так дело не в том, что много писать, а в том, что писать много лишнего
А это уже дело принципа - Dont Repeat Yourself )

0