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

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3460856#p3460856"]..... И получить или:
1) Ненадёжную систему: события идут часто, и очередное событие от таймера может быть потеряно, так как не обработалось ещё предыдущее, потому что шина как раз загружена процессором или другими DMA-каналами. В результате - по запросам от таймера данные считываются из памяти-источника в FIFO-буфер DMA, но не успевают записаться в память-приёмник, потому что она как раз сейчас сильно занята -> FIFO переполняется -> данные теряются. Такое будет происходить от случая к случаю - как карта ляжет.[/uquote]
Слишком много домыслов, лично я без понятия насколько часто у него там идут события и какая сопутствующая нагрузка. Нужен был вариант решения, если в итоге передача при помощи DMA не подходит в принципе, то какой с меня спрос

2) Очень медленную пересылку, потому что (для борьбы с п.1) период таймера пришлось сильно увеличить.

Я писал проги под ЛА и осциллы, там задержка между транзакциями DMA от 2 тактов(для F4 и DCMI), если без таймера, а таймер добавляет еще такт. Это в идеальном случае, если мк в сон вгонять, но если, допустим, запустить DMA и дожидаться окончания передачи проверяя флаг, то искажения захваченной осциллогамы будут крайне незначительными, т.е. CPU читающий команды из флеша и DMA сохраняющий данные в RAM практически не мешают друг другу, а для некоторых конфигураций и серий мк они не пересекаются совсем. Так что не нужно заранее драматизировать, возможно времени там более чем достаточно.

PS: Такой трансфер нужно делать только единым блоком, по одному сигналу запроса.

Burst я упомянул, но он применим далеко не всегда и на время такой передачи можно заблокировать вообще все. А как иначе?

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3460894#p3460894"]Слишком много домыслов, лично я без понятия насколько часто у него там идут события и какая сопутствующая
нагрузка. Нужен был вариант решения, если в итоге передача при помощи DMA не подходит в принципе, то какой с меня спрос [/uquote]
А разве не Вы предложили формировать DMA-запросы от таймера? Количество DMA-запросов - по размеру блока. Событие у автора одно - изменение на внешнем пине. По нему нужно стартовать передачу блока. Вы предложили (как я понял) запустить таймер по этому событию, чтобы он сформировал N сигналов (по размеру блока) с фиксированным периодом?
Вот почему так не стоит делать я и написал.

[uquote="Reflector",url="/forum/viewtopic.php?p=3460894#p3460894"]Я писал проги под ЛА и осциллы, там задержка между транзакциями DMA от 2 тактов(для F4 и DCMI), если без таймера, а таймер добавляет еще такт. Это в идеальном случае, если мк в сон вгонять, но если, допустим, запустить DMA и дожидаться окончания передачи проверяя флаг, то искажения захваченной осциллогамы будут крайне незначительными, т.е. CPU читающий команды из флеша и DMA сохраняющий данные в RAM практически не мешают друг другу, а для некоторых конфигураций и серий мк они не пересекаются совсем. Так что не нужно заранее драматизировать, возможно времени там более чем достаточно.[/uquote]
Ну если так, если "искажения захваченной осциллогамы будут крайне незначительными" и Вы считаете это нормальным, что данные иногда теряются, то тогда да - можно.
Я кстати и писал об этом.
Но я бы не стал даже включать такой осциллограф или ЛА, который иногда теряет данные.
Кроме CPU, проверяющего флаг, могут быть и другие задачи (под РТОС), а также ISR. А также могут быть в этот момент активны другие DMA-каналы. И все эти транзакции к памяти могут идти как в ту же память, которая сейчас копируется через DMA, так и в другую. И при этом всё будет работать по-разному, т.е. - по-разному глючить конечно, работой это назвать нельзя.
Я про это всё тоже написал.

[uquote="Reflector",url="/forum/viewtopic.php?p=3460894#p3460894"]

PS: Такой трансфер нужно делать только единым блоком, по одному сигналу запроса.

Burst я упомянул, но он применим далеко не всегда и на время такой передачи можно заблокировать вообще все. А как иначе?[/uquote]
Burst тут как бы вообще не при делах. burst - это размер пересылки, выполняемой за один цикл арбитража памяти, без переарбитража. Блок DMA-пересылки как правило состоит из множества burst-ов (если burst используется).

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3460913#p3460913"]А разве не Вы предложили формировать DMA-запросы от таймера? Количество DMA-запросов - по размеру блока. Событие у автора одно - изменение на внешнем пине. По нему нужно стартовать передачу блока. Вы предложили (как я понял) запустить таймер по этому событию, чтобы он сформировал N сигналов (по размеру блока) с фиксированным периодом?[/uquote]
Если выбран режим Mem2Mem, то задал, допустим, скопировать 10 байт поштучно, включил DMA и он все скопировал, а если режим Periph2Mem, то пришел запрос DMA от периферии и скопировался 1 байт, т.е. скобы скопировать все нужно 10 запросов. Если не нравится таймер, который может периодически формировать нужные запросы, а при наличии RCR даже точное их количество, то предлагай свой более простой вариант.

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

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

Кроме CPU, проверяющего флаг, могут быть и другие задачи (под РТОС), а также ISR. А также могут быть в этот момент активны другие DMA-каналы. И все эти транзакции к памяти могут идти как в ту же память, которая сейчас копируется через DMA, так и в другую. И при этом всё будет работать по-разному, т.е. - по-разному глючить конечно, работой это назвать нельзя.

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

[uquote="Reflector",url="/forum/viewtopic.php?p=3460894#p3460894"]Burst тут как бы вообще не при делах. burst - это размер пересылки, выполняемой за один цикл арбитража памяти, без переарбитража. Блок DMA-пересылки как правило состоит из множества burst-ов (если burst используется).[/uquote]
В том и смысл, чтобы раз дернуть DMA и передать не байт, а сразу некое их ограниченное подмножество.

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3460966#p3460966"]Если выбран режим Mem2Mem, то задал, допустим, скопировать 10 байт поштучно, включил DMA и он все скопировал[/uquote]
Это же без DMA-запросов. pokk то зачем такой режим? Ему нужно: по единственному DMA-запросу скопировать весь блок байт. DMA-запрос должен формироваться от внешнего пина.
[uquote="Reflector",url="/forum/viewtopic.php?p=3460966#p3460966"]а если режим Periph2Mem, то пришел запрос DMA от периферии и скопировался 1 байт, т.е. скобы скопировать все нужно 10 запросов.[/uquote]
А это - с DMA-запросами, но на один запрос - копирование только 1 байта. Это тоже не то, что нужно pokk.

[uquote="Reflector",url="/forum/viewtopic.php?p=3460966#p3460966"]Если не нравится таймер, который может периодически формировать нужные запросы, а при наличии RCR даже точное их количество[/uquote]
Причём тут периодические запросы? Запрос у pokk - единственный, и по нему весь блок должен быть скопирован. Если я правильно понял.

[uquote="Reflector",url="/forum/viewtopic.php?p=3460966#p3460966"], то предлагай свой более простой вариант.[/uquote]
Не работал с stm32f103 и не знаю возможностей его DMA-контроллера, поэтому ничего не предлагаю. Но знаю что на других МК такое сделать возможно.

[uquote="Reflector",url="/forum/viewtopic.php?p=3460894#p3460894"]В том и смысл, чтобы раз дернуть DMA и передать не байт, а сразу некое их ограниченное подмножество.[/uquote]
Вот именно. А burst - это из другой оперы совсем.

PS: Вообще - даже не зная возможностей DMA-контроллера stm32f103, можно предложить такой вариант:
По DMA-запросу (изменение на внешнем пине) DMA-канал1 делает пересылку в регистр управления DMA-канала2 одного слова, в котором установлен бит EN. Таким образом разрешая работу DMA-канала2. А DMA-канал2 уже заранее запрограммирован на пересылку желаемого блока. Запрограммирован, но не разрешён.
Вот и всё.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3460980#p3460980"]Причём тут периодические запросы? Запрос у pokk - единственный, и по нему весь блок должен быть скопирован. Если я правильно понял.[/uquote]
Пусть количество принимаемых DMA байт равно 10, пришел байт по USART/SPI, генерится запрос и DMA забирает принятый байт, счетчик уменьшается на 1 и дальше DMA ждет следующего принятого байта и, соответственно, следующего риквеста. Когда придут все 10 байт DMA выставит флаг TransferComplete. То же самое с таймером, каждый Update генерит запрос DMA и счетчик уменьшается на 1, этот запрос(как и любой другой) не запускает автоматическую передачу всего блока, как некоторые могут подумать. У ADC есть continuous mode, в таком случае он может непрерывно генерить запросы для DMA, причем с задаваемым фиксированным интервалом. А если чтение идет с порта или FSMC, которые в чистом виде слейвы, то они сами ничего не генерят и единственный запрос сторонней периферии приведет к передаче 1/2/4 байт, если без Burst. По крайней мере я не знаю о режимах STM32 в которых можно было бы по запросу периферии передать весь блок целиком...

Добавлено after 3 minutes 57 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=3460980#p3460980"]PS: Вообще - даже не зная возможностей DMA-контроллера stm32f103, можно предложить такой вариант:
По DMA-запросу (изменение на внешнем пине) DMA-канал1 делает пересылку в регистр управления DMA-канала2 одного слова, в котором установлен бит EN. Таким образом разрешая работу DMA-канала2. А DMA-канал2 уже заранее запрограммирован на пересылку желаемого блока. Запрограммирован, но не разрешён.
Вот и всё.[/uquote]
О, это уже вариант который вполне может оказаться рабочим, но нужно проверять.

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3460993#p3460993"]О, это уже вариант который вполне может оказаться рабочим, но нужно проверять.[/uquote]
Это рабочий вариант. Я так делал. Правда не на STM32.
Если в DMA-контроллере этого STM32 есть режим свЯзных списков, то можно сделать так, чтобы по завершении передачи всего блока DMA-каналом2, следующим элементом свЯзного списка, он заново переинициализировался на передачу нового блока.

[dosikus]

[uquote="jcxz",url="/forum/viewtopic.php?p=3460980#p3460980"]По DMA-запросу (изменение на внешнем пине)[/uquote]

Осталась самая малость, сущий пустячок- найти этот несуществующий реквест...

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3461343#p3461343"]Осталась самая малость, сущий пустячок- найти этот несуществующий реквест...[/uquote]
А что - это проблема?
Я так понимаю - раз автор вопроса молчит, значит он всё уже давно сделал и у него уже давно всё работает.

[dosikus]

jcxz, только если как-то через через Capture таймера

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3461395#p3461395"]jcxz, только если как-то через через Capture таймера[/uquote]
Вот именно. Или через любую другую удобную периферию. Хоть UART

[dosikus]

jcxz, да не все так гладко, обеспечить минимальное время реакции на смену уровня на пине через "хоть UART" не выйдет.

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3461433#p3461433"]jcxz, да не все так гладко, обеспечить минимальное время реакции на смену уровня на пине через "хоть UART" не выйдет.[/uquote]
Автор не озвучил ни длительность импульса ни периодичность его повторения ни требуемое время реакции на него.
Удобнее конечно через таймер. Но при желании и UART можно - загнать его на максимальную скорость, oversampling8 и минимальное число бит в символе.
Там подводный камень может быть в другом: нужно не забывать вычитывать из этой периферии причину request-а - байт из UART-а или защёлкнутое значение из таймера, чтобы сбросить этот request. Для этого можно использовать такой DMA-request, который идёт на два разных DMA-канала, и вторым каналом прочитать эту причину (поставив каналу приоритет пониже).

[pokk]

Благодарю всех, за ответ, это я подключаю winzet 5100(5300) через FMSC, и хотел по максимум задействовать аппаратные возможности процессора, что бы по выводу прерываний от wiznet (пришел запрос на считывания пакета данных, или запрос на закидывания следующего пакета ) сразу уже закидывать подготовленные данные или считывать данные автоматом, а после уже разбирать что пришло. Но походу получиться больше геморроя, так что сделаю, либо на прерывании по выводу int запускать считывание DMA, либо вообще его в майне опрашивать полингом, и там уже запускать дальнейшие операции.

[afz]

А подскажите, плз, как правильно объяснить CMSIS'у под Кейлом, что нужно использовать внешний ВЧ-генератор (кварц)? Просмотрел RTE_Device.h в кейловском Configuration Wizard'е, там High-speed External Clock был 25 МГц, поставил 8 МГц (мой кварц), но, похоже, на кварц так и не переключилось, продолжает работать от внутреннего клока. А принудительного переключения на кварц в этом визарде нет.

И, кстати, как попроще глянуть (отладчиком), действительно оно не переключилось, или это у меня кварц поганый попался?

Проверял своей любимой программкой мигания - она раз в секунду коротко взмаргивает светодиодом и считает минуты, а в начале каждой минуты взмаргивает дважды. Так вот, вечером засек по секундной стрелке часов, когда взморгнуло дважды, утром глянул - расползлось секунд на 20. Аналогичная программуля на разных АВР-ках расползалась с часами за ночь не более, чем на секунду-другую. Глядя на эти 20 секунд (а может и не 20, а больше на целое число минут, оно-то считается по модулю 60), я сделал вывод, что на STM32 клок остался от HSI - на всех АВР-ках те же китайские кварцы, а тут какой-то особенный, да?..

[WiseLord]

А что за STM32? На той же STM32F103 обязательно должен быть кварц с нагрузочной способностью 6пФ (даже не рекомендация, а чёткое требование в даташитах/мануалах), хотя те же китайские платы на C8T6 идут с неправильным кварцем и конденсаторами в нагрузке, судя по мультиметру, где-то на 15пФ.

Я пока не заменил кварц и конденсаторы на правильные, вообще не мог понять, что не так с RTC - могут вообще не тикать, а берёшь плату в руку (наводки? земля?) - начинают, но с жуткой погрешностью.

А с нормальным кварцем - уход порядка секунды в сутки, да и тот можно скорректировать.

[VladislavS]

[uquote="afz",url="/forum/viewtopic.php?p=3462001#p3462001"]И, кстати, как попроще глянуть (отладчиком), действительно оно не переключилось, или это у меня кварц поганый попался?[/uquote]Если кварц не включен, то на этой строке повиснете навсегда.

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

while(!(RCC->CR & RCC_CR_HSERDY));

[oleg110592]

[uquote="afz",url="/forum/viewtopic.php?p=3462001#p3462001"]А подскажите, плз, как правильно объяснить CMSIS'у[/uquote]
у CMSISа, например для F0, в папках есть файлик типа system_stm32f0xx.c, где настройка по умолчанию на HSI. У ST есть экселевские утилиты под разные семейства типа Clock configuration tool for STM32F0xx microcontrollers (AN4055):
https://www.st.com/en/development-tools ... 32088.html
Там можно птичками наконфигурить и сгенерить новый system_stm32f0xx.c.
Только похоже под старый CMSIS. Можно попробовать переделать.
Сейчас ST предлагает для конфигурации тактирования куб - можно подглядеть внутренности HAL-овой или LL-вой реализации.

[VladislavS]

Вот не понимаю зачем гадать где там что само нагенерилось? Неужели так трудно самому включить кварц и PLL? Ну это же не USB-стек, тут всего то около 10 строчек кода если размашисто писать.

[Oxford]

Любовь уповать на говнолибы, калокубы...Главное чтобы не изучать и не читать ничего, а потом форум зае...ывать вопросами. Буксуют на простейших вещах, включить альтернативную функцию, настроить тактирование....посмотреть регистр RCC_CR запущен ли внешний кварц и т.д.

[philosoraptor]

Как кто-то метко заметил однажды, не бывает плохих инструментов, бывают кривые руки (и все остальное).