Перейти к содержанию
    

USB MTP протокол

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

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

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А как 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 может хранить данные без ФС ? Всё равно 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:

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Нужен спец !

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...