Witam,
próbuję podłączyć rejestr przesuwny 74HC595 do mikrokontrolera ATmega8. Nie wiem dlaczego nie działa. Poniżej przedstawiam schemat i program:



[ panowie proszę po pierwsze zmniejszać nieco wielkości tych obrazków i wklejać je z miniaturami tak jak w instrukcji: topic44.html .... bo się strona forum rozjeżdża .... mirekk36 - ok? Tym razem poprawiłem ]


- na schemacie jest wiele dodatkowych rzeczy - nie są one podłączone. Układ zestawiony jest na płytce prototypowej tyko z rejestrem przesuwnym z diodami LED na wyjściach.
- na schemacie jest symbol ATmegi88, w rzeczywistości jest to ATmega8 (układ pinów jest identyczny).


ATmega programuje się prawidłowo. Na rejestr wysyłane są śmieci albo nic.
Ktoś ma jakieś pomysły? Dziękuję za pomoc.

Pin SCL rejestru na pewno jest podłączony do plusa ?

Tak, jest podłączony. Sprawdziłem

Śmieci widzisz przy programowaniu procka ?

Przy programowaniu procka widzę śmieci, ale to wydaje się być normalne z powodu dzielenia wspólnych linii sygnałowych z programatorem. Może lepszym opisem będzie - diody zapalają się w sposób przypadkowy, czasem dwie, czasem jedna, która po chwili gaśnie, czasem nawet palenie się diod odpowiada prawidłowemu ustawieniu ich w programie.

Nie wiem na ile masz wdrożony schemat z zamieszczonego pliku. Na ile kod odpowiada schematowi.
Ale może być przyczyna współdzielenie portu B z czymś innym w połączeniu z błędnym maskowaniem bitów tego portu.

Uruchomienie SPI masz zrobione dobrze.
Wysłanie bajtu też, z ładnym oczekiwaniem na flagę SPIF.

a odpinałeś programator? skoro piszesz że piny są współdzielone.

W skład układu wchodzi tylko mikrokontroler i rejestr przesuwny z diodami. Program nie zawiera nic więcej poza tym co wkleiłem. Zauważyłem jedną rzecz tylko jeszcze: Jeżeli przypisze się zmienną SS odpowiadającą za zatrzask do pinu PB2 to wszystko działa prawidłowo. Na innych pinach nie działa (porty są sprawne).
Próbowałem z rozłączonym programatorem, ale również bezskutecznie.

No właśnie to jest jedna rzecz ciekawa. Ale teoretycznie to nie powinno mieć znaczenia. SPI można zrealizować programowo i używać dowolnych pinów.

Programator jeśli to jest USBasp to powinien mieć na wyjściu bufory trójstanowe. Po zakończeniu programowania one się rozłączają i nie obciążają wejść. Współdzielenie pinów ISP może robić problemy przy programowaniu jeśli piny procesora są czymś obciążone (podciągnięte silnie do masy albo do VCC) np. LCD HD44780. Wtedy będzie problem z zaprogramowaniem. Ale nie odwrotnie.

Odpowiedź znajduje się w datasheetcie, rozdział "SS Pin Functionality", podrozdział "Master mode".
Mała ciekawostka - gdybyś uruchomił cały układ, a przede wszystkim ULN2803 to by tych chocków-klocków nie było A teraz mały konkurs: potrafisz powiedzieć dlaczego?

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Brawo! Problem rozwiązany, wszechświat uratowany. Ale zastanówmy się dlaczego?
Wywnioskowałem, że aby tryb Master w komunikacji SPI działał prawidłowo to pin SS musi być ustawiony jako WYjście. Jeżeli jest ustawiony jako WEjście to musi na nim być utrzymywany stan wysoki. Jest to spowodowane tym, że gdyby ten port był wejściem i byłby na nim stan niski to ATmega odczytałaby to jako znak, że ma być Slave'em. Natomiast jeżeli port ten jest ustawiony jako WYjście to może być używany do zadań innych, zupełnie nie związanych z komunikacją SPI.
Na schemacie do pinu PB2 (SS) podłączony jeden z pinów ULN2803 odpowiedzialny za świecenie pierwszego wiersza w matrycy. Zatem kiedy cały układ został zestawiony wraz z ULNem to pin ten został ustawiony jako WYjście i SPI działało jak należy. Wcześniej, gdy ULNa nie było to pin ten nie był w żaden sposób obsługiwany przez program, dlatego wg domyślnego stanu pinów był wejściem. Bardzo prawdopodobne, że właśnie z tego powodu SPI nie działał prawidłowo, ponieważ ATmega myślała że jest Slave'em.

Dobrze rozumiem?