Да. Из описания следует, что _FS_TINY == 1 уменьшает используемый FATFS буфер

Т.е. предлагаете делать прослойку типа SmartDrv в старом мс-досе?? А вы в курсе, что при этом можно очень легко нарушить целостность файловой системы при сбое или отключении питания? Сколько было потрачено сил и убеждений в свое время, чтоб не жали на ресет по делу и без дела в старых компах... Хотя да, на древних винтах ускорение было заметным.

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


А Вы пробовали? 1000 раз стёрли и на 1001-й раз получили отказ?
И исходя из чего же производитель назначает этот самый гарантийный срок? Вы считаете это как-то связано с числом циклов перезаписи??
Вот специально скачал доку на microSDHC от kingston с: http://www.kingston.com/ru/flash/microsd_cards/sdc4
В ней утверждается:

Т.е. - если следовать Вашей логике и производитель назначает гарантийный срок исходя из числа циклов перезаписи, то берём заявленную скорость передачи 4МБ/сек умножаем её на среднюю продолжительность жизни среднего человека и получаем, что в течение гарантийного срока карта выдержит поистине гигантское число циклов перезаписи (при условии эксплуатации в режиме непрерывной записи)!
Все эти пожизненные и прочие гарантии - всего-лишь маркетинговый ход.


Что именно Вы хотели этим сказать?
Да - условия эксплуатации карт разные и могут меняться. А время жизни (число циклов) задано для наихудшей комбинации этих условий. В реальности же большинство карт эксплуатируются бОльшую часть времени как Вы сказали "на теплом столе". В таких условиях на этом самом "теплом столе" число циклов перезаписи может быть в разы больше минимального, заявленного изготовителем.
Вот именно это я и хотел сказать своей аналогией с SDRAM: 64мсек производителем заданы для наихудших условий эксплуатации, поэтому в моём же случае при комнатной температуре и стабильном питании вдали от крайних значений, получаются на порядки лучшие показатели. И именно поэтому:

Да, что-то вроде, только более специализированной и заточенное под конкретную задачу.



Естественно в курсе, но FAT и так не является отказоустойчивой ФС, по определению. И состояние ФС не гарантируется при отключении питания во время выполнения операции записи. С этой точки зрения мое предложение не ухудшает характеристик получаемого результата.




Я с логикой вполне дружу. Взял я это из Вашего же сообщения в этой теме:


Или Вы этого не писали?



Я давал подтверждения выше по теме. В ответ Вы мне написали, что:


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



Пробовали не с картами памяти, с флешом типа NAND. Требования выравнивания износа при использовании NAND взялись не из воздуха, а из практической необходимости. О чем я Вам и пытаюсь уже несколько раз сказать.



Безусловно. И с механизмами, реализованными в носителях. В противном случае поток рекламаций сведёт на нет всю выручку. А крупные производители умеют считать деньги.

К вопросу о надёжности поинтересуйтесь рекомендациями того же Micron'а относительно eMMC. Пару слайдов прикрепил к этому сообщению.



Ровно то, что и сказал: Ваши слова не аргумент возможно огромного числа циклов перезаписи или огромного запаса надёжности, заложенного производителем "на всякий случай".



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

У ТСа нет ОЗУ даже для буферизации основного потока, не то что ещё и FAT. Ведь в этом-то и вся проблема. Если-б ОЗУ было - проблемы и не было-бы: выкинуть вообще любую файловую систему и писать просто поток блоков на SD через буфер.


Эти "прослойки" есть и на современных компах. Иначе - операции с мелкими файлами на SD становятся оооооочень затратны по времени. Да и на МК при интенсивных модификациях файлов, кеширование очень полезно.
А чтобы не слетали файловые системы - тут разработчик, на этапе проработки идеологии всей системы в целом, должен голову включить и подумать как этого добиться (или супервизиром питания, дающим запас времени после сигнала аварии питания; или дополнительной non-volatile памятью, в которую ПО будет делать журналирование любых критических операций с файловой системой; или ещё какими другими методами).

Если б были ОЗУ в небольших корпусах с каким-то примитивным интерфейсом. А то они все с параллельной шиной, из-за чего у микросхемы и процессора много ног т.е. либо огромные корпуса, либо BGA. Габариты критичны, а BGA дорого

Их есть, например, Serial SRAM and Serial NVSRAM
Но тут перед Вами встанет другая проблема: накладные расходы из-за примитивного интерфейса будут, возможно, больше выигрыша из-за дополнительной памяти. Так что параллельная шина, большие корпуса и т.п. За все нужно платить.

Я тоже такой не знаю, у меня только есть:
1. SD Specifications. Part 1. Physical Layer. Simplified Specification. Version 3.01. May 18, 2010
2. SD Specifications. Part A2. SD Host Controller Simplified Specification. Version 2.00. February 8, 2007
3. SD Specifications. Part E1. SDIO Simplified Specification. Version 2.00. February 8, 2007
И я там не находил ничего, подтверждающего наличие внутри SD механизмов перераспределения износа. Хотя может что и пропустил, так как не изучал от корки до корки.


Требования эти может выполнять например ПО системы, куда подключена SD. Т.е. - прослойка между например FatFS и интерфейсом SDIO/SPI карты. А не контроллер SD-карты, который останется "тупым". Нужно более эффективное использование SD при интенсивных модификациях - вносите соотв. драйвер в ваше firmware. А для подавляющего большинства применений SD-карт это не нужно и не нужно производителям париться добавляя эту мало кому нужную функцию в контроллер SD, тратя на это ресурсы SD-карты.


Да ну!!? А как же тогда работают например флеши программ микроконтроллеров, из которых код может читаться на скоростях около 20-30МГц???
Это что-ж - написали коротенький цикл while () {}, включили, поработала программа несколько суток и адье! - стёрлась!
К деградации ведёт только стирание.

Приведу пример про конкретный чип на основе родственника SDcard - eMMC:





Приведу пример из стандарта 84-A441 на eMMC:



Ну и при вызове Trim:


Вообще ничего волшебного в Trim нет, просто он позволяет посекторно флушить память. Другое дело непонятно, можно ли на MLC вообще не вызывать TRIM, ERASE или ACMD23?

Протестировал тут стирание группы в моей eMMC через CMD35,CMD36,CMD38: при стирании 2/20МБ - то 30мс, то 2 секунды, в не зависимости от длины и наличия данных.

Да, видел их. Они маленькие, всего 128КБайт. А мне, при потоке 1МБайт/с и пропусках 0.5с нужно раз в 5 больше.

Так такие чипы есть. На I2C и на SPI:
а) FRAM (например FM25V20A); есть даже МК с FRAM-памятью (вместо FLASH), например - MSP430FR5739;
б) nonvolatile-SRAM http://www.cypress.com/products/nonvolatil...0-bottom_side-8 (это ОЗУ + FLASH, куда автоматом скидыватся содержимое ОЗУ при аварии питания);
в) и просто ОЗУ есть, только размер вроде небольшой у них.


Вы внимательнее посмотрите на сайте Cypress:
FM25V20A - 256кБ;
CY15B104Q - 512кБ.
И что-то подобное было у других вендоров.

Можно пойти другим путём:
1. Например 4х проводный интерфейс у меня пишет быстрей однопроводного.
2. Взять контроллер с большей внутренней памятью.

Кстати карта имеет право осуществлять запись доли секунды. У моей, согласно даташиту - 250мС. Поэтому я, для надёжности, всегда использую внутренний буфер более чем на четверть секунды.

Хорошо, возможно в каких-то новых картах выравнивание износа есть. Это не противоречит основной спецификации SD.
Только ТСу толку от этого 0. А если эти 2 сек из-за именно выравнивания износа - так только вред один - задержки записи ещё больше могут быть, и как-то ему такие карты отсеивать надо. Или всё устройство переделывать надо, отказавшись от SD или поставив доп. ОЗУ или пересмотрев алгоритм записи.

И тем не менее это так: https://en.m.wikipedia.org/wiki/Flash_memory#Read_disturb

Что теперь скажете?

Из всего этого выбираю проц с достаточным набортным ОЗУ.

Сообщение отредактировал mantech - Sep 12 2016, 17:00