Привет всем ... Зафигачил тут карту ММС ... Все хорошо, при обращении к конкретному адрессу и прочесть 512 байт все работает ... Если читать уже не один сектор, а несколько подряд, то уже на примерно 10 прочтении висяк while(SPI(0xff)!=0xFE); нема ответа 0xFE он че заснул чтоли?

Вот эта конструкция не очень понятна SPI(0xff)!=0xFE

Скорее всего он не заснул а перешел в slave

У Вас SS сконфигурирован на вход или на выход ?
если на вход, подтяжка есть ?

SS лучше управлять вручную, так надежнее.
Попробуй этот кусок, у меня работает нормально.

Извеняюсь за плохо выложенную проблемму... Значить так ... весит у меня на СПИ Экран и флешка ...
Еще я обнаружил интересны факт если отправить команду на блок 512 байт ... и потом читатьс адресса кратному 512 байт 0x200 все читается... если в адресс некратен то ваще не присылает ... ладно я и так читаю блоками в 512 байт ... тока если прочесть подрят гдето 10 блоков то карточка в недает ответ 0xFE начало блока данных... так я и думаю что он мож спит иль че ... Контроллер у меня мастер и молько мастер .. SS соответственно на выход ... тут точно карта глючить ... проверено та плате без экрана...

Скажите какие особенности при работе с Картой вам встричалить ... и какие нужно учитывать для нормальной безпроблеммной работы с картой ...

На сайте самсунга есть полная документация MMC стандарта как в работе по SPI так и в MMC режимах.

Спецификация гласит что так называемый TOKEN "синхронизирующий бит начала передачи", может появляться в любой момент тактов ожидания ответа, то-есть он может быть не кратен 8-ми циклам.
Решение проблемы: надо отлавливаить не код "FE" , а всего-лишь первый нулевой бит, и по нему уже синхронизироваться, он может появляется в любое время а не так как вы его ожидаете.
Я в интернете на зарубежных форумнаходил исходники с подобным неправильным способом работы с карточкой и так-же жалобы на неспособность работы некоторых карточек от некоторых производителей.
Поэтому пришлось написать полность свои функции. С обработкой токенов-ответов на разные там ошибки карты. Карточки с которыми я работал вот такие: APACER 512Mb, Kingston 1G, Transced 2G и пару каких-то неизвестных ( 5 вольтовых )производителей. И никаких проблем.
Написал функции обработки информационных структур (CCD, SCD - по моему их так зовут), для определения размерности карты и максимального рабочего пакета, без обработки этих структур в которых присутствует информация о максимальных размерах: входном пакете записи и пакете чтения.
Так же перед работой карточки надо установить командами размерность пакета, это как за правило.
Еще, можно пересекать границы адресов, но только не адресов которые кратны максимально заявленного размера блока передачи текущей карты.

Я думаю Вам надо переписать код, для того чтобы синхронизировать работу вашего SPI в микроконтролере Вы должны написать чисто програмный отлавливатель первого нулевого бита. Тогда у Вас не будут проблемы с несовместимостью Вашего устройства с карточками.

Тогда получается если 0 бит будет в середине(апаратный SPI) допустим 4й бит, то все данные за ним нужно подвинуть на 4 влево? Тогда и вправду нада програмный SPI ...

Однозначно.
Почитай мануал с самсунга, поймешь что я не шучу.
Там есть так называемый на графиках обмена, период ожидания ( Ncr ) - и может принимать значение от 1 до 8, но обычное заявленное значение равно 8. В других мануалах максимальное значение и того больше.
И самое главное, обязательно: если будешь применять команды записи или чтения, то предварительно примени команду SET_BLOCKLEN (она же CMD16), с параметром удобного для тебя размером блока, но не больше заявленого в CSD.WRITE_BLK_LEN. И при чтении не пересекай адреса через границы кратные размерности CSD.WRITE_BLK_LEN или CSD.READ_BL_LEN.
Привет студентам.

Не пугайте людей, в spi все что происходит должно быть кратно 8 битам, иначе это уже не spi.

while(((r1 = mmc_spi(0xff)) & 0x80) && --retry); // wait for response
return r1; // if more than 8 retries, card has timed-out
это ожидание после посылки команды, никаких сдвигов.
почитайте вложение в мой предыдущий пост, перепробовано на 20 разных карточках.

Ну често сказать то я больше согласен с товарищем Max_Shaman на счет того что начало блока данных т.е. бит 0 мож выскочить где попало ... а согласен потому, что когда у меня висяк, то 0 был уже не 0-м битом а 1-м ... так я думаю что и вправду нада программный SPI ему ... это первое, и сразу созрел у меня еще вопрос ... на счет скорости чтения ... вот посмотрим тесты чтения с разных карточек и у всех она разная ... вот как это понимать ... ведь когда мы читаем из карточкм то скоростью клока определяется скорость чтения данных из нее ... вот если напримен 8Мгц клок это уже 1мегабайт у сек ... но карточка по тестам допустим неможет так быстро читать ... короче если без этой воды ... что определяет скорость чтения из карточки ... ведь есть же разница между карточками ...

С программным spi нормальную скорость уже не получите
А скорость разная потому что после посылки команды "чтение сектора" карточка отвечает кодом MMC_STARTBLOCK_READ (0xFE) не сразу и эта задержка у всех разная.

В структуре CSD или OSD не помню уже как конкретно она зовется. Есть информация о максимально граничных частотах CLK, но там как минимум 20 мгц, я эти данные просматривал даже у старых 5 вольтовых карточек, у MMC+ заявленая СLK как правило до 50мгц доходит .

AlexBoy - спецификация, она и в африке спецификация, а SPI тут не причем.
MMC_STARTBLOCK_READ - это константа заявленная в скачаном где-то хеадере как FE. И такие исходники не по спецификации, я их просматривал и жалобы на них тоже. Поэтому и решил поискать спецификацию.

Не все так мрачно. Нулевой бит может придти любым, но это не значит, что нужно двигать данные на 4 бита java script:emoticon(':)', 'smid_2')
У меня проверка выглядит так:
do Res=ShiftSPI(0xFF); while((Res==0xFF) && --cnt;
Работает примерно с 20 разными типами MMC и SD на аппаратном SPI 16 МГц (не в AVR правда, а в ARM, но это без разницы)

Max_Shaman - боюсь вы невнимательно читали документацию.

Я использовал:
MultiMediaCard Product Manual, Rev. 5.2 © 2002/2003 SANDISK CORPORATION

А там есть таблица "Table 5-9. Timing Constants definitions" в которой NCR от 1 до 8 при этом единица измерения равна 8 clock cycles.

Мой MP3 плейер на ATmega отлично считывает файлы как с MMC так и с SD карточек и ни разу проблем с чтением не наблюдал.

Ты сам себе противоречишь. Привет вечным студентам.

чего тут непонятного? NCR может быть равным от 1 до 8 байт а не бит как вы вероятно думаете

Ncr - измеряется не в байтах, а в CLOCK CYCLE - а это в переводе означает один такт CLK на шине SPI, он же период tpp который заявлен в документации (и он разделен на две части как можно было догадаться twh и twl). И это не пересылка или прием одного байта - это один такт из тех восьми которые входят в обычную транзакцию SPI. Пусть Ncr и заявлена фиксированой в определенных карточках, это зависит от специфики интерфейсного контролера который там стоит и отвечает за интерфейс, а они бывают разные.

А можно ссылочку на документ, где Ncr измеряется в CLOCK CYCLE. В док-те, приведенном TinyQ
_________Min___Max___Unit
NCR______1_____8____ 8 clock cycles

т.е однозначно в байтах

http://www.samsung.com/Products/Semiconduc...8nafa_rev09.pdf - например.

Если не будет скачиваться заййдешь на сайт самсунга www.samsung.com и в поиске на этой странице даш запрос "MMC datasheet " там очень много всего.

ВЫ, многоуважаемый, не обратили внимание, что в приведенном ВАМИ документе на стр.64 присутствует точно такая же таблица. Откуда еще информация о некратности ответа байту?

Проглядел возможно. Не вините. Посчитал клоки за восьмиклочные юниты. У меня просто исходники так работают, жду первый нулевой бит програмно для Single Block Read и Single Block Write, когда эти транзакции, а потом запускаю для обработки следующих данных уже SPI аппаратный. Что только ради правильной синхронизации не придумаешь. Давно все это было, года полтора назад, запамятовал малость. Прошу прошения за наглость.
Звыняйте. Исправлюсь.