Attiny85 ma tutaj taki sens, że jest mały. Da się do tego układu zrobić malutką płytkę wymiarami identyczną jak płytka OLED i całość złożyć "na kanapkę" i to w wersji DIL8.
Nie znam Atmegi w obudowie 8 nóżkowej, trzeba byłoby użyć jakiejś w TQFP, ale to powoduje że ciężko jest się zmieścić na jednostronnej płytce o takich wymiarach jak OLED, a dwustronną ciężko jest wytrawić w warunkach domowych, zaś zamawiać w Chinach w tym konkretnym przypadku (potrzebuję póki co 2 sztuki) nie ma sensu.
Projektów takich VU jest sporo, wybrałem właśnie ten dlatego że można go ładnie zminiaturyzować. Dałoby się nawet zrobić nową identyczną wymiarami płytkę do OLED i od razu na niej upchać uC wówczas oczywiście w SMD. Może nawet coś takiego zrobię, zobaczę jak ten VU będzie się sprawdzał w praktyce. Z atmegą to nie będzie możliwe ze względu na rozmiar obudowy.
Ceny powariowały już dawno, zaczęło się od koronawirusa. Teraz w ogóle nie opłaca się bawić ani w Mega, ani w Tiny bo ze 2-3 lata temu wyszła nowa rodzina uC - AVR Dx, która funkcjonalnie bije na głowę każdego wcześniejszego, a cenowo jest tańsza.
Zobacz np. AVR16EA32, technicznie można porównać ten uC do Mega168, tyle że w Mouserze kosztuje niecałe 4.6zł, za Mega 168 trzeba zapłacić min. 1zł więcej.
Mega i Tiny to po prostu już stare procesory, trzeba pamiętać że ich historia sięga końca lat 90 ubiegłego wieku. W technice to są ze dwie epoki.
Za chwilę pewnie wszystkie stare (poatmelowe) Mega i Tiny pojawią się jako "not recommended for new design", a za jakieś 5 lat większość nie będzie już produkowana.
Ale wracając do tematu - program już działa, zgodnie z oczekiwaniami błąd był po mojej stronie. Okazuje się, że trzeba skonfigurować wyprowadzenie uC jako wejście. Jeśli ma to być wyprowadzenie "cyfrowe" to oczywiste że trzeba określić czym ma być a jeśli wejściem to jakim, ale dla mnie dziwne jest że analogowe także wymaga takiej konfiguracji, przecież wyjściem być nie może a podciąganie do V+ nie ma sensu, a wręcz byłby to skandaliczny błąd. Nie rozumiem dlaczego funkcja analogRead() tego nie robi z automatu, przecież i tak na którymś etapie te nieszczęsne bity w taki czy inny sposób trzeba ustawić.
Być może dlatego że nie wszystko jest do końca przemyślane i zrobione zgodnie z logiką to zmusza bardziej świadomych programistów do operowania bezpośrednio na rejestrach.
Z drugiej strony zauważyłem że zwykle jak ktoś jest dobrym programistą, to najczęściej takim sobie elektronikiem i na odwrót.
W każdym razie:
rozwiązuje problem.
W oryginalnym kodzie ta konfiguracja jest w innym pliku - ELECTROLIB.h i wygląda tak:
zakomentowałem już wcześniej konfigurację związaną z PB4 aby nie kolidowała ponieważ zamierzałem go użyć jako ADC2, ale jakoś mi umknęło że wejścia analogowe też są tutaj skonfigurowane.
Finalnie cała ta funkcja wyleciała, a konfigurację przeniosłem do funkcji setup bo tak jest to o wiele bardziej czytelne.
Zresztą oryginalny kod odchudziłem o kilka innych rzeczy, bo to jest ta sama "biblioteka" którą autor kodu używa do tworzenia gier. Zawiera kilka funkcji oraz zmiennych potrzebnych do obsługi np. joysticka czy generowania dźwięku które są kompletnie zbędne w tym przypadku.
Jeśli chodzi o zasoby sprzętowe, nie umiem tego dokładnie policzyć, ale szacując mniej więcej wychodzi mi że wcale nie trzeba dużo RAM. Jeśli dobrze rozumiem działanie programu, to potrzeba cały 1 bajt na grafikę, kolejny na maskę określającą położenie wskazówki i kolejny na wskaźnik "peak". Razem 3 bajty, do tego dochodzi kilkanaście zmiennych które są typu uint8_t oraz dwie zmienne 2 bajtowe dla wartości ADC. Mieścimy się w 128 bajtach, a do dyspozycji jest 512. Pamięć flash zgodnie z tym co wyświetla kompilator, zajęta w ok. 51%, wychodzi więc na to że taki Tiny85 jest aż nadto do takiego zastosowania. Gdyby dobrze zoptymalizować kod, to pewnie dałoby się to zamknąć w Tiny45, bo bez moich dodatków w postaci regulacji kontrastu i zmiany trybu wyświetlania negatyw/pozytyw, a po pobieżnym usunięciu zbędnych funkcji udało mi się zejść do 48% zajętości flash. Z ciekawości możne sprawdzę czy będzie działało na Tiny45.
Przerabiałem jeszcze sterownik grafiki bo ja używam wyświetlacza 1.3" który jest na SH1106, a nie SSD1306 co w sumie zajęło kolejny 1% pamięci programu, za to pewnie dałoby się samą bibliotekę wyświetlacza napisać tylko dla 1106 i wówczas zwolnilibyśmy kolejne % pamięci flash.
Nie znam Atmegi w obudowie 8 nóżkowej, trzeba byłoby użyć jakiejś w TQFP, ale to powoduje że ciężko jest się zmieścić na jednostronnej płytce o takich wymiarach jak OLED, a dwustronną ciężko jest wytrawić w warunkach domowych, zaś zamawiać w Chinach w tym konkretnym przypadku (potrzebuję póki co 2 sztuki) nie ma sensu.
Projektów takich VU jest sporo, wybrałem właśnie ten dlatego że można go ładnie zminiaturyzować. Dałoby się nawet zrobić nową identyczną wymiarami płytkę do OLED i od razu na niej upchać uC wówczas oczywiście w SMD. Może nawet coś takiego zrobię, zobaczę jak ten VU będzie się sprawdzał w praktyce. Z atmegą to nie będzie możliwe ze względu na rozmiar obudowy.
Ceny powariowały już dawno, zaczęło się od koronawirusa. Teraz w ogóle nie opłaca się bawić ani w Mega, ani w Tiny bo ze 2-3 lata temu wyszła nowa rodzina uC - AVR Dx, która funkcjonalnie bije na głowę każdego wcześniejszego, a cenowo jest tańsza.
Zobacz np. AVR16EA32, technicznie można porównać ten uC do Mega168, tyle że w Mouserze kosztuje niecałe 4.6zł, za Mega 168 trzeba zapłacić min. 1zł więcej.
Mega i Tiny to po prostu już stare procesory, trzeba pamiętać że ich historia sięga końca lat 90 ubiegłego wieku. W technice to są ze dwie epoki.
Za chwilę pewnie wszystkie stare (poatmelowe) Mega i Tiny pojawią się jako "not recommended for new design", a za jakieś 5 lat większość nie będzie już produkowana.
Ale wracając do tematu - program już działa, zgodnie z oczekiwaniami błąd był po mojej stronie. Okazuje się, że trzeba skonfigurować wyprowadzenie uC jako wejście. Jeśli ma to być wyprowadzenie "cyfrowe" to oczywiste że trzeba określić czym ma być a jeśli wejściem to jakim, ale dla mnie dziwne jest że analogowe także wymaga takiej konfiguracji, przecież wyjściem być nie może a podciąganie do V+ nie ma sensu, a wręcz byłby to skandaliczny błąd. Nie rozumiem dlaczego funkcja analogRead() tego nie robi z automatu, przecież i tak na którymś etapie te nieszczęsne bity w taki czy inny sposób trzeba ustawić.
Być może dlatego że nie wszystko jest do końca przemyślane i zrobione zgodnie z logiką to zmusza bardziej świadomych programistów do operowania bezpośrednio na rejestrach.
Z drugiej strony zauważyłem że zwykle jak ktoś jest dobrym programistą, to najczęściej takim sobie elektronikiem i na odwrót.
W każdym razie:
Kod:
void setup() {
pinMode(1, INPUT_PULLUP);
pinMode(A2,INPUT);
pinMode(A3,INPUT);
TinyOLED_init();rozwiązuje problem.
W oryginalnym kodzie ta konfiguracja jest w innym pliku - ELECTROLIB.h i wygląda tak:
Kod:
void TINYJOYPAD_INIT(void){
pinMode(1,INPUT);
digitalWrite(4,LOW);
pinMode(4,OUTPUT);
pinMode(A0,INPUT);
pinMode(A3,INPUT);zakomentowałem już wcześniej konfigurację związaną z PB4 aby nie kolidowała ponieważ zamierzałem go użyć jako ADC2, ale jakoś mi umknęło że wejścia analogowe też są tutaj skonfigurowane.
Finalnie cała ta funkcja wyleciała, a konfigurację przeniosłem do funkcji setup bo tak jest to o wiele bardziej czytelne.
Zresztą oryginalny kod odchudziłem o kilka innych rzeczy, bo to jest ta sama "biblioteka" którą autor kodu używa do tworzenia gier. Zawiera kilka funkcji oraz zmiennych potrzebnych do obsługi np. joysticka czy generowania dźwięku które są kompletnie zbędne w tym przypadku.
Jeśli chodzi o zasoby sprzętowe, nie umiem tego dokładnie policzyć, ale szacując mniej więcej wychodzi mi że wcale nie trzeba dużo RAM. Jeśli dobrze rozumiem działanie programu, to potrzeba cały 1 bajt na grafikę, kolejny na maskę określającą położenie wskazówki i kolejny na wskaźnik "peak". Razem 3 bajty, do tego dochodzi kilkanaście zmiennych które są typu uint8_t oraz dwie zmienne 2 bajtowe dla wartości ADC. Mieścimy się w 128 bajtach, a do dyspozycji jest 512. Pamięć flash zgodnie z tym co wyświetla kompilator, zajęta w ok. 51%, wychodzi więc na to że taki Tiny85 jest aż nadto do takiego zastosowania. Gdyby dobrze zoptymalizować kod, to pewnie dałoby się to zamknąć w Tiny45, bo bez moich dodatków w postaci regulacji kontrastu i zmiany trybu wyświetlania negatyw/pozytyw, a po pobieżnym usunięciu zbędnych funkcji udało mi się zejść do 48% zajętości flash. Z ciekawości możne sprawdzę czy będzie działało na Tiny45.
Przerabiałem jeszcze sterownik grafiki bo ja używam wyświetlacza 1.3" który jest na SH1106, a nie SSD1306 co w sumie zajęło kolejny 1% pamięci programu, za to pewnie dałoby się samą bibliotekę wyświetlacza napisać tylko dla 1106 i wówczas zwolnilibyśmy kolejne % pamięci flash.