Witam i pozdrawiam wszystkich!
W ramach prac studialnych nad zajmującym niewiele miejsca "kokpitem"/panelem sterującym do symulatora lotniczego postanowiłem zbudować MJoy16-C1. Konstrukcja do najnowszych nie należy, ale chciałem w praktyce wyrobić sobie własny pogląd na temat potrzebnej funkcjonalności, zanim zacznę projektować coś innego, lub podobnego, na AVR ze sprzętowym USB. MJoy16 wydawał mi się, po przeczytaniu postów i opisów na kilku forach, dobrym punktem wyjścia. I co najważniejsze już sprawdzonym przez innych
.
Polutowanie wszystkiego do kupki nie stanowiło problemu, jednak próby wykorzystania pobranego z sieci wsadu zakończyły się fiaskiem. Próbowałem wykorzystać oprogramowanie znalezione w kilku źródłach - w paczkach .rar lub .zip z (niezależnie od źródła pochodzenia) plikami:
mjoy_16.hex o rozmiarze 21726 bajtów, oraz
mjoy-16.eep o rozmiarze 132 bajtów,
oba pliki datowane 2005-03-07 godz 22:10 (wygenerowane na "moich" egzemplarzach sumy kontrolne crc dołączam w plikach mjoy_16.hex.sfv i mjoy-16.eep.sfv w paczce sk.zip). Wsad w tych plikach zdaje się zawierać błędną, lub uszkodzoną wersję oprogramowania.
W czym problem? Najbardziej poglądowo problem widać na obrazkach 1 i 2, przedstawiających stan odczytu matrycy klawiszy (uzyskane odpowiednio za pomocą windowego narzędzia systemowego do konfiguracji kontrolerów gier i MJoy Mappera).
Duży blok klawiszy wykrywany jest w stanie "klawisze wciśnięte" mimo, że żaden klawisz nie jest wciśnięty, a nawet nic nie jest podłączone do złączy na płytce. Uprzedzając ewentualne rady w niżej przedstawionym zakresie zaznaczam już w tym momencie, że:
1) projekt płytki i jej wykonanie zostały wielokrotnie i starannie sprawdzone (zgodność z netlistą, przerwy, zwarcia itd.)
2) montaż został wielokrotnie i starannie sprawdzony (typy, wartości i sprawność zastosowanych elementów, zimne luty, zwarcia itd.)
3) gotowe urządzenie (oraz układy na płytkach testowych, jak opisano poniżej) podłączano do kilku różnych komputerów z systemami WinXP i Win7 - zawsze z tym samym rezultatem.
Podejrzewając początkowo uszkodzenie mikrokontrolera ATmega 16 wlutowałem inny (nowy) egzemplarz i po zaprogramowaniu stwierdziłem objawy identyczne jak początkowo - ten sam blok matrycy klawiatury sygnalizowany jest w stanie "klawisze wciśnięte". Nie chcąc męczyć płytki drukowanej kolejnym demontażem i lutowaniem procesora SMD przetestowałem wsad na procesorach: ATmega 16 (2 różne egzemplarze) i ATmega 32 (3 różne egzemplarze) w obudowach dil na dwóch różnych płytkach prototypowych. Rezultat ten sam.
Porównałem zawartości plików mjoy_16.hex i mjoy-16.eep pochodzących z różnych paczek pobranych w różnych źródłach. Wszystkie okazały się identyczne.
Badanie oscyloskopem przebiegów na złączach matrycy klawiatury i portach mikrokontrolerów (także tych zamontowanych na płytkach prototypowych) wykazuje w każdym zbadanym przypadku, że:
1) na portach PB4,PD4,PD5,PD6i PD7 (wiersze "E" oraz "I"-"L" matrycy ) stan logiczny nie zmienia się na niski w czasie skanowania (na pozostałych portach sterujących wierszami przebiegi są prawidłowe w zakresie poziomów napięcia czasu trwania i wzajemnych przsunięć w czasie "niskostanowych" impulsów) - tak, jakby te wiersze nie były skanowane.
2) na porcie PC4, sterującym kolumną 5 utrzymuje się stale stan niski, tak jakby nie był włączany rezystor podciągający (pozostałe kolumny są podciągane poprawnie).
Niestety nie znalazłem w sieci tekstów źródłowych oprogramowania, analiza możliwych przyczyn, jakie mogłyby powstać po stronie softu jest poważnie utrudniona.
Wyczerpałem też chyba pomysły na dalsze poszukiwanie przyczyn opisanej niesprawności.
Byłbym wdzięczny osobom, które uruchomiły MJoya-16 za uwagi dotyczące rozwiązania problemów podobnych do opisanych, ewentualnie za zrzut flasha z działającego egzemplarza.
Problem rozwiązany!!!- co odnotowuję tu dla porządku i do wiadomości ewentulnych przyszłych poszukiwaczy rozwiązania podobnego problemu.
Przyczyną opisanych "anomalii" był włączony interfejs JTAG w mikrokontrolerze. W badanych przez mnie ATmegach 16 i 32 jest on domyślnie, fabrycznie, włączony - a wyłączenie wymaga przeprogramowania odpowiedniego FUSE-bitu. O fakcie tym zapomniałem zupełnie, gdyż JTAGA nie używam, a mój programtor niegdyś skofigurowany na domyślne kasowanie tegoż FUSE-bitu robil to dodtąd niezawodnie... aż tym razem, po porządkach uczynionych niedawno na dysku komputera, nie odnalazłwszy pliku konfiuguracyjengo zachował się domyślnie i zachował fuskę bez zmian.
Po wyłączeniu JTAGA układ docelowy i te na płytkach działają bezbłędnie, kod MJoya-16 dostepny w necie jest nieuszkodzony.
Dziękuje kolegom: zając z Polish VATSIM forum i konraf z forum aztec.pl za pomoc w rozwiązaniu problemu.
W ramach prac studialnych nad zajmującym niewiele miejsca "kokpitem"/panelem sterującym do symulatora lotniczego postanowiłem zbudować MJoy16-C1. Konstrukcja do najnowszych nie należy, ale chciałem w praktyce wyrobić sobie własny pogląd na temat potrzebnej funkcjonalności, zanim zacznę projektować coś innego, lub podobnego, na AVR ze sprzętowym USB. MJoy16 wydawał mi się, po przeczytaniu postów i opisów na kilku forach, dobrym punktem wyjścia. I co najważniejsze już sprawdzonym przez innych
Polutowanie wszystkiego do kupki nie stanowiło problemu, jednak próby wykorzystania pobranego z sieci wsadu zakończyły się fiaskiem. Próbowałem wykorzystać oprogramowanie znalezione w kilku źródłach - w paczkach .rar lub .zip z (niezależnie od źródła pochodzenia) plikami:
mjoy_16.hex o rozmiarze 21726 bajtów, oraz
mjoy-16.eep o rozmiarze 132 bajtów,
oba pliki datowane 2005-03-07 godz 22:10 (wygenerowane na "moich" egzemplarzach sumy kontrolne crc dołączam w plikach mjoy_16.hex.sfv i mjoy-16.eep.sfv w paczce sk.zip). Wsad w tych plikach zdaje się zawierać błędną, lub uszkodzoną wersję oprogramowania.
W czym problem? Najbardziej poglądowo problem widać na obrazkach 1 i 2, przedstawiających stan odczytu matrycy klawiszy (uzyskane odpowiednio za pomocą windowego narzędzia systemowego do konfiguracji kontrolerów gier i MJoy Mappera).
Duży blok klawiszy wykrywany jest w stanie "klawisze wciśnięte" mimo, że żaden klawisz nie jest wciśnięty, a nawet nic nie jest podłączone do złączy na płytce. Uprzedzając ewentualne rady w niżej przedstawionym zakresie zaznaczam już w tym momencie, że:
1) projekt płytki i jej wykonanie zostały wielokrotnie i starannie sprawdzone (zgodność z netlistą, przerwy, zwarcia itd.)
2) montaż został wielokrotnie i starannie sprawdzony (typy, wartości i sprawność zastosowanych elementów, zimne luty, zwarcia itd.)
3) gotowe urządzenie (oraz układy na płytkach testowych, jak opisano poniżej) podłączano do kilku różnych komputerów z systemami WinXP i Win7 - zawsze z tym samym rezultatem.
Podejrzewając początkowo uszkodzenie mikrokontrolera ATmega 16 wlutowałem inny (nowy) egzemplarz i po zaprogramowaniu stwierdziłem objawy identyczne jak początkowo - ten sam blok matrycy klawiatury sygnalizowany jest w stanie "klawisze wciśnięte". Nie chcąc męczyć płytki drukowanej kolejnym demontażem i lutowaniem procesora SMD przetestowałem wsad na procesorach: ATmega 16 (2 różne egzemplarze) i ATmega 32 (3 różne egzemplarze) w obudowach dil na dwóch różnych płytkach prototypowych. Rezultat ten sam.
Porównałem zawartości plików mjoy_16.hex i mjoy-16.eep pochodzących z różnych paczek pobranych w różnych źródłach. Wszystkie okazały się identyczne.
Badanie oscyloskopem przebiegów na złączach matrycy klawiatury i portach mikrokontrolerów (także tych zamontowanych na płytkach prototypowych) wykazuje w każdym zbadanym przypadku, że:
1) na portach PB4,PD4,PD5,PD6i PD7 (wiersze "E" oraz "I"-"L" matrycy ) stan logiczny nie zmienia się na niski w czasie skanowania (na pozostałych portach sterujących wierszami przebiegi są prawidłowe w zakresie poziomów napięcia czasu trwania i wzajemnych przsunięć w czasie "niskostanowych" impulsów) - tak, jakby te wiersze nie były skanowane.
2) na porcie PC4, sterującym kolumną 5 utrzymuje się stale stan niski, tak jakby nie był włączany rezystor podciągający (pozostałe kolumny są podciągane poprawnie).
Niestety nie znalazłem w sieci tekstów źródłowych oprogramowania, analiza możliwych przyczyn, jakie mogłyby powstać po stronie softu jest poważnie utrudniona.
Wyczerpałem też chyba pomysły na dalsze poszukiwanie przyczyn opisanej niesprawności.
Byłbym wdzięczny osobom, które uruchomiły MJoya-16 za uwagi dotyczące rozwiązania problemów podobnych do opisanych, ewentualnie za zrzut flasha z działającego egzemplarza.
Problem rozwiązany!!!- co odnotowuję tu dla porządku i do wiadomości ewentulnych przyszłych poszukiwaczy rozwiązania podobnego problemu.
Przyczyną opisanych "anomalii" był włączony interfejs JTAG w mikrokontrolerze. W badanych przez mnie ATmegach 16 i 32 jest on domyślnie, fabrycznie, włączony - a wyłączenie wymaga przeprogramowania odpowiedniego FUSE-bitu. O fakcie tym zapomniałem zupełnie, gdyż JTAGA nie używam, a mój programtor niegdyś skofigurowany na domyślne kasowanie tegoż FUSE-bitu robil to dodtąd niezawodnie... aż tym razem, po porządkach uczynionych niedawno na dysku komputera, nie odnalazłwszy pliku konfiuguracyjengo zachował się domyślnie i zachował fuskę bez zmian.
Po wyłączeniu JTAGA układ docelowy i te na płytkach działają bezbłędnie, kod MJoya-16 dostepny w necie jest nieuszkodzony.
Dziękuje kolegom: zając z Polish VATSIM forum i konraf z forum aztec.pl za pomoc w rozwiązaniu problemu.
