Есть устройство записи звука, пишет на 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 на флешке проще, хотя идеи есть :-)

Сообщение отредактировал codier - Mar 5 2011, 09:02

Проект 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 системой один раз.

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

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

Сообщение отредактировал codier - Mar 5 2011, 16:42