Jump to content

    

USB MTP протокол

На устройстве реализован mass storage.

Поскольку на физическом накопителе не разместить ФС, то приходится эмулировать FAT32 на-лету, что не нравится.

Наткнулся на MTP-протокол, который бы подошёл идеально если бы хранилась музыка или видео. Но у меня бинарные файлы данных.

Можно ли MTP заставить гонять произвольные данные и на сколько это противоречит MTP-стандарту?

 

Share this post


Link to post
Share on other sites

Шось на форуме поиск совсем загнулся -- глянь Гуглом "MTP site:electronix.ru".

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

Хотя сами музыка/кино тоже вполне себе бинарники ;)

 

Мало информации -- почему, допустим, "на физическом накопителе не разместить ФС" ?

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

Снаружи ОС этим всем пользуется и создаёт там MBR, разделы разных типов, что угодно потом внутри...

Share this post


Link to post
Share on other sites
Шось на форуме поиск совсем загнулся -- глянь Гуглом "MTP site:electronix.ru".

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

Хотя сами музыка/кино тоже вполне себе бинарники ;)

 

Мало информации -- почему, допустим, "на физическом накопителе не разместить ФС" ?

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

Снаружи ОС этим всем пользуется и создаёт там MBR, разделы разных типов, что угодно потом внутри...

Спасибо за ответ.

В поиске уже копался и вики читал)

Жаль что эти копирасты не сделали нормальный протокол файлобмена...

> Мало информации -- почему, допустим, "на физическом накопителе не разместить ФС" ?

Много spi-флешей. Поддерживается структура записи в них, определённая требованием отказоустойчивости. Дабы вылет одной или нескольких произвольных не привёл к потере данных или, по крайней мере, к сбою записи.

 

Share this post


Link to post
Share on other sites

А как MTP может хранить данные без ФС ? Всё равно MS-овцы должны цепочки секторов прослеживать на низком уровне, стирания у файлов бывают, фрагментация... Это они навернули дополнительные слои сверху, а снизу наверняка обычная FAT с парой копий главной таблицы кластеров и ограниченным корневым каталогом.

 

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

 

Я бы лично "абстрактные" требования отказоустойчивости реализовал дублированием на нижайшем уровне -- последовательным или параллельным размещением тех же данных на разных чипах флэши. У них же есть chip select, можно включить 2-3 штуки сразу и подавать по общей шине данные -- во все выбранные чипы и запишутся ! Потом вычитать быстро по очереди, сравнить (или контроллер сам проверит "качество" при записи и выставит бит проблемы), принять какое-то решение (если ошибка хоть где-то, пометить этот адрес сектора как сбойный на следующие разы)... Лишь бы верхнему уровню, которому хочется читать-писать, была видна "плоская" карта памяти девайса, тогда сверху проблем не будет.

 

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

Можно же на обычной FAT/NTFS открыть 2-3 файла "верхним уровнем" и в них писать по очереди одно и то же с периодическими CRC-вставками блоков, при чтении сравнивая непобитость и беря аналогичный кусок из более целого файла, если в первом проблемы ? У старых винчестеров в секторе на 512 байт было дополнительное поле CRC разного размера, сейчас у флэшей с этим проблемы :(

FAT-ов можно завести больше, чем обычные 1 или 2, только для SPI-флэшей операция изменения "большого" сектора при "вписи" нового файла, для которого нужно поменять пару 00 на его № кластера, достаточно тяжкая и неэффективно портящая секторы в FAT-области постоянными форматированиями выше среднего.

Современные флэши с гигантскими единицами записи как будто специально придумывали, чтобы затруднить работу с древними ФС ;)

Можно даже "под FATы" поставить специальную флэшь с произвольным доступом на чтение-запись (правда, я про такие не слышал, кроме гипотетической MRAM), а для данных оставить "крупно-секторные"...

Или в FAT-области хранить её инверсию -- тогда "постформатные" FF станут выдаваться наружу, как 00, будут считаться свободным пространством, ОС при записи файлов будет писать туда числа, которые окажется легко "вписать" в FF без перетирания сектора. Но при стирании файлов уже потребуется форматирование :(

По-любому, FAT требует особого внимания, хорошо её хранить в ОЗУ (видимо, так сейчас и делается), а при появлении признаков пропадания питания успевать сбрасывать в энергонезависимое место. Я нашим конструкторам так и говорил -- можете в конденсаторе где-то накопить напряжения на 1 с работы с флэшью и подать в проц прерывание, если внешняя цепь точно сдохла ?.. ;)

 

Share this post


Link to post
Share on other sites
А как MTP может хранить данные без ФС ? Всё равно MS-овцы должны цепочки секторов прослеживать на низком уровне, стирания у файлов бывают, фрагментация... Это они навернули дополнительные слои сверху, а снизу наверняка обычная FAT с парой копий главной таблицы кластеров и ограниченным корневым каталогом.

 

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

 

Я бы лично "абстрактные" требования отказоустойчивости реализовал дублированием на нижайшем уровне -- последовательным или параллельным размещением тех же данных на разных чипах флэши. У них же есть chip select, можно включить 2-3 штуки сразу и подавать по общей шине данные -- во все выбранные чипы и запишутся ! Потом вычитать быстро по очереди, сравнить (или контроллер сам проверит "качество" при записи и выставит бит проблемы), принять какое-то решение (если ошибка хоть где-то, пометить этот адрес сектора как сбойный на следующие разы)... Лишь бы верхнему уровню, которому хочется читать-писать, была видна "плоская" карта памяти девайса, тогда сверху проблем не будет.

 

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

Можно же на обычной FAT/NTFS открыть 2-3 файла "верхним уровнем" и в них писать по очереди одно и то же с периодическими CRC-вставками блоков, при чтении сравнивая непобитость и беря аналогичный кусок из более целого файла, если в первом проблемы ? У старых винчестеров в секторе на 512 байт было дополнительное поле CRC разного размера, сейчас у флэшей с этим проблемы :(

FAT-ов можно завести больше, чем обычные 1 или 2, только для SPI-флэшей операция изменения "большого" сектора при "вписи" нового файла, для которого нужно поменять пару 00 на его № кластера, достаточно тяжкая и неэффективно портящая секторы в FAT-области постоянными форматированиями выше среднего.

Современные флэши с гигантскими единицами записи как будто специально придумывали, чтобы затруднить работу с древними ФС ;)

Можно даже "под FATы" поставить специальную флэшь с произвольным доступом на чтение-запись (правда, я про такие не слышал, кроме гипотетической MRAM), а для данных оставить "крупно-секторные"...

Или в FAT-области хранить её инверсию -- тогда "постформатные" FF станут выдаваться наружу, как 00, будут считаться свободным пространством, ОС при записи файлов будет писать туда числа, которые окажется легко "вписать" в FF без перетирания сектора. Но при стирании файлов уже потребуется форматирование :(

По-любому, FAT требует особого внимания, хорошо её хранить в ОЗУ (видимо, так сейчас и делается), а при появлении признаков пропадания питания успевать сбрасывать в энергонезависимое место. Я нашим конструкторам так и говорил -- можете в конденсаторе где-то накопить напряжения на 1 с работы с флэшью и подать в проц прерывание, если внешняя цепь точно сдохла ?.. ;)

 

> А как MTP может хранить данные без ФС

Надо читать стандарт, конечно, но я на сколько понял, MTP определяет только протокол обмена, но не способ хранения данных. Тем он мне и приглянулся сначала.

 

> А что за сбои чудятся, каков характер, на практике они бывали, или просто перестраховка

- А у вас несчастные случаи были на стройке?

- Нет.

- Будут.

Из этой области ))

Температура + перегрузки + цена потери данных велика. Поэтому отказоустойчивость было первое требование.

 

> ОС обычно заточена на возврат кода ошибки, может пометить у себя место неудачной записи в FAT и больше его не использовать.

Ну, если предположить, что в винде отключено кеширование ФС, то, возможно, на это можно положиться.

А вообще, винда в устройство не пишет. Устройство пишет само в себя. А винда потом только считывает. Для этого и эмулируется fat32.

 

> Или в FAT-области хранить её инверсию -- тогда "постформатные" FF станут выдаваться наружу, как 00, будут считаться свободным пространством

Да, я тоже думал об этом. Вполне можно так сделать. И хранить таблицу FAT во внутренней флеши. Уж если она гикнется... То, можно быть уверенным, гикнулось всё :05:

Изначально была сделана линейная запись. И сейчас работает именно она. Хотя это будет переделываться.

Когда ещё не шла речь о режиме mass storage и FAT-е, мне приходила в голову идея сделать такой алгоритм...

Исходя из того, что необходимый размер данных неизвестен, но он меньше 1 гб, то:

1. Сначала пишется всё параллельно во все 32 флеши.

Когда доходим до конца, то

2. Стираем половину флешей и продолжаем параллельную запись в них

И так по заполнению делим адресное пространство на 2 постоянно.

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

Так что будем думать менее красивые способы :rolleyes:

 

Share this post


Link to post
Share on other sites

Стирать можно и по очереди -- просто надо знать, какие сектора подлежат, и чтобы скорости хватало.

Я считаю, что всё должно быть как можно проще -- так все варианты проследить гораздо проще.

Более 2 копий всего иметь смысла не имеет -- одновременно гикнуться они смогут с квадратом вероятности, которая и так небольшая. Куб -- уже некрасиво и параноидально. Хотя 4 -- самое оно, если уж начальство совсем хочет перезастраховаться.

И писать бы данные неодновременно все 2-3-4 -- если по питанию помехи, то все N запишутся криво, но разносить во времени очень неудобно.

А если молния ударит или ЯВ -- то и 10 копий не спасут ;)

 

Плохо, что сектора все кратны степени 2 и нельзя дописывать свои CRC, чтоб быстро определять, какое из данных сломалось. А если в другой сектор по 4 байта -- это неудобно, дубляж опять же, потом и на этот сектор надо CRC заводить в 3ю степень... Только если полсектора на данные, а остальное на проверку -- дублять так дублять ! ;)

 

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

Интерфейс наружу мог бы быть простейшим -- ПО просит у кристалла выделить определённый № логического сектора (чисто отформатированного), записать его, прочитать его, ну и вернуть в "пул" свободных. Если микросхема что-то из этого не смогла, пусть вернёт ошибку. Да, и размер сектора можно запросить на старте, но 512 байт желательно по дефолту -- с громадными "от демократов" работать неудобно никому и никогда ;)

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

Нужно записать нечто -- смотрит по своим таблицам №№ незанятых секторов, запрашивает их у железа, пишет туда, а если уже файл не нужен -- возвращает обратно в пул его сектора. Тамошние данные уже потеряны навечно на 100 % (сектора вернутся "наружу" только при следующем запросе выделения поформатированными через цикл равномерной обработки всего свободного пула-"фифошки").

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

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

Форматированием тоже пусть железо занимается -- у него должна быть очередь из готовых к выдаче небитых секторов, голову списка нужно постоянно форматировать. Микроконтроллеры обязательно ставятся к каждой микросхеме флэши -- пусть этот "мозг" будет сразу встроен !

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

Ну то есть главный смысл этого потока: придумал кто-то гемор -- пусть лично его и мучает, а не перекладывает на другую голову, пока ещё белую и пушистую ;)

 

Кстати, зачем столько дубляжа при ответах ? ;)

Я лично стараюсь сильно цитировать в самом крайнем случае.

Share this post


Link to post
Share on other sites

MTP-устройство оперирует файлами, в отличие от Mass Storage, которое оперирует блоками.

Как там MTP-устройство внутри себя хранит эти файлы, операционной системе глубоко фиолетово. Главное, чтобы вовремя уведомляло, если появился какой новый файл, или исчез старый.

В то время, как на Mass Storage именно сама ОС строит нужную ей ФС для хранения файлов.

Другой уровень абстракции.

Share this post


Link to post
Share on other sites

Это да, но нам-то самим реализовывать ещё больший отрыв от железа из 5 микросхем до той самой абстракции с подкаталогами и хаканьем правильного лицензированья по дороге ?

Всё началось с того, что ТС захотел упростить себе жизнь -- кидать снаружи файл с хитрым именем за одну посылку из Far, получать внутри его в 32 копии на линейной ФС и как-то возвращать весь список, видимо, просканировав всю флэшь и собрав свойства файлов в ОП.

Мне Гугл на "mtp api" ничего не выдаёт и похоже, что в России этими вещами никто не занимался, по крайней мере, на нашем языке не светился. И моба такого нет, чтобы видеть процесс вживую и оценить сложность.

Нужен спец !

Share this post


Link to post
Share on other sites
Мне Гугл на "mtp api" ничего не выдаёт и похоже, что в России этими вещами никто не занимался, по крайней мере, на нашем языке не светился. И моба такого нет, чтобы видеть процесс вживую и оценить сложность.

Поищите "mtp protocol specification".

Например, спецификация на MTP.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this