Witam.

Mam sobie transmisje SPI z urzadzeniem Slave (sam jestem Masterem).
Procek to Atmega88 @ 3.3V @ 6MHz.

Program wysyła duzo bajtów w ta i nazad, ale zawsze wygląda to tak:

SPDR = 0x??;

while(!(SPSR & (1<<SPIF)));

Powyzsze linijki wywoluja się w przerwaniu zegara. Główny program nie
korzysta z SPI.

Niestety okazyjnie program zwisa. Ale nie podczas pracy, tylko startu.
Po prostu co ktoryś start procesora program przestaje funkcjonować
zatrzymujać sie na takim while(...) ; w nieskończoność. Wiem, ze do tego
miejsca dochodzi bo widzę efekty działania programu do wystąpienia
pierwszego przerwania zegara. I wtedy zonk.

Probowałem uproscić program i problem wystepuje nawet przy wysyłaniu
paru bajtow przez SPI. Jak mowie, psuje sie tylko co któryś start
procesora. Jak juz przejdzie pierwszy raz to będzie potem miliony razy
przechodził bez problemu ladnie pracując.

Teraz pytanie: słyszał ktoś może o jakims bugu w tym procesorze
związanym z SPI? Wiem, ze problem jest raczej w moim kodzie, ale
wolałbym zeby mi ktoś to jasno stwierdził: u mnie działa.

do góry

W dniu 13.03.2010 17:12, Sebastian Biały pisze:
> Witam.
>
> Mam sobie transmisje SPI z urzadzeniem Slave (sam jestem Masterem).
> Procek to Atmega88 @ 3.3V @ 6MHz.
>
> Program wysyła duzo bajtów w ta i nazad, ale zawsze wygląda to tak:
>
> SPDR = 0x??;
>
> while(!(SPSR & (1<<SPIF)));
>
> Powyzsze linijki wywoluja się w przerwaniu zegara. Główny program nie
> korzysta z SPI.

Witam
A nie lepiej byłoby obsługiwać przerwania SPI do wysyłki danych ?

Pozdrawiam
Grzegorz

do góry

Grzegorz Kurczyk wrote:
> A nie lepiej byłoby obsługiwać przerwania SPI do wysyłki danych ?

Nie. Docelowo obsługuje tym pamięć szeregową RAM i musze mieć dość
szybką reakcję na SPI żeby się wyrobic w czasie. Wręcz będzie tam
zamiast tej pętli pare nopów. Ale na razie są pętle, które z jakis
przyczyn nie działają.

do góry

> Mam sobie transmisje SPI z urzadzeniem Slave (sam jestem Masterem).


Jeśli dobrze pamiętam to w tym trybie jest istotny jest stan nóżki SS.
Sprawdź czy jest odpowiedni.

Paweł

do góry

Paweł wrote:
> Jeśli dobrze pamiętam to w tym trybie jest istotny jest stan nóżki SS.
> Sprawdź czy jest odpowiedni.

To sprawdzilem jako pierwsze. Jest.

do góry

Sebastian Biały pisze:
> Paweł wrote:
>> Jeśli dobrze pamiętam to w tym trybie jest istotny jest stan nóżki SS.
>> Sprawdź czy jest odpowiedni.
>
> To sprawdzilem jako pierwsze. Jest.

Tzn. nie wiem, czy TO masz na myśli ;)... kiedyś miałem problem z
ATmega8... w każdym bądź razie jeśli coś się działo z pinem SS (był w
stanie niskim przy starcie) program właśnie na takim while'u się
zacinał... Bo dane musiały być "wytaktowane" przez zewnętrzny sygnał na
SCK ;)... a tego brakowało... Najlepiej albo ustaw SS jako _wyjście_. A
jeśli nie możesz tego zrobić, to dodaj pętlę (albo pętle) sprawdzającą
(sprawdzające), czy pin MASTER jest ustawiony... Najlepiej bezpośrednio
przed tym while'm, na którym zwisa... Będziesz mieć pewność, że to nie
to ;)...
Dlaczego Ci o tym piszę - otóż miałem z tym jaja, właśnie "co jakiś
czas"... stan przejściowy, zakłócenia chwilowe, które były
interpretowane jako stan niski... a do tego troszkę źle zrozumiałem PDFa
i się nad tym namęczyłem chwilę, zanim wydumałem o co chodzi ;)...

--
Pozdrawiam
Konop

do góry

Konop wrote:
> ATmega8... w każdym bądź razie jeśli coś się działo z pinem SS (był w
> stanie niskim przy starcie)

Prawie trafiłeś.

Dla potomnych:

SPCR |= (1<<MSTR);
DDRB |= (1<<2); //SS

Może spowodowac, że bit MSTR natychmiast zostanie skasowany jeśli SS
wisi na wysokiej rezystancji i akurat ma 0.

Ale:

DDRB |= (1<<2); //SS
SPCR |= (1<<MSTR);

Nigdy go nie skasuje.

Przez ten jeden cykl zegarowy miałem na SS albo 0 albo 1. I czasem
przechodziło a czasem nie (kasując mastera).

Dzieki za nakierowanie.

do góry

W dniu 2010-03-14 14:02, Sebastian Biały pisze:

> DDRB |= (1<<2); //SS
> SPCR |= (1<<MSTR);
>
> Nigdy go nie skasuje.

Po zapaleniu bitu w DDRB włączasz pin SS jako wyjście. Zalecałbym
wcześniej w PORTB nakazać mu przyjęcie odpowiedniej wartości (0 albo 1).
Jeżeli zmieniasz tylko DDRB, przyjmujesz to co akurat przez przypadek
było ostatnio. Proponuję nie bazować na wartościach z resetu.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

Adam Dybkowski wrote:
>> DDRB |= (1<<2); //SS
>> SPCR |= (1<<MSTR);
>> Nigdy go nie skasuje.
> Po zapaleniu bitu w DDRB włączasz pin SS jako wyjście. Zalecałbym
> wcześniej w PORTB nakazać mu przyjęcie odpowiedniej wartości (0 albo 1).
> Jeżeli zmieniasz tylko DDRB, przyjmujesz to co akurat przez przypadek
> było ostatnio. Proponuję nie bazować na wartościach z resetu.

Akurat nie. "If SS is configured as an input and is driven low while
MSTR is set, MSTR will be cleared" oraz "If SS is configured as an
output, the pin is a general output pin which does not affect the SPI
system". Jesli jest outputem, to nie ma znaczenia jaki jest jego stan,
jestem zawsze masterem jeśli ustawię MSTR. To był błąd u mnie, przez
jeden cykl zegara SS byl inputem i to wystarczyło żeby czasem zerowala
się flaga mastera.

Kod w dalszej czesci steruje SS ale to nie zmienia juz nigdy bitu MSTR.

do góry