Программная запись 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]

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

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

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

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

то

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

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

[aaarrr]

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

Переносимость не в смысле "возможность компиляции тулзом X" (что я вообще не считаю проблемой), а в смысле "возможность работы из любого адреса".

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

Вы не можете заранее знать, безопасно ли менять рабочий адрес процедуры. Если она, конечно, не состоит из шести команд (целых 24 байта ОЗУ сэкономили!) как в данном случае.

[defunct]

Переносимость не в смысле "возможность компиляции тулзом X" (что я вообще не считаю проблемой), а в смысле "возможность работы из любого адреса".

Ок, хорошо, с такой точки зрения согласен.
Но переносимость всмысле "возможность компиляции тулзом X" теряется. Хоть это и не проблема - но это время, наше время!
Зачем самое дорогое что есть, тратить на адаптацию кода к тулзу X?

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

Если она не содержит вызовов других функций, и не использует глобальных переменных, можно спокойно прогнозировать ее поведение при выполнении с любого адреса.
(т.е. важно чтобы функция всего навсего не содержала в себе адресацию через PC).
Как достичь - передать ей все требуемые данные в качестве параметров.

Если она, конечно, не состоит из шести команд (целых 24 байта ОЗУ сэкономили!) как в данном случае.

тем не менее 24 байта сэкономлено.