замена AT45DB161B-RI на AT45DB161D-SU, проблема с отсутствием ноги RDY/~BUSY Опции

[plombir]

Доброго дня, Господа!

Так как м/с flash AT45DB161B-RI (28 ног) снята с производства, решено заменить её на 8-и ножечную. Так, вот, проблема возникла при написании кода определения занятости м/с. Если раньше сигнал проверялся на ноге RDY/~BUSY и проблем не было, то здесь она отсутствует и приходится проверять через "Регистр Статуса" 7-ой бит. Что то не получается... Перепробовал по разному и по всякому. Начинает работать если ставится задержка из цикла NOP-ов вместо ожидания.

Если кто сталкивался с программным опросом м/с flash AT45 через регистр, подскажите пожалуйста последовательность действий при ожидании занятости.

[Ykidia]

Вы же данные не тем концом суете.

Вообще-то 2 варианта. Если вдруг Вы правы, тогда у меня бы все читалось наоборот, и в статусе было бы что-то вроде 0x35 вместо 0xAC или 0x37 вместо 0xEC. Но такого нет и рядом, читается 0x00 (либо 0xFF, который я раньше выдавал в линию для старта передачи), а в большинстве "рабочих" экземпляров читается что надо.
Ну а второй вариант - просто посмотрите внимательно на мой дефайн:

#define SPI_MODE 0x38

Бит 6 = 0, отсюда

When 0, SPI data is transferred MSB (bit 7) first.

что вполне совпадает с требованиями:

All instructions, addresses, and data are transferred with the most significant bit (MSB) first.

Единственное, у меня IAR строчки вида S0SPSR; просто выкидывает. Хотя это явная ошибка, по стандарту должно быть чтение. Поэтому я делаю { volatile uint8_t tmp = S0SPSR; }. Не смотрели листинг, может то же самое?

У меня не выкидывает. Смотрел по листингу для 2214 - чтение на месте. Для 2138 при компиляции почему-то сообщает, что выражение не имеет эффекта, но по листингу все равно чтение остается.

Сообщение отредактировал Ykidia - Mar 31 2007, 20:59

[defunct]

Вообще-то 2 варианта. Если вдруг Вы правы, тогда у меня бы все читалось наоборот...

Вообще-то был бы только 1 вариант - писалось бы наоборот тоже. Тобиш вместо опкода 0x57 посылался бы 0xEA.. На такой опкод вполне реально получить в ответ 0x0 или 0xFF.
Но это к проблеме не относится.. а так просто чтобы обратить внимание на причинно следственную связь.

А по проблеме, думаю банально накосячили с сигналами либо заняли чем-то SSEL..
Если программно клокать, работает?

S0SPSR;

Я бы так ни в жизнь не написал.

Код

    V32 dummy = S0SPSR; // dummy read of SPIF

куда понятнее смотрится и безопастнее.