April 10th, 2015

Тернист наш путь.

Вот же непруха! упёрся в странный глюк, когда безобидный вызов функции вызывает hard fault - именно сам вызов, а не то, что функция начинает делать. Покумекал, увеличил стэк до 2 килобайт (было 256 байт всего) - глюк пропал.

Теперь Mass Storage распознаётся системой более лучше™. Я вижу объём (уже не новость, впрочем), но "диск" по-прежнему не размечен и при попытке его форматировать вижу очень странное: запись идёт по нужным адресам, затем адрес "заворачивается через верх" (т.е. доходит до максимального значения, обнуляется, и снова начинает расти), доходит до значения 00004E00 и система фиксирует невозможность продолжения работы с диском.

4E00 это ровно 39 секторов (по терминологии файловой системы, не физических!) по 512 байт. А когда я смотрю, что же там записалось, то вижу только FF.

Перед записью, разумеется, я стираю затронутые сектора (физические, не файловой системы! это две разные сущности - сектор флэш-памяти и сектор файловой системы), затем уже пишу данные. То, что функции записи и чтения работают, я уже раньше проверил.

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

Ещё заметил, что иногда приращение адресов идёт так: 00000000, 00000200, 007EEF00, 00000600,.. т.е. среди нормальных значений, появляющихся с шагом в 512 единиц, нет-нет да и выскочит какая-то аномалия. Это фирменный код от ST.com так себя ведёт!

ДА!!!!!!!!!!!1111

Косой-кривой, без нормального механизма аккуратного (без излишеств) стирания секторов, но флэш-диск ЗАРАБОТАЛ!!!!!!! И я могу создавать-редактировать-удалять файлы на микросхеме флэш-памяти, собственноручно запаянной на самостоятельно спроектированной плате абсолютно моего устройства!!!!!!!!!!!!

Триумф.

Collapse )
  • Current Music
    Sam Butera - Bim Bam
  • Tags

worklog: прикрутил простейший алгоритм кэширования

Теперь чтение и запись флэшки идут через буфер размером в один физический сектор.
Алгоритм не универсален и совершенно точно будет тупить, если запись вдруг перескочит через границу сектора, но в нормальных условиях такое происходить не должно, ибо в физический сектор 4096 байт прекрасно укладываются логические сектора файловой системы (512, 1024, 2048, 4096 байт - всё чётко).

Под кэш отъедено аж 4 кБ системного ОЗУ, коего всего-то 64 килобайта (и 2кБ уже ушло на стэк). Наверное, в будущем, память на плате с ПЛИСкой можно будет заюзать под эти нужды. Или... ну, не знаю... память внутри видеоконтроллера (там её больше мега, из которых использовано от силы килобайт 400). Изврат, но тёплый и ламповый. Сразу вспоминаются времена DOS - то была эпоха. "INT 21H" и всё такое :)

А выигрыш простой: если раньше скорость записи была от силы 9.5 кБ/с, то щас 60..70 кБ/с, что заметно комфортнее (учитывая скромные объём флешки). Скорость чтения вообще упёрлась в скорость USB Full-speed.

Результатами удовлетворён.

Теперь пора прикручивать FatFs уже к самому контроллеру. Надо только разобраться, где в хитросплетениях библиотеки USB MSC спрятан код её отключения, дабы не вызывать конфликты файловой системы.

worklog

Вот что я вижу, когда микроконтроллер монтирует раздел 0 и читает корневой каталог:
mmounting fs...Success
d---A 2015/03/31 12:29 212481  BOARD.BIT
----A 2014/01/12 13:35 346661  DS1337~1.PDF
----A 2015/04/10 18:45 0  WHAT.TXT
----A 2015/04/10 18:50 0  FILE.EXT
4 File(s),559142 bytes total


Как мне нравится, когда просто подключаешь библиотеку, дописываешь туда интерфейс (ибо FatFs не привязана к аппаратуре и требует промежуточный слой HAL) - и вуаля, работает!


Теперь надо грамотно разрюхать источник потенциальных проблем: когда дивайс подключается к компу, прошивка должна вырубать работу драйвера файловой системы. Иначе возможно разрушение ФС, когда доступ осуществляется со стороны компа и со стороны прошивки. Но это уже мелочи, я вывел сигналы конфигурации USB (как только он пришёл, ФС надо вырубить) и отключения интерфейса (а в этот момент - подрубить обратно).