Witam,
Problem, z którym się do Was zwracam jest troszkę zagmatwany ale będę się starał opisać wszystko jasno i klarownie, bo sam nie mam już sił.
Jest procesor, atmega88, na etapie budowania poszczególnych modułów docelowego programu. Uruchomiłem całkiem ładnie obsługę RC5 (może nie do końca super ale działa).
Później uruchomiłem sprzętowe TWI (M88 jako master), działa pięknie.
Postanowiłem przejść krok dalej i uruchomić komunikację z układem AR1020. JEst to kontroler touchscreena od Microchipa. Sprzętowo skonfigurowany jest do pracy z magistralą TWI. Układ ładnie odpowiada ACK na adres, można do niego pisać i czytać (ma magiczne ramki danych) ale... włączenie przerwań instrukcją sei(); wszystko psuje.
Kod inicjujący w/w scalak:
Nie jest to finalna wersja ale przy wyłączonych przerwaniach (konkretnie, gdy nigdy nie użyję instrukcji sei();) wszystko działa.
Wysyła się do niego ramkę: adres+0x55+ilość_bajtow+komenda.
W odpowiedzi powinien odpowiedzieć czymś takim: adres+0x55+kod_odpowiedzi+komenda. Przykładowo wysyłam 0x9A, 0x55, 0x01, 0x12 i chcę otrzymać 0x9B, 0x55, 0x00, 0x12. To, że jakieś dane są do odbioru scalak sygnalizuje stanem wysokim na jednej z linii, którą ja mam podpiętą do PD2 (INT0 - stan wysoki oznacza też, że naciśnięty został touchscreen, dlatego podpięte do przerwania). Tak więc po wysłaniu ramki danych czekam sobie w pętli na stan wysoki na PD2. Jeśli przerwania są wyłączone, sprawdzanie stanu pinu działa bez zarzutu. W momencie, gdy przerwania są włączone (nawet, jeśli nie ma zezwolenia na przerwanie od INT0), stan pinu fizycznie się zmienia (mam analizator stanów logicznych to wiem
) ale proc tego nie zauważa, ciągle krąży w pętli. Tak dzieje się w momencie, gdy instrukcja sei(); występuje przed wywołaniem funkcji inicjującej scalak.
Chciałem obejść problem i uruchomić przerwania (potrzebne chociażby do RC5) po wykonaniu inicjacji scalaka, ale występuje inny problem. Inicjacja przechodzi pomyślnie, dochodzi do włączenia przerwań... i następuje reset, znów inicjacja która zawisa w pętli oczekiwania na zmianę stanu linii. Zmiana następuje, procek nie widzi i zostaje tak na wieki.
Summa summarum:
działa ale nie mam obsługi przerwań,
zawisa na inicjacji,
powoduje restart a następnie zawisa na inicjacji.
Może ktoś miał podobny problem, czy jest jakaś tajemna zależność pomiędzy
sei();, bit_is_celar(...); a resetem?
Sprzętowy watchdog wyłączony.
W miarę możliwości będę starał się odpowiadać na sensowne pytania
Problem, z którym się do Was zwracam jest troszkę zagmatwany ale będę się starał opisać wszystko jasno i klarownie, bo sam nie mam już sił.
Jest procesor, atmega88, na etapie budowania poszczególnych modułów docelowego programu. Uruchomiłem całkiem ładnie obsługę RC5 (może nie do końca super ale działa).
Później uruchomiłem sprzętowe TWI (M88 jako master), działa pięknie.
Postanowiłem przejść krok dalej i uruchomić komunikację z układem AR1020. JEst to kontroler touchscreena od Microchipa. Sprzętowo skonfigurowany jest do pracy z magistralą TWI. Układ ładnie odpowiada ACK na adres, można do niego pisać i czytać (ma magiczne ramki danych) ale... włączenie przerwań instrukcją sei(); wszystko psuje.
Kod inicjujący w/w scalak:
Kod: C / C++
Nie jest to finalna wersja ale przy wyłączonych przerwaniach (konkretnie, gdy nigdy nie użyję instrukcji sei();) wszystko działa.
Wysyła się do niego ramkę: adres+0x55+ilość_bajtow+komenda.
W odpowiedzi powinien odpowiedzieć czymś takim: adres+0x55+kod_odpowiedzi+komenda. Przykładowo wysyłam 0x9A, 0x55, 0x01, 0x12 i chcę otrzymać 0x9B, 0x55, 0x00, 0x12. To, że jakieś dane są do odbioru scalak sygnalizuje stanem wysokim na jednej z linii, którą ja mam podpiętą do PD2 (INT0 - stan wysoki oznacza też, że naciśnięty został touchscreen, dlatego podpięte do przerwania). Tak więc po wysłaniu ramki danych czekam sobie w pętli na stan wysoki na PD2. Jeśli przerwania są wyłączone, sprawdzanie stanu pinu działa bez zarzutu. W momencie, gdy przerwania są włączone (nawet, jeśli nie ma zezwolenia na przerwanie od INT0), stan pinu fizycznie się zmienia (mam analizator stanów logicznych to wiem
Chciałem obejść problem i uruchomić przerwania (potrzebne chociażby do RC5) po wykonaniu inicjacji scalaka, ale występuje inny problem. Inicjacja przechodzi pomyślnie, dochodzi do włączenia przerwań... i następuje reset, znów inicjacja która zawisa w pętli oczekiwania na zmianę stanu linii. Zmiana następuje, procek nie widzi i zostaje tak na wieki.
Summa summarum:
Kod: C / C++
Kod: C / C++
Kod: C / C++
Może ktoś miał podobny problem, czy jest jakaś tajemna zależność pomiędzy
sei();, bit_is_celar(...); a resetem?
Sprzętowy watchdog wyłączony.
W miarę możliwości będę starał się odpowiadać na sensowne pytania