Sprawdzenie kodu. Czy to jest dobrze napisane?

Witam, napisałem taki kod, działa, ale zastanawia mnie czy jest on z Waszego punktu widzenia dobrze napisany, są to dwa efekty led na przerwaniu sterowane jednym przyciskiem, za pomocą jednej zmiennej steruje efektami, a kolejna w przerwaniu wczytuje efekt.

W pętli while, IF'y powinny być zagnieżdżone, żeby dobrze działał debouncing.

a deklaracja stałych w pamięci FLASH nie powinna delikatnie inaczej wyglądać?
Nie za dużo tam tych 'PROGMEM'?

Problem leżał w większy bądź równy od "t'' (t>=) w przerwaniu, teraz działa naprawdę ok, wcześniej miałem tylko równy (t==). Gdzieś "gubiła" się ta zmienna?, może ktoś wytłumaczyć? I jeszcze mam pytanie co do sprawdzania wszystkich danych w przerwaniach jak jest dużo takich "if(t==1...10)" to uC musi sprawdzać je po kolei i wykonac jakoas operacje/instrukcje, bywa tak ze zabraknie mu czasu na to? czasem przerwanie trwa bardzo krotko...

Zastanawiałeś się co będzie, gdy zmienna i będzie miała wartość np. 11 i w tym momencie zmienisz zmienną m na wartość 2?

Właśnie jeśli "t" będzie równe 11 i przejdzie do drugiego efektu będzie ja zmieniać za każdym zgłoszeniem przerwania o 1 czyli do wartości jaka możne pomieścić pamięć uC bo w drugim efekcie jest tylko do 10??

To inaczej: jaka jest wartość g_ledpol[11]?, albo g_ledpol[13]?

brutus_gsm wiem ze problem tkwi w jakimś szczególe ale nie mogę złapać, jaka wartość pytasz w g_ledpol gdy 11 i 13 ale tam zmienna zmienia się tylko do 10
chyba ze masz na myśli g_redrid

No właśnie zmienna t nie zmienia się do 10 i w tym problem

Brutus_gsm wrote:

zmienna t nie zmienia się do 10

jak nie? mam przecież (t>=10)? ma być 11?

No masz, ale co jest przed tym warunkiem? Inkrementacja zmiennej i odczytanie bajtu z pamięci flash. Dopiero po tym sprawdzasz warunek i jeśli jest większa niż 10, to ją zerujesz. Przeanalizuj ten kod krok po kroku. Weź pod uwagę to, że gdy m=1, zmienna te może zmieniać się aż do 15. Gdy zmienisz m na 2, to może się zdarzyć sytuacja, że t będzie większe od 10. A taka sytuacja nie powinna mieć miejsca. Warunek masz nie w tym miejscu, co trzeba, albo o jeden za mało, można to różnie rozwiązać.

AAaa błędem będzie to ze "t" osiąga np te 11 i uC chce wgrać do Portu B ''nie wiadomo co'', powinienem najpierw sprawdzać zmienna "t" potem zaprzęgać _pgm_byte

Dodano po 4 [minuty]:

Myślę o wszystkich efektach w jednej tablicy i odpowiednio zerować i ustawiać zmienna "t'' tez będzie to jakieś rozwiązanie? (Odn. drugiej części wypowiedzi)

Rozwiązałem problem ze zmienna, podaje cały kod jeszcze raz, jeśli ktoś ma chwile zerknąć na obsługę przerwania czy tak może zostać, oczywiście zostanie mi poprawić kod na czytelniejszy i kilka innych małych zmian. Dołączyłem jeszcze kilka ledow, wiec doszła mi jeszcze jedna tablica oraz zmienna "d" która służy do opóźnienia wczytywania danych z tablic, jednego z efektów (przesuwania ledow), i właśnie nie wiem czy tyle zmiennych i tablic nie obciąży uC bo mam zamiar cały kod w przerw. rozbudować o kolejne zmienne, pgm_read_byte, ogolnie o większa ilość efektów zaprzęganych z tablic