Программная запись 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 (которого и так не много) навсегда;
- мало того еще надо лезть и править скрипт линкера;
- при переносе программы между компиляторами код работать не будет, т.к. надо еще и учитывать особенности компилятора.

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