О volatile замолвлю я слово

jcxz

Но тут уже всё, явного присваивания нет и компилятор и/или линкер берут и просто выкидывают эти куски кода. Тогда получается, что надо теперь бегать по всем исходникам искать эти вызовы и расставлять модификаторы?

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

Реклама

uldemir

Увы... написать этот пост меня вынудило то, что у меня как раз и не записывалась одна переменная в FRAM. По окончании записи в журнал, я в нулевой адрес FRAM хотел записать сколько записей сделано:

Код:

frames_to_go = FRAM_SIZE/sizeof(data_buffer_t) - frames_to_go;
FRAM_dma_log_Start(0x0000));
FRAM_dma_log_write((uint8_t*)&frames_to_go, sizeof(frames_to_go));
FRAM_dma_log_Stop();
frames_to_go = 0;

Да, я схалтурил и воспользовался уже использованной переменной... но факт тот, что записывалась туфта, а не число записей. Пока не объявил эту переменную волатильной. А потом просто сделал отдельную волатильную переменную, а frames_to_go вернул в исходное неволатильное состояние.

И я сейчас установил максимальную оптимизацию. Кажется, её называют LTO.

p.s. И еще, у меня контроллер, сейчас, MSP432, а у него несколько странный DMA. Структуры каналов у него пишутся в память. Правда, я не нашел, где взять определения этих структур и поэтому пользуюсь функциями предоставляемыми driverlib (который, к тому же еще и прописан в ПЗУ микроконтроллера при изготовлении).

Реклама

jcxz

uldemir писал(а):

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

Не очень понятно - зачем это всё?
Вот у меня сейчас открыт проект на MSP430FR5739. У него FRAM. Есть константы, расположенные во FRAM (и закрытые от модификации с помощью MPU). Объявлены они так:

Код:

typedef u8 Addr[ADDR_LEN];
static Addr const volatile addrCData = {ADDR_SENS, 0x91, 0x92, 0x99, 0x99};

Компилирую с максимальной оптимизацией код, читающий и модифицирующий эту addrCData. Получаю листинг:

Код:

         if (*(u32 const *)&addrCData[0] != *(u32 const *)&b.addr[0] || addrCData[4] != b.addr[4]) break;
92910200.... CMP.W   0x2(SP), &??addrCData + 2
1520         JNE     ??RadioAct_9
A291....     CMP.W   @SP, &??addrCData
1220         JNE     ??RadioAct_9
D2910400.... CMP.B   0x4(SP), &??addrCData + 4
0E20         JNE     ??RadioAct_9

Как видно - идёт реальное чтение из памяти addrCData, без создания для неё алиаса (как было бы без volatile).

Код:

                                          #ifdef MPU_ENABLE
                                          MPU.CTL0 = toSW(0, 0xA5);
B24000A5A005 MOV.W   #0xa500, &0x5a0
                                          #endif
                                          *(u8 volatile *)&addrCData[0] = ADDR_PROBE_RX;
F2403D00.... MOV.B   #0x3d, &??addrCData
                                          #ifdef MPU_ENABLE
                                          MPU.CTL0_L = B0;
D243A005     MOV.B   #0x1, &0x5a0
                                          #endif

Модификация первого байта addrCData. Тоже всё ок. Никаких лишних команд.

IAR C/C++ Compiler V7.12.1.987/W32 for MSP430

VladislavS

Прятать алгоритмические проблемы за volatile - плохая практика. Лучше найти проблему в коде.

Реклама

Эиком - электронные компоненты и радиодетали

О volatile замолвлю я слово

Кто сейчас на форуме