DVS, попробуй эту функцию вот в таком виде.
В том документе, который у меня, там требуется постоянно перед и после снятия /CS слать синхру по SCK в кол-ве 8 штук при MOSI=1.Код:u08 mmcSendCommand(u08 cmd, u32 arg) { u08 r1; // release chip select SPI_CS = 1; spiTransferByte(0xFF); // assert chip select SPI_CS = 0; spiTransferByte(0xFF); // issue the command r1 = mmcCommand(cmd, arg); return r1; }
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Хех, интересно про такой метод тактирования я инфы не находил, смотрел только "времянку" (диаграмма с задержками) для MMC.
Вечером попробую и отпишусь.
При посылке синхры после изменения CS, карта стала выходить из idle!!!
Но "чем дальше в лес-тем болше дров" теперь карта непонятно как выходит из MULTIPLE_BLOCK_READ и MULTIPLE_BLOCK_WRITE, дело в том, что стоит только вогнать её в режим MULTIPLE_BLOCK_READ, затем сбросить контроллер и попытаться провести инициализацию, то в R1 будет 0x3F (стабильно). А когда мне требуется снова режим MULTIPLE_BLOCK_READ, но с другого сектора, то карта вобще в него не входит. Попытался сделать STOP_TRAN ( CMD12 ), эффект есть, но не всегда.
Короче говоря MULTIPLE_BLOCK_READ с определённого сектора включается только один раз после инициализации. Я попытался прочитать PBRS, всё ок, данные правильные.
Попытался сделать перед началом MULTIPLE_BLOCK_READ
mmcReset(), в которую перед CMD0, добавил CMD12 и всё запустилось! Но!!!
Мне так не нравится :-((( Как то оно жёстко и в лоб, всё равно, что перед запуском другого приложения винду перегружать :-)
А процедуру MULTIPLE_BLOCK_READ (CMD18) можно подсмотреть? А то я пользовался по-секторным... Кстати, CMD12 (STOP_TRAN) обязательна для останова выполнения CMD18 и CMD25, после неё нужно отослать #0FFh (при этом должны получить от карты #0xFh, где х - любое число), далее опять шлем в карту #0FFh, при этом должны получить response = #0FDh, что говорит об успешном завершении обмена.
Ну, вот вроде бы и всё...
В смысле код функции интересует?Сообщение от jdigreze
Буду разбираться, а пока с полным сбросом всё работает :-)
Кстати, что если сразу после инициализации до начала MULTIPLE_BLOCK_READ, послать CMD12 ? Я посмотрел R1=0, но в MULTIPLE_BLOCK_READ не входит, точнее так на команду MULTIPLE_BLOCK_READ R1=0, дальше жду синхробайта в ответ (долго жду) и не дожидаюсь :-)
И ещё момент (может из предыдущих сообщений не понятно было): если войти в MULTIPLE_BLOCK_READ и счиать определённое кол-во байт, затем не делать STOP_TRAN!!!, то GO_IDLE хоть запосылайся - сброса не будет! Поэтому на всякий случай пришлось перед GO_IDLE сделать STOP_TRAN. Иначе только питание отключать или карту вынимать, а это не хорошо.
Всё таки в MMC как то оно логичнее что-ли сделано, хотя если бы я группой команд MULTIPLE_... не пользовался, то ничего и не заметил.
Ага. Если не хочешь на всеобщий доступ, пиши на мыло
Однако, это не правильно...
Хз. Но скорее всего так делать нельзя...
И еще. Сразу не обратил внимание. Считывать блоки нужно по 512 байт + 1 байт начала блока + 2 байта CRC для каждого сектора. Если произвольно послать CMD12, то данные (512байт) нужно дочитать до конца + CRC, и только после этого придет респонз.
После входа в MULTIPLE_BLOCK_... карта реагирует только на CMD12 и питаниеИ это нормально!
Кстати, GO_IDLE лучше не делать. Нет смысла. У меня хоть и посекторно работает, но постоянное чтение/запись идет в разные области карты, и все нормально.
Скорее всего MMC карты менее требовательны к полноте реализации протокола. Карты SD сложнее устроены, с ними и работать приходится сложнее.
ЗЫ: У тебя ящик электропочты 1,5Мб примет? Давай док вышлю, там с диаграммами очень всё наглядно...
Я не сторонник слишком ветвлённых функций, поэтому предпочитаю, пусть оно будет в одном месте и сгодиться в любом случае, как при смене на новую карту, так и при переинициализации текущей карты.
То что ты просил лежит у меня на ftp. Туда же можешь положить pdf. Инфу для доступа смотри в привате.
Вот такой у меня вопрос возник: данные о файлах внутри tzx имеют выравнивание, или же отделяются маркерами?
Это я к тому, что у тебя при чтении, после посыла STOP_TRANS идет retry на 255 байт, а если, например сектор считан от начала всего на 10 байт, а потом ты шлешь STOP_TRANS, после чего пытаешься дождаться в течении 255 байт респонза, то его не получишь, в результате все остальные команды будут игнорироваться. Попробуй после посыла CMD12 дочитать текущий сектор до конца (+2 байта CRC), и лишь потом войти в цикл ожидания респонза. Респонз должен прийти через 1 байт.
И не то и не другое.
Я про это знаю. За выходные думаю "выйдет каменный цветок" :-)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
