Запись и чтение массива, расположенного во флеш в ИАР и winAVR.., Нужна помощь. Опции

[skyled]

Вот такой код написан под ИАР. Мне нужно его переписать под WinAVR чтобы тоже во флеш и как из флеши читать потом блоком по три значения? Спасибо.

Код

__flash u8 rf_fram_table[][3]={
  
{0x30,0x98,0x40},
{0x31,0xff,0x8f},
{0x32,0x80,0x28},
{0x33,0x80,0x56},
{0x34,0x4E,0xF6},
{0x35,0xF6,0xF5},
{0x36,0x18,0x5C},
{0x37,0xD6,0x51},
{0x38,0x44,0x44},
{0x39,0xE0,0x00}
};

[MrYuran]

Вот, навскидку.
Или ещё поищите

[skyled]

Это я знаю. Там запись и чтение одного байта, а не блока.

[MrYuran]

Это я знаю. Там запись и чтение одного байта, а не блока.

Не совсем понял: а чтение блока это разве не многократное чтение байтов?

[skyled]

Да, многократное, но в том и соль чтоб использовать массив как есть, не переделывая под чтение одиночных байт. Думал может можно как-то проще. В ИАРе же есть такая возможность.

[=GM=]

в том и соль чтоб использовать массив как есть, не переделывая под чтение одиночных байт. В ИАРе же есть такая возможность

Интересно, а как вы читаете массив в IAR, не переделывая под чтение одиночных байт?

[MrYuran]

Интересно, а как вы читаете массив в IAR, не переделывая под чтение одиночных байт?

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

[skyled]

Оно действительно так. Ну да чего уже, все переписал заново.

[777777]

Видимо, имелось в виду, что в ИАРе можно один раз определить переменную как _flash или _eeprom и дальше работать с ней как с обычной, без привлечения дополнительных функций.

Это как, подробнее можно? Для каждого присваивания выполняется запись через регистры EEPROM? А как же ожидание готовности? Или компилятор считает, что программисту не фиг обращать внимание на такие мелочи?

[Сергей Борщ]

Для каждого присваивания выполняется запись через регистры EEPROM?

Да.

А как же ожидание готовности? Или компилятор считает, что программисту не фиг обращать внимание на такие мелочи?

А вы считаете, что создатели компилятора, которые предусмтрели запись через регистры EEPROM настолько глупы, что не догадались организовать и ожидание готовности?

[777777]

А вы считаете, что создатели компилятора, которые предусмтрели запись через регистры EEPROM настолько глупы, что не догадались организовать и ожидание готовности?

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

[_Pasha]

Не говоря уже о том, что запись в EEPROM имеет ограниченный ресурс, поэтому при выполнении ее простым

Все же, в ГЦЦ сильно не хватает указанных фич, а именно - чтоб был предусмотрен insn для работы с данными, находящимися в определннном сегменте. Вот было бы б!....

[Сергей Борщ]

но когда программист будет присать свой код, ему не мешало бы знать,

Когда программист пишет свой код, ему не мешало бы думать. Это не компилятор, это программист захотел в этом месте использовать переменную, расположенную в EEPROM, а не ее локальную копию в ОЗУ. Если он пользуется инструментом не думая - сам себе злобный Буратина и не нужно пенять на компилятор, который предоставляет думающим программистам удобный способ обращения. Не нравится, хотите врукопашную - вперед, никто (а тем более компилятор) не запрещает писать в регистры EEPROM ручками. Быстрее код от этого не станет, а вот сложнее - однозначно.

Вот было бы б!....

Начиная с 4.5.0 в GCC появилась поддержка нескольких адресных пространств, которые будут в новом стандарте. Ждем...

[777777]

Не нравится, хотите врукопашную - вперед, никто (а тем более компилятор) не запрещает писать в регистры EEPROM ручками. Быстрее код от этого не станет, а вот сложнее - однозначно.

Ну вот я пишу в регистры EEPROM ручками. Естественно, код от этого стал быстрее. Потому что я использую для этого прерывания, имеется кольцевой буфер, куда помещаются ожидающие записи байты, откуда они по прерываниям записываются, не мешая ходу программы. EEPROM - это не область памяти, а фактически устройство, и "естественно" работать с ним именно по прерываниям, а не ожидая часами миллисекундами готовности. Мне кажется, это куда естественней, чем представлять его как память в некоем адресном пространстве, доступ к которому осуществляется экзотическим способом. Лучше честно предъявить пользователю этот способ, а уж он сам решит, как ему работать.

[Сергей Борщ]

Мне кажется, это куда естественней, чем представлять его как память в некоем адресном пространстве, доступ к которому осуществляется экзотическим способом. Лучше честно предъявить пользователю этот способ, а уж он сам решит, как ему работать.

Вот именно - способ предъявлен. Естественное обращение к отдельному адресному пространству. Ваше право решать - нравится или нет. Если вам лично не нравится - разработчики компилятора не виноваты. Они не лишали вас возможности творить ручками. Меня такой способ доступа устраивает. Пауза в несколько миллисекунд при старте программы меня не беспокоит нисколько - если надо быстрее, включите прибор на эти миллисекунды раньше. И паузы при записи меня не беспокоят ни разу, ибо запись происходит пару раз за все время жизни устройства и как правило под контролем оператора, а время его реакции несопоставимо больше. В итоге имею компактный и понятный код. По моим понятиям эта часть кода должна быть оптимальна с точки зрения размера, а прерывания/кольцевые буфера этому не способствуют.