понимаю что тема не новая, но все таки где почитать и код посмотреть???
под ммс все есть, но коннектора под нее нет
в подфорум для начинающих не стал, ибо слишком долго а мне бы побыстрее

Moderator:
Для "побыстрее" читайте на форуме многочисленные ответы на вопросы Ваших предшественников, а не засоряйте основные ветки форума дежурными вопросами.

Для winAVR
Если без FAT, то я использовал стандартные атмеловские библиотеки:
Нажмите для просмотра прикрепленного файла

Вот для установки библиотеки

Работает стабильно, без проблем с SD 1ГБ Apacer 60x (объём меньше-больше не пробовал)
Пишет и читает секторами по 512 б. Результат удобно смотреть в winhex.
В корневой папке найдёте mmc.c тут разберёте функции. Там же найдёте mmc.h тут описано подключение к CPU. Пример основной программы в avrlib/examples/mmc. Не забудьте ввести изменения в global.h и makefile (частота и камень)
Изначально отформатировал SD под FAT16

P.S. недели 2 назад попал в Вашу ситуацию, долго ковырялся, тем особо не нашёл, но в итоге всё заработало, может вам поможет, сэкономите время...

Удачи

Посмотри И вообще посети И здесь посмотри, много найдешь

Для экспериментов, в качестве коннектора замечательно работают разъёмы от старых FDD-5,25 (дисководов).
Ещё подойдёт кусок ISA разъёма от старой матплаты PC.

Добавлю, что предлагаемый в этой библиотечке (если я правильно понял) подход "через SPI" описан по-моему в 99% всех app.notes на эту тему... По крайней мере оставшегося 1% я не видал. ;-)

Практика показывает, что большинство карт отнюдь не достигают теоретического максимума скорости обмена по SPI - надолго уходят в бизи после операции записи (особенно если записывать по одному сектору, что опять же предлагается в 99% app.notesов). Почему по SPI даже при multiple write карточка часто уходит в бизи, а по SD4, вроде бы, не так часто - это я не вполне не понял.

В конце концов это составляет скорость записи от 50 до 150 кбайт в секунду (еще и от карты зависит). Для большинства задач это вполне достаточно, но если что, то я предупредил. ;-)

Кстати, на мой взгляд, искать по форуму SD-карты трудно, потому что в слове SD "меньше трех букв" ;-)))

При записи по одному сектору в режиме 1-wire SD у меня получилась такая скорость (с разными тактовыми):
103 КБ/сек - 215 КБ/сек (CLK = 20 MHz)
26.5 КБ/сек - 30 КБ/сек (CLK = 300 kHz)

Карта уходит в BUSY. Multiple write не использую.

Вот уж действительно. Никто не хочет по форуму поискать что к чему. Откройте же http://elm-chan.org/fsw/ff/00index_e.html. Там все внятно написано, библиотека под FAT12-FAT32 опубликована совершенно бесплатная, примеры benchmark'ов приведены. Какого рожна еще надо?

Вот именно - скоростями с которыми кард-ридеры записывают тут и не пахнет. Впрочем, в спецификации так и сказано (да и по смыслу получается) что если не использовать Multiple Write то используется только один буфер и после каждого сектора карта ждет пока он запишется. М-м-м... как-то я мутно "своими словами" спецификацию пересказываю. ;-)

Что касаемо до файловых систем, в аппликейшн-нотах надо поискать. На сайте SiLabs например можно готовые текстики взять и немного переделать с учетом используемого проца.



Обратите внимание, что там бенчмарки для режима SPI либо для контроллера с MMC-интерфейсом. Когда появится ссылка на "рожна" с библиотеками для собственной реализации SD4 и бенчмарками для него это будет хорошо. Я на форумах (на edaboard и у silabs) видел что кто-то хвастался, мол, реализовали и все стало круче - но общаться люди не пожелали. Если сам домучаю (сейчас этот проект немножко на край стола съехал, ждет влияния финансов со стороны заказчика) - поделюсь, если это еще будет актуально... ;-)

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

Если можно, вы для пользы и для истории объясните, в чем конкретно проблему видите? А то вот пойду сейчас по неправильному пути "ногомахания", плакать буду потом горькими слезами... А если сейчас точно удастся понять в чем корень зла, так может избегну этой опасности...

У контроллеров с SD-интерфейсом на борту есть один минус. Я их что-то не встречал в корпусах меньше LQFP-100, а в носимые устройства иногда хочется вставить что-нибудь типа QFN-48... Потому что чем мельче - тем лучше... А кто встречал?

Правда NXP обещает что вот-вот начнет задумываться о маловыводных корпусах, в течение этого же 2009 года мол образцы начнут рассылать... Но ждать же невозможно!

Проблема в том, что превзойти даже обычный однопроводный SPI уже будет затруднительно. Сколько тактов понадобится на извлечение/упаковку 4-х бит и вывод их в порт? А еще придется CRC считать по всем линиям отдельно.

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

А что у нас там с извлечением/упаковкой битов? Мне разве показалось что там по полубайту все отправляется, вроде бы ничего не перепутано как бывает порой...

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

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

Есть еще третье решение - микросхему интерфейса использовать. Но опять же в мелких корпусах вариантов почти нет. Все это грустно. ;-)

aaarrr все объяснил.

А Вы еще в добавок и не представляете, где есть узкое место -тот-же SPI упирается в 20(двадцать) мегабит, что более двух мегабайт в секунду. По той-же Вашей цитате Джеймса при уменьшении скорости обмена по SPI в 66 (шестьдесят шесть) раз получили скорость обмена меньше всего в 4 (четыре) раза. Вспомните начала алгебры и посчитайте, с какой скоростью будет происходить работа c SD, если даже передача будет происходить мгновенно. Так-что копайте насчет тормозов в сотни килобайт совсем в другом месте.

Ну и зачем микроскопическому носимому устройству мечтается десятки мегабайт в секунду заливать на карточку?

И что, от этого легче?


А вот и камень на могилу: CRC в SD-режиме отключить нельзя.

Новую тему создавать не буду, задам здесь коль фат упоминался.
Посоветуйте пожалуйста литературу или ссылку с подробным описанием FAT16 на русском.
Может волшебные ключевые слова, по которым искать.
Поиск по форуму дает многочисленные ветки по применению ит.д. в которых теряю надежду найти необходимую информацию.
Заранее спасибо!

На русском не (по)советую. Лучше поищите гуглом fatgen103.pdf - роднее описания не бывает.

Даже копать не нужно, в спецификации написано черным по белому. И это уже обсудили даже... И про SPI, и про одинокий буфер. ;-)

Если SD4 реализуется либо силами самого проца, либо трудами периферийного SDIO-интерфейса, тогда, по-видимому, для карточки разницы никакой не будет и скорость "принципиально" одинакова...



Зачем мп3-файлы с компа в носимое устройство заливать? Чтобы их воспроизводить! ;-)))
Вопрос собственно в том что примерно каждый час может требоваться обновление контента объемом примерно 1Гб, а карточку вынимать низя...


Легче чем что? Так выходит что надо считать 1024 полубайта на сектор, на что уйдет 1024 клока. Чтобы "выстрелить" 32-разрядное слово уйдет скажем 20-30 тактов, потом берем следующее слово из памяти, допустим еще 10 тактов. Получается, что в целом 500нс уходит на 4 байта то есть в идеале можно надеяться на 8Мб в секунду. Ясно что реалии будут поменьше, но все же это не 200кб/сек...

Я не прав?



А вот это действительно наигнуснейший ППЦ, спасибо.
Кстати, если физиономией ткнете в соответствующее место в мануале, буду вдвойне благодарен.
Или имеется в виду собственно что про CRC ON и CRC OFF режимы указано только в разделе относящемся к SPI и это следует понимать так что обсуждавшаяся CMD59 в SD4 режиме не будет работать?



Скорее всего посоветуют как можно быстрее "программистский минимум" английского освоить. ;-)

Можете найти легко такую страшно бородатую книгу (она еще на глиняных табличках была) с фамилией автора Джордейн (с гугла с полпинка в любом формате). Если мне склероз не изменяет, там в разделе Диски описывается FAT12. Причем очень подробно и понятно. Ну а FAT16 попроще... Короче сразу станет ясно.

Ключевые слова: "структура загрузочной записи FAT16", "структура логического раздела/диска FAT16", "формат таблицы размещения файлов", "структура каталога FAT16"...

В общем, там все просто...

Мы о каком железе говорим? В названии темы стоит AVR.
Назовите архитектуру, и я скажу, какие на ней получатся тормоза.


Для SD-режима CMD59 указана как reserved. Понять это можно только одним образом.

Уважаемый aaarrr, подозреваю что вы правы.

Контроллер я, конечно, по забывчивости уже не AVR имел в виду, а более абстрактно мыслил... Я AVR-ы люблю, но я не настолько фантазер, конечно...

Впрочем, давеча, восскорбев сердцем после вашей подсказки нашел-таки "подходящий" проц с SDIO и USB Hi-Speed... Правда он зрительно половину PCB-шки занимает... Потому что LQFP-шный... Возможно пора действительно на BGA пересаживаться... ;-)))

Ну, в общем, за консультации и подсказки всем спасибо!

Родион

Вот нашел переводы про SD и FAT. Может кому пригодится.
h__p://w_w.piclist.ru/mmc.html

Есть новые данные...
Реализовал Multiple Write для 1-wire SD. Скорость теперь стала 2.3 MB/sec. CLK=20MHz.

Так про это самое (мультисекторное чтение/запись) много раз уже писалось и на нашем форуме тоже. В чем великое откровение сих результатов?

попробуйте тут http://yourdevice.net/article.html посмотреть