Форум разработчиков электроники ELECTRONIX.ru > SPI

Sergio66

Nov 2 2006, 14:14

Вот такая незадача:
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 регистре, хотя на физическом контакте ничего нет?
Но при этом связь не идет!
Поделитесь своими соображениями ПЛЗ!

klop

Nov 2 2006, 14:45

Цитата(Sergio66 @ Nov 2 2006, 17:14)

Что то засело в PINB регистре, хотя на физическом контакте ничего нет?

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

Sergio66

Nov 2 2006, 15:04

Цитата(klop @ Nov 2 2006, 18:45)

Цитата(Sergio66 @ Nov 2 2006, 17:14)

Что то засело в PINB регистре, хотя на физическом контакте ничего нет?

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

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

slog

Nov 2 2006, 15:19

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

=GM=

Nov 2 2006, 15:37

Цитата(Sergio66 @ Nov 2 2006, 15:04)

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

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

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

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

klop

Nov 2 2006, 15:44

Цитата(=GM= @ Nov 2 2006, 18:37)

Цитата(Sergio66 @ Nov 2 2006, 15:04)

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

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

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

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

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

Sergio66

Nov 2 2006, 15:45

Цитата(=GM= @ Nov 2 2006, 19:37)

Цитата(Sergio66 @ Nov 2 2006, 15:04)

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

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

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

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

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

=GM=

Nov 2 2006, 17:24

Цитата(Sergio66 @ Nov 2 2006, 15:45)

Цитата(=GM= @ Nov 2 2006, 19:37)

Цитата(Sergio66 @ Nov 2 2006, 15:04)

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

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

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

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

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

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

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

$ilent

Nov 3 2006, 07:42

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

Sergio66

Nov 3 2006, 08:03

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

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

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

Цитата($ilent @ Nov 3 2006, 11:42)

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

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

Sergio66

Nov 3 2006, 11:26

Цитата($ilent @ Nov 3 2006, 11:42)

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

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

$ilent

Nov 3 2006, 12:55

Цитата(Sergio66 @ Nov 3 2006, 14:26)

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

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

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

Sergio66

Nov 3 2006, 13:01

Цитата($ilent @ Nov 3 2006, 16:55)

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

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

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