Устройство памяти в STM32

Доброго дня!!!
Разбираюсь STM32F411 в мануал пишут под GPIOA выделено памяти с адресным пространством с 0х4002 0000-0х4002 03FF если правильно считаю это 1Кб. для конфигурирования GPIOA нам доступны 10 32bitных регистра это 40 байт. Вопрос: Зачем для GPIO столько памяти выделено?

0

Сообщение от Roman2947 В STM32 нет EEPROM?

есть но не во всех, у stm32L.... есть

0

вообще чтение производится по адресу Addr & FFFF FFFC - это адрес ячейки памяти, а дальше в пределах Addr & 0000 0003 работает дешифратор ядра...
но сквозная адресация физических ячеек памяти и выделенных из них байт и полуслов - позволяют об этом не задумываться

0

Сообщение от ВитГо и затем уже дешифратор внутри cpu выполнит усечение значения до нужной размерности

откуда Вы все эти тонкости знаете

0

Сообщение от Roman2947 куда мне пользовательские настройки или данные сохранять теперь?

1 использовать кристаллы где есть
2 использовать внешнюю микросхему
3 использовать флэш как eeprom, например вот https://habr.com/ru/company/ruvds/blog/578690/

0

Сообщение от Roman2947 в AVR ах есть, а здесь что ж обделили. куда мне пользовательские настройки или данные сохранять теперь?

ну да, есть такое...

все зависит от того как часто эти пользовательские настройки меняются

я например даже на avr применял self-programing.. причем у меня во флеше был именно виртуальный диск (это к тем кто начинает писать о малом ресурсе перезаписи флеша :-) все там нормально с ресурсом :-)) я проверял)

ну или лепить внешний еепром - сейчас 8ми ногих spi интерфейсных много и на разный объем по типу 24lc32 и так далее... их вагон разных

Добавлено через 4 минуты

Сообщение от Roman2947 откуда Вы все эти тонкости знаете

даташит

и это вы еще не задумались о том что происходит при подключении по fsmc внешней памяти с разрядностью ШД в 16 бит :-) а ведь читать на ассемблере 32ух битные значения можно продолжать :-) и пофигу что у физической микросхемы всего половинный размер данных от требуемого :-)

0

ВитГо, с ресурсом там всё плохо. Это решается редкой записью и методами wear leveling.

0

Сообщение от Rius ВитГо, с ресурсом там всё плохо. Это решается редкой записью и методами wear leveling.

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

ну и wear leveling конечно тоже желателен, тут вопросов нет :-)

0

Там вроде заявлялось о ресурсе в 10000 циклов стирания. Если каждую секунду... в сутках всего 86400 секунд.
А запись при отладке это незначимая мелочь. Такими темпами можно было бы 13 лет перепрошивать каждый день

0

Сообщение от Rius А запись при отладке это незначимая мелочь. Такими темпами можно было бы 13 лет перепрошивать каждый день

а уж запись пользовательских настроек - так вообще вечность :-)

0

Сообщение от Roman2947 Почему не делают одну цельную 32 битную ячейку с одним адресом?

Потому что далеко не всегда на практике нужны такие большие переменные. Часто достаточно 8- или 16-битных, а ведь к ним тоже надо как-то обращаться.

Сообщение от ВитГо нет, а нужно ?

Да уж лишним бы не было. Все-таки ресурс у флеша поменьше будет.

0

Сообщение от COKPOWEHEU Да уж лишним бы не было.

BKPRAM не спасет ?

0

Там места малоооооооооооо .....

0

Сообщение от Rius ам места малоооооооооооо .....

эхх.. эт, точно (с) Товарищ Сухов...

ну тогда только 24lc... в принципе по spi проводов не много придется кидать...

0

Сообщение от ВитГо конечно можно

Я бы не был бы так уверен, что так всегда. Фишка в том, что сам факт доступа к данным (на чтение и на запись, в отдельности) тоже может иметь осмысленные и различные источники и приемники. Равно как и размерность запрошенных данных. Вот вам пример: на платформе AVR регистр USART DR имеет размер 16 бит. По идее вы можете прочитать его как 16бит, а можете прочитать как 2х8бит. И вот во втором случае двойное чтение этого регистра вернет вам совершенно не то, что Вы, возможно, ожидаете. Ну, и в случае с STM32 в общем, то же самое. Ну, или скажем, Вы не пробовали читать 32х битные регистры STM32 по не выровненным адресам, 32х битным чтением? ) Думаю, ничего хорошего Вы не получите. Это хорошо, если процессинг настолько будет умный, что хоть данные первого чтения сместит правильно, но насчет чтения следующей ячейки и ее правильного размещения в ответе я что-то сильно сомневаюсь.

Добавлено через 3 минуты

Сообщение от ValeryS 1 использовать кристаллы где есть

вдогонку, есть еще вариант OTP-memory (One-Time Programmable)

Добавлено через 1 минуту

Сообщение от Rius методами wear leveling

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

Добавлено через 1 минуту

Сообщение от ВитГо у меня по крайней мере не было ни одного обращения...

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

Добавлено через 7 минут

Сообщение от Rius с ресурсом там всё плохо. Это решается редкой записью и методами wear leveling.

Пожалуй, присоединюсь. И FLASH и EEPROM не вечные, ни по времени хранения, ни по количеству записей. Особенно "на улице", то есть в автомобиле и во дворе частного дома, когда температуры могут быть от -40 до +80 и даже +100 градусов. Поэтому, если девайс много чего может "терять", теряя настройки (например, при неправильных настройках уйдет в разнос), то нужно предполагать дублирование/восстановление данных, wear-leveling, и постоянный контроль правильности данных.

0

Сообщение от Voland_ а платформе AVR регистр USART DR имеет размер 16 бит. По идее вы можете прочитать его как 16бит,

Учитывая что на AVR вообще нет чтения по 16 бит - каким образом? Да и сам UDR всегда был 8-битным, пусть и с теневыми регистрами где-то в недрах блока USART.

0

Voland_, навороченное решение не доводилось встречать.
Ещё надо беспокоиться о том, что присутствующие в программе функции стирания памяти программ, могут сработать когда не надо и как не надо, под влиянием внешним условий.

0

Сообщение от Voland_ Но, например, ремонтники старых мониторов с Вами не согласятся

это скорее вопрос к софту мониторов, не так ли ?

0

Сообщение от COKPOWEHEU Учитывая что на AVR вообще нет чтения по 16 бит - каким образом? Да и сам UDR всегда был 8-битным, пусть и с теневыми регистрами где-то в недрах блока USART.

это точно, я просто вспомнил про "бит 8" в опциях USART, но сейчас перепроверил, что его перекидывают в UCSRB, предполагая четкие правила по записи этого бита, и по его чтению (как раз именно потому, что на него влияет чтение/запись в UDR но не в сам UCSRB).

Добавлено через 2 минуты

Сообщение от ВитГо это скорее вопрос к софту мониторов, не так ли ?

Ну... я не уверен, что это вообще "софт" в традиционном понимании. Ведь чтение/запись настроек могли бы быть собраны и на ASIC'е и стейт-машине. А в таком случае собрать еще и wear-level'ing - это слишком, имхо.

0

Сообщение от Voland_ Ну... я не уверен, что это вообще "софт" в традиционном понимании. Ведь чтение/запись настроек могли бы быть собраны и на ASIC'е и стейт-машине.

вот и я о том же, это проблема именно механизма сохранения настроек,

Сообщение от Voland_ А в таком случае собрать еще и wear-level'ing - это слишком, имхо.

и нафиг не нужно при грамотной части первой :-)

0