Перейти к содержанию
    

STM32, micro-eeprom в "Option bytes"

Необходимо иметь возможность хранить буквально несколько байт. Девайс low-density. Почитал на форуме про методики хранения в main flash memory - громоздко и не гибко. Собственно flash состоит из трёх блоков main(var), system(2kb) и option bytes(8b). В последнем блоке есть 8 байт памяти:

"4 for write protection, 1 for read protection, 1 for configuration and 2 for user data storage"

Ну два байта(user data), понятно, можно использовать, хочется ещё первых четыре заюзать(WP которые). Собственно, из документации понял что при активации read protection(RP) первые несколько страниц(количество зависит от density) основного flash блокируются на запись, а оставшиеся страницы могут быть перезаписаны только программой(не отладчиком).

Так ли необходима защита от записи основной памяти? Если в программе нет кода совершающего такие действия, то даже при слёте PC по идее прошивка не будет испорчена. Или я ошибаюсь?

 

Такой способ, по идее, позволит сохранять информацию минимальным кодом(и без какой либо опастности для программы). А загрузка происходит вообще автоматом(в "регистры": FLASH_OBR и FLASH_WRPR)

 

PS: с ARM'ами только начинаю работать и железа ещё не видел - выясняю необходимый минимум внешних деталей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Необходимо иметь возможность хранить буквально несколько байт. Девайс low-density.

 

Что значит low density в контексте микропроцессорной техники? Поясните, чтот-то я пропустил...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

low-density это применительно конкртено к линейке МК серии STM32. Это не столь важно, просто размер флэша ограничен(low <= 32kB), и не хочется засорять его лишним кодом.

А насчёт FRAM(уже смотрю): именно этого и не хочется, чтобы для хранения нескольких чисел(которые будут очень редко изменяться, за время жизни устройства от силы раз 10 :) ) использовать внешние микросхемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

за время жизни устройства от силы раз 10 :) ) использовать внешние микросхемы.

 

гы, а в LPC23 случаем нету тоже каких пару байт энергонезависимой и чтобы без IAP и батареек? мечты :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

low-density это применительно конкртено к линейке МК серии STM32.

 

слово density там только один раз встретилось -

improved performance with better code density

так что я все равно не понял... но звучит непонятно и красиво. Больше вопросов нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

слово density там только один раз встретилось -

improved performance with better code density

так что я все равно не понял...

Плохо смотрите. Откройте любой даташит на STM32 и в первой же строке будет, к примеру для STM32F103xB -

Medium-density performance line ARM-based 32-bit MCU...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Необходимо иметь возможность хранить буквально несколько байт.

А насчёт FRAM(уже смотрю): именно этого и не хочется, чтобы для хранения нескольких чисел(которые будут очень редко изменяться, за время жизни устройства от силы раз 10 :) ) использовать внешние микросхемы.

Всего несколько чисел и от силы 10 раз изменятся? Вам никакой EEPROM не нужен. Выделяем в главной флэш участок байт в 128, данные приписываем в конец по мере обновления, этого хватит на Ваши нужды без всяких стираний.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Идея понятна, но универсальности хочется - не считать же, сколько раз производилось сохранение новых параметров (при возникновении сбоев иногда приходится покрутить их в ту или иную сторону по нескольку раз). Да и кода будет больше чем в моём варианте (загрузка данных будет с перебором до первых FF'ов). То что ничего внешнего цеплять не нужно уже уяснил :).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Необходимо иметь возможность хранить буквально несколько байт...

 

PS: с ARM'ами только начинаю работать и железа ещё не видел - выясняю необходимый минимум внешних деталей.

Подскажите документ, по которому Вы ориентировались по работе с Flash-памятью,плиз :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Идея понятна, но универсальности хочется - не считать же, сколько раз производилось сохранение новых параметров (при возникновении сбоев иногда приходится покрутить их в ту или иную сторону по нескольку раз). Да и кода будет больше чем в моём варианте (загрузка данных будет с перебором до первых FF'ов). То что ничего внешнего цеплять не нужно уже уяснил :).

ИМХО, надуманная проблема. Кода совсем немного требуется. Сделайте правильно - но пожалеете. "Правильно" - это как Вам посоветовали :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...