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

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3895450#p3895450"]почему вы не возмущаетесь функцией memset - у нее параметры тоже не volatile! хотя "по смыслу" она очень похожа на работу рассматриваемой функции с DMA.[/uquote]
Для кого-то похожа, для кого-то нет. И очевидно есть веские обстоятельства, почему так.

memset меняет значение области памяти в текущем программном контексте. Компилятор знает что изменяется и в какой момент времени. В случае с дма-трансфером у компилятора нет информации о том, что какая-то область памяти подвергнется изменениям или эта область будет как-то использована. Если не "зажать" область памяти (переменную) с помощью volatile, то компилятор может попытаться соптимизировать, высвободить или переиспользовать это пространство со всеми вытекающими. Вы подготовили буфер к отправке, передали указатели в блок DMA, но к моменту, когда дело дойдет до реальной передачи, эта область памяти может быть использована компилятором по своему, а не вашему усмотрению.

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

Что вы заладили с этим своим воидом. Не играет оно тут никакой роли.

[uquote="VladislavS",url="/forum/viewtopic.php?p=3895477#p3895477"]ARV, вы задаёте правильный, но очень неудобный вопрос.[/uquote]
Вам он что-ли неудобный? То, что правильное значение указателя будет записано в CPAR/CMAR независимо от наличия volatile в параметрах фунции, ежу понятно и никогда и ни кем здесь не оспаривалось. Вы что и кому доказываете здесь с упорством, достойным лучшего применения?

За неимением HAL-а, накидал простенький пример, иллюстрирующий обсуждаемый вопрос.

Чепуху вы в очередной раз накидали. Пламенный ответ на вопрос, который вам никто не задавал.

[ARV]

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

это может (???) произойти, как понимаю, уже после того, как злосчастная функция отработает, ведь она ничего, кроме записи в несколько регистров аппаратуты, не делает - верно? так зачем самой функции требовать volatile-буфер, если ей на это плевать? внутри этой функции никакой оптимизации нет и быть не может - там ДАННЫЕ не используются от слова вообще! нужно volatile снаружи функции или нет - вопрос другой, речь о параметрах функции!

и, если честно, я как-то не очень понимаю: как может компилятор модифицировать область памяти, которую я выделил в программе, без моего ведома?! тут явно какой-то подвох...

Добавлено after 15 minutes 3 seconds:
кстати, в MinGW GCC функция memset получает именно void*, потому и не ругается на любой буфер.

[Eddy_Em]

[uquote="a5021",url="/forum/viewtopic.php?p=3895322#p3895322"]Судя по тому, какое количество фанатов хала понабежало, говорить такие вещи здесь -- пустое дело.[/uquote]
Если не хочешь смущать людей вонью, то не стоит нырять в кучу с навозом!

[VladislavS]

[uquote="a5021",url="/forum/viewtopic.php?p=3895656#p3895656"]Пламенный ответ на вопрос, который вам никто не задавал.[/uquote]Зато вам ARV его раза три задал, но ответа не получил. А я к тому же показал, что volatile в параметрах функции никак не повлиял на возможность завести !volatile буфер. А так кмк самой функции он кмк собаке пятая нога, то и применять его там никакого смысла нет.

[uquote="ARV",url="/forum/viewtopic.php?p=3895670#p3895670"]и, если честно, я как-то не очень понимаю: как может компилятор модифицировать область памяти, которую я выделил в программе, без моего ведома?! тут явно какой-то подвох...[/uquote]А он и не меняет. Он наоборот не использует или не меняет её содержимое, ошибочно полагая, что знает что там. Или даже вообще не выделяет память, если думает, что может обойтись регистром или константой.

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=3895690#p3895690"][uquote="a5021",url="/forum/viewtopic.php?p=3895322#p3895322"]Судя по тому, какое количество фанатов хала понабежало, говорить такие вещи здесь -- пустое дело.[/uquote]
Если не хочешь смущать людей вонью, то не стоит нырять в кучу с навозом![/uquote]А можно поинтересоваться, кто из участников дискуссии им пользуется? Пока что я наблюдаю лишь одного "искателя багов". Я, например, до сего дня и не подозревал о существовании такой функции.

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3895670#p3895670"]так зачем самой функции требовать volatile-буфер, если ей на это плевать?[/uquote]
Не надо ничего требовать. Вопросов бы не было, если бы она, функция, не провоцировала ложный шухер в то самое время, когда все по канону.

и, если честно, я как-то не очень понимаю: как может компилятор модифицировать область памяти, которую я выделил в программе, без моего ведома?! тут явно какой-то подвох...

А код, который вы со всем тщанием и трепетом собственноручно начертали можно выбрасывать? Так выбрасывает же. Выбрасывает в любом объеме, если сочтет бесполезным. Оптимизация называется.

кстати, в MinGW GCC функция memset получает именно void*, потому и не ругается на любой буфер.

На колу мочало...

[uquote="VladislavS",url="/forum/viewtopic.php?p=3895694#p3895694"]Зато вам ARV его раза три задал, но ответа не получил.[/uquote]
И вы решили на его вопрос ответить за меня? Кому как, конечно, но лично у меня доброхоты вызывают легкое недоверие.

А так кмк самой функции он кмк собаке пятая нога, то и применять его там никакого смысла нет.

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

[ARV]

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

то есть вы хотите сказать, что если я напишу static char buf[128]; то компилятор сможет его "соптимизировать", даже если я использую ссылку на него?! по-моему, это уже из области фантастики. тем более, если я этот самый buf получил из malloc

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

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3895773#p3895773"]то есть вы хотите сказать, что если я напишу static char buf[128]; то компилятор сможет его "соптимизировать", даже если я использую ссылку на него?! по-моему, это уже из области фантастики.[/uquote]
Если вы предпочитаете верования знаниям -- ваше право. Ссылки на то, что буфера под DMA должны быть Volatile я приводил. Если бы статик был "неоптимизируемым", никакой волатайл никогда бы не потребовался. Ему просто не нашлось бы применения.

[a797945]

а если задавать объем буфера не "...[255]", а например [4]
компиль все равно будет кидать предупреждения?

[ARV]

Если вы предпочитаете верования знаниям -- ваше право

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

Если бы статик был "неоптимизируемым"

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

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

[a5021]

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

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

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

[uquote="a797945",url="/forum/viewtopic.php?p=3895806#p3895806"]а если задавать объем буфера не "...[255]", а например [4]
компиль все равно будет кидать предупреждения?[/uquote]
Что должно измениться, по вашему?

[a797945]

изменится ли
сам проверить не могу
просто предложил
пишу кратко чтоб демагогию не разводить

[ARV]

Почему буфер, ссылка, что-угодно не могут подвергнутся сокращению, если с точки зрения компилятора это никак не используется и впустую занимает место?

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

[КРАМ]

[uquote="a5021",url="/forum/viewtopic.php?p=3895786#p3895786"]Ссылки на то, что буфера под DMA должны быть Volatile я приводил.[/uquote]
Вопрос был про указатели, а не про сами буферы.
http://www.pic24.ru/doku.php/osa/articl ... r_chainiks

[uquote="a5021",url="/forum/viewtopic.php?p=3895786#p3895786"]буфера под DMA должны быть[/uquote]
БуферА у Маньки, а в МК бУферы...

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3895906#p3895906"]потому что компилятор не может никаким способом узнать, что и как делает со ссылкой функция[/uquote]
А код функции компилирует не компилятор, а силы небесные? Вот так новость!

[ARV]

А код функции компилирует не компилятор, а силы небесные?

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

[a5021]

[uquote="КРАМ",url="/forum/viewtopic.php?p=3895921#p3895921"]Вопрос был про указатели, а не про сами буферы.[/uquote]
Ну-ка, ну-ка... Вот такая запись:

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

volatile char * buffer;

о чем говорит? Это сам указатель volatile или volatile -- это область, на которую он указывает?

[http://www.pic24.ru/doku.php/osa/articles/volatile_for_chainiks

Да-да, главное букварем трясти, если ни с чем другим не сложилось.

БуферА у Маньки, а в МК бУферы...

Благодарю, что вы нашли время сообщить об этом. Маньке привет.

[uquote="ARV",url="/forum/viewtopic.php?p=3895933#p3895933"]да вы меня удивляете![/uquote]
А уж вы-то меня как, не передать.

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

"динамически-загружаемой" ? в эмбеде? покажете?

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

[ARV]

"динамически-загружаемой" ? в эмбеде? покажете?

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

догадайтесь, что этот самый компилятор сделает со всем, что в функции на его взгляд не используется?

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

[WiseLord]

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

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=3895941#p3895941"]а что, для эмбеда компиляторы какие-то особые, не так работают, как не-для-эмбеда?[/uquote]
Таки да. Но я с радостью переменю свое мнение, если вы явите миру динамическую библиотеку, скомпилированную с помощью, скажем, arm-none-eabi.

ну и потом, линух крутится в миллионах эмбеддед-устройствах

Раз и в руках фокусника из ниоткуда возник линух. Совсем дело плохо, что так метаться приходится? Вроде ж раньше только про HAL говорили.

так я об этом и говорю: компилятор собирает функцию, которая получает указаель на какую-то не-volatile память - откуда он узнает, что эта память на самом деле в других местах не нужна и будет выброшена?

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

[ARV]

Как по вашему, компилятор в этом случае может определить, что и как ему следует оптимизировать?

вот смотрите, какой пример.

есть функция printf, получает в параметрах НЕ-volatile указатели на символ. когда я пишу

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

#include <stdio.h>
static const char *s = "Hello, world";

int main{
   printf(s);
}

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

так, по-вашему?

Добавлено after 4 minutes 58 seconds:
кстати, вывод printf вполне где-то в недрах ОС может кончаться именно DMA-передачей... и чо?

Добавлено after 11 minutes 3 seconds:
а теперь заменим printf на вашу HAL_DMA_что_то_там_инит - что изменится?