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

[Paramedic]

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

[AlexandrY]

Особенно беспокоит возможность реализации подмены нестандартного потока аудио в стандартный wav через MSD.

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

[sasamy]

Структуры файловой системы содержатся в самом PC и внешним устройствам недоступны.

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

[AlexandrY]

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

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

[sasamy]

Хе-хе, еще одна неадекватная идея.

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

File-backed Storage Gadget ссылка работает с целиком подготовленным файлом того-же размера как вся FAT система им эмулируемая!

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

Т.е. чтобы сэмулировать FAT размером с NAND нужно где-то в памяти микроконтроллера сделать файл такого-же размера.

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

[AlexandrY]

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

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

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

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