указатели в keil

VladislavS

[uquote="Ser-B",url="/forum/viewtopic.php?p=3455239#p3455239"]Всего лишь хотел передать суть проблемы.[/uquote]Суть вам описали в первом же ответе.

[uquote="Ser-B",url="/forum/viewtopic.php?p=3455239#p3455239"]В М3 действительно все было норм, а М0 такая вот ерунда.[/uquote]Ну да, M3 умеет невыровненный доступ.

[uquote="Ser-B",url="/forum/viewtopic.php?p=3455239#p3455239"]Задача записывать во флеш настройки скопом из всех массивов и считывать в массивы при включении мк.[/uquote]Откройте для себя memcpy.

Реклама

jcxz

[uquote="Ser-B",url="/forum/viewtopic.php?p=3455239#p3455239"]Проблема исчезла при объявлении 32-разрядных массивов. Правда, появился дополнительный расход памяти.[/uquote]
Не знаю как там в кейл, но в 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

[uquote="jcxz",url="/forum/viewtopic.php?p=3455757#p3455757"]И если объявить long-переменную с этим префиксом, то даже на МК не поддерживающих невыровненный доступ, обращения к таким невыровненным переменным будет происходить как по-маслу - без HF.[/uquote]ТС злобный буратино, он невыровненный доступ с помощью приведения типа указателя получает. Против лома никакой __packed не спасёт. Если он захотел 32-битный доступ, то он его получит.

Реклама

Z_h_e

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

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

Alex писал(а):Или просто в union их объединить.

Реклама

VladislavS

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3455910#p3455910"]Лучше объявить массив с 32х битными элементами[/uquote]Вот нахрена эти извращения? ТС написал, что это копирование происходит ОДИН РАЗ ПРИ СТАРТЕ ПРОГРАММЫ для считывания конфигурации. На чём экономить собрались? Микросекунда при старте погоду сделает?

Реклама

ПростоНуб

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

Ser-B

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

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

Ser-B

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

ПростоНуб

[uquote="Ser-B",url="/forum/viewtopic.php?p=3456040#p3456040"]В memcpy реализована процедура записи во flash?[/uquote]
Нет, но ссылку на исходник memcpy, обеспечивающий оптимальную скорость копирования я привел выше. Берите его за основу. Если, конечно, не жалко flash.
Я в таких случаях предпочитаю пользоваться EEPROM или AT24C*

Ser-B

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3456054#p3456054"]Если, конечно, не жалко flash.[/uquote]
Почему её должно быть жалко? Запись происходит максимум несколько десятков раз за всю жизнь девайса. Объем флеша МК вполне позволяет.

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 плюс еще пару команд.

Копирование маленьких объёмов данных с помощью 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

[uquote="Ser-B",url="/forum/viewtopic.php?p=3509430#p3509430"]RCC->CR &= ~((uint32_t)RCC_CR_HSION);
while((RCC->CR & RCC_CR_HSIRDY) == 0) { }

Стал виснуть MK при записи во flash на
*(__IO uint16_t*)(Address) = (uint16_t)data;[/uquote]
Запись во флеш тактируется от HSI, который ты отключил.

Ser-B

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