Мелкие вопросы по МК и ПЛИС.

ploop

RAM? Изнашивается?

Это такое же ОЗУ (оперативная память), как у вас на компьютере.

Реклама

zero648

Alexeyslav писал(а):Собственно, если вам надо хранить какие-то данные которые часто меняются но их надо запоминать при обесточивании - храните их в RAM!!! EEPROM здесь вообще не при делах, она задействуется только при исчезновении питания и начальной загрузке.

Здрасте

, как раз чтобы сохранить данные без питания их помещают в EEPROM, а RAM без питания ничего не сохраняет.

Реклама

ploop

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

Prosperous

Друзья, ну ответьте, кто - нибудь. Правильно я делаю начальную инициализацию EEPROM или нет??? И еще, а как размазывать данные в ячейках памяти? Их же как-то отслеживать надо.

Реклама

ploop

Что размазывать? Зачем?
Сказали уже - в EEPROM постоянно писать не нужно. Если у вас часто изменяются данные, храните (и изменяйте сколько влезет) их в ОЗУ, считывая туда из EEPROMа при включении, и записывая обратно в EEPROM при выключении питания.

Реклама

Prosperous

Да я это все понял, тут в некоторых темах советуют сохранять данные в разные ячейки ЕЕПРОМ, что повышает ресурс памяти. А как это организовать? Типа цикла какого - нибудь делать с заранее известными ячейками? или в рандомные пишется и как - то отслеживается?

Реклама

ploop

Как часто устройство будет включаться/выключаться? При условии, что 1 раз в день (ежедневно) , ресурса ячейки тебе хватит на 27 лет.

Alexeyslav

273 года для EEPROM, 27 лет это если хранить в основной памяти, но программная запись туда возможна только из бутлоадера.

Переменные в RAM будут хранится, а в EEPROM - эвакуироваться.

ploop

Я имел ввиду ресурс перезаписи, у них около 10000 если память не изменяет...

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

В смысле? А SPM для чего?

Alexeyslav

Так вот SPM и работает только из бутлоадера, попытка использовать команду из основной программы ни к чему не приведет. Это сделано для того чтобы программа не могла убить сама себя и основную ФЛЕШ-память при ошибке или из каких-то других соображений. На некоторых контроллерах вовсе нет бутлоадера, и команда SPM является простым балластом.

ploop

Хотел поспорить, но глянул даташит.

ATmega48A/48PA/88A/88PA/168A/168PA/328/328P support a real Read-While-Write Self-Programming mechanism. There is a separate Boot Loader Section, and the SPM instruction can only execute from there. In ATmega 48A/48PA there is no Read-While-Write support and no separate Boot Loader Section. The SPM instruction can execute from the entire Flash.

Вот на 48й я её и испытывал

Alexeyslav

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

avreal

ploop писал(а):Хотел поспорить, но глянул даташит.
...

Ну и ладушки.
Там, где есть бут-лоадер, подпрограмму записи можно разместить в секции бут-лоадера и вызывать ее откуда угодно.
Там, где бут-лоадера нет (mega48, tiny13, …), там SPM выполняется из откуда угодно, просто выполнение программы тормозится до конца записи, так как нет области RWW.

Вот где засада, так это в tiny4..10/20/40
Но у них команды SPM и нет. У них и LPM нет, флеш мапится с адреса 0x4000 для чтения обычными LDS/LD/LDD.
Если бы ещё STS/ST/STD на флеш работали

А то ни EEPROM нет, ни возможности записи во флеш изнутри. Итого мимо меня.

Alexeyslav

Флеш всеравно не выгодно использовать для хранения условно-переменных данных, у нее ресурс в 10 а то и в 100 раз меньше чем у EEPROM.

ploop

Мне на самом деле ни разу не приходилось применять SPM. Испытывал помню, давно, но ради спортивного интереса. EEPROM-ки пока хватало на всё.

avreal

Alexeyslav писал(а):Это сделано для того чтобы программа не могла убить сама себя и основную ФЛЕШ-память при ошибке или из каких-то других соображений.

Для этого есть фьюз BOOTEN (у имеющих область бут-лоадера, скажем, у меги88) и SELFPRGEN (у не имеющих области бут-лоадера, скажем, у меги48, тини13).

Alexeyslav писал(а):На некоторых контроллерах вовсе нет бутлоадера, и команда SPM является простым балластом.

У каких контроллеров команда SPM есть, но не рабочая? Я не очень бут-лоадерами интересуюсь, мож что и пропустил.

avreal

Alexeyslav писал(а):Флеш всеравно не выгодно использовать для хранения условно-переменных данных, у нее ресурс в 10 а то и в 100 раз меньше чем у EEPROM.

Так «невыгодно» или «невозможно, команда- балласт»

?
Да и что значит «невыгодно»?
Для каких-то данных и EEPROM может мало быть, FRAM не зря придумали.
Для каких-то и флеша хватит. Вон у MSP430 и всяких прочих ARM-ов EEPROM «не частый гость» и ничего.
Если в среднем данные нужно раз в день писать, то и флешовые 10 тысяч (однотысячные разве сейчас остались?) это 27лет, как уже писали.
Не знаю, как у кого, мои серийные устройства больше 12-14 лет пока не работали.
С выделением бОльшей области и размазыванием записей для такого срока можно и раз пять в день писать.

Prosperous

ploop писал(а):Как часто устройство будет включаться/выключаться? При условии, что 1 раз в день (ежедневно) , ресурса ячейки тебе хватит на 27 лет.

Я делаю прошивку и отдаю устройство другим разработчикам, Которые будут его тестить уже с точки зрения своих нужд. Так что не могу точно сказать. В режиме отладки я думаю не больше 1000 раз. Потом вообще относительно редко.

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

Alexeyslav

Перезапись в разные ячейки - это другой уровень работы с ячейками. разделяешь всю память на кластеры, каждый кластер - размером с необходимую область для хранения твоих данных + 1 байт. Который если не равен $FF - значит данный кластер сейчас используется. Когда надо считать данные в первый раз - перебираешь все кластеры и останавливаешься на первом у которого этот признак не равен $FF. Каждая новая запись - в следующий по счету кластер. Чем больше кластеров тем реже каждый из них будет перезаписываться. Заодно перед записью проверять содержимое ячейки, если оно равно тому что надо записать - лишний раз её не дергать.

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

Prosperous

Спасибо за ответ