SPIF w Atmega88

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.

Reply to
Sebastian Biały
Loading thread data ...

W dniu 13.03.2010 17:12, Sebastian Biały pisze:

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

Pozdrawiam Grzegorz

Reply to
Grzegorz Kurczyk

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ą.

Reply to
Sebastian Biały

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

Paweł

Reply to
Paweł

To sprawdzilem jako pierwsze. Jest.

Reply to
Sebastian Biały

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 ;)...

Reply to
Konop

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.

Reply to
Sebastian Biały

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

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.

Reply to
Adam Dybkowski

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.

Reply to
Sebastian Biały

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.