Программная запись FLASH AT91SAM7S128 Опции

[MiklPolikov]

at89sam7s128

Нужно сохранять данные при отключении питания.

Через указатель на Internal Flash (адреса с с 0x00100000 по 0x0020000) получается только читать.

сhar *pnr;
pnr= (char*) 0x00100001;
*pnr=0x33;

Этот код выполняется но во FLASH ничего не записывается.

Как записать во FLASH ?


Спасибо !

Сообщение отредактировал MiklPolikov - Dec 26 2008, 07:24

[aaarrr]

Способ потенциально небезопасный (iap_PageWrite не ROPI, размер его может и превысить 128 байт, стека может и не хватить и т.п.).
Стоит ли ради экономии полутора сотен байт RAM так напрягаться?

[defunct]

Способ потенциально небезопасный (iap_PageWrite не ROPI, размер его может и превысить 128 байт, стека может и не хватить и т.п.).
Стоит ли ради экономии полутора сотен байт RAM так напрягаться?

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

PS: iap_PageWrite в RAM не копируется, ибо незачем, копируется только iap_FlashCmdFunc.
Пользователю предоставляется только iap_PageWrite(..) выполняемая из FLASH.

[aaarrr]

Стоит, т.к. лучше эту полусотню байт к стеку добавить.

На стеке это все же просто мертвый груз.

PS: iap_PageWrite в RAM не копируется, ибо незачем, копируется только iap_FlashCmdFunc.
Пользователю предоставляется только iap_PageWrite(..) выполняемая из FLASH.

Да, не заметил как-то, пардон. Тогда тем более лучше воткнуть эту процедуру средствами линкера, т.к. это даже меньше полусотни байт.

[defunct]

На стеке это все же просто мертвый груз.

Кто мертвый груз?
Освободившуюся память можете отдать под что угодно, как вариант - увеличить объем стека.
А Вы о чем?

Тогда тем более лучше воткнуть эту процедуру средствами линкера, т.к. это даже меньше полусотни байт.

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

[aaarrr]

Кто мертвый груз, вы о чем?

О том, что эти несчастные 128 байт надо добавить к стеку заранее, хотя задействованы они будут "раз в пятилетку".

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

Хотя бы тем, что не будет такого маразма при каждом вызове iap_ExecCmd:
- выделили 128 байт на стеке
- скопировали туда 128 байт с начала iap_FlashCmdFunc, не разбираясь, надо ли так много

[defunct]

О том, что эти несчастные 128 байт надо добавить к стеку заранее, хотя задействованы они будут "раз в пятилетку".

Я так понимаю вы сейчас пишите в контексте, как бы это сказать, некоего ОСа, в котором используются отдельные маленькие стеки для каждой задачи. Верно? Если я прав, то конечно вам нельзя себе позволить разместить автоматическую 128-ми байтовую переменную в стеке. Но это сугубо ваша проблема, а не проблема предложенного подхода.

Я же пользую общий стек для всех задач, поэтому никогда не испытываю проблем с его объемом. Я могу себе позволить выделить в стеке буфер под например 1.5KB Ethernet пакет, без задней мысли. Поэтому выделить 128 байт в стеке это для меня не проблема, настолько же насколько объявиление переменной типа int.

к слову в оригинальном коде, память я выделяю из пакетного пула:

Код

void iap_ExecCmd( U32 FCR_val)
{
    PPACKET_BUF pPacketDesc = pool_AllocPart();
    U32 ThumbMode = (U32)iap_FlashCmdFunc & 0x01;

    while (!pPacketDesc)
    {
        Kernel_Dispatch();
        pPacketDesc = pool_AllocPart();
    }
    ...

А специально для форума подготовил код использующий стек-фрейм, т.к. он получается отвязанным от конкретной реализации.

Большой стек у меня получается вчастности за счет того, что в программе практически нет лишнего статически распределенного мусора. Как например функций записи страницы флеш.

Хотя бы тем, что не будет такого маразма при каждом вызове iap_ExecCmd:
- выделили 128 байт на стеке
- скопировали туда 128 байт с начала iap_FlashCmdFunc, не разбираясь, надо ли так много

С другой стороны не будет и такого маразма как в вашей реализации:
- Откусили ~n-байт от RAM (которого и так не много) навсегда;
- мало того еще надо лезть и править скрипт линкера;
- при переносе программы между компиляторами код работать не будет, т.к. надо еще и учитывать особенности компилятора.

Насчет скопировали неразбираясь надо ли так много, а стоит ли оно того это разбирательство? По скорости никто не жмет, т.к. непосредственно запись страницы флеш длится на порядки дольше чем это избыточное копирование.

[aaarrr]

Но это сугубо ваша проблема, а не проблема предложенного подхода.

Нет, не моя. Выделять на стеке огромные объекты - это не лучший подход в любом случае.

С другой стороны не будет и такого маразма как в вашей реализации:
- Откусили ~n-байт от RAM (которого и так не много) навсегда;
- мало того еще надо лезть и править скрипт линкера;
- при переносе программы между компиляторами код работать не будет, т.к. надо еще и учитывать особенности компилятора.

n в районе <50, неужели в ваших проектах настолько плохо с RAM?
Владение инструментарием - это норма, а не маразм.

[defunct]

Нет, не моя. Выделять на стеке огромные объекты - это не лучший подход в любом случае.

128 байт это не огромный объем, это сравнимо с контекстом регистров процессора (16x4), поэтому не делайте из мухи слона на ровном месте.

n в районе <50, неужели в ваших проектах настолько плохо с RAM?

Как говорится, с мира по нитке, глядиш и набежит KB, а это уже существенно.

Владение инструментарием - это норма, а не маразм.

Выделили и скопировали - это тоже норма, а не маразм, при динамическом распределении памяти.

[aaarrr]

Как говорится, с мира по нитке, глядиш и набежит KB, а это уже существенно.

И кто теперь делает из мухи слона?

Выделили и скопировали - это тоже норма, а не маразм, при динамическом распределении памяти.

Только скопировали то, что:
1. Сгенерировано компилятором
2. Для вырезания и копирования не предназначено

Т.е. теоретически имеет право не работать.

[defunct]

Только скопировали то, что:
1. Сгенерировано компилятором
2. Для вырезания и копирования не предназначено

Т.е. теоретически имеет право не работать.

Если бы мы обсуждали некий гипотетический способ достижения цели, можно было бы порассуждать теоретически.
А так имеется конкретный __рабочий__ код, стоит ли вспоминать о его теоретическом праве? ;>

[aaarrr]

Если бы мы обсуждали некий гипотетический способ достижения цели, можно было бы порассуждать теоретически.
А так имеется конкретный __рабочий__ код, стоит ли вспоминать о его теоретическом праве? ;>

Этот "рабочий" код с легкостью может реализовать свое право и стать __нерабочим__ при смене компилятора или опций оптимизации.

[defunct]

Этот "рабочий" код с легкостью может реализовать свое право и стать __нерабочим__ при смене компилятора или опций оптимизации.

Ключевое слово "может" реализовать, и также слегкостью может и не реализовать.
Для успокоения, можно отключить оптимизацию одной функции (той что копируется), но думаю и этого делать не потребуется.

В отличие от вашего подхода, когда код жестко привязывается к конкретному компилятору, и при переносе однозначно становится нерабочим.

[aaarrr]

В отличие от вашего подхода, когда код жестко привязывается к конкретному компилятору, и при переносе однозначно становится нерабочим.

Код у меня ни к чему не привязывается, а уж скрипт линкера в любом случае менять придется. И нерабочим такой код назвать нельзя, тут вы теплое с мягким путаете.

Ключевое слово "может" реализовать, и также слегкостью может и не реализовать.

При переходе дороги на красный свет вас может сбить машина. Так что, будем ломиться на красный?

[defunct]

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

Зачем его менять в любом случае?
Кто мешает писать так, чтобы не надо было менять.

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

некоторые компиляторы требуют атрибут __ram, и т.п. так, что ничего я не путаю.

При переходе дороги на красный свет вас может сбить машина. Так что, будем ломиться на красный?

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

[aaarrr]

Зачем его менять в любом случае?
Кто мешает писать так, чтобы не надо было менять.

Никто не мешает, если это не противоречит правилам. Ваш пример противоречит.
Хотите использовать какой-нибудь simple memory map и визарды - да флаг в руки, только далеко не всегда это возможно.

...ничего я не путаю.

Работоспособность кода и возможность собрать его компиляторами X и Y - абсолютно разные вещи.

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

Это не подземный переход, а канализационный коллектор.

[defunct]

Ваш пример противоречит.

Вашим правилам он противоречит что ли? Ну так не делайте так, если он противоречит вашим правилам.

Работоспособность кода и возможность собрать его компиляторами X и Y - абсолютно разные вещи.

Невозможность собрать приводит к неработоспособности кода. очевидно.

[aaarrr]

Вашим правилам он противоречит что ли? Ну так не делайте так, если он противоречит вашим правилам.

И моим в том числе. Делать не буду, и другим не советую.

Невозможность собрать приводит к неработоспособности кода. очевидно.

Невозможность собрать приводит к отсутствию предмета как такового, ничуть не влияя на его потенциальную работоспособность.

[defunct]

Делать не буду, и другим не советую.

А я советую делать так. По крайней мере для сохранения конфигурации способ идеален по следующим причинам:

1. Накладные постоянные расходы RAM - 0.
2. Код всегда лежит во флеш, т.о. он не может быть случайно перетерт.
3. Можно забыть, что такое скрипты линкера.
4. Вопреки опасениям уважаемого aaarrr, никаких проблем с переносом между компиляторами и установленным уровнем оптимизации нет. Специально попробовал в трех компиляторах IAR 4.40, RVDS 3.1 и Keil CA последний, все с максимальным уровнем оптимизации (т.е. один раз написав код, перенос между компиляторами не требует никаких правок, ни сам код ни скрипты ничего менять не надо). Ну а если вдруг при использовании какого-то компилятора (допускаю) случится худшее и код откажется работать, нужно будет отключить оптимизацию одной функции (iap_FlashCmdFunc() в примере) и все.

[aaarrr]

1. Накладные постоянные расходы RAM - 0.

Даже с этим можно поспорить, если нет кучи или другого подобного источника памяти.

2. Код всегда лежит во флеш, т.о. он не может быть сучайно перетерт.

В нормальной программе ничего не может быть случайно перетерто.

3. Можно забыть, что такое скрипты линкера.

Но лучше все же помнить.

4. Вопреки предположениям уважаемого aaarrr, никаких проблем с переносом между компиляторами и установленным уровнем оптимизации, специально попробовал в трех компиляторах IAR 4.40, RVDS 3.1 и Keil CA последний, все с максимальным уровнем оптимизации (т.е. один раз написав код, перенос между компиляторами не требует никаких правок).

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

Можно написать эту процедуру на асме, тем самым гарантировав ее переносимость, и спокойно копировать в ОЗУ. Но нельзя переносить результат работы компилятора. Даже когда все кажется очевидным и безопасным.

[defunct]

Можно написать эту процедуру на асме, тем самым гарантировав ее переносимость, и спокойно копировать в ОЗУ.

Или наоборот непереносимость, т.к. ситаксис ассемблера может отличаться.

Да и вы начинаете сами себе противоречить.
то

Для данного конкретного случая вполне очевидный результат.

то

Но нельзя переносить результат работы компилятора. Даже когда все кажется очевидным и безопасным.

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