flash массив в AvrStudio

[DenChik87]

Необходимо сохранить рассчитываемые данные во флэш, в виде массива используя AVRStudio. Для этого определил место под пятьсот значений переменных типа char во флэш так:
unsigned char mass[500]PROGMEM={};

Далее пытаюсь записать значения в этот массив:
mass[i]PROGMEM=data - но такая форма записи недопустима(компилятор ругается).
Подскажите как можно организовать алгоритм записи переменных в i-й адрес массива зарезервированный во флешь ?

[uk8amk]

AVR106: C functions for reading and writing to Flash memory
AVR109: Self Programming

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

[Z_h_e]

Атрибуты для GCC имеют несколько более длинную запись для указания сегмента памяти. Для короткой записи PROGMEM есть дефайн.
Нужно #include <avr/pgmspace.h>

Кроме того, данные во флеш не могут быть переменными, только константа.
const unsigned char mass [2] PROGMEM =
{0,0};

[ARV]

настоятельно рекомендую перейти на свежие версии AVR-GCC, в которых полноценно реализована поддержка пространства памяти __flash: больше никаких pgm_read_byte!

Добавлено after 2 minutes 33 seconds:

Кроме того, данные во флеш не могут быть переменными, только константа.
const unsigned char mass [2] PROGMEM =
{0,0};

нет, в WinAVR const не является необходимым (лично я PROGMEM всегда пишу на первом месте PROGMEM char mass[] = "str";). а вот в свежих версиях, как я выше советовал, для __flash необходимо и const указывать.

[COKPOWEHEU]

Ну, для старых WinAVR'ов оно так, но более современные avr-gcc уже требуют обязательного const.
Можете привести пример обойтись __flash'ом без ручного дерганья регистров? Мне казалось, что использование специальных функций это не только лень разработчиков, но и сигнал пользователю что эта операция не так проста. В частности я не знаю что произойдет при перезаписи страницы, с которой программа исполняется в данный момент.

[ARV]

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

я не совсем понял, о какой ситуации вы говорите? я пока что в своей практике ни разу ничего не дёргал при работе с FLASH... все время полагаюсь на компилятор и библиотеку... опыт у меня, разумеется, не слишком обширный... и с микроконтроллерами, у которых FLASH больше 64К работал совсем немножко... и тем более не писал бутлоадеров, которые что-то там в страницах FLASH переписывают...

так что или уточните, или извините

ну а по поводу примера - вам ли он требуется?! я лично приятно удивлен тем, как свежак GCC раскручивает "указатель, находящийся в ОЗУ, указывающий на указатель во FLASH, который указывает на указатель во FLASH, который указывает на функцию". написал что-то вроде
ptr1->ptr2->ptr3->func(); и все проблемы, и какой там указатель const, а какой __flash, компилятор сам разбирается.

удобно.

[COKPOWEHEU]

Если упростили чтение из EEPROM, сумев обойтись без pgm_read_* - отлично. Впрочем, как и ожидалось, это не так. Следующие записи эквивалентны и попрежнему требуют pgm_read_*

Код:

PROGMEM const char var;
__flash const char var;

Проверил на последней доступной версии gcc-4.9.2

я не совсем понял, о какой ситуации вы говорите?

ТС-у надо не только читать из flash, но и писать туда. Отсюда и вопрос что будет с программой, меняющей собственную прошивку.

ну а по поводу примера - вам ли он требуется?!

Не сталкивался с таким, поэтому и интересно

[Z_h_e]

Я думаю ТСу не надо писать в массив, а имел он ввиду инициализацию массива. Видимо проблема решена и он молча устранился из своей же темы.

[ARV]

Если упростили чтение из EEPROM, сумев обойтись без pgm_read_* - отлично. Впрочем, как и ожидалось, это не так.

вы меня подозреваете в дезинформировании уважаемого сообщества?!

Код:

const __flash char bytes[] = {1,2,3,4,5};

for(uint8_t i=0; i<5; i++)
   PORTB = bytes[i];

и никаких pgm_read_xxx

кстати, я не самый тщательный выискиватель, но у меня в ходу avr-gcc 6.3.0, в которой есть LTO-оптимизация, выжимающая последние байты экономии

[COKPOWEHEU]

Беглый поиск не дал результатов по gcc-avr выше 4.9, в репах (даже unstable) тоже самое. Собирать руками смысла не вижу. Обычный gcc уже давно обновился до 6 версии. Так что для типичного компилятора все верно.

[oleg110592]

http://blog.zakkemble.co.uk/avr-gcc-6-1-0/
в файле "gcc.info":

Per default, any data including read-only data is located in RAM (the
generic address space) so that non-generic address spaces are needed to
locate read-only data in flash memory _and_ to generate the right
instructions to access this data without using (inline) assembler code.

'__flash'
The '__flash' qualifier locates data in the '.progmem.data'
section. Data is read using the 'LPM' instruction. Pointers to
this address space are 16 bits wide.

'__flash1'
'__flash2'
'__flash3'
'__flash4'
'__flash5'
These are 16-bit address spaces locating data in section
'.progmemN.data' where N refers to address space '__flashN'. The
compiler sets the 'RAMPZ' segment register appropriately before
reading data by means of the 'ELPM' instruction.

[ARV]

Беглый поиск не дал результатов по gcc-avr выше 4.9, в репах (даже unstable) тоже самое. Собирать руками смысла не вижу.

я тоже не вижу смысла собирать руками, тем более что у меня они не заточены под такую тонкую работу
поэтому я наискал себе уже собранные версии: 4.9.2, 5.2.1, 6.1.1 и 6.3.0

и не жужу