[AVR-GCC] Graficzny wyświetlacz LCD, algorytmy sterowania.

A kto będzie liczył widmo? Chyba nie AVR, bo ledwo wyrobi mając do roboty przesyłanie dużej ilości danych z karty SD do dekodera mp3.

Obsługa LCD jest raczej prosta w takim zastosowaniu.
Musisz się zaopatrzyć w procedury piszące po LCD.
Potem rysujesz jakieś ładne tło a na nim text.
Musisz raczej mieć jakiś większy procesor (ATMega32 na przykład) żeby pomieścić czcionkę i jakieś tła.

Ja bym rysował słupki od nowa, ale nie czyścił bym wcześniej ekranu.
Po prostu rysował bym słupek dwukolorowy. Dół na czerwono na przykład (i to był by ten właściwy słupek), a górę na czarno (to by służyło do zamalowania tego co tutaj było wcześniej, czyli poprzedniego słupka jak akurat był wyższy niż ten co teraz ma być). Dzięki temu nie było by zbyt dużego efektu Tearingu (Czy jak tam to się zwie ;p W każdym razie efektu migotania) na LCD.

W takim razie tearingu się nie pozbędziemy, ale znacznie go zminimalizujemy i pewnie nie będzie w ogóle widoczny.
Bo wyczyszczenie całego LCD i narysowanie wszystkiego od nowa na pewno będzie widoczne i będzie strasznie wyglądało.
A odświeżenie słupka, i to bez zamalowywania całego a jedynie tej części która ma zniknąć, po pierwsze będzie trwała bardzo krótko i po drugie jak już spowoduje mignięcie, ale nie całego LCD tylko górnej części słupka.

Ja bym zrobił czcionkę z własnym tłem (wada to nienajmilszy efekt wizualny, ale jak tło w miejscu textu będzie jednokolorowe to chyba mała wada).
Wtedy nie musowo wypełniać tego spacjami (czyścić) tylko normalnie piszesz nowym textem po tym i już. Samo się przy okazji wyczyści.
Na menu jest wiele patentów więc może sprecyzuj co konkretnie chcesz.

A chcesz to Menu zrobić w programie głównym czy w przerwaniu?
A gdzie będzie przerzucanie danych z karty do dekodera?

Nie ma zasady. Można zrobić jak się chce.

No to nie wiem.
Trzeba zmienne określające poziom Menu.
1. Można dwie zmienne i zrobić Menu w postaci tablicy XY. Proste w oprogramowaniu, ale niewygodne w użytkowaniu. Bo wyjdzie dość dziwaczne Menu (nie w kształcie drzewa).
2. Można nazwijmy to na osobnych pozycjach Menu. Nawet jedna zmienna określająca pozycję Menu by wystarczyła. Można łatwo zrobić drzewo, ale chodzenie po gałęziach trzeba zrobić ręcznie. To znaczy jesteś w gałęzi powiedzmy numer 12 (A sam numer 12 nic nie znaczy. Po prosu taki sobie wybrałeś.) a chcesz iść wstecz. No to po wciśnięciu przycisku "Back", będąc w pozycji 12 należy zmienić pozycje na przykład na 43 (Gdzie 43 też nic nie znaczy. Po prostu tak sobie nazwałeś pozycję która jest przed pozycją 12.).
Zabawa. I albo dużo if-ów, albo gdy to będzie w programie głównym to dużo pętli while (gdzie pętla while sama w sobie zwiera odpowiednie "if-y". To znaczy ifów nie ma, ale samo bycie w pętli narzuca wykonanie określonych rzeczy, a nie rzeczy z innych pętli. Był by tylko jeden if określający wyjście z pętli. Powiedzmy zamiast sprawdzać gdzie jesteś i gdzie skakać, sprawdzasz tylko gdzie skakać. Jesteś w pętli 12 więc już tego nie sprawdzasz. Po prostu w pętli numer 12 masz tylko jednego if-a który sprawdza czy wcisnąłem przycisk "Back", i jak tak to skacze do pętli numer 43. Ale tak jak mówię niezła z tym zabawa.
3. Można połączyć te dwie rzeczy i zrobić na przykład jedną zmienna określającą jeden poziom drzewa, drugą określającą drugi poziom i trzecią trzeci.

W pierwszym i trzecim przypadku zależnie od rozpiętości każdego poziomu będzie konieczne sprawdzanie szerokości. To znaczy, na przykład w jednej gałęzi masz dwie pozycje, w innej 4. Więc jak klikasz „Left” to w pierwszej gałęzi ma chodzić tylko do dwóch i przewijać, w drugim do czterech i przewijać.
Można to zrobić na tablicach zawierających długości każdego submenu, a tablice indeksować zmiennymi określającymi pozycję.
W drugim przypadku nie trzeba tego, bo sam układ zapewnia określony sposób przechodzenia (powiedzmy od pozycji 43 do 44, od 44 do 45, od 45 do 46 od 46 do 43. Czyli samo się przewinie po 4 kliknięciach w przycisk "Left").
Ale się rozpisałem. I pewnie niezbyt zrozumiale ;p
Jak coś niejasne to pisz.