Есть устройство записи звука, пишет на NAND флэш поток аудио без стандартных файловых систем, менеджмент файлов самописный, оптимизированный по скорости.
Хочется сделать ридер данных с устройства который бы подключался к USB и напрямую к выводам NAND и на скорости близкой к скорости работы NAND мог читать и писать файлы, прикидываясь съемным носителем и звуковые файлы были доступны через проводник винды или другой оси в виде wav.
Для реализации планируется взять какой-нить быстрый проц типа LPC3130 с аппаратным интерфейсом NAND флэш и HiSpeed USB.
Есть какие-то засады в такой реализации? Особенно беспокоит возможность реализации подмены нестандартного потока аудио в стандартный wav через MSD.
Покритикуйте плз. Заранее спасибо.

Проблема выработки есть. Более того есть проблема необходимости использовать ECC для обхода битых битов. Чем дальше растёт плотность упаковки данных, тем проблема более актуальна. SD карта решает проблему, у неё встроенный контроллер ECC и прочие прелести - но жрёт сильно больше голой NAND. Сразу писать в ФАТ для нашего случая это слишком большие накладные расходы , избыточное решение. Собственно уже писал, что характеристика диктофонов в плане потребления экстремальные, и каждый "лишний" такт заметен.



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

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

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

Почему же не понятно? Структура FAT фиксированная. Всё что вне Data Area - служебный блок. Проверка только 1 - на адрес начала данных во 2-ом кластере в FAT. Если адрес не совпадает, то идём в "медленный" код и генерим системные блоки.

Хотелось бы узнать - какие чипы nand используются ?

Я бы за файловую Windows так смело не отвечал бы.
Во первых чтобы там все четко было со взаимным пониманием винды и дивайса надо чтобы винды сами этот Mass storage отформатировали. Понятно что при таком сценарии сразу амбец.

С другой стороны все эти опенсорсные FAT-ы страдают кой какой кривизной.
Скажем отформатированная в Keil FS может быть и не понята виндами. Я на такое спотыкался.
Не забываем что сорсы FAT в винде закрыты и там проприетарное решение.
У них есть и extFAT, работает на тот же Mass Storage и распространена на мобильных дивайсах.

Еще проблемка что тут нельзя повлиять на поведение виндов, а вдруг им захочется подправить MBR, или слегка подефрагментировать?
Сами опенсорсные иммитаторы SCSI подмножества команд для Mass Storage страдают неполнотой и неточностью соблюдения спецификации.

Я бы для задачи предложил использовать не Mass Storage, а MTP (Media Transfer Protocol) протокол.
Для виндов это стандарт и индифферентен к файловым системам.
Протокол не сложный, на указанный ARM легко ляжет.

Достаточно сделать все в соответствии со спецификацией.


"Опенсорсные FAT-ы" решают совсем другую задачу. И вовсе необязательно их кривизну копировать.


Нет такой проблемки. Во-первых, винда не дефрагментирует просто так сменные носители. Во-вторых, можно просто сказать, что диск Read Only.

Я конечно не претендую, но из своего опыта могу вот что сказать. Самописная реализация FAT16 с доступом на базе атмелского USB+MSD (может с правками, не помню) работает и под винды и под линукс абсолютно нормально на разных машинах. Форматирование делал своё и проблем не замечал. Могу точно скзать, что винда кеширует содержимое всей FAT таблицы и больше к ней не обращается, если только не операции записи - проверял. FAT может и проприетарный, но простой и настолько вылизанный и описанный, что вроде как проблем с ним быть не может. Я не беру в расчёт длинные имена файлов и русский язык.

Может просто не сталкивался...

В данной задаче надо делать readonly девайс, но вижу одну проблемку - как удалять данные.. если только кнопкой или через интерфейс на устройстве, но думается что там нет экрана.

Кстати, насчёт ресурса флеша подумал. Раз запись идёт кольцом, то наверное каких-то особых мер придумывать не надо. А вот с сектором кратным 512 байтам проблема - куда пихать избыточность? Как вообще решают такие проблемы?

Какие чипы используются не было озвучено, но в тех же самсунговских K9F страница 512 + 16 байт (или 2к+64 в бОльшего объема).

Samsung


Уже есть и 4к и 8к страницы... Дальше наверное ещё больше будут.


Интересная альтернатива , надо подумать. А этот протокол работоспособен на осях отличных от винды?

Ну вот смотрю у самсунга nand даже малой емкости имеют типичные токи на чтение/запись/стирание 8-10 мА, а у вас 1,2 мА вместе с контроллером ?

Сообщение отредактировал sasamy - Mar 6 2011, 15:19

Так не все же время она читается/пишется/стирается.

Я понимаю что Вы это понимаете, но вот ТС пишет



В то время как 1 Гбайт e-mmc имеет для аналогичных операций токи 30 мА, при этом автоматически уходит в режим низкого потребления, а запись на FAT от их костыльного метода будет отличаться только тем что нужно вписать последовательность секторов которую они точно также где-то хранят в таблицу fat.

В случае SD/(e)MMC и прочих стандартных носителей производитель заботится о неком разумном балансе между производительностью и потреблением. Поэтому нисколько не удивляет, что заточенное на микропотребление и низкую производительность решение (как у ТС) в конечном итоге заметно выигрывает.

Да, к тому же SD карты по потреблению сильно различаются...