FAT16 на MMC

Hello, Vladislav! You wrote to <All>to All on 05 Jul 06 23:48:17:

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

With best regards, . E-mail: snipped-for-privacy@p80.f.n6023.z2.fidonet.org

Пpивет, Alexander!

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

AL> Да, именно так. Единственное - повышается риск кАки при пропадании AL> питания.

Так вроде бы как раз нет. Пока пишу данные - вообще без разницы, пропадет питание - но кластеры не будут потеряны. Только момент модификации FAT - но это один раз, вместо того, чтобы каждый раз лазать и подцеплять кластер за кластером (да и по ресурсу перезаписей тоже выгоднее). И, в конце концов, если в процессе модификации грохнулся, можно тупо восстановить из второй копии...

с уважением Владислав

Hello, Vladislav! You wrote to "Alexander Lavrov" snipped-for-privacy@p80.f.n6023.z2.fidonet.org>to Alexander Lavrov on 06 Jul

VB> Так вроде бы как раз нет. Пока пишу данные - вообще без разницы, VB> пропадет питание - но кластеры не будут потеряны. Только момент VB> модификации FAT - но это один раз, вместо того, чтобы каждый раз лазать VB> и подцеплять кластер за кластером (да и по ресурсу перезаписей тоже VB> выгоднее). И, в конце концов, если в процессе модификации грохнулся, VB> можно тупо восстановить из второй копии... Hу, кому чего важнее. В моем случае важна была информация записываемая в файл. Если файл большой (а ММС довольно медленное устройство) то шанс кирдыка возрастает.

With best regards, . E-mail: snipped-for-privacy@p80.f.n6023.z2.fidonet.org

Пpивет, Alexander!

VB>> перезаписей тоже выгоднее). И, в конце концов, если в процессе VB>> модификации грохнулся, можно тупо восстановить из второй копии...

AL> Hу, кому чего важнее. В моем случае важна была информация записываемая AL> в файл. Если файл большой (а ММС довольно медленное устройство) то AL> шанс кирдыка возрастает.

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

с уважением Владислав

Wed Jul 05 2006 23:48, Vladislav Baliasov wrote to All:

VB> Hужно сделать простейшую реализацию файловой системы на MMC/SD. VB> мне хочется с VB> минимальным расходом как программной памяти, так и RAM. Собственно, нужно VB> работать в каждый момент только с одним файлом на носителе, читать его, VB> либо писать (точнее, время от времени дописывать), создавать новый, VB> стирать старый.

Cделай файловую систему в виде связного списка. Типа: блок данных, и в нем же ссылка на следующий блок, атрибут занят/свободен и пр. Блок = сектор флеша. Для реализации такой структуры памяти вообще не нужно. VLV

"Любите книги - в них видно фиги" (c)

Пpивет, Vladimir!

VB>> на носителе, читать его, либо писать (точнее, время от времени VB>> дописывать), создавать новый, стирать старый.

VV> Cделай файловую систему в виде связного списка. Типа: блок данных, VV> и в нем же ссылка на следующий блок, атрибут занят/свободен и пр. VV> Блок = сектор флеша. Для реализации такой структуры памяти вообще не VV> нужно.

Hе, не подходит. Хочу переносить данные из устройства стандартной карточкой через стандартный ридер, не заморачиваясь с работой с "диском" на физическом уровне на PC.

с уважением Владислав

Thu Jul 06 2006 22:05, Vladislav Baliasov wrote to Vladimir Vassilevsky:

VV>> Cделай файловую систему в виде связного списка. Типа: блок данных, VV>> и в нем же ссылка на следующий блок, атрибут занят/свободен и пр. VV>> Блок = сектор флеша. Для реализации такой структуры памяти вообще не VV>> нужно.

VB> Hе, не подходит. Хочу переносить данные из устройства стандартной VB> карточкой через стандартный ридер, не заморачиваясь с работой с "диском" VB> на физическом уровне на PC.

Снаружи это выглядит как стандартный FAT с одним файлом на весь диск. Внутри этого файла делается своя файловая система. На PC пишется программа, которая разбирает/собирает файл.

VLV

"Любите книги - в них видно фиги" (c)

Пpивет, Vladimir!

VB>> карточкой через стандартный ридер, не заморачиваясь с работой с VB>> "диском" на физическом уровне на PC.

VV> Снаружи это выглядит как стандартный FAT с одним файлом на весь диск. VV> Внутри этого файла делается своя файловая система. Hа PC пишется VV> программа, которая разбирает/собирает файл.

Я примерно так и представлял. Все равно коряво. Если бы хоть оно было фиксированной длины... Hе, нафиг. Уж мучаться - так мучаться...

с уважением Владислав

Hi Vladislav !

Совсем недавно 06 Jul 06 12:13, Vladislav Baliasov писал к Alexander Lavrov:

VB>>> если там есть место, а затем тупо писать в свободные кластеры VB>>> подряд, а по завершению записи присоединить все занятые кластеры VB>>> к файлу, и скорректировать длину и дату в оглавлении. Вроде как VB>>> подводных камней нет или я что-то не учел ? Я тоже так делаю, пока ничего криминального не увидел. Есть один подводный камень: свободные кластеры должны следовать друг за другом и их количество должно быть достаточным для твоего файла. Я написал функцию, которая возвращает длину найденной свободной цепочки кластеров и номер первого свободного кластера. Сначала запрашиваю эту функцию, потом определяю, что туда влезет, потом пишу. После записи кластеров модифицирую FAT и его копии, а также элемент каталога. Для упрощения жизни всегда работаю с корневым каталогом.

AL>> Да, именно так. Единственное - повышается риск кАки при AL>> пропадании питания.

VB> Так вроде бы как раз нет. Пока пишу данные - вообще без разницы, VB> пропадет питание - но кластеры не будут потеряны. Как это не потеряны? Если ты после каждого кластера делаешь зарубку в FAT и модифицируешь запись в каталоге- то они не теряются. Если же ты нигде не отметил, что этот кластер уже занят и не указал кем занят, а питание вырубили- то кластер с данными не соотнесен ни одному файлу, то есть потерян.

VB> Только момент модификации FAT - но это один раз, Hе один, а столько раз, сколько копий FAT указано в бутовом секторе.

VB> вместо того, чтобы каждый раз лазать и подцеплять кластер за VB> кластером (да и по ресурсу перезаписей тоже выгоднее). У меня ключевым было быстродействие. Пока не начал писать в заранее неайденные пустые сектора потоком - то в свой реалтайм не укладывался, быстродействия CPU не хватало на честное обслуживание файловой системы (с поиском следующего пустого кластера на диске по мере необходимости).

VB> И, в конце концов, если в процессе модификации VB> грохнулся, можно тупо восстановить из второй копии... Вот если бы еще каталожные записи резервировались, вообще бы все было хорошо :)

WBRgrds Ruslan

Пpивет, Ruslan!

VB>>>> Вроде как подводных камней нет или я что-то не учел ?

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

По крайней мере для его фрагмента (увы, изначально я не могу знать, сколько мне нужно).

RM> Я написал функцию, которая возвращает длину найденной свободной RM> цепочки кластеров и номер первого свободного кластера. Сначала RM> запрашиваю эту функцию, потом определяю, что туда влезет, потом пишу. RM> После записи кластеров модифицирую FAT и его копии, а также элемент RM> каталога. Для упрощения жизни всегда работаю с корневым каталогом.

Примерно так я и хотел.

RM> Как это не потеряны? Если ты после каждого кластера делаешь зарубку в RM> FAT и модифицируешь запись в каталоге- то они не теряются. Если же ты RM> нигде не отметил, что этот кластер уже занят и не указал кем занят, а RM> питание вырубили- то кластер с данными не соотнесен ни одному файлу, RM> то есть потерян.

Я могу перезапросить данные у датчиков. Хотя, похоже, это будет достаточно криво (надо сообщать датчикам, чтобы они не могли модифицировать свои данные, пока со всеми не разобрался - что-то так мне не нравится. А закрывать файл после каждого датчика - ресурс по перезаписи FAT будет сокращаться).. Похоже, лучше будет применить рамтроновскую память для хранения фрагмента FAT (поскольку уже предполагается ее применять).

VB>> Только момент модификации FAT - но это один раз,

RM> Hе один, а столько раз, сколько копий FAT указано в бутовом секторе.

Hу, это само собой...

с уважением Владислав

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladislav Baliasov! You wrote in conference fido7.ru.embedded to Ruslan Mohniuc on Wed, 12 Jul

VB> мне не нравится. А закрывать файл после каждого датчика - ресурс по VB> перезаписи FAT будет сокращаться).. Похоже, лучше будет применить VB> рамтроновскую память для хранения фрагмента FAT (поскольку уже VB> предполагается ее применять).

Кстати появился новый тип энергонезависимой памяти - магниторезистивная MRAM от Freescale:

dima

Hi Vladislav !

Совсем недавно 12 Jul 06 23:07, Vladislav Baliasov писал к Ruslan Mohniuc:

RM>> Есть один подводный камень: свободные кластеры должны следовать RM>> друг за другом и их количество должно быть достаточным для твоего RM>> файла.

VB> По крайней мере для его фрагмента (увы, изначально я не могу знать, VB> сколько мне нужно). То есть у тебя запись- это долговременный процесс с ожиданием события, по которому ты прервешься?

VB> Похоже, лучше будет применить VB> рамтроновскую память для хранения фрагмента FAT (поскольку уже VB> предполагается ее применять). Сто процентов. Такое точно хорошо. FAT-то сам небольшой. Только нужно еще следить, чтобы за время выключения тебе носитель в слоте не подменили, иначе глупость получится :)

WBRgrds Ruslan

Пpивет, Ruslan!

RM>>> друг за другом и их количество должно быть достаточным для RM>>> твоего файла.

VB>> По крайней мере для его фрагмента (увы, изначально я не могу VB>> знать, сколько мне нужно).

RM> То есть у тебя запись- это долговременный процесс с ожиданием события, RM> по которому ты прервешься?

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

VB>> Похоже, лучше будет применить

RM> Сто процентов. Такое точно хорошо. FAT-то сам небольшой.

Hебольшой, но целиком может не поместиться, так что тоже не все так просто.

RM> Только нужно еще следить, чтобы за время выключения тебе носитель в RM> слоте не подменили, иначе глупость получится :)

Hу, это само собой... По-первости мне казалось, что задача проще, но теперь уже как-то даже страшновато... И подходящих готовых решений не вижу.

с уважением Владислав

Hello,Dmitry !

DO> Кстати появился новый тип энергонезависимой памяти - DO>магниторезистивная MRAM DO> от Freescale: DO>

Особенно денег :-) Вот когда подешевеет, может быть...

WBR G.G.

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Gena Gutnicky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 13 Jul

DO>> Кстати появился новый тип энергонезависимой памяти - DO>> магниторезистивная MRAM от Freescale: DO>> Обещают 35ns доступ на запись и чтение, 10лет DO>> сохранности данных, 512kB (4Mb) в чипе. Жрет правда довольно DO>> душевно...

GG> Особенно денег :-)

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

dima

Hello, Gena! You wrote to Dmitry Orlov on Thu, 13 Jul 2006 20:39:51 +0000 (UTC):

GG> Hello,Dmitry !

DO>> Кстати появился новый тип энергонезависимой GG> памяти - DO>магниторезистивная MRAM DO>> от Freescale:

GG>

GG> Особенно денег :-) GG> Вот когда подешевеет, может быть...

Лет 11-12 назад, я покупал 8мбит флешки по 70 долларов, а ведь они тогда не "только что появились" (через год упали в цене вдвое). Фристайловские - только-только появились, и сейчас 4 мегабита стоят четвертак. Для единственой и первой микросхемы -не так и много. Вопрос скорее - в спросе и технологии. Смогут ли они сильно наращивать размер, и кардинально снижать энергопотребление (оно там даже в невыборке нехилое) - от этого буджет зависеть спрос, а от него - и цена.

With best regards, Alexandr Torres.

2:461/28, E-mail: snipped-for-privacy@yahoo.com

Hi Vladislav !

Совсем недавно 13 Jul 06 23:06, Vladislav Baliasov писал к Ruslan Mohniuc:

RM>> То есть у тебя запись- это долговременный процесс с ожиданием RM>> события, по которому ты прервешься?

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

VB>>> Похоже, лучше будет применить ...FRAM

RM>> Сто процентов. Такое точно хорошо. FAT-то сам небольшой.

VB> Hебольшой, но целиком может не поместиться, так что тоже не все так VB> просто. Hу, можно и просто сектор или кластер. Hу сохраняешь один нужный кластер или даже просто сектор (512 байт) из Фата и одну запись для дирректории (32 байта). Собираешь его в FRAM, потом пишешь сектор в фат. Когда файл закрыт- тогда записывешь и дирректорию.

RM>> Только нужно еще следить, чтобы за время выключения тебе носитель RM>> в слоте не подменили, иначе глупость получится :)

VB> Hу, это само собой... По-первости мне казалось, что задача проще, но VB> теперь уже как-то даже страшновато... И подходящих готовых решений не VB> вижу. Да нет тут ничего хитрого. Ты только на ассме не пиши. ;) И посчитай заранее, какой все-таки у тебя траффик, может многие вещи и проще можно сделать. Hу, скажем все держать просто в RAM, записывать сектор в момент его заполнения сразу в MMC, закрывать файл раз в минуту (обновляешь FAT и запись в дирректории). Если питание вырубили- то потеряется максимум минута. Вытаскиваешь данные из датчика, открываешь уже имеющийся на диске файл, продолжаешь запись в него. Удобно тем, что на карточке всегда есть все данные кроме последней минуты, можно грубо выдернуть и пойти их смотреть на PC.

PS. Я с MMC не работал, мне CompactFlash ближе. Может, там на MMC свои заморочки есть.

WBRgrds Ruslan

Пpивет, Ruslan!

VB>> Hу, это само собой... По-первости мне казалось, что задача проще, VB>> но теперь уже как-то даже страшновато... И подходящих готовых VB>> решений не вижу.

RM> Да нет тут ничего хитрого. Ты только на ассме не пиши. ;)

;) Увы, как раз на асме и придется - и переучиваться сейчас не вовремя (и ломает конкретно).

RM> проще можно сделать. Hу, скажем все держать просто в RAM, записывать

RAM у меня очень ограниченно.

RM> сектор в момент его заполнения сразу в MMC, закрывать файл раз в RM> минуту (обновляешь FAT и запись в дирректории).

И лишний раз перезаписывать сектор не хочется из соображений ресурса (хотя, в общем-то, позволительно - запас в 100K мне долго не выбрать, если не переписывать FAT по каждому кластеру).

RM> PS. Я с MMC не работал, мне CompactFlash ближе. Может, там на MMC свои RM> заморочки есть.

Вроде как особой разницы нет.

с уважением Владислав

Hello,Dmitry! DO>>> Кстати появился новый тип энергонезависимой памяти - DO>>> магниторезистивная MRAM от Freescale: DO>>> Обещают 35ns доступ на запись и чтение, 10лет DO>>> сохранности данных, 512kB (4Mb) в чипе. Жрет правда довольно DO>>> душевно...

GG>> Особенно денег :-)

DO> Деньги - дело наживное, в смысле, что подешевеет наверняка. А вот сотня DO> миллиампер - не шутки, и, я конечно не специалист, но боюсь что этот DO> показатель будет трудней, чем цену снизить.

Тогда непонятно, чем эта штуковина лучше старого доброго FRAM от Ramtron"а ? Я, к сожалению, так и не смог его попробовать, но по отзывам, штука очень хорошая. Быстродействие RAM одновременно с энергонезависимостью Flash - это не кот начихал.

WBR G.G.