Dzień dobry,
Od dłuższego czasu walczę z magistralą TWI na Atmedze8. Odbieranie/wysyłanie bajtu między dwoma uC działa poprawnie, jednak problemy zaczynają się kiedy próbuję odebrać bufor ze slave'a. Cały program zawiesza się w momencie kiedy master oczekuje odebrania danych ze slave'a w funkcji TWI_read_buf. Dokładnie w tej linijce:


Próbowałem temat ugryźć na wiele sposobów ale bez rezultatu. Nie mam już pomysłu gdzie robię błąd, dlatego proszę Was o pomoc w rozwiązaniu problemu.

Biblioteka.h:



Biblioteka.c:


Dla mastera:


Dla slave'a:

W kodzie dla slave-a jest funkcja której wogule nie ma w plikach:


------------------------ [ Dodano po: 1 minucie ]

a ok zapomniałeś ją wrzucić do pliku h biblioteki.

Faktycznie, zapomniałem ją tam wrzucić. Problem jednak dalej aktualny.

Problem masz w tej funkcji:

Ponieważ w rejestrze TWCR nie ustawiasz bitu TWEA, slave zwraca status code=0xC8, a twoja pętla while czeka cały czas na kod 0xB8 (ukryty pod makrem TW_ST_DATA_ACK), tak więc jak zmodyfikujesz funkcję do takiej postaci:

Slave wyśle wszystkie 8 bajtów z bufora. Niestety na tym zakończy i już więcej nic nie wyśle bo znów ugrzęźnie w tej samej pętli while która nadal czeka na status code=0xB8, a przecież gdy master odbierze ósmy bajt wysyła NACK czyli moduł TWI slave zwróci status code=0xC0.
Musiałbyś do warunku pętli while dodać drugi jako sumę logiczną z drugim status codem, lub też wogule zrezygnować ze sprawdzania tych kodów, a jako koniec operacji wysyłania sprawdzać czy bit TWINT został ustawiony na 1.

Tak, to było to! Ogromnie dziękuję za pomoc! Jeszcze dopytam przy okazji. Slave się 'odblokował' i wysyła bufor tylko, że z niewiadomych przyczyn ciągle jego pierwszy indeks. Zamieniłem funkcję TWI_write_slave_buf na tą analogiczną do poradnika p.Mirka ale dalej to samo. Co może być tego przyczyną?

Hym... na to pytanie to chyba będzie mi ciężko odpowiedzieć bo u mnie po modyfikacji funkcji TWI_write_slave(uint8_t data) do postaci:

cały bufor leci do mastera we właściwej formie czyli w terminalu master cyklicznie wypluwa ciąg 12345678.
Nie wiem, może masz coś nie tak w samej bibliotece UART-a, bo tej nie wrzuciłeś więc nie jestem w stanie powiedzieć dla czego u mnie to działa a u Ciebie nie. Ja podłączyłem bibliotekę do UARTA mirkową z BB. Wprowadziłem kilka koniecznych zmian tak by owa biblioteka działała poprawnie, reszta kodu jest żywcem przerzucona ze źródeł które wrzuciłeś, z modyfikacją jedynie funkcji TWI_write_slave.

Po dodaniu delaya do funkcji write_slave problem zniknął Bardzo dziękuje za pomoc!

Powiem tak - jeśli dodałeś tego delaya i problem zniknął to masz coś nie tak (przypuszczam że z warunkiem w while).
Sekcję

dodałem tylko po to by podejrzeć jakie wartości status code zwraca TWI SLAVE-a, delay był tu konieczny i oszacowany na "bezpieczne oko" tak by operacja wysyłki tego kodu po UART była już na pewno po operacji wysłania bajtu po TWI.
W czasie normalnej pracy modułu TWI właściwy czas oczekiwania załatwia właśnie pętla while która zatrzymuje działanie programu do czasu pojawienia się właściwego status code co jest równoznaczne z zakończeniem operacji wysyłania bajtu przez moduł TWI.
U mnie program działa również po usunięciu delaya i funkcji uart_putint.

A tak wogule to nie wiem czy twoje podejście do TWI SLAVE jest właściwe. Widzisz moduł SLAVE powinien wykonywać polecenia MASTER-a. Więc budowanie funkcji która wysyła zdefiniowaną ilość bajtów nie do końca jest trafione.
Funkcja powinna cały czas wysyłać kolejne dane jeśli MASTER po odbiorze bajtu wystawia ACK, informując SLAVE że chce odczytywać kolejne bajty; a przerwać funkcję w momencie wysłania przez MASTER NACK. Przynajmniej tak to robią wszelakie moduły pracujące na magistrali TWI w roli SLAVE-a. Takie jest moje zdanie - choć niekoniecznie musi być słuszne