Pierwsze założenia ...
dni tygodnia harmonogramu można upchnąć w jednym bajcie
np
niech tydzień zaczyna się od poniedziałku, a każdy dzień to bit wtedy:
dni.0 -> poniedziałek
dni.1 -> wtorek
dni.2 -> środa
dni.3 -> czwartek
dni.4 -> piątek
dni.5 -> sobota
dni.6 -> niedziela
i extra
dni.7 -> od poniedziałku do piątku, lub od soboty do niedzieli

z czasem chyba z dwóch bajtów się nie ucieknie, więc niech będzie tak:
zegar 24 godzinny odmierza godziny w zakresie 0 do 23 i minuty 0 do 59
więc maksymalna wielkość czasu po przeliczeniu na minuty wyniesie 23x59-> 1357, a testowanie harmonogramu musiało by odbywać się dla przykładu zawsze o sekundzie = 0.
Gdy zastosuję typ Integer (dwa bajty) o pojemności -32768 do +32767 dodatkowo będzie można go użyć do unieczynniania nastawy ładując doń wartość ujemną
tym sposobem do zapamiętania aktywnych dni tygodnia w harmonogramie wystarczy jeden bajt a niestety do zapamiętywania czasu aktywacji lub dezaktywacji potrzebne będzie wiele dwu bajtowych zmiennych.
Reszta to algorytm porównujący jedną zmienną bajtową i jedną dwu bajtową aktywnego dnia tygodnia i czasu z nastawami harmonogramu.
Teoretycznie wskaźnik on/off może być niepotrzebny gdy funkcją przełączającą będzie toggle, niemniej w takim wypadku użytkownik nastawiający harmonogram będzie musiał wykazać się myśleniem, przy jego planowaniu.