Покритикуйте плз. задумку Опции

[Paramedic]

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

[codier]

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

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

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

[Paramedic]

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

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

[codier]

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

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

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

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

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

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

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

[Paramedic]

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

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

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

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

[codier]

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

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