Они набиты функциями до предела, отсюда возникают сложности при первоначальном изучении, это минус, но это же и плюс - так как купив даже бюджетную сотку (STM32F100) получаешь мощный комбайн почти на все случаи радиолюбительких поделок (т.к. большинство из них сделано на pic/avr, ну у буржуев еще моторолы и неки мелькают). Потом, когда уже более-менее разобрался, что там к чему и появились собственные заготовки, где вся рутинная часть по инициализации контроллера написана и надо только подправить под конкретный проект - дело пойдет быстрее. К тому же и внутри семейств STM8 и STM32, и даже между ними производитель стремился использовать максимально (насколько это технически возможно) похожую распиновку и периферию, чтоб облегчить процесс миграции вверх/вниз по семействам.

Еще мне не очень нравится как написана документация у ST, не особо она легко воспринимается с непривычки, но это придирки - ничего такого с чем нельзя было бы жить, просто можно и удобнее сделать.

Кстати, у ST есть полезная штука STM32CubeMX (и STM8CubeMX), где в графическом редакторе задаешь какие тебе модули необходимы, какие пины, их настройки и затем программа генерирует заготовку проекта с кодом инициализации для одной из нескольких популярных сред разработки на выбор. Сейчас у них появилась своя среда разработки STM32CubeIDE, которая по сути ребрендированный TrueStudio for STM32 (купленный ими со всем Atollic'ком несколько лет назад) со встроенным в него CubeMX. Была у них еще одна бесплатная IDE для STM32 - System Workbench, разработанная компанией AC6 Tools для них, но кажется особо не прижилась она, по итогу сделали ставку на Atollic. Впрочем, и первое и второе - суть есть Eclipse.

Также у коммерческих IDE от IAR и Keil есть бесплатный lite-режим с ограничением размера бинарника до 32к. У Кейла есть, также, бесплатные лицензии для семейств Cortex M0/M0+ (STM32F0, STM32G0, and STM32L0), с ограничением размеров кода до 256к, что для таких контроллеров за глаза.

Но естественно, все средства подразумевают использование языка С. Ассемблер для АРМов хоть и документирован, но для реального написания программ не применяется. Если простая задача быстрее будет слепить на чем-то уже известном, чем тратить время на изучение новой платформы. А если с заделом на будущее, то можно и попробовать.

@ rubin

Насчет логарифмирования - боюсь, тут этот фокус не прокатит... Причина простая - точность аналогового логарифмирования не позволит восстанавливать исходную форму с достаточной точностью... Я немного знаю тему - применяли мы в одной приблуде логарифмирование импульсов в широком диапазоне - так вот там были бооольшие сложности с температурной стабильностью и повторяемостью, да и диапазон в 60дБ был получен упорным трудом моего тогдашнего шефа и учителя (гениального разработчика аналоговых схем, серьезно).
Ну да попробуем и без этого - у меня в заводском Korg'е стоит кодек на 24 с диапазоном, как у 18 битного - и работает, правда шипит на больших гейнах. А может - и не он шипит - там операционник на входе неудачно включен - инвертором (у него питалово 3,3В)  - и по сигналу резистор большой, точно не помню, но больше 470к, так что он тоже шумит хорошо...
Буду пробовать. Кодек пришел, но я еще его не приколхозил - макет-то на печатке собран, теперь нужно его частично разобрать и на проводках приклеить кодек, да еще и часть сигналов меняется по выводам проца - мне ж на него нужно I2S подать, да еще в полном дуплексном...
Кстати - ты не разбирался с полным дуплексом на I2S?
Из руководства не очевидно, как его включить...

Ыыы... Лично мне Куб не понравился... Точнее не так. Он-то мне сначала понравился - типа удобно, но под IAR он чет у меня конфликтовал c программой мигания светодиодом (библиотеки HAL не совмещались с более старыми SPL). Я поскрипел зубами, а потом понял, что могу писать на С все в привычном мне стиле Асм: при настройках и с периферией работать непосредственно с регистрами, а способы проверки условий (например - нажатия кнопки или выхода параметра за допустимый предел) - в С очень похожи на Асм...
Так что я не пользуюсь Кубом. Поскольку все мои программы я пишу "для себя", могу себе позволить это делать так, как удобно мне. У меня есть "заготовки" для настройки различной периферии на разных ядрах семейства (ну те, что я уже использовал) и я их использую в новых проектах. Мне так удобнее и привычнее.
Кстати - вот у STM32F103 как раз некоторые настройки отличаются от всех прочих STM'ов  - думаю, что этот проц был один из первых выпущен, и тогда еще не придумали, как лучше. Например - порты настраиваются не так, как я описал, USART немного другой, ну и там еще по мелочи.
В общем - советую начать с даташитов... Есть мой перевод на русский, если надо - ну он не всеобъемлющий, но основное я перевел.
А в Кубе я сейчас подглядываю систему синхронизации при включении незнакомых STM'ов - она там довольно наглядная (картинка ).
В общем - ставь Atollic, IAR, или чего другое понравится, приобрети ST-Link китайский - и вперед!
У меня под эту платку с STM32F103 осциллограф написан . Можешь прицепить к ней экранчик на ili9341 с SPI интерфейсом - а программу я тебе сброшу - сможешь для начала надергать из нее кусков - настройки портов, таймеров, SPI, DMA...
PS Почему я работаю в Атоллике? Сначала поставил IAR - довольно удобно... Все - кроме создания проекта - для меня это был такой танец с бубном! (возможно - я отупел со свими Асмовскими привычками - но мне было проще в одном проекте все работы делать по разным программам, чем создать новый проект...)
А потом коллега по работе посоветовал Атоллик... Тут, по крайней мере, создавать проект немного легче (особенно если не подключать стандартные библиотеки). Я понимаю - это же Ересь - без библиотек обходиться , это не по правилам! Но - в стандартных библиотеках всегда куча лишнего - причем лишнего в коде, что замедляет исполнение программы (а для осциллографа или Хаммонда это таки критично). Потому я из библиотек "выпиливаю" нужные кусочки и вставляю себе в проект.
А обольщаться огромным быстродействием STM не стоит - использование "стандартных" С-шных подходов легко сводит его к скорости Atmeg'и.
А с точки зрения удобства работы/интерфейса - и IAR и Atollic и Keil - они как близнецы-братья, все очень похоже.

Да пожалуйста!
Просто по себе знаю - самое сложное - начать, "съехать с места", потом оно уже катится само. Потому готов помочь, чем смогу.

Продолжим по теме цифровой примочки.
Пока не прикручен кодек, я немного поупражнялся в алгоритмах обработки на 12 бит. Что я хотел добиться - имитировать темброблок. Вообще-то в аналоге можно решать эту задачку разными способами: классический маршалловский/фендеровский трехручечный, одна ручка "тон", как на простых примочках, параметрика, обрезной фильтр с резонансом...
Я делал в примочках своих по-разному, да и не только я...
Решил сделать и одноручечный (он неплохо работает как "презенс" и с трехручечным ТБ) и трехручечный  - для имитации разных приборов.
Одноручечный делается в цифре довольно легко - RC цепь с изменяемым временем... А вот классический на 3 ручки - я пока не знал, как сделать. Решил сделать 3 полосы по своему (попробовал реализовать вариант своего ТБ, я когда-то его выкладывал здесь на форуме, он непохож ни на Баксандалла, ни на классику ). Попробовал несколько вариантов - не то, что нужно ...
Тогда решил для начала сделать регулировку верха и низа. Сделал два фильтра 1го порядка и регулировку уровня сигнала каждого из них. Получилось похоже...
А вот с серединой - не пошло. Я разозлился и начал программировать резонансный фильтр . За основу взял идею из http://we.easyelectronics.ru/Soft/prostoy-polosovoy-filtr.html  - естественно, доработал до нужных кондиций. Оказалось - работает, можно настроить добротность, частоту и уровень сигнала. Получилось неплохо, хотя и не совсем классически (Маршалл в Jackhammer  сделал что-то похожее). Покрутил на реальном сигнале и получил вот такие картинки (на входе - синус, он ограничен почти до прямоугольника) - ИМХО таки похоже на осциллограммы реальной примочки:

На первой осциллограмме верх поднят больше, на второй - низ.

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

Жесть какая-то. Ни в руководстве, ни в даташите ничего внятно не написано, надо лезть в библиотечные исходники, чтоб убедится, что модуль реально существует....

Кажется, примерно разобрался... там действительно есть урезанные "теневые" модули приемо-передатчиков для режима полного дуплекса, они могут работать только ведомыми, и они почти никак не показаны и еле упомянуты словами в основной документации. Более-менее вразумительно, хоть и скуповато, описаны только в библиотечных *.c/*.h-файлах драйверов периферии.

То есть для, включения этого режима помимо правильной настройки соответствующих пинов, надо включить и сами эти IP-блоки. У их регистров свое расположение в адресном пространстве контроллера, и там такая же управляющая структура как и для обычного SPI/I2S. В библиотеках SPL и HAL есть функции чтоб их запустить и настроить. Если больше близок "ассемблерный" стиль прямого обращения к регистрам без абстрагирующих прокладок, то можно посмотреть на внутреннее устройство этих функций и сделать все вручную, аналогично другим случаям.

Вот еще цитата (из библиотеки):

"It is possible to use SPI in I2S full duplex mode, in this case, each SPI peripheral is able to manage sending and receiving data simultaneously using two data lines. Each SPI peripheral has an extended block called I2Sxext (ie. I2S2ext for SPI2 and I2S3ext for SPI3).

The extension block is not a full SPI IP, it is used only as I2S slave to implement full duplex mode. The extension block uses the same clock sources as its master. To configure I2S full duplex you have to:
             
(#) Configure SPIx in I2S mode (I2S_Init() function) as described above.
            
(#) Call the I2S_FullDuplexConfig() function using the same structure passed to I2S_Init() function.
             
(#) Call I2S_Cmd() for SPIx then for its extended block.
            
(#) To configure interrupts or DMA requests and to get/clear flag status, use I2Sxext instance for the extension block.

~~~~~~~~~~~~~~~~~~~~~~~~~~

Example: To use SPI3 in Full duplex mode (SPI3 is Master Tx, I2S3ext is Slave Rx):
             
RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI3, ENABLE);   
I2S_StructInit(&I2SInitStruct);
I2SInitStruct.Mode = I2S_Mode_MasterTx;    
I2S_Init(SPI3, &I2SInitStruct);
I2S_FullDuplexConfig(SPI3ext, &I2SInitStruct)
I2S_Cmd(SPI3, ENABLE);
I2S_Cmd(SPI3ext, ENABLE);
      ...
while (SPI_I2S_GetFlagStatus(SPI2, SPI_FLAG_TXE) == RESET) {}

SPI_I2S_SendData(SPI3, txdata[i]);
      ... 
while (SPI_I2S_GetFlagStatus(I2S3ext, SPI_FLAG_RXNE) == RESET) {}

rxdata[i] = SPI_I2S_ReceiveData(I2S3ext);"

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

Она мало того что малость кривоватая (причем почти все модули - работать вполне можно, но без эррат далеко не уедешь), так еще и стиль подачи информации у ST тот еще... иногда кучу доков приходится перерыть, чтоб получить ясный ответ на достаточно безобидный вопрос. Особенно, в начале освоения - вообще уматериться можно. Как будто квест проходишь.

С праздником!

С модулем, насколько я понимаю это дело, примерно так (на примере F405/407). Согласно даташиту:

Регистровые блоки "основных" модулей имеют базовые адреса в памяти

SPI2/I2S2 - 0x40003800
SPI3/I2S3 - 0x40003C00

А "расширенных" соответственно:

I2S2ext - 0x40003400
I2S3ext - 0x40004000

Длина и набор регистров у них одинаковые с "основными", принципы работы тоже, за тем исключением, что они не работают как SPI и всегда slave'вы. То есть, допустим, настраиваем на определенный аудиобитрейт, протокол и формат аудиоданных ведущий модуль, и ставим скажем на передачу, настраиваем прерывания/ПДП (если надо), включаем. Затем тоже самое делаем с "теневым" модулем, устанавливаем его на прием и тоже включаем. Ну или наоборот. Можно даже их обоих ведомыми сделать, наверное, и приемник и передатчик, а ведущим - сам кодек, если в нем такая возможность предусмотрена.

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

Протравил вчера (наконец то!) плату под новый вариант примочки на STM32F401... Осталось просверлить и заполнить компонентами. Ну и - добиться взаимности от кодека...
2 rubin
А вы не  в курсе - чет я сразу и не нашел там - тактирование  модуля расширения включается отдельно, или он включен при включении основного модуля I2S?

OldMike писал(а) 31.05.2020 :: 06:52:36:



Тоже вот не нашел - вероятно, вы правы - там тактирование общее для всего узла SPI/I2S. Но это, так сказать, то тактирование, которое обеспечивает работоспособность логики модуля в целом. Если я правильно понимаю документацию, есть еще тактирование обеспечивающее собственно передачу данных, несущую частоту, там своя кухня - выделенная PLL для I2S при выборе внутреннего, либо тактовый сигнал будет поступать извне, от кодека, например. В группе регистров, относящихся к системе RCC несколько штук относится к I2S так или иначе.