26-01-2025, 21:01
Autor kodu twierdzi że musi być taktowanie 16MHz.
Analizując dość pobieżnie kod i jego działanie, doszedłem do wniosku że jedyne co tu można byłoby zmienić to wykorzystać sprzętowe USI do obsługi I2C, bo tu chyba jednak jest programowe.
Tyle że to nie spowoduje tak dużego wzrostu wydajności aby można było obniżyć taktowane 2x.
Ewentualnie mając do dyspozycji uC Mega, można byłoby użyć wyświetlacza SPI ale jeśli programowe I2C ma wystarczającą przepustowość, to użycie SPI niczego nie wniesie.
Program działa dość prosto, oblicza aktualne położenie wskazówki na podstawie danych z ADC, odczytuje z pamięci Flash bajt bitmapy, jeśli trzeba to nakłada na niego wskazówkę jeśli nie to nie nakłada i przekazuje do wyświetlacza. I tak z każdym kolejnym bajtem.
Z tego powodu wcale nie trzeba dużej ilości RAM. Myślę że wystarczyłyby nawet same rejestry procesora, których jest 32 czyli mamy 32 bajty. Kompilator zgłasza, że zużywam 499B z 512B, czyli 13 bajtów.
Moim zdaniem ten kod jest sprytnie napisany.
Trzeba byłoby się dokładnie przyjrzeć matematyce użytej w programie, bo chyba jedyne na czym dałoby się realnie zyskać to mnożenie, którego procesory Tiny nie wykonują natywnie (brak instrukcji MUL, MULS, MULSU). Jeśli operacji mnożenia jest dużo to faktycznie Mega mogłaby sporo wnieść ale jeśli nie, to uzysk nie będzie na tyle duży aby dało się zjechać z zegarem. Do obliczania położenia wskazówki wykorzystywana jest funkcja "map", nie wiem jak ona działa ale prawdopodobnie wykorzystuje operacje mnożenia i dzielenia. Skalowanie którego używam do kontrastu można byłoby zrealizować "ręcznie" dzieląc odczytaną wartość przez 4, tyle że podział przez 4 to przesunięcie bitowe o dwie pozycje w prawo i akurat do tego jest dedykowana instrukcja więc użycie uC Mega niczego nie wniesie ale do innych skalowań być może bardziej efektywne byłoby użycie dedykowanej instrukcji mnożenia. Wszystko zależy od tego jak działa funkcja "map" i jak to realizuje kompilator. Trzeba byłoby przerzucić to na jakiś procek Mega i sprawdzić co się wydarzy, ale na pierwszy rzut oka niewiele da się zyskać.
Tak naprawdę chyba najwięcej roboty pozwalającej na oszczędzenie zasobów uC wykonuje kontroler wyświetlacza przy czym SSD1306 ma tutaj pewną przewagę nad SH1106. Ten drugi jest przystosowany do obsługi matrycy 132x64, a steruje matrycą 128x64 i to jeszcze wyśrodkowaną czyli widoczne są piksele od 2 do 130 co powoduje że trzeba za każdym razem wprowadzać przesunięcie o 2 piksele i 2 piksele wcześniej kończyć. SH1106 nie przechodzi też automatycznie do następnej strony co powoduje że co 128 "taktów" trzeba wysłać komendę zmiany strony.
Pierwszy problem dałoby się rozwiązać tworząc bitmapę o szerokości 132 pikseli z czego 2 pierwsze i 2 ostatnie byłyby puste, natomiast problemu zmiany strony przeskoczyć się nie da.
SSD1306 jest pod tym względem lepszy, ale z nieznanych mi powodów nie spotyka się go w wyświetlaczach 1.3", a jedynie w 0.96".
Analizując dość pobieżnie kod i jego działanie, doszedłem do wniosku że jedyne co tu można byłoby zmienić to wykorzystać sprzętowe USI do obsługi I2C, bo tu chyba jednak jest programowe.
Tyle że to nie spowoduje tak dużego wzrostu wydajności aby można było obniżyć taktowane 2x.
Ewentualnie mając do dyspozycji uC Mega, można byłoby użyć wyświetlacza SPI ale jeśli programowe I2C ma wystarczającą przepustowość, to użycie SPI niczego nie wniesie.
Program działa dość prosto, oblicza aktualne położenie wskazówki na podstawie danych z ADC, odczytuje z pamięci Flash bajt bitmapy, jeśli trzeba to nakłada na niego wskazówkę jeśli nie to nie nakłada i przekazuje do wyświetlacza. I tak z każdym kolejnym bajtem.
Z tego powodu wcale nie trzeba dużej ilości RAM. Myślę że wystarczyłyby nawet same rejestry procesora, których jest 32 czyli mamy 32 bajty. Kompilator zgłasza, że zużywam 499B z 512B, czyli 13 bajtów.
Moim zdaniem ten kod jest sprytnie napisany.
Trzeba byłoby się dokładnie przyjrzeć matematyce użytej w programie, bo chyba jedyne na czym dałoby się realnie zyskać to mnożenie, którego procesory Tiny nie wykonują natywnie (brak instrukcji MUL, MULS, MULSU). Jeśli operacji mnożenia jest dużo to faktycznie Mega mogłaby sporo wnieść ale jeśli nie, to uzysk nie będzie na tyle duży aby dało się zjechać z zegarem. Do obliczania położenia wskazówki wykorzystywana jest funkcja "map", nie wiem jak ona działa ale prawdopodobnie wykorzystuje operacje mnożenia i dzielenia. Skalowanie którego używam do kontrastu można byłoby zrealizować "ręcznie" dzieląc odczytaną wartość przez 4, tyle że podział przez 4 to przesunięcie bitowe o dwie pozycje w prawo i akurat do tego jest dedykowana instrukcja więc użycie uC Mega niczego nie wniesie ale do innych skalowań być może bardziej efektywne byłoby użycie dedykowanej instrukcji mnożenia. Wszystko zależy od tego jak działa funkcja "map" i jak to realizuje kompilator. Trzeba byłoby przerzucić to na jakiś procek Mega i sprawdzić co się wydarzy, ale na pierwszy rzut oka niewiele da się zyskać.
Tak naprawdę chyba najwięcej roboty pozwalającej na oszczędzenie zasobów uC wykonuje kontroler wyświetlacza przy czym SSD1306 ma tutaj pewną przewagę nad SH1106. Ten drugi jest przystosowany do obsługi matrycy 132x64, a steruje matrycą 128x64 i to jeszcze wyśrodkowaną czyli widoczne są piksele od 2 do 130 co powoduje że trzeba za każdym razem wprowadzać przesunięcie o 2 piksele i 2 piksele wcześniej kończyć. SH1106 nie przechodzi też automatycznie do następnej strony co powoduje że co 128 "taktów" trzeba wysłać komendę zmiany strony.
Pierwszy problem dałoby się rozwiązać tworząc bitmapę o szerokości 132 pikseli z czego 2 pierwsze i 2 ostatnie byłyby puste, natomiast problemu zmiany strony przeskoczyć się nie da.
SSD1306 jest pod tym względem lepszy, ale z nieznanych mi powodów nie spotyka się go w wyświetlaczach 1.3", a jedynie w 0.96".