Вот такая незадача:
1. Мега32
2. SPI, работающий по прерыванию в Slave режиме и только на прием
3. на порту В (там же где и SPI) висит ЖКИ, т.е. порт В перенастраивается на вывод.
4. Данные по SPI идут пакетами с интервалом в 40 мс.
Алгоритм работы таков:
Принимаем пакет, как только пакет принят, ждем паузу. Если пауза достигла 1 мс, выводис принятую информацию на ЖКИ. 1 мс пауза означает, что началась пауза между посылками не менее 40 мс.
Процедура вывода на ЖКИ занимает 15 мс.
Начинается функция записи данных в ЖКИ так:
char DDRBx = DDRB;
char PORTBx = PORTB;
Далее идет переопределение направления портов, вывод данных, всякая муть...
Заканчивается
PORTB = PORTBx;
DDRB = DDRBx;

После первого же вывода на ЖКИ SPI перестает работать - т.е. прерывания по приему не генерятся.
В АВР СТУДИО отлаживаю при помощи JTAG ICE. После приема первого пакета, после вывода на дисплей, когда SPI затыкается, останавливаю программу, и вижу, что настройки SPI (регистры) в порядке, Порт В - DDRB - все как и должно быть - (РВ7 - SCK- прием, РВ6 - MISO - передача, РВ5 - MOSI - прием, РВ4 - SS - прием), а вот PINB4 (он же SS) видится, как "1". Т.е. как будто кто то SS перевел в "1". Но, тестер на ноге микросхемы видит "0"!!!
Сто это может означать?
Бред Студио?
Что то засело в PINB регистре, хотя на физическом контакте ничего нет?
Но при этом связь не идет!
Поделитесь своими соображениями ПЛЗ!

Ну положим физически регистра PINB просто нет. Там сначала (от пина) идет Latch а потом тригер (ресинхронизатор однако). То есть там ничего застрять не может.

Вот и я так думаю, однако, как объяснить тот факт, что тестер видит "0", а СТУДИО - "1". Да и связь по SPI прекращается

Читай http://www.gaw.ru/html.cgi/txt/doc/micros/avr/arh128/15.htm
Думаю сам разберёшся, чудес тут быть не может.

Объяснение такое. В слейве у вас SS=0, чтобы можно было принимать данные. Когда вы переводите SPI из режима слейв в режим, SS должен быть 1, чтобы правильно работал мастер, он и выставляет 1.

Если же SS у вас остается нулём, то мастер воспринимает это, как если бы другой мастер собирается что-то передать, возникает коллизия(:-(.

На с.134 документа doc2503 описано, что надо сделать, чтобы избежать коллизии.

Я думал что у человека только slave mode:
2. SPI, работающий по прерыванию в Slave режиме и только на прием

Нет! нет никакого мастера! В качестве источника данных выступает просто сдвиговый регистр. Есть только СПИ слейв.

Чудак-человек. Я ж не говорю, что на другой стороне мастер! Я говорю, что как ваш МК, которого вы только что настроили мастером, воспринимает ситуацию на SS.

Вы лучше скажите, вы SS держите в нуле, когда перенастраиваете СПИ на мастера? Если ответ да, то мое объяснение правильное.

А вы SPI выключаете после приёма, если нет - то отключите...

Чудак-человек. Я ж не говорю, что на другой стороне мастер! Я говорю, что как ваш МК, которого вы только что настроили мастером, воспринимает ситуацию на SS.

Вы лучше скажите, вы SS держите в нуле, когда перенастраиваете СПИ на мастера? Если ответ да, то мое объяснение правильное.
[/quote]

2 GM - Мое устройство работает исключительно в СЛЭЙВ режиме. Принял посылку по заранее известному расписанию, отобразил на ЖКИ. Вот и все.



Вот это единственное разумное, что и мне пришло в голову сегодня ночью. Буду пробовать...

Есть! Действительно, перед тем, как перепрограммировать ноги контроллера на передачу я отключтл СПИ командой SPCR &=~(1<<SPE);
И действительно, заработало.
Вот сколько открытий чудных готовит нам фирма АТМЕЛ!
Что то я не припоминаю,чтобы где то в мануале хоть слово об этом было сказано!

Есть там такое, ведь когда включаешь SPI ноги формируются сами "режим ожидания - нормально 0 или нормально 1". И изменить их нельзя пока SPI не выключишь.

К тому же отключение SPI если он в мастере и сброса его пинов в 0 очень полезно, когда используешь несколько подчинённых устройств - чтобы они не "подсасывали" питание через свои защитные диоды... Энерго-потребление снижается оч резко...

Сообщение отредактировал $ilent - Nov 3 2006, 13:00

Только вот, пока я не выключал SPI, все, кроме него самого функционировало нормально. И ноги переключались в банальный I/O режим. Вот только сам SPI дурил!
Но, тем не менее, проблема была именно в этом. и она решена!