Мне перевод не нужен, читаю английский без перевода
Но вопрос мой был немного в другом. Я знаю, как работает CMD25. Меня интересует: есть ли железобетонная гарантия, что файловая система от Чана при мультисекторной записе (передавая sector_count > 1) выдаст сектора "без дырок". Например, она пишет сектора 10, 11, 12 - это без дырок. Их сразу можно писать на карту. А вот с дырками, но тоже несколько секторов: 10, 20, 12. Есть дырка. Я к чему задаю вопрос: может быть ФС требует записи нескольких секторов, лежащих не линейно, в надежде, что низкоуровневый драйвер сам разгребёт это? Например через кольцевой буфер? Я думаю, что Чан всё делает правильно, т.е. даёт сектора последовательно, пригодные для записи на носитель. Но всё же, а вдруг?

Приклеить на компаунд или липучку

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

При наличии больших буферов ФС - драйвер технически может вызывать функцию disk_write с параметром "Количество секторов", отличным от единицы.
Фактически, единственный такой вызов я нашёл в функции f_write() в том случае, если ЕСТЬ свободные сектора, куда это поместится, и размер данных больше чем на один сектор.

Так что, весь разбор что и куда писать, находится выше. Драйверу же карты передаются только команды "Пиши вот это, вот сюда, в таком-то количестве".

Пиши вот это, вот сюда, в таком-то количестве, подряд с указанного места. Я пользуюсь - работяет.
Кстати, очень понравилось extFAT, там как раз нужно 64 битное смещение в seek

Сообщение отредактировал Genadi Zawidowski - Sep 3 2018, 19:32

Отлично! Значит библиотека ФС всё сама разруливает. Кстати, я не делал мультисекторную запись пока, но даже посекторная запись идёт со скоростью до 200 кбайт/сек. Что довольно шустро для моих задач)

Пилил я как-то свой тест скорости карточек. Не оптимальный до ужаса. Тем не менее, результат был таким:


Здесь кристалл работал на ~96МГц, возможно, меньше. SDIO тактировалось от PLL на 48МГц.
Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно.

Были у меня ещё какие-то весёлые проблемы с записью больших блоков через FatFS, хотя библиотека собиралась с неправильными параметрами, и объём памяти под неё старательно ужимался. В итоге, при записи огромных буферов из памяти (как раз размером в несколько секторов) получал странные зависания в случайных местах. В причинах не разобрался, добавив костыль, заставив код писать мелкими блоками.

Эх... SDIO это совершенно другой полёт. Как правило, все неприятные нюансы (таймауты, ожидание откликов (R1, R2...)) оно на себя берёт. Да ещё + DMA. С SPI, конечно, тоже можно DMA включить на передачу чисто блоков, но драйвер уж сильно замороченный выходит...

Вы не поверите, но и на приём - тоже можно!
SDIO мало где реально нужно в embedded области.

SDIO может эмбеддедуу и ненужен, он нужен заказчику который мне этот эмбеддед заказал!
нужно писать телеметрию изделия, а потом когда что то пекосо....лось в нутри оного изделия и оно со звуком ящика с гвоздямт стукнолось об землю - обосновано назначать виновптого
как я говорил, теперь попробую eMMC микросхемку запустить вместо сокет+карта. так выглядеть поприличнее будет, как мне кажется.

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

Все карты/накопители разные. Некоторые позволяют вольности с протоколом, другие не поймут.

Так-то неплохо, конечно, но пайка карт в печи не гуд - может фирмварь потереться...

У Вас как-то видимо неправильно составлено ТЗ. Заказчик должен заказывать функционал, а не способы его реализации. А уж способы реализации должен выбирать инженер исходя из требований ТЗ и здравого смысла. И как подключено некое ЗУ или его тип, объём - это однозначно должен определять инженер, а не заказчик. Заказчик в ТЗ должен только указать: необходима фиксация данных телеметрии в энергонезависимой памяти в течение не менее чем такого-то времени и такие-то и такие-то параметры (как то так). А уж как это делать и куда сохранять - забота инженера (программиста).


Вполне нормально писали текущую телеметрию во FRAM+FLASH по SPI без каких-то проблем.
А писать это дело в FatFS, внутренние операции которой Вы не контролируете - это стрелять себе в ногу. Или заказчику, который не умеет грамотно составить ТЗ. И разработчик занимается натягиванием FatFS, вместо обеспечения хранения потока телеметрии, устойчивого к авариям питания (без всяких FS).

Они феном паялись
А о каком "фирмварь" идет речь?

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

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

В общем случае Вы безусловно правы. Но при наличии повышенных требований к защите информации, Заказчик может позволить себе не заморачиваться формулированием их (требований) в весьма мудреных терминах отрасли, а потребовать использования уважаемых им (Заказчиком) протоколов.