указатели в keil

[VladislavS]

Ser-B писал(а):

Всего лишь хотел передать суть проблемы.

Суть вам описали в первом же ответе.

Ser-B писал(а):

В М3 действительно все было норм, а М0 такая вот ерунда.

Ну да, M3 умеет невыровненный доступ.

Ser-B писал(а):

Задача записывать во флеш настройки скопом из всех массивов и считывать в массивы при включении мк.

Откройте для себя memcpy.

[jcxz]

Ser-B писал(а):

Проблема исчезла при объявлении 32-разрядных массивов. Правда, появился дополнительный расход памяти.

Не знаю как там в кейл, но в IAR есть чудесный префикс __packed. И если объявить long-переменную с этим префиксом, то даже на МК не поддерживающих невыровненный доступ, обращения к таким невыровненным переменным будет происходить как по-маслу - без HF. И "дополнительный расход памяти" чудесным образом уйдёт в небытие.
Думаю что и в кейл должно быть что-то подобное.

[ozzy]

http://www.keil.com/support/man/docs/ar ... 968737.htm

и
http://www.keil.com/support/man/docs/ar ... 966304.htm

[VladislavS]

jcxz писал(а):

И если объявить long-переменную с этим префиксом, то даже на МК не поддерживающих невыровненный доступ, обращения к таким невыровненным переменным будет происходить как по-маслу - без HF.

ТС злобный буратино, он невыровненный доступ с помощью приведения типа указателя получает. Против лома никакой __packed не спасёт. Если он захотел 32-битный доступ, то он его получит.

[Z_h_e]

Лучше объявить массив с 32х битными элементами, он то точно будет пословно выравнен, а побайтный доступ к нему работать будет.

Добавлено after 3 minutes 6 seconds:

Или просто в union их объединить.

[VladislavS]

Z_h_e писал(а):

Лучше объявить массив с 32х битными элементами

Вот нахрена эти извращения? ТС написал, что это копирование происходит ОДИН РАЗ ПРИ СТАРТЕ ПРОГРАММЫ для считывания конфигурации. На чём экономить собрались? Микросекунда при старте погоду сделает?

[ПростоНуб]

Зачем изобретать велосипед и не пользоваться memcpy()? https://devel.rtems.org/browser/umon/ma ... a9b6214cd6
Причем это верно для любой платформы. Функция memcpy() почти всегда имеет оптимизацию под конкретную архитектуру. Уж больно часто необходимо копировать массивы данных.

[Ser-B]

объявляю массив таким образом:
__align(4) uint8_t adr_sensor[QTY_TERM_SENSOR][8];
и все норм.

[Аlex]

ТС, откройте для себя структуры и, как уже выше сказали, memcpy. И любые параметры пихайте в эту структуру.
Потом просто сохраняйте/читайте её, и никаких проблем не будет.

[Ser-B]

В memcpy реализована процедура записи во flash?

[ПростоНуб]

Ser-B писал(а):

В memcpy реализована процедура записи во flash?

Нет, но ссылку на исходник memcpy, обеспечивающий оптимальную скорость копирования я привел выше. Берите его за основу. Если, конечно, не жалко flash.
Я в таких случаях предпочитаю пользоваться EEPROM или AT24C*

[Ser-B]

ПростоНуб писал(а):

Если, конечно, не жалко flash.

Почему её должно быть жалко? Запись происходит максимум несколько десятков раз за всю жизнь девайса. Объем флеша МК вполне позволяет.

[optima]

На простое копирование из 8 битного массива 4 байтов в 32 битную переменную id_data, с реверсом данных в необходимый вид. Таким образом
id_data = moimassiv[1]<<8;
id_data = ( id_data + moimassiv[2])<<8;
id_data = ( id_data + moimassiv[3])<<8;
id_data = id_data + moimassiv[4];
Уходит 14 asm команд, если то же самое делаю применяя memcpy то уже 47 команд! Потом еще нужно сделать реверс __REV плюс еще пару команд.

[Аlex]

Копирование маленьких объёмов данных с помощью memcpy, естественно, будет нерациональным по скорости. И это нужно понимать.
Вы бы ещё с одним байтом сравнили
Ну а реверс нужен не всем. ТС'у, для сохранения/чтения данных он явно ни к чему.

[optima]

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

[Ser-B]

Увеличил тактовую частоту с помощью PLL с 8МГц до 24МГЦ.

RCC->CR |= ((uint32_t)RCC_CR_HSEON);
while((RCC->CR & RCC_CR_HSERDY) == 0) { }

RCC->CFGR = (RCC->CFGR & (~RCC_CFGR_PLLMUL)) | RCC_CFGR_PLLMUL3 | RCC_CFGR_PLLSRC_HSE_PREDIV; // (6)

RCC->CR |= RCC_CR_PLLON; // (7)
while((RCC->CR & RCC_CR_PLLRDY) == 0) // (8)
{

}

RCC->CFGR |= (uint32_t) (RCC_CFGR_SW_PLL); // (9)
while ((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL) //(10)
{

}
RCC->CR &= ~((uint32_t)RCC_CR_HSION);
while((RCC->CR & RCC_CR_HSIRDY) == 0) { }

Стал виснуть MK при записи во flash на
*(__IO uint16_t*)(Address) = (uint16_t)data;

[VladislavS]

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

FLASH->ACR = FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY_1;

[Ser-B]

Не помогает.
Да и FLASH_ACR_LATENCY ставится если SYSCLK > 24MHz

Добавлено after 10 minutes 16 seconds:
Полжение дел одинаковое на stm32f030 и stm32f071

[Reflector]

Ser-B писал(а):

RCC->CR &= ~((uint32_t)RCC_CR_HSION);
while((RCC->CR & RCC_CR_HSIRDY) == 0) { }

Стал виснуть MK при записи во flash на
*(__IO uint16_t*)(Address) = (uint16_t)data;

Запись во флеш тактируется от HSI, который ты отключил.

[Ser-B]

Благодарю. Заработало.