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

Нормальная идея. Только придется:
1. На МК реализовать Mass-Storage.
2. Средствами МК реализовать файловую систему. Например, FAT32, иначе хост не сможет читать ваши файлы.
3. При записи звука от источника звука МК должен будет корректно формировать соотв. файлы.

Вроде все. Если это сделать, то файлы на вашем дивайсе будут видны в проводнике, как обычные файлы, записанные на флэшке или плейере. А дальше открывайте их чем хотите. И подменять ничего не придется, если ваши файлы будут иметь поддерживаемый ОС хоста формат.

P.S. Это по сути и получится плеер с диктофоном ...

Я бы больше беспокоился насчет как эмулировать FAT в устройстве без реального носителя FAT.
Эта тема тут периодически всплывает и адекватных идей пока не звучало.
Компьютер работает с USB Flash как с обычным блочным устройством.
Т.е. в командах от PC нет явных намеков какие он файловые операции делает, есть только периодические чтения и записи каких-то логических блоков в неизвестной последовательности из Flash памяти устройства. Но блоки должны содержать правильную информацию как в настоящей FAT.
Структуры файловой системы содержатся в самом PC и внешним устройствам недоступны.

Ну, запись в силу специфики данной задачи можно исключить, а с чтением проблем не вижу. Хотя логичнее было бы сделать сам диктофон на МК с HS USB и интерфейсом NAND, благо они есть.

Только все с точностью до наоборот - вся структура ФС находится на носителе а PC согласно ей читает/записывает нужные секторы. Вся задача решается за 15 мин. в Linux на одном контроллере - вместе с записью звука и usb mass storage через File-backed Storage Gadget.

Понятно, что сделать всё, вместе с записью звука на одном ARM+Linux проще. Но у нас специфика такая, что диктофон малогабаритный и с большой автономностью. А так как объёмы памяти большие, надо иметь возможность быстро сливать данные, вот поэтому и идём к такому решению.
Я не знаю как получить в режиме записи 8кГц 16 бит 1,6мА потребление и в режиме ожидания (работают часы, таймеры, опрос кнопок и ещё по мелочи) 10-12мкА на решении ARM+ОС :)


С первым пунктом проблем вроде нет, а вот по 2 и 3 могут быть засады? Если например принять что файлов не может быть больше 1000 и все файлы будут находиться в корне диска, это упростит задачу?

Собственно вот это меня и беспокоит:

Если устойство с внутренней автономностью, то почему не писать на FAT, организованный поверх NAND ? Тогда можно прикрутить готовый MSD. Как я понял, надо писать 8кГц 16бит, т.е. 16кбайт/сек, что мало, а значит не надо бояться накладных расходов на запись в FAT.

PS: А вообще, эмулировать FAT интересней :-) Сам сталкивался с такой задачей, но пока решал что FAT на флешке проще, хотя идеи есть :-)

Проект FAT на NAND недавно выложил:
http://www.indemsys.ru/products/47-armulti...mator2-pcb.html (смотреть в ресурсах)

Выравнивание износа есть , но FTL уровня по сути нет.
При записи однородных больших файлов накладные на FAT в таком решении минимальны и оно вполне работоспособно.

Файловая от микриума одна из самых быстрых и надежных. Портируется и без самой операционки.
Здесь результаты тестов на SD карте: http://eewiki.ru/wiki/Example_SDUCFSSpeed_for_ARMGS10

А поверх NAND, это как?

Хе-хе, еще одна неадекватная идея.
File-backed Storage Gadget ссылка работает с целиком подготовленным файлом того-же размера как вся FAT система им эмулируемая!
Т.е. чтобы сэмулировать FAT размером с NAND нужно где-то в памяти микроконтроллера сделать файл такого-же размера.
Собственно это самый логичный путь.
Он то и предлагается обычно при возникновении этой темы. Но кому он нужен?

После заявления что структура ФС носителя находится на PC а не на носителе я бы постеснялся про адекватность говорить.



Ну и дальше - что ?



А - понятно, забористая дурь файл этот надо делать не в памяти (ram похоже имелась ввиду) а прямо в nand поверх нормальной ФС для nand типа ubifs, тогда с компрессией эфективный объем nand на несжатых pcm данных может в разы увеличиться. Естественно образ этот нужно локально еще смонтировать чтобы записывать в FAT раздел

Можно cy7c68013 + контроллер с параллельным портом. Эмуляция FAT - драйвером на компьютере.

Проще всего вместо nand поставить e-mmc и писать на нее в fat - больше вообще ничего не надо, никаких дополнительных контроллеров и заморочек с usb.

Хамить не надо, а то удалю.
Вы теряете нить разговора.
Речь о том чтобы содержимое NAND вообще не трогать.
Структуры FS это не то, что в блоках на носителе, а то чем оперирует операционка при работе с файлами.
Т.е. кэш-и, объекты устройства, объекты файлов, управляющие структуры команд и т.д.
О терминологии можем спорить, но не здесь.
Ключевая проблема скверной идеи эмуляции в памяти - размер.

Кстати, обычное zip архивирование для PCM кодированного аудио сигнала как мертвому припарки. Может процентов 20 сжатие будет. Зато тормоза на считывание такого контента будут оочень большие.

AlexandrY написал варианты. NAND - это просто носитель, ничто не запрещает на нём реализовать секторы, а на них FAT, да и любую файловую систему. Я с NAND не работал, про проблему выроботки ресурса на нём деталей не знаю, но выше уже знающие люди написали.

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

Насчёт эмуляции FAT (говорю в приложении к FAT16) идеи такие:
1. Все секторы, что не данные генерить "на лету"
2. MBR и Bootsector можно хранить во флеше контроллера
3. Допущение: Запись данных осуществляется непрерывным блоком (как на ленту) -> Если выровнять блоки по размеру кластера (64-128 кбайт для больших флешек), то больших проблем с генерацией "на лету" собственно таблицы FAT быть не должно.
4. Небольшое торможение при генерации на лету служебных секторов не смущает, т.к. делается Host системой один раз.

Если блоки не выравнивать, то тоже можно, но геморней

Пните меня где я ошибаюсь..

Проблема выработки есть. Более того есть проблема необходимости использовать 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 мА вместе с контроллером ?

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

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



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

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

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