Кто работал с памятью at45db161d или в принципе с at45dbxxxd, пожалуйста подскажите, Проблемы с at45db161d и их решение Опции

[lomtev]

Так вот, ситуация такая. Использовал примеры программ из аппноутов, переписал коды команд на те которые советуют в даташите. Перепроверил и в других источниках типа занятие 7 с сайт 123avr. Функции написаны правильно. Сначала стираю память, потом пишу в нее значения до 176, тобишь записываю 176 байт. Потом читаю память и сохраняю данные в массив, после вывожу массив на экран (в выводе символов ошибок нет точно), выводятся исключительно значения 255, в рядок так 255 255 255 и т.д. Впихивал вывод значений в разные места программы с выводом разных переменных - вроде все работает. да и в противном случае вывело первоначальное значение массива а это 0. Забавная еще вещь наблюдается, программа написана изначально была для 28 ногово чипа, а я использую 8 ногий так что приходится читать занятость из регистра стуса строчкой типа while (!(SPSR & temp));, я думал что ошибка в ожидании и добавил строчку SPDR = STATUS_REGISTER;, но потом удалил, покуда изменений не произошло.
Так теперь зараза не хочет работать без этой строчки, хотя раньше работала так же криво как и сейчас.
И еще при стирании биты выставляются как я понял в значение 255.
Кто-нибудь сталкивался или работал с данным чипом? В тупике. предположений нет вообще. Если кто хочет помочь и нуждается в наглядной демонстрации кода, то я выложу.

[sensor_ua]

1) Прерывания пока разрешать не нужно (в setup()), а иногда и вредно - а вдруг где-то в дебрях спрятанного текста обработчик прерывания SPI от Папы Карло затерялся?
2) Сначала нужно всё-таки записать-прочитать буфер, чтобы убедиться в правильной настройке интерфейса, пинов и вааще - похоже, к этому уже пришли. Для работы с буфером ничего стирать не нужно (там ОЗУ), т.е. erasing(); нафиг. Это для отладки.
3) В функции записи нет строки unsigned char temp = 0x80; оно типа глобально, но в чтениичто-то есть -намешано. Вообще использовать переменные там, где можно использовать литералы (константные объявления через #define) - это моветон. Переменные жрут озу (стек), их нужно правильно объявлять, не забывать инициализировать, не позволять опитмизатору их выбрасывать... Кроме того, цифирьки разбирать типа SPCR = 0x5C; не очень хорошо - это приводит к нежеланию читать код у меня (ИМХО, и у большинства тоже), но это бы полбеды - беда в том, что такое написание приводит к механическим ошибкам и не позволяет поддерживать код уже через очень короткое время после написания. Компилятор всё-равно всё в цифирьки перепакует, но нафига человеку его работу пытаться сделать, да ещё и неуклюже? Помотрите хотя бына примеры инициализации из DS - там достаточно читабельно. Короче, замените, где надо эту temp на (1<<SPIF), а где на (1<<BUSY). Равно и остальное, а то обсуждение усложняется
5) Приведение типа к знаковому (char)SPDR в функции чтения - нафиг. Объявление bt_word[] не нашёл.
4)Для отладки уберите всякие static buffer_counter и запишите хотя бы один раз в буфер с нулевого адреса несколько байт данных, ну и прочитайте оттуда же. Цикл, вызывающий запись в буфер одного байта, уберите из main и положите в функцию записи, а лучше пока вааще убить и попробовать тупо записать, например, 4 константы.
5) Убрав вызов erasing() из main перестанет выключаться SPI 8-D
SPCR = 0x00; // Выключить SPI
и есть вероятность, что то, что написано далее, будет фунциклировать
6) Функцию стирания надо будет рихтовать - там некорректные кусочки ожидания готовности (обсуждали ранее)- ожидание либо вынести в отдельную функцию, либо по месту поправить. Я, например, не использую принципиально функции записи со стиранием, потому, если драйвер для себя, то могу запихнуть ожидание внутрь, но если иначе, то смысла прятать нет. Кроме того, в ожидании (а это порядком 40+ мс!!!) часто можно заниматься чем-то более важным иногда узнавая, как же ж там дела...