Форум программистов, компьютерный форум, киберфорум
Наши страницы
Микроконтроллеры Atmega AVR
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.98/98: Рейтинг темы: голосов - 98, средняя оценка - 4.98
drvtos
0 / 0 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
1

Внутренняя память против внешней: что лучше?

01.04.2012, 22:25. Просмотров 17634. Ответов 35
Метки нет (Все метки)

Уважаемые коллеги,

Хочу посоветоваться. У меня есть модуль (АЦП). Он имеет кучу параметров, которые нужно вычислять и потом запоминать. Ну, чтобы еще позже считывать и пользоваться :)
Давно уже использую EEPROM (часто называю его ФЛЕШом) самой атмеги. По объему хватает, все внутри, минимум проблем. Назову эти параметры ФЛАЕШ-параметрами. Их около 100 байт.

Но есть параметры, которые пищу часто, слишком часто для ресурса ФЛЕШки. Раньше они хранились во внешней памяти с батарейкой. Здесь же на форуме, спасибо вам, мое внимание обратили на ФРАМ. Епст! вещь обалденная. Поставил, запустил, работает на ура. Пишу в нее всего 2 параметра, 10 байт, назову их ФРАМ-параметрами.

Пока игрался с новой для меня микрухой, я и не пытался ничего менять революционно. ФЛЕШу флешово, ФРАМу фрамово. То есть пишу в 2 разных памяти.

И вдруг, с очередной переделкой платы и программы, появились проблеммы с надежностью хранения ФЛЕШ-параметров. Скорее всего, там при старте были некие процессы, которые нужно было выждать. В общем, сделал 2 копии, включил BOD и поставил на старте 2 секунды паузы. Проблема ушла, так что даже не знаю ее истинной причины. Не думаю, что сама ФЛЕШка барахлит.

Но, как говорится, осадок остался. И стал я думать: если ФРАМку я запаиваю всегда (была сначала идея, что она не всегда нужна, но потом это жлобство отбросил), то почему бы не делать в ней резервную копию и ФЛЕШ-параметров?
А потом посмотрел, с какой скоростью пишется-читается ФРАМ... Быстро! Так почему бы не сделать ее вообще основной (и единственной) для хранения и ФРАМ, и ФЛЕШ-параметров?
Оно КАНЕШНА, как-то стремно, выносить из МК "на улицу". У меня еще от 15-летней давности проблем с шинами остались "зашпоры" (не знаю, как по-русски, ну, хреновые воспоминания). Реально тогда ушли от шин и надежность работы контроллеров в пром-условиях возросла в разы. Но тут не параллельная шина, а последовательная... И обращения нечастые, и их повторить можно, если контролька не сошлась. То есть, такого, чтобы МК просто слетел с катушек от неправильно принятого байта, не случится...

Вот и решил вас спросить: как вы думаете, для устройства, работающего в условиях достаточно больших помех, можно ли разместить информацию во внешней микрухе? Микрухе, самой по себе надежной и с огромным ресурсом перезаписи.
Или все же внутренняя память МК чем-то лучше? Поделитесь соображениями, вместе решим.

Спасибо!
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
01.04.2012, 22:25
Ответы с готовыми решениями:

Оперативная память: Ваш совет, какой выбор лучше и почему?! 2 варианта пока не выбрал, что лучше!
Доброго времени суток! Оперативная память: Ваш совет, какой выбор лучше и...

ASP против MIDAS, что лучше для программирования web-приложения?
Тем кто программирует на Delphi ... Идет процесс выбора платформы...

Внутренняя память 0.00 МБ. Не видит внутреннюю память
Здраствуйте, девайс Prestigio Multipad PMP5670c_DUO. Я пытался найти способ...

Внутренняя таблица в ячейке внешней таблицы со скрипотом сортировки и фиотрации HTML
Есть таблица, к которой применен скрипт фильтрации и сортировки. Но, к...

Что лучше SSD или Оперативная память?
Хотел поинтересоваться у знающих людей, или тех, кто пробовал так поступать....

35
DY HOTT
0 / 0 / 0
Регистрация: 22.01.2010
Сообщений: 4,000
02.04.2012, 05:04 21
Битые байты это и есть проблемы с еепром :)))

Я обычно байты пишу парами. Байт и его XOR по ключу. При чтении также читаю байт и ксор, ксорю с ключом, сравниваю. Если совпадает - данные верны. Если нет - факин щит. Грузим дефолты, бэкапы и прочие реанимационные методы.
0
THI BIOST
0 / 0 / 0
Регистрация: 23.01.2010
Сообщений: 1,142
02.04.2012, 10:01 22
Цитата Сообщение от DY HOTT
Битые байты это и есть проблемы с еепром :)))

Я обычно байты пишу парами. Байт и его XOR по ключу.
Я пишу [данные][CRC16][данные][CRC16] Если в момент записи вырубило питание - одна из копий точно цела останется и не надо будет реанимаций проводить (особенно, если часто такое случается). И пишу не сами данные, а изменения и пересчитываю CRC.
0
drvtos
0 / 0 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
02.04.2012, 10:03 23
Цитата Сообщение от DY HOTT
Я обычно байты пишу парами
А если вообще 3 копии делать? Места хватает (110 байт всего-то данных), времени тоже...

Я, когда думаю над способами повышения надежности хранения данных, все время спрашиваю: а какова природа сбоев? Если, скажем, это провал или помеха по питанию, то при наших быстрых записях можно запороть все три копии. И тогда да, шит. Но тогда и рецепт мой таков: имею 2-3 копии во ФРАМе (ФЛЕШе, сейчас не принципиально). Имею копию в ОЗУ, с ней работаю (это удобно все равно). Теперь что-то изменилось: я из ОЗУ прописываю копию №1, со всеми там контрольками, как положено. Ставлю себе событие на, скажем, 100 мс. Через это время прописываю вторую копию во ФРАМ. Суть в том, что я разношу во времени эти записи в разные банки (копии) данных. Если и станется сбой, то он не будет долгим.
Ну, нужно еще предусмотреть, что за 100 мс может изменитья еще какой-то параметр. Тогда уж получится: в ОЗУ самый свежий вариант, в первом банке - прошлый, во втором - еще более старый. Бр-р! Тут нужно тщательно продумать...

Конечно, организационно значительно больше ипатни. Но и результат, ИМХО, будет классным. Трудно представить, чтобы в такой системе данные запоролись.
ИЛИ?
0
Леанид Ивинавич
0 / 0 / 0
Регистрация: 16.02.2012
Сообщений: 699
02.04.2012, 11:32 24
У меня была точно такая же ситуация. В шаговом приводе понадобилось сохранять текущую координату. Пришлось поставить FROM. Все остальные параметры тоже перенес во FROM. Храню две копии всех параметров, так как не исключена ситуация, когда выключение питания случится во время записи. Никаких проблем при эксплуатации устройства не выявлено.

Вопрос о надежности очень сложный, здесь трудно сравнить корректно. Нужно проводить какие-то тесты по неизвестно какой методике. Чужой опыть тут тоже мало о чем может сказать, так как на результат влияют многие факторы: качество питания, разводка плат, корректность ПО. У меня сложилось мнение, что хранение информации во внешней памяти более надежно. Хотя про внутреннюю EEPROM AVR тоже ничего плохого сказать не могу. Она портилась только в ранних кристаллах без BOD, типа AT90S2313.

При записи FROM пишу сразу весь блок параметров. А вот в проектах, где храню параметры во внутренней EEPROM, всегда сравниваю старое значение с новым, а пишу только тогда, когда есть различия. Экономлю ресурс. В некоторых случаях даже организую в EEPROM кольцевой буфер, когда количество требуемых перезаписей близко к предельному. Для внешней памяти делать сравнение старого и нового значения неудобно, так как обмен по y2s относительно медленный. Но если есть копия в ROM, то такую проверку делать можно. Ну и защита блока данных с помощью CRC - само собой. Обычно в начале блока данных пишу еще и сигнатуру, которую стираю при начале модификации блока и восстанавливаю в конце. Это позволяет быстро определить актуальность данных. Если обе копии разрушены (или не были инициализированы) - инициализация из FLASH (памяти программ), где хранятся значения по умолчанию. Никогда не использую заливку EEPROM программатором. Система должна уметь себя инициализировать и восстанавливать.
0
itysiy
0 / 0 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
02.04.2012, 11:41 25
Цитата Сообщение от DY HOTT
ЕЕПРОМ бьется даже если БОД бит включен. Не помогает. Одна из причин - на RC тактовой при скачках питания начинает плавать частота и могут поплыть тайминги записи в еепром. Так что кварц, бод и хоорооошее питание.
а могут быть проблемы при чтении из ЕЕПРОМ при включенном БОД и тактированием от внутренней рц цепочки? Или это только для записи?
0
drvtos
0 / 0 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
02.04.2012, 11:55 26
Цитата Сообщение от Леанид Ивинавич
Все остальные параметры тоже перенес во FROM
А как-то сравнить в этом использовании I2C и ISP не можете?

Цитата Сообщение от Леанид Ивинавич
Никогда не использую заливку EEPROM программатором. Система должна уметь себя инициализировать и восстанавливать.
Да я тоже так делал, инициализацию из ПЗУ, если свежезалитый кристалл. Но иногда, когда не все учту, бывает ругня в первый раз, потом мои танцы с бубном. Все лечится, в конце-концов, но таких случаях бывает проще поставить EESAVE и при отладке не трахаться каждый раз с дефолтными значениями. Например, есть преобразователь, с кучей калибровочных точек. Я его включил первый раз, зашил прогу, прокалибровал (ну, не смертельная, но все же процедура). Начал работать, увидел необходимость изменить пару байт в проге. Которые не влияют на соддержимое и формат калибровочных к-тов. И что? Ставлю EESAVE, перепрошиваю прогу и сразу включаюсь в работу. Мой Дракончик очень хорош в таком режиме.

Так что не соглашусь: заливка программатором ЕЕПРОМа бывает очень удобна.
0
Леанид Ивинавич
0 / 0 / 0
Регистрация: 16.02.2012
Сообщений: 699
02.04.2012, 12:17 27
Цитата Сообщение от drvtos
А как-то сравнить в этом использовании I2C и ISP не можете?
Вы имели в виду I2C и SPI? Если так, то SPI - более скоростной интерфейс, соответственно, менее помехоустойчивый.

Цитата Сообщение от drvtos
Ставлю EESAVE, перепрошиваю прогу и сразу включаюсь в работу...
Так что не соглашусь: заливка программатором ЕЕПРОМа бывает очень удобна.
Совсем не понял, какая связь между EESAVE и заливкой EEPROM программатором. Я тоже ставлю EESAVE, когда в EEPROM хранятся калибровочные значения. При первой заливке программы в EEPROM нет сигнатуры, все значения инициализируются из FLASH дефолтными. Потом прибор калибрую, он что-то сохраняет в EEPROM, а при последующих заливках программы EEPROM не трогается. Где тут нужна заливка EEPROM программатором?
0
drvtos
0 / 0 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
02.04.2012, 12:37 28
Цитата Сообщение от Леанид Ивинавич
Вы имели в виду I2C и SPI? Если так, то SPI - более скоростной интерфейс, соответственно, менее помехоустойчивый.
Я пока ориентируюсь на SPI - надо же было с чего-то начинать знакомство с ФРАМ. И мне нравится как раз его скорость. Где-то у техасцев прочел интересную мысль: девайсы и интерфейсы. которые позволяют работать быстрее, являются и более помехоустойчивыми. Действительно, мы же не говорим о каком-то искусственном разгоне интерфейса. Просто используем протокол, в который паспортно заложен быстрый обмен. Так? Значит, ничего не нарушая, а даже и отступив скромненько от 5 МГц, разрешенных производителем ФРАМки, до 2 МГц, я могу быть уверен, что нолики-единички в нормальных условиях дойдут как миленькие. Так? Очень хорошо! А при помехе (мы так представляем себе) сбойнуть может как I2C, так и SPI. Значит, чем быстрее пролетит процесс обмена, тем меньше вероятность сбоя! Вот и все. Тут я с парнями из далекой Америки полностью согласен.

Да, с EESAVE я ступил. Действительно, при старте новой проги разумно заливать все из ПЗУ. Как я и делал всегда. А при перезаливке использовать прекрасную фичу EESAVE. Что я научился недавно.
0
THI BIOST
0 / 0 / 0
Регистрация: 23.01.2010
Сообщений: 1,142
02.04.2012, 12:47 29
Цитата Сообщение от drvtos
отступив скромненько от 5 МГц, разрешенных производителем ФРАМки, до 2 МГц
А где, гм, такое старьё есть? Сейчас посмотрел свои (у меня набор разных ёмкостей и напряжений) - просто память от 20 МГц, RTC - 16 МГц.

ЗЫ. Я пишу/читаю по тактам, без ожидания готовности на максимальной скорости SPI - 17 тактов на байт, а если USORT в роли SPI - то 23 такта на байт.

А потом - отступ вниз - это нормально, клоки SPI можно вообще остановить, вот вверх - ИМХО низзья.
0
Леанид Ивинавич
0 / 0 / 0
Регистрация: 16.02.2012
Сообщений: 699
02.04.2012, 13:00 30
Цитата Сообщение от drvtos
Где-то у техасцев прочел интересную мысль: девайсы и интерфейсы. которые позволяют работать быстрее, являются и более помехоустойчивыми.
Спорное утверждение. Любая более высокочастотная схема воспринимает помехи в более широкой полосе частот. Чем шире полоса, тем выше приведенное ко входу напряжение помех. Конечно, тут играет роль пороговый уровень, но сейчас повсеместно напряжение питания снижается, вместе с ним и порог, что еще больше понижает помехоустойчивость. Что касается микросхем с I2C, то там, как правило, на входах стоят фильтры, реализованные на логических вентилях, которые не пропускают короткие импульсы. Да и максимальная частота логики там ниже. Хотя у I2C есть другое слабое место - это однотактные выходы с подтягивающими резисторами. Но на практике часто приходилось шаманить с согласованием линий интерфейса SPI, если они длинные. На той же длине I2C всегда работал нормально. Но медленно. Хотя если у Вас память находится рядом с процессором, и SPI дальше никуда не идет, то проблем не будет. Вот, кстати, как раз сейчас обсуждают тему сбоев на SPI: http://soxopa.ru/319125.html?todo=full
0
dymo2611
0 / 0 / 0
Регистрация: 10.03.2012
Сообщений: 1,110
02.04.2012, 13:07 31
У "медленных" девайсов шире временное окно на пассивную перезарядку ёмкостей на входе/выходе, когда собственно переключение уже произошло и вход/выход выродился в пассивную RC-цепочку. То есть дело не в том, как различаются по тактовой частоте и соответственно по скорости, а по временам переключения.
0
drvtos
0 / 0 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
02.04.2012, 13:36 32
Цитата Сообщение от dymo2611
У "медленных" девайсов шире временное окно на пассивную перезарядку ёмкостей на входе/выходе, когда собственно переключение уже произошло и вход/выход выродился в пассивную RC-цепочку. То есть дело не в том, как различаются по тактовой частоте и соответственно по скорости, а по временам переключения.
Вывод не понял. И что?

А на Сахаре много внимания уделили вопросу передачи быстрых сигналов по длинной линии. Думаю, что у меня это не проблема. Расстояние между ФРАМкой и МК - порядка 1 см, на этих линиях висит еще разъем для ISP ( буквально несколько миллиметров) и больше ничего. Разве могут быть какие-то проблемы при частоте, скажем, 2 МГц? Не представляю, честно. Ну, уж на крайняк, снижу еще в 2 раза :)

Поэтому за качество связи при нормальном питании я кагбэ спокоен. А все остальное (см. мои дифирамбы быстрой связи) говорит только в пользу быстрого пакета. Считаем, что уважаемые коллеги меня не испугали :)
0
dymo2611
0 / 0 / 0
Регистрация: 10.03.2012
Сообщений: 1,110
02.04.2012, 13:51 33
Цитата Сообщение от drvtos
Цитата Сообщение от dymo2611
У "медленных" девайсов шире временное окно на пассивную перезарядку ёмкостей на входе/выходе, когда собственно переключение уже произошло и вход/выход выродился в пассивную RC-цепочку. То есть дело не в том, как различаются по тактовой частоте и соответственно по скорости, а по временам переключения.
Вывод не понял. И что?То, что соединения между медленными девайсами более чувствительны к помехам, т.к. дольше находятся в режиме пассивного перезаряда ёмкостей. Вероятность помехи проскочить именно в этот момент соответственно выше.
У быстрых девайсов драйверы сильнее. Токи перезарядки выше того, что может навести внешняя помеха.
0
ShodS
0 / 0 / 0
Регистрация: 01.02.2010
Сообщений: 2,011
02.04.2012, 15:07 34
Брат, а вариант - мониторить 12в до сразу после диодного моста - не подходит? Темболее, как я понял, у тебя объем инфы прекрасно помещается в SROM. Да и причин для искажения данных в EEPROM, вроде как нет, кроме несвоевременного пропадания U.

При старте, прочитали значения из EEPROM, потом просто работаем с SROM до тех пор пока не получили сигнал о снижении 12в ниже порогового уровня. Тутже сохраняем актуальные данные в EEPROM, и ждем дальнейших новостей от монитора питания (времени (пока после кренки напряжение начнет снижаться), помоему предостаточно будет чтобы сохранить сотню, другую байт).

Плюс первый - не надо никаких микросхем памяти.
Плюс второй - EEPROM используется очень экономично.
Плюс третий - ресурсы контроллера свободнее (не надо городить работу с внешней памятью).
0
drvtos
0 / 0 / 0
Регистрация: 25.05.2010
Сообщений: 3,610
02.04.2012, 15:23 35
Цитата Сообщение от ShodS
а вариант - мониторить 12в до сразу после диодного моста - не подходит?
Да, брат, знаю такой способ. Не знаю только, почему его не использую :) То ли аппаратно усложнять не охота (хотя ФРАМка тоже аппаратура), то ли не доверяю я скорости процессов у МК...
Ну, у меня мостика нет, внешнее питалово 10...27 В приходит на кондер 470,0 и на импульсник. Ловить его пропадание тоже можно, конечно. Но в широком диапазоне оно и стремно как-то. При 10 В - делитель на 2-3, а при 27 В - уже на 5-10? И сколько импульсник продержит - тоже хз.
Стремно.

А в остальном - шикарное решение. Все в ОЗУ у меня помещается, использовано 44%. Записать раз на сеанс работы - так любое ЕЕПРОМ выдержит сто лет.
0
Леанид Ивинавич
0 / 0 / 0
Регистрация: 16.02.2012
Сообщений: 699
02.04.2012, 17:30 36
Цитата Сообщение от dymo2611
когда собственно переключение уже произошло и вход/выход выродился в пассивную RC-цепочку
Это частный случай, а не черта всех медленных устройств. В общем случае вывод неверный. Драйверы с большим выходным током дают больше проблем, чем преимуществ. Например, создают большие импульсные токи по общему проводу. В новых IC часто скорость нарастания выходного сигнала можно программно уменьшать как раз для повышения помехоустойчивости. Иначе остро стоит проблема отражений от неоднородностей линий связи. Впрочем, вопрос помехоустойчивости цифровых схем очень обширен, нет смысла здесь в него углубляться. Что касается I2C, то он благодаря ряду мер имеет лучшую помехоустойчивость, чем SPI. Ценой меньшей скорости.

Цитата Сообщение от drvtos
знаю такой способ. Не знаю только, почему его не использую :)
Использовал такой метод сохранения данных в EEPROM. Напряжение питания до импульсного стабилизатора мониторил с помощью встроенного компаратора и внутреннего опорного источника. Работает надежно, одно из изделий массово (тысячи штук) эксплуатируется в жестких условиях (животноводческие комплексы), нареканий нет. В Вашем случае для гарантии того, что влиянием извне входная емкость не рарядится быстро, напряжение на нее нужно подать через диод. Ну и программно обрабатывать срабатывание компаратора нужно правильно. Возможна ситуация, когда компаратор сработал, а напряжение дальше не падает, процессор работает. Нужно обработать все ситуации.
0
02.04.2012, 17:30
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
02.04.2012, 17:30

Внутренняя память и флешка
Доброго времени суток. :) А как сделать чтобы внутренняя память осталась...

Динамическая память против статической
Пишу математическую библиотеку. Сначала писал как обычно - class Vector {int a,...

Какой лучше антивирус исползовать против вирусов и взломов?
Какой лучше антивирус исползовать против вирусов и взломов,подскажите? И ключик...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
36
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru