А это по стандарту? Это как-то подменяется на memcpy неявно?

у меня тоже такой вопрос возник. посмотрел в листинг но там ассемблер ничего не понятно.

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

Не забудьте также разместить функции работы с флэш в ОЗУ (требование процессора). В библиотеке уже все подготовлено, но в среде разработки в скаттер-файле надо указать разместить секцию ram_code в ОЗУ. Для KEIL это будет модификация подсекции загрузки ОЗУ:

спасибо большое за ЦУ. а __attribute__ ((section(".ram"))) не поможет? вроде как это тоже указание на размещение функции в ram.

Сообщение отредактировал IgorKossak - Nov 25 2014, 15:10

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

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

Функции работы с флэшем в библиотеке для EFM32 уже объявлены и "сложены" в именованную секцию "ram_code", поэтому нужно секцию "ram_code" лишь как-то поместить в ОЗУ. Как написано в помощи к функции WriteWord

Кстати, коль мы о секциях заговорили.
Вы можете разместить структуру напрямую в пользовательской странице и работать с ней в коде программы как с нормальной константой во flash:

В скаттере надо указать, чтобы все константы секции были размещены в пользовательской странице, то есть добавить load region

В итоге, можно иметь константы, объявленные в разных участках кода, разных файлах проекта, но принадлежащие одной и той же именованной секции, как это показано выше, и пользовать их как обычные константы. А компоновщик кинет все в нужную область флэша согласно указанию из скаттера. Затем можно, например, через коммуникационный протокол модифицировать все эти константы, настраивая таким образом приложение. Например, сменить адрес узла, и т.п. И не надо хранить "копии" настроек из флэш в ОЗУ: в конце концов ОЗУ в контроллерах всегда существенно меньше, чем флэш.

Сообщение отредактировал KnightIgor - Nov 25 2014, 17:40

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

Если параметры во флэше, - а я бы назвал это настройками, - обновляются не по 10 раз в секунду, а в какие-либо ключевые моменты жизни приложения, после чего последнее пользуется результатами и делает свою работу, то почему же не удобно обновлять прямо во флэше? Например, коэффициенты коррекций и поправок в системе с ADC, и т.п. Ну, вначале, при калибровке, может и надо будет раз 20 перезаписать настройки, но потом они будут довольно долго неизменны. Или вот пример из нашей практики. Надо управлять светодиодами через ШИМ. Характеристка вход-выход выражается степенной функцией (гамма-коррекция). Если считать на лету каждый раз по формуле для нескольких каналов, можно перегрузить процессор. Можно работать и по таблице, но ее надо качать по каналу. Мы же меняем показатель (гамму) короткой командой, а процессор тут же единожды вычисляет и создает таблицу, которой потом и пользуется постоянно. Все во флэше.

это совершенно разные вещи.

так структуру объявлять не правильно, тем более для 32-х разрядного проца. Нужно выравнивать к 4-ём. Чтоб не париться над выравниванием лучше в структуре сначало объявить 32-х битные переменные ,потом 16-ти, затем 8-ми.

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


ну то есть у вас в коде это константы и вы их изменить не можете из программы. И есть дополнительные функции которые просто меняют область флеши, фактически не думая что там лежит и тем самым обходят защиту const.
В целом решение, проблему вижу только при изменении структуры настроек во время модификации кода, надо не забыть поправить ее в 2 местах. То есть и саму структуру и функции ее сохранения-модификации во флеше.

как я понял если не указывать явно packed компайлер по дефолту делает padding.



Я пишу в Attolic TrueStudio и я честно говоря не нашел там скаттер файл.

Это было не объявление структуры.

Если структура в флэш-памяти может меняться в процессе работы программы, её следует объявлять как const volatile.


Эта проблема - вовсе не проблема. Для этого существует X Macro.