pier napisał: Tak właśnie myślałem że używanie przerwań i poleceń wait nie jest dobrym rozwiązaniem. Dzięki za odpowiedź.
To nie ma nic wspólnego. Po to są przerwania żeby w ten sposób z nich korzystać.
Natomiast twój problem bierze się z całkowicie czegoś innego. Po prostu tak napisałeś przerwanie i tak często je wykonujesz, że u ciebie w tym konkretnym przypadku zajętość procesora na potrzeby przerwania to bardzo duży procent. Przez co nie dziwne , że nie tylko polecenia wait ale i wszystkie inne procedury będą ci działały jak muchy w smole. Trzeba w końcu nauczyć się:
1. albo w celu generowania nośnej korzystać ze sprzętowego PWM'a
2. albo w celu generowania nośnej korzystać z programowego togglowania jak ty to robisz ale wykorzystując tryb timera o nazwie CTC żeby ustawić sobie wartość OCRx na 53 i wtedy już w przewaniu unikniesz linijki:
i już kod przerwania będzie krótszy szczególnie że nie wiedzieć czemu stosujesz takie niskie częstotliwości taktowania procesora. Ja osobiście jeszcze nigdy gdy używałem wewn oscylatora nie pracowałem na procku, który byłby taktowany mniej niż 8MHz !!! Po co się bawić w 4MHz albo jak niektórzy 1MHz ?
a teraz kilka faktów i przeliczeń żebyś wiedział dlaczego tak się u ciebie dzieje i dlaczego byłoby już dużo lepiej gdybyś zrobił to choćby z Timerem w trybie CTC i taktowaniem 8MHz
Po pierwsze taktujesz procka 4MHz czyli 1cykl=250ns - prawda? (jak dla mnie to kupa czasu - marnotraswo po prostu)
Swoje przerwanie wywołujesz z częstotliwością 4MHz/53 czyli ok 75,5Khz czyli co ok 13,2us - prawda ? dosyć często
więc policzmy ile cykli (rozkazów) może się wykonać pomiędzy przerwaniami , czyli 13,2us / 250ns = ok 52 cykle - czyli tylko ok 52 rozkazy asemblera. I te 52 cykle to w uproszczeniu 100% zajętości procesora.
I teraz tak - gdyby przerwanie od Timera było wykonywane powiedzmy w 10 rozkazach (cyklach) czyli 2,5us to już dla programu głównego zostałoby o tyle mniej prawda?
A teraz weź pod uwagę, że Bascomowe przerwanie nawet puste to DUUUUŻO DUUUŻO więcej niż 10 rozkazów asemblerowych. W związku z czym może ono u ciebie zabierać prawie 120% czasu (bo jeśli przerwanie ma ze 100 rozkazów cykli to będzie się wykonywało DŁUŻEJ niż te 13,2us!!!!) - przez co wydaje się, że program w pętli głównej się Ślimaczy pomimo to że nośna jest generowana OK

.... po prostu masakra amerykańską piłą tarczową na własne życzenie.
-------------
A teraz?
A teraz dajesz sobie taktowanie 8MHz (co za problem przestawić fusebity i zmienić dyrektywę Crystal w Bascomie???) i co się będzie działo?
1 dzielone przez 8MHz daje ci jeden cykl o długości 125ns (wiadomo cztery razy szybciej niż poprzednio)
przerwanie ustawiasz nadal tak samo czyli co 13,2us (tylko inne wartości dajesz do OCR albo u siebie Load Timer, xx gdzie xx będzie teraz nie 53 a ok 106 (co za problem?)
i teraz najważniejsze - ile rozkazów może się wykonać pomiędzy przerwaniami ? już ok 105 cykli. Więc jeśli np przerwanie wykonywać się będzie nawet 80cykli to już polecenie Wait 1 nie będzie się aż tak kosmicznie wydłużało.
I dla porówniania dajesz tym razem kwarc 16MHz - czyli 1cykl = 62ns !!!! - więc sam widzisz co dalej się dzieje pozytywnego z twoim programem i obciążeniem procka przez takie szczególnie Bascomowe przerwanie, które ma okropnie długi tzw prolog i epilog.
------------------------------------
Reasumując jeśli byś nawet przy 4MHz użył opcji NOSAVE dla przerwania Timera i napisałbyś w czystym asemblrze cykliczną zmianę stanu pinu wyjściowego co dałoby radę zrobić na prawdę w kilku instrukcjach to i na tych 4MHz twoje Wait 1 trwałoby jedną sekundę jak się należy. No ale tu trzeba by umieć w asemblerze programować
Oczywiście to całe tłumaczenie moje - jest takie w przybliżeniu ale dobrze oddaje istotę twojego i nie tylko twojego problemu w takich programach.
janbernat - Wait w Bascomie nie wyłącza żadnych przerwań - to byłoby niestety bez sensu. Myślę że te moje objaśnienia chociaż troszkę będą zrozumiałe.