GetSmart
Feb 1 2014, 09:23
В стандарте на этот счёт что-то оговорено?
Например, если хочется в фоновом режиме организовать чтение карты, но чтобы другой процесс мог в любой момент без лишних задержек прервать чтение и переключиться на чтение/запись другого сектора. Или может быть есть другой вариант прерывания чтения.
Цитата(GetSmart @ Feb 1 2014, 13:23)

В стандарте на этот счёт что-то оговорено?
В стандарте оговорено, что можно снять во время Busy. В другое время, надо полагать, нельзя.
Цитата(GetSmart @ Feb 1 2014, 13:23)

Например, если хочется в фоновом режиме организовать чтение карты, но чтобы другой процесс мог в любой момент без лишних задержек прервать чтение и переключиться на чтение/запись другого сектора. Или может быть есть другой вариант прерывания чтения.
Кэш и буфер записи не помогут? Это все же более традиционный путь.
GetSmart
Feb 1 2014, 16:39
Цитата(aaarrr @ Feb 1 2014, 22:09)

Кэш и буфер записи не помогут?
На уровне ПО есть и то и другое. Просто организовано упреждающее чтение. При смене адреса старый сектор уже не требуется и чтение его можно было бы скоропостижно прервать.
Интересует прерывание внутри передачи 512 (или более) блока данных.
В спецификации сказано конкретно и понятно.
The CS signal must be continuously active for the duration of the SPI transaction (command, response and data). The only exception occurs during card programming, when the host can deassert the CS signal without affecting the programming process.
GetSmart
Feb 2 2014, 10:34
Тогда вопрос для хоть сколько-нибудь знакомых с внутренней организацией карты. Какие подводные камни можно ожидать, если во время тестирования ограниченного/небольшого кол-ва карт они будут корректно отрабатывать отключение CS при чтении? Вопрос предлагаю рассматривать как ситуация отключения CS, неожиданная даже для ПО. И хотелось бы конструктивно, без пионерских страшилок. Самое страшное, что мне, как незнакомому с втурненней организацией карты, пока видится - карта будет продолжать/завершать передачу данных после передёргивания CS. Т.о. ПО может неверно интерпретировать response карты при передаче ей новой команды.
По поводу выдержки. ..."must be"..."without affecting"... Следует переводить как: CS влияет на приём (интерпретации) SD-картой пакета данных, состоящего из команды, ответа и данных. Влияние может быть вполне нейтральным, если не допустимым, - завершение отработки команды. Допустимым оно будет при явном указании об этом. Нейтральным только вероятно, по желанию разработчика. В документации на серию AT45DBxxx тоже нигде явно не указывается о вольном обращении с CS, но учитывая общие особенности работы с этой серией - понятно, что это допустимо, т.к. и при чтении и при записи нигде не указывается размер блока данных в SPI-транзакции.
Не мешайте мух с котлетами, вторая часть фразы c "without affecting" относится только и исключительно к "card programming" (это когда она физически пишет блок во флеш), а не к другим режимам, во всех других режимах он "must be", и все тут. Читать надо вЫнимательнее - "Сигнал CS ДОЛЖЕН БЫТЬ....., за одним исключением, когда программинг"
Практически, скорее всего, сброс CS переведет выходной буфер карты в 3-е состояние, а автомат самой карты останется в том же состоянии, в котором и был. Хотя тут каждый производитель контроллера флеша волен реагировать так, как ему хочется, так как ситуация явно ошибочная, и никто не думает, что в ней и как делать.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.