a5021 писал(а):Это единственный способ избежать множества дивных эффектов в случайные моменты времени
Не единственный. Например, если никто не мешает Вам заблокировать работу с буфером, пока DMA в него пишет.
А надеятся, что добавление volatile к аргументу чудесным образом всё решает - это неправильно.
Например, возьмём буфер из 10 volatile элементов. Допустим, DMA читает из этого буфера их последовательно, и процесс чтения в данный момент времени - на 5-м элементе. В это время параллельно (по прерыванию, например), изменяются элементы 2 и 7. Какие могут быть варианты:
1. volatile. Из индекса 2 мы уже прочитали - тут ничего не попишешь, ну а из индекса 7 будет прочитано новое число. Есть повод задуматься, хорошо ли это, что данные пришли из разных по сути выборок.
2. не volatile. Есть очень малый шанс, что из индекса 7 будет прочитано прежнее число, а не свежезаписанное (малый потому, что вряд ли весь массив будет предварительно скопирован в рабочие регистры и тем самым "закэшируется" локально). Но если и так - то плохого в этом ничего нет.
Оба варианта имеют свои недостатки. А делать принудительно весь аргумент функции как volatile - это лишь лишить себя (и компилятор) дополнительной возможной оптимизации.
Вместо этого, если Вам действительно нужна атомарность работы со всем буфером, Вы, как программист, должны обеспечить её другим способом - каким-нибудь аналогом mutex-а. В случае микроконтроллера без ОС - это может быть какой-нибудь банальный флаг типа (volatile bool isBusy). Напишите свою HAL_SPI_Receive_DMA_Locked() функцию, в которой будет вызов уже стандартной HAL-овской, обёрнутый этим флагом, и обеспечьте другую часть своего кода на проверку этих флагов, чтобы они и не думали лезть в этот буфер, пока он залочен.
