Ну тогда полный вариант:

[attachment=13085:attachment]

Более экономичный и быстродействующий

Сегодня проверил с SD_Micro от Kingston на 64 МБ.
Данная последовательность команд (смотри топик выше) с ней работает!!!

Кто плавал посоветуйте!!!

Как вычислять CRC16?
Или что скармливать вместо CRC в конце CMD24 ?

http://www.maxim-ic.com/appnotes.cfm/an_pk/4068

Там очень подробно про CRC7 ( раздел Cyclic Redundancy Check ) и в конце про CRC16.

Откопал в приведённой доке следующее:
59 (0x3B) CRC_ON_OFF Only Bit 0 R1 Argument sets CRC on (1) or off (0).

Ты случаем не сталкивался с работой команды 59
(она отключает только проверку или и саму выдачу CRC?)

Я тоже хотел отключить это CRC, уж больно оно мне мешало, но как оказалось, оно по умолчанию и выключено, т.е. CMD59 включает проверку CRC. Только вот кому это надо? Лучше её не трогать.

По умолчанию в режиме SPI проверка CRC отключена, то есть мы должны отправить правильный CRC7 только с первоq командой - CMD0 (там считать ничего не надо - все известно заранее). То есть, байты CRC7 и CRC16 надо отправлять и получать, но на содержимое забить. я 0xFF отправляю.

CMD59 может включить/отключить этот режим. Я на всякий случай подаю CMD59 - мало ли что там производителю SD card взбредет в голову.

Сообщение отредактировал Rudolph - Aug 21 2007, 09:40

Дело не в этом просто у меня иногда карточка мусором сыпет...
Хочу в качестве проверки... (его включать не надо она его и так выдаёт при чтении)

Откопал на китайском сайте исходник ОДНО НО
то что карточка возвращает с этим CRC не совпадает

оригинал в файле [attachment=13133:attachment]

;**************************************************
;CRC16
;**************************************************

Mat_CRC16:
lds R16_Tmp1, SPI_Blo1 ; Настроим счётчик
mov R10_Racht, R16_Tmp1 ; Нам нужен блок длиной в SPI_Blo1 и SPI_Blo0
lds R16_Tmp1, SPI_Blo0
mov R09_Racht, R16_Tmp1

; LDI R18, $FF ; Предустановка значения
; LDI R19, $FF

clr R18
clr R19

ldi Xl, low(SpiMas) ; Укажем на память
ldi Xh, high(SpiMas)

rjmp CRC_LoopEnd ; Перейдём к исполнению
CRC02:
LD R16, X+
EOR R18, R16
LDI R17, $9
CRC03:
DEC R17
BREQ CRC05
CLC
ROR R19
ROR R18
CRC04:
BRCC CRC03
LDI R16,1
EOR R18,R16
LDI R16,$A0
EOR R19,R16
RJMP CRC03
CRC05:

ldi R16_Tmp1, 1 ; Уменьшим счётчик циклов на 1
sub R09_Racht,R16_Tmp1
sbc R10_Racht,R01_Tut0

CRC_LoopEnd:
mov R16_Tmp1,R09_Racht
or R16_Tmp1,R10_Racht
brne CRC02 ; Если не всё получили - повторим

STS SPI_CRCL, R18 ; Закатаем результат
STS SPI_CRCH, R19

RET

В общих чертах у тебя последовательность команд какая?

Случаем никто ФАТ не ковырял? Как вычислить номер блока – соответствующий началу размещения файлов? И как вычислить объём флеши (т.е. максимальный адрес) ?

Я использую предформатирование - Т.е. закатываю на флешу файл, а после
его изменения сливаю на комп...

В этом случае я просто ломился по адресу 00045000 и попадал на начало файла,
но как недавно обнаружилось у некоторых флешей начало файла может быть другим...
(например с 00044E00)...

В данный момент такая:

0. Частота SPI < 400 kHz

1. 100 байтов 0xFF, что б уж точно хватило.
2. CMD0 до тех пор, пока не получу 0х01, с таймаутом конечно.
3. CMD55.
- Если ответ на CMD55 == 0x01, то это SD и далее CMD41 до тех пор, пока не получу 0х00
- Если ответ на CMD55 == illegal command, то это MMC и далее CMD1 до тех пор, пока не получу 0x00

4. Выставляю частоту SPI на макс., т.е. 3.7 МГц

Все, теперь работаю с карточкой. Конечно надо еще сделать анализ всех битов в ответах (R1, например) и т.д.

Запись, чтение и стирание проходят нормально.

Насчет FAT-ов я надеюсь на Windows CE. Там все это есть, так что, надеюсь, мне только придется написать аппаратно-зависимый драйвер SPI.

Ох, забфл совсем, после пункта 4 идет:

5. CMD59 arg = 0
6. CMD16 arg = 512
7. CMD9 arg=0 - получить регистр CSD.

Вот пока с регистром CID только непонятки какие-то. Не получить его, но, наверное, я что-то неправильно делаю - будем разбираться.

У меня ОДНА последовательность на CID и CSD...
(разница только в команде)
Вчера возился с алгоритмом расчёта объёма карты...
Одно НО у меня получается 30 метров с хвостиком вместо 32х

32 mb
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

8C 26 01 2A 0F 59 01 E9 F6 D9 83 E3 92 40 40 D3 - CID
15 00 00 30 30 30 30 30 30 09 B3 00 9B 9A 28 E3 - CSD

09 - Read_Bl_Len 59 => 9
07 - Sector_Size 83 E3 => 10.000011 1.1100011 => 0000111 => 07
07 - старший байт C_Size 01 E9 F6 => 000000.01 11101001 11.110110 => 07 A7 => 07
A7 - младший байт C_Size => A7
03 - C_Size_mult D9 83 => 110110.01 1.0000011 => 011 => 03
> OK.

mult = 2^(c_size_mult + 2) = 2^(3+2) =32
block_len = 2^read_bl_len = 2^9 =512
block_nr = (c_size + 1) * mult = 07A8h*32d =62720
Capacity = block_len * block_nr =62720*512 =32112640 = 30,625 mb

Дык реальный объем всегда меньше. Все правильно.

Перефразирую:
Надо что-бы на экране писалось 32, 64, и т.д.
как подправить формулу пересчёта?
(табличный метод не хочу)

ИМХО искать ближайшее из константных значений (32, 64, 128...) и его выводить.