Tester rezonatorów kwarcowych

[gaweł]

Swego czasu obiecałem w temacie „Z PC-towego śmiatnika”, że jak coś wymyślę, to dam znać. No i wymyśliłem: tester rezonatorów kwarcowych. Temat nawet całkiem interesujący, gdyż jest to okazja na połączenie kilku wątków (takie zagadnienie wielowątkowe). Nawet doliczyłem się trzech wątków, bo z PC-towego śmetnika pochodzi zastosowanie układu FS741 i TPS2013 <tutaj>, oraz wątek poświęcony kompilatorowi SDCC dla procków C51 <tutaj>.
Zdecydowałem się na użycie proca z rodziny C51. Tak nawiasem mówiąc to chyba najbardziej rozległa rodzina (liczba jego mutacji i firm, które wypuściły go na świat jest całkiem spora). Tak patrząc z historycznego punktu widzenia, to był taki okres w dziejach, że ten proc stał się praktycznie jedną z niewielu alternatyw do stosowania. Owszem był wręcz kultowy Z-80, ale czasy jego świetności przeszły do historii i można o nich jedynie poczytać w kronikach. Era AVR'ów jeszcze nie nadeszła, więc... nie bardzo była szeroka alternatywa do wyboru. Cóż, trzeba się dostosować do możliwości i w ich zakresie się poruszać. Wybór jest jeszcze podyktowany przez czysty pragmatyzm: przez całe życie człowiek sobie zgromadził tak całkiem sporo problemów. Tak na moje oko to będzie jakieś 100 sztuk procków (a może i więcej) z tej familii, z którymi nie bardzo wiadomo co zrobić (bo zupy z nich nie będę gotować – chyba wyjdzie mało kaloryczna).

qt01_il01.jpg

A problemy należy rozwiązywać, więc... o jednego na stosiku będzie mniej. Tak jakoś się dzieje, że wszystko powoli składa się do kupy. Jednym z powodów, dla których przestałem używać tych procków było oprogramowanie narzędziowe. W czasach średniowiecznych pisałem w asm, ale ta zabawa na dłuższą metę jest dosyć wyczerpująca (nawet mam kilka niedokończonych projektów w tej architekturze, bo nie chciało mi się dłubać w asmie, może właśnie przyszedł czas na realizację niedokończonych tematów). Każdy jakoś dąży do lepszych czasów, gdzie podstawowym narzędziem jest kompiler C. No więc pojawił się niekomercyjny (legalny w użyciu i bez ograniczeń) kompiler C dla procków C51. Nawet naumiałem się jego używać.
Jak sprawdzić, że rezonator kwarcowy działa? Jest taka koncepcja, że należy podłączyć go do układu FS741. Jak jest wszystko OK, to na wyjściu tego cosia będzie fala prostokątna. Początkowo wymyśliłem jedynie jakiś układ, który stwierdzi, czy jest na wyjściu FS741 przebieg zegarowy. Takie coś typu jest ↔ nie ma. Temat odłożyłem na kilka dni do przemyśleń. Często stosuję tą metodę: czy wytrzyma próbę czasu. No i koncepcja nie wytrzymała tej próby, została znacznie poszerzona. No urodziła mi się w głowie taka rozbudowa: może przydało by się stwierdzić a ile Hz'ów ów cóś produkuje. Skoro w szufladzie walają się całkiem fajne układy, to wymyśliłem sobie, że ten układ będzie miał komutowane zasilanie przez układ TPS2013. FS741 ma jakieś swoje magiczne dopasowania do rezonatora kwarcowego w zależności od jego częstotliwości, które „zaciąga” jedynie w chwili załączenia zasilania → trzeba prockiem włączać i wyłączać układ. Przy okazji sam układ staje się bezpieczny, bo nie do końca wiadomo, czy takie grzebanie w biegu mu nie nabruździ (rezonatory kwarcowe w końcu trzeba wtykać i wytykać). No i nie wiadomo, czy jak gwałtownie zmieni się częstotliwość rezonatora, to czy układ nie zgłupieje. No więc istniejąca koncepcja została powiększona o miernik częstotliwości.
Wygląda to następująco. Sam generator oparty o układ FS741 z komutacją zasilania w wykonaniu TPS2013.

qt01_il02.png

Całością zarządza procek (z rodziny C51, mam nadzieję, że starczy mu pamięci FLASH na program, choć w sytuacji podbramkowej mam asa w rękawie: AT89C53 → ten ma szersze horyzonty, znaczy więcej pamięci). Aplikacja nie odbiega od typowej. Jedynie sygnał RESET dla proca (w C51 jest takie nietypowe rozwiązanie, gdzie stanem aktywnym jest HIGH, ja jakoś sympatyzuję z filozofią Ziloga, gdzie stanem aktywnym jest LOW) jest przepuszczony przez bramkę Schmitta na potrzeby układu PLD.

qt01_il03.png

Wszystko chciałem zrealizować w średniowiecznej technologii, nawet hercmeter zrobić na TTL'ach, ale wyszedł pewien problem. Zakładając, że zajdzie potrzeba obróbki kwarców do 50MHz, to standardowe TTL'e mogą mieć problemy z nadążaniem za rzeczywistością (liczniki tak wysoko nie sięgają). Pozostała alternatywa pod tytułem układ PLD. No więc sam hercmeter bazuje na mało średniowiecznych układach: rodzina XC9500XL.

qt01_il04.png

Obok pomiernika częstotliwości jest drobny układ tranzystorowy do stwierdzenia, czy jest fala prostokątna, czy jej nie ma. Wyjście ma charakter logiczny.
Jak się bawić, to na całego. Do zabawy jest niezbędny jakiś wyświetlacz i niewielka klawiatura. Schematy nie są skomplikowane.

qt01_il05.png

Klawiatura bazuje na układzie 74HCT165: rejestr przesuwający o wejściu równoległym i wyjściu szeregowym. To pozwala znacząco zaoszczędzić piny w procku, ale komplikuje obsługą (no coś za coś).

qt01_il06.png

Całość zamyka impulsowy stabilizator napięcia. Często stosuję takie rozwiązanie z układem LM2575, przynajmniej nie sprawia mi niespodzianek.

qt01_il07.png

Taka to oto koncepcja. Nie jest to jeszcze projekt zrealizowany do końca, więc nie wiadomo, czy nie zawiera problemów do rozwiązania, których nie dostrzegłem w fazie tworzenia schematu. Buduję jeden egzemplarz, więc nawet nie będę projektować płytki PCB, całość pokynarzę. Oprócz sporej pracochłonności, ta koncepcja ma jedną poważną zaletę: każdy problem jaki wyjdzie po drodze można rozwiązać bez przecinania ścieżek. Cokolwiek wyjdzie nie tak, da się naprawić metodą przecinania drucików i innego połączenia i finalnie tego nie będzie widać.
PS
Zrezygnowałem z początkowej koncepcji sterowania pinami RS0 i RS1 w układzie FS741. Gdyby coś wyszło nie halo ze wzbudzeniem rezonatora, to mam w zanadrzu jeszcze wolne piny w procku i zawsze można coś dobudować. Robiąc „badania naukowe” z tym układem, sprawdziłem kilka kwarców, ale były one ze środkowego zakresu częstotliwości. Nie sprawdziłem przykładowo typowych kwarców zegarkowych 32kHz i bardzo dużych typu kilkadziesiąt MHz. Cóż, o problemach dowiadujemy się jak już wystąpią, ale ufam, że nie będzie problemów.

[j23]

Zacna koncepcja Kolego Gaweł..
Czytałem całość i mam pytanie co oznacza "WAVE_PRE" w Twojej metodologii użycia Xilinxa dla procka C51? -tzn.zakładam,że zadaniem Xilinxa jest preskalowanie fali prostokątnej wygenerowej przez FS741 do dalszego użytku.
Moje pytanie jest typu, czy jest to jakaś podzielona częstotliwość (np.przez 1kHz) i wtedy w Xilinxie na wejściu gdyby było 50MHz to na wyjściu byłoby 50kHz (częstotliwość znośna dla C51), czy inaczej to badanie częstotliwości kwarcu przebiega (np.jest jakieś wsparcie sprzętowe)?

[gaweł]

Czytałem całość i mam pytanie co oznacza "WAVE_PRE" w Twojej metodologii

To jest status The presence of a wave - obecność fali. Sygnał wypracowany przez układ tranzystorowy i doprowadzony do procka (przez negującą bramkę z wejściem Schmitta). Będę o tym więcej pisał jeszcze dzisiaj.

Moje pytanie jest typu, czy jest to jakaś podzielona częstotliwość (np.przez 1kHz) i wtedy w Xilinxie na wejściu gdyby było 50MHz to na wyjściu byłoby 50kHz (częstotliwość znośna dla C51), czy inaczej to badanie częstotliwości kwarcu przebiega (np.jest jakieś wsparcie sprzętowe)?

Nie, układ PLD będzie całkowicie autonomicznym miernikiem częstotliwości. Wstępnie oszacowałem, że jego zasoby powinny wystarczyć. Wiem, że można wpuścić do procka ciąg impulsów o częstotliwości przeskalowanej do jego możliwości, ale w tym przypadku idea jest inna. Z tego powodu jest dodatkowy generator do wypracowania okna impulsu pomiarowego. Te 16MHz to jest "okrągła" częstotliwość do wyprodukowania czasów 1sek, 0.1 sek 0.01sek itp. O wszystkich aspektach i rozwiązaniach będę pisał (wkrótce). Mogłem użyć generatora o f=1MHz (taki powinien być gdzieś w szufladzie) ale jakoś gdzieś mi się zapodział. W sumie to żaden problem, to dodaje tylko 4 przerzutniki do podziału 16MHz na 1MHz.
Widzisz, układy PLD mają tą fajną cechę, że jak się generator znajdzie, to po jego podmianie usuwam kawałek kodu w opisu VHDL'owego i nadal wszystko jest OK. Po prostu jak się znajdą wszystkie komponenty, to stworzą zespół i całość będzie hulać jako rozwiązania najbardziej optymalne. Jak nie, to będzie troszeczkę mniej optymalne. Ale nadal będzie to rozwiązanie.

[j23]

Bardzo dziękuję za szybką odpowiedź Kolego Gaweł i cierpliwe, dokładne wyjaśnienie mi szczegółów Twojego projektu.
"Co to znaczy sprzęt plus talent"... Zazdroszczę szerokiej wiedzy z elektroniki popartej praktycznym doświadczeniem (a więc wiedza wykorzystana w praktyce - coś pięknego)...

[gaweł]

Zazdroszczę szerokiej wiedzy z elektroniki popartej praktycznym doświadczeniem (a więc wiedza wykorzystana w praktyce - coś pięknego)...

Zgodzę się z Tobą w całej rozciągłości, wiedza to bezcenny element a zastosowana w praktyce, to... już kosmos.
A co cię hamuje w zdobywaniu wiedzy?

[gaweł]

Status obecności fali

Ten fragment został obmacany w programie symulacyjnym LTSpice (pisałem o tym <tutaj>: jeszcze jeden wątek do całości). Schemat został opublikowany wyżej i już uwzględnił przyczynki wynikające z symulacji. W LTSpice wklepałem następujący schemat:

qt02_il01.png

Kondensator na wlocie (C4 na schemacie wyżej) odcina składową stałą. Bez tego kondka, jakby generator się zatrzymał w stanie HIGH, to wyszedłby oszukańczy status na wyjściu, toteż mały kondek rozwiązuje poważne problemy. Tranzystor w układzie wspólnego emitera ma bardzo odpowiedzialną rolę, rozładowuje kondensator (C1 na schemacie), który jest stale ładowany przez rezystor R3. Przy braku impulsów (braku stymulacji tranzystora), kondek naładuje się praktycznie do napięcia zasilania. Przekroczenie pewnego progu napięcia na tym kondku, spowoduje reakcję kolejnego tranzystora. Rozwiązanie jest identyczne jak w poprzednim stopniu. Dodana jest dioda (D1). Ma ona za zadanie zmniejszyć wrażliwość tranzystora Q2 na stymulację. Przy małych częstotliwościach kondek ładuje się energią przez rezystor R3 do większych napięć, zanim tranzystor Q1 go zgasi. Dobrze to widać na przebiegach symulacji. Na schemacie zaznaczone są trzy istotne punkty: Point_A, Point_B i Point_C. Symulacja zawsze dotyczy wygenerowania fali prostokątnej oraz po osiągnięciu iluś tam cykli przestaje być generowana fala. Pozwoli to na sprawdzenie działania w sytuacji: jest fala i nie ma fali.
Dla częstotliwości 10kHz przebieg jest następujący:

qt02_il02.png

Point_A to wyjście z generatora, Point_B to napiątko na kondku i Point_C to status wyjściowy. Wypracowany status to HI w sytuacji, gdy jest fala oraz LO w sytuacji przeciwnej. Ten sygnał zostaje przepuszczony przez bramkę negującą z wejściem Schmitta. Do procka dojdzie status jako LO w sytuacji obecności fali oraz HI w sytuacji braku fali. Dałem ten sygnał na wejście od przerwań (przerwanie zgłaszane stanem LO). Gdyby generator lekko się zacinał, to procek na każdą „czkawkę” dostanie przerwanie (będzie można je przynajmniej zliczyć).
W powiększeniu to wygląda następująco:

qt02_il03.png

Przerzut tranzystora Q2 odbywa się już przy około 1V, więc świadoma i celowa strata o kilkaset miliwoltów na spore znaczenie. Wstępnie kondek miał wartość 100nF ale to dla małych frekwencji generowało zmiany statusu wyjściowego (zmieniłem na 10nF). LTSpice okazał się przydatnym narzędziem, można zawsze wnieść korektę do rozwiązania docelowego.
Dla 10MHz, powyższe akcje są następujące:

qt02_il04.png

i w powiększeniu:

qt02_il05.png

Tym razem, napięcie na kondku nawet nie dygnęło. Im wyżej to już jest tylko prościej.
I w ten sposób procek dowiedział się, że jest lub nie ma fali i nawet jest w stanie dowiedzieć się, że zachodziły jakieś drobne nieporozumienia na styku rezonatora kwarcowego i układu FS741.

[j23]

A co cię hamuje w zdobywaniu wiedzy?

Nic mnie nie hamuje. Jakąś tam wiedzę posiadam (i stale staram się ją poszerzać, a także powtarzać już obecną), zakładam jednak, że zdecydowanie mniejszą z elektroniki niż Ty Kolego Gaweł. To jakby porównać dwie sondy kosmiczne zbierające informacje (czyli wiedzę), np. sondę Voyager i sondę New Horizons. Mimo, iż ta druga młodsza i posiada odrobinę lepsze możliwości (w kwestii skali sond, które jeszcze powstaną) to i tak sonda New Horizons nie dogoni sondy Voyager, poza tym zapewne sonda Voyager zbierze unikalne dane, których nie uda się ponownie zebrać tej drugiej.. aczkolwiek sonda New Horizons będzie robiła wszystko żeby regularnie uzupełniać swoje dane, które być może kiedyś staną się porównywalne z tymi od sondy Voyager..

[gaweł]

Te kosmiczne porównanie jest bardzo dobre

[gaweł]

Układ PLD
(cz. 1)

Kolejny etap realizacji całego projektu, to funkcjonalność układu PLD. Jak już wspomniałem, jest to autonomiczny pomiernik częstotliwości. Jak każdy tego typu układ (układ synchroniczny), musi być napędzany sygnałem zegarowym. Tym sygnałem zegarowym jest produkt generatora 16MHz (sygnał CLK16MHZ na rysunkach). W układzie PLD napędza on wszystkie synchroniczne elementy (przede wszystkim automat stanów) oraz służy do wypracowania „okna pomiarowego” → sygnału otwarcia się licznika na przychodzące impulsy (sygnał Wave na rysunkach).
Implementacja pomiernika wprowadziła pewne zmiany we wstępnej koncepcji przedstawionej wyżej. Przede wszystkim układ stał się jedynie do odczytu a „zlecenie” pomiaru zostało wyeksportowane jako pin (sygnał RUN_STB na rysunkach). W trakcie prac doszło do uzasadnionej koncepcji umożliwiającej utworzenie coś ala zakres pomiarowy (sygnał MODE1S na rysunku). Ma to swoje odbicie w następujących kawałkach:

qt03_il01.png

oraz

qt03_il02.png

Jak łatwo zauważyć, zmianie uległ zestaw układów scalonych. Wstępne szacunki okazały się niedoszacowane, układ ma za małe zasoby. No cóż, pierwsze koncepcje nie zawsze są właściwe, ale zawsze istnieje możliwość modyfikacji. Koniecznością stało się wejście na wyższy poziom posiadania i wzięcie układu w wyższej półki: XC9572XL (ma dwa razy większe zasoby). Tak jakoś opatrzność miała pieczę, bo w szufladzie znalazł się taki sam układ (w sensie PLCC44, bo kynarzenie układów QFP to wyzwanie dla mistrzów).
Pomiar częstotliwości odbywa się zgodnie z jej definicją: liczba impulsów, która zaistniała w jednostce czasu. Jeżeli impulsy będą zliczane przez interwał czasu 1s to wynik wyjdzie w Hz, jeżeli czas pomiaru będzie wynosił 0.001s, to wynik będzie w kHz. Normalnie do odmierzenia tego czasu używa się częstotliwości z rastra dziesiętnego (np. dla 1MHz odliczenie miliona impulsów trwa 1s). Na schemacie zastosowany jest generator częstotliwości 16MHz. Można tą częstotliwość za pomocą 4-bitowego licznika podzielić przez 16 i uzyskać 1MHz, który będzie podstawą do uzyskania 1s (0.001s). Jednak poszedłem po rozum do głowy i tak nie będzie. Zauważmy, że jeżeli odliczę milion impulsów o częstotliwości 16MHz, to uzyskam czas jako jedna szesnasta sekundy. Analogicznie odliczenie tysiąca impulsów daje jedną szesnastą czasu 0.001s. Oznacza to, że takie podejście skraca czas pomiaru 16 razy → wynik pomiaru jest 16 razy mniejszy. To implikuje, że procek po wczytaniu danych z rejestrów musi wynik pomnożyć przez 16 (czyli przesunąć wynik w lewo o 4 bity). To oszczędza zasoby układu PLD (nie ma licznika dzielącego 16MHZ przez 16, licznik zliczanych impulsów jest krótszy i spadł jeden sygnał selekcji (REGSEL2). Przy 24-bitowym liczniku da się go wczytać w trzech podejściach plus czwarte podejście to wczytanie statusu. Budowany jest tester rezonatorów kwarcowych, więc utrata 4 najmłodszych bitów z wyniku nie stanowi problemu. To niewiele, przykładowo dla 1MHz to różnica o 16 (procentowo to 16ppm – tolerancja elementów jest większa, więc nie ma się o co kłopotać, w końcu czy to jest lot w kosmos?). Dla rezonatora 10MHz to różnica 1.6ppm, im większa częstotliwość, tym problem staje się mniejszy.

Układ PLD odpowiada teraz następującej deklaracji jednostki projektowej:

Kod: Zaznacz cały

entity FreqM is port ( Wave      : in std_logic ;
                       Clk16MHz  : in std_logic ;
                       PLD_Reset : in std_logic ;
                       RD_Stb    : in std_logic ;
                       Run_Stb   : in std_logic ;
                       Mode1s    : in std_logic ;
                       PLDD      : out std_logic_vector ( 7 downto 0 ) ;
                       REGSel0   : in std_logic ;
                       REGSel1   : in std_logic ) ;
end FreqM ;


Mamy tu:

• WAVE – wejściowy sygnał, dla którego należy zmierzyć częstotliwość,
• CLK16MHZ – sygnał zegarowy taktujący układem PLD,
• PLD_RESET – sygnał zerowania układu (klasyczny element procesorowych peryferali w popularnej filozofii, czyli stanem aktywnym jest LO),
• RD_STB – sygnał strobu odczytu (coś ala chip select w układach procesorowych) → układ reaguje na zbocze opadające,
• RUN_STB – sygnał strobu zlecenia pomiaru → układ reaguje na opadające zbocze,
• MODE1S – określa, czy pomiar trwa 0.001S (stan LO) czy 1S (stan HI),
• PLDD – szyna danych do odczytu zawartości rejestrów pomiernika,
• REGSEL0, REGSEL1 – sygnały wyboru wewnętrznego rejestru (coś jak szyna adresowa w wielu rozwiązaniach układów procesorowych).

Wewnątrz używane są następujące sygnały (wykaz ważniejszych):

• AutomatState – rejestr kodujący stan automatu,
• StatusRegister – rejestr statusu (do odczytu dla REGSEL1:REGSEL0=11),
• OutputRegister – rejestr wyjściowy, do którego wpisywane są dane opadającym zboczem RD_STB w zależności od REGSEL1:REGSEL0,
• WavePulseCnt – licznik impulsów na wejściu WAVE (rejestr 24-bitowy wczytywany zboczem opadającym RD_STB dla pozostałych kombinacji REGSEL1:REGSEL0,
• TimeReg – licznik upływu czasu (20 bitowy licznik do utworzenia okna pomiarowego na 0.001s i 1s)
• ReadyFlag – flaga gotowości pomiaru (wchodzi jako jeden z bitów StatusRegister),
• OverFlowFlag – flaga przepełnienia licznika WavePulseCnt (wchodzi jako jeden z bitów StatusRegister),
• RunReq – wewnętrzna flaga trwania pomiaru ustawiana opadającym zboczem pinu wejściowego RUN_STB (wchodzi jako jeden z bitów StatusRegister),
• MeasurementWindow – okno pomiarowe (dla stanu HI licznik WavePulseCnt zlicza przychodzące impulsy).

Wewnątrz układu PLD rządzi automat synchroniczny, dla którego wyróżniono 4 stany (z raportu syntezy wynika, że stan automatu jest kodowany dwubitowym rejestrem i stany te mają następujące kody, choć w rzeczywistości wartości kodów nie mają istotnego znaczenia, mają być unikalne):

• IdleState – (kod 00) stan bezczynności automatu, w tym stanie badana jest flaga RUNREQ (ustawiana opadającym zboczem pinu wejściowego RUN_REQ), jednocześnie jest trzymany wyzerowany licznik pomiaru czasu,
• StartState – (kod 01) stan przygotowania pomiaru, ustawienie niezbędnych flag i liczników do stanu rozpoczęcia pomiaru,
• RunState – (kod 11) sam pomiar, jest zakończony po osiągnięciu stanu licznika upływu czasu odpowiedniej wartości (F423F → 1s lub 3E7 → 0.001s), i wyzerowaniu flagi okna pomiarowego,
• StopMeasurementState – (kod 10) ustawienie flagi gotowości pomiaru i wyzerowanie licznika upływu czasu.

Przejścia pomiędzy stanami automatu ilustruje rysunek:

qt03_il03.png

Realizacja czynności wynikających z rysunku, to:

Kod: Zaznacz cały

 AutomatInstance : process ( Clk16MHz , PLD_Reset )
  begin
    if PLD_Reset = '0' then
      AutomatState <= IdleState ;
      ReadyFlag <= '0' ;
      OverFlowFlag <= '0' ;
      ResetReg <= '0' ;
      ResetWaveCnt <= '0' ;
      MeasurementWindow <= '0' ;
    else
      if Clk16MHz'event and Clk16MHz = '0' then
        case AutomatState is
          when IdleState =>
            ResetReg <= '0' ;
            if RunReq = '1' then
              AutomatState <= StartState ;
              ReadyFlag <= '0' ;
              OverFlowFlag <= '0' ;
            end if ;
          when StartState =>
            AutomatState <= RunState ;
            MeasurementWindow <= '1' ;
            ResetWaveCnt <= '1' ;
          when RunState =>
            ResetWaveCnt <= '0' ;
            if WavePulseCnt ( 23 downto 4 ) = "11111111111111111111" then
              OverFlowFlag <= '1' ;
            end if ;
            if Mode1s = '1' then
              if TimeReg = "11110100001000111111" then  -- 1000000 = F4240 = 11111000001000110000 odjac jeden (=F423F)
                AutomatState <= StopMeasurementState ;
                MeasurementWindow <= '0' ;
              end if ;
            else
              if TimeReg = "00000000001111100111" then  -- 1000 = 3E8 = 1111101000 odjac jeden (=3E7)
                AutomatState <= StopMeasurementState ;
                MeasurementWindow <= '0' ;
              end if ;
            end if ;
          when StopMeasurementState =>
            ReadyFlag <= '1' ;
            ResetReg <= '1' ;
            AutomatState <= IdleState ;
        end case ;
      end if ;
    end if ;
  end process ;


No to startujemy z pomiarem. Za ten detal odpowiada proces opisany następująco:

Kod: Zaznacz cały

 CmdInstance : process ( Run_Stb , PLD_Reset , ResetReg )
  begin
    if PLD_Reset = '0' or ResetReg = '1' then
      RunReq <= '0' ;
    elsif Run_Stb'event and Run_Stb = '0' then
      RunReq <= '1' ;
    end if ;
  end process ;


Flaga (przerzutnik) RunFlag jest zerowana sygnałem PLD_RESET (na pinie wejściowym) lub wewnętrznym sygnałem ResetReg (wypracowanym przez automat sterujący w ściśle określonym momencie). Jej ustawienie następuje w wyniku wystąpienie opadającego zbocza RUN_STB (na pinie wejściowym). Ta flaga jest diagnozowana przez automat synchroniczny w stanie IDLESTATE i pozwala na rozpoczęcie pomiaru.

[gaweł]

Układ PLD
(cz. 2)

Zapisy w języku VHDL odzwierciedlają rzeczywiste rozwiązania. Słowo zapisane (w VHDL) tworzy realne połączenia (wewnątrz układu PLD). Odpowiednio je interpretując można stworzyć jakąś własną wizję. Wracając do automatu sterującego, napisałem, że jest to dwubitowy rejestr. Przyjmując zaproponowane przez oprogramowanie syntezy stany tego automatu, może wyglądać jak na poniższej ilustracji. Mając na uwadze, że przerzutnik typu D (HCT74) reaguje na narastające zbocze sygnału zegarowego oraz jest zerowany (również ustawiany) stanem „0”, natomiast z opisów w VHDL'u wynika, że automat reaguje na opadające zbocze zegarowe, to w torze zegarowym znajduje się negator.

part4-02.png

Bazując na dwóch przerzutnikach można zakodować cztery różne stany (i dokładnie cztery stany są przewidziane dla automatu). Sygnał zewnętrznego zerowania (PLD_RESET) zeruje oba przerzutniki (powstaje stan 00 → IdleState). Z każdym odpowiednim zboczem sygnału zegarowego do tych przerzutników z częstotliwością 16MHz wpisywany jest nowy stan. Te sygnały wzbudzenia przerzutników pochodzą z odpowiedniej logiki kombinacyjnej, która przede wszystkim uwzględnia własny stan oraz bierze pod uwagę kilka innych sygnałów występujących w całym mierniku. W każdym z tych stanów są do zrealizowania jakieś czynności, jak przykładowo ustawianie czy zerowanie odpowiednich przerzutników symbolizujących odpowiednie flagi. Na rysunku są pokazane jedynie wybrane. Przerzutniki te są również napędzane tym samym sygnałem zegarowym. Każdy z nich ma własną logikę, która determinuje dla każdego z tych przerzutników odpowiednią przyszłość.
Przykładowo dla flagi gotowości pomiaru (ReadyFlag) może wyglądać to następująco:

part4-07.png

Flaga ta może ulec zmianie (poza sytuacją RESET'u) jedynie w stanie IdleState oraz StopMeasurementState. Poza tymi stanami, flaga ta nie ulega zmianie. Wejście danych dla przerzutnika typu D jest wypracowane przez układ kombinacyjny, który uwzględnia aktualny stan automatu (AutomatState) oraz sygnał żądania pomiaru (RunReq). Najprościej to wyjaśnić bazując na multiplekserze (przykładowo HCT153). Na wejścia selekcyjne podany jest aktualny stan automatu. Na wejście A (dla selekcji 00) wchodzi sygnał z logiki bramkowej: jeżeli RunReq = 1, to do przerzutnika należy wpisać 0. W przeciwnym wypadku ma być zachowany stan dotychczasowy. To zapobiega utracie statusu gotowości z poprzedniego pomiaru jeszcze nie odczytanego przez procka. W sytuacji zakończenia pomiaru, następuje wpis jedynki. W każdej innej sytuacji zachowany jest stan aktualny (nie ulega zmianie → wpisany jest własny). Oczywiście, przedstawiona wizja rozwiązania uwzględnia przede wszystkim koncepcyjną prostotę i nie uwzględnia optymalizacji funkcji logicznych. W rzeczywistym rozwiązaniu funkcje logiczne są optymalizowane (w końcu program od syntezy ma „duży łeb” to niech myśli).
W podobny sposób można zaproponować funkcje wzbudzenia dla każdej pozostałej rejestrowej flagi.
Wspomniany wyżej opis (w VHDL'u) ustawienia flagi rozpoczęcia pomiaru można obrazkowo przedstawić jako następujące rozwiązanie:

part4-01.png

Przerzutnik jest zerowany sygnałem zewnętrznym (PLD_RESET) lub sygnałem wewnętrznym wypracowanych przez automat sterujący w ściśle określonej sytuacji. Natomiast jest ustawiany (wpis jedynki) jedynie opadającym zboczem sygnału zewnętrznego (RUN_STB). Stan tego przerzutnika wchodzi choćby do logiki na poprzednim obrazku oraz do logiki sterującej samym automatem (w funkcjach kombinacyjnych przewidzianych do wzbudzania obu przerzutników stanu automatu).
Sam automat zgodnie z sygnałem zegarowym zmienia w określonych sytuacjach swój stan.
Bloczek „Logika automatu” można rozpisać na drobniejsze. Dla stanu IdleState może wyglądać następująco:

part4-03.png

Z tego stanu (kodowanego przez 00) wyszarpnąć automat może jedynie sygnał żądania pomiaru (RunReq) i automat przechodzi do stanu kolejnego (kodowanego przez 01). W sytuacji, gdy oba przerzutniki zawierają 00, to może nastąpić wpis tego samego lub wpis 01 (w zależności od sygnału RunReq). Powyższy rysunek pokazuje możliwą implementację dla przypadku IdleState.
Jeżeli automat zmieni stan na kolejny (StartState, kodowany jako 01), to kolejna funkcja kombinacyjne może wyglądać następująco:

part4-04.png

Tu automat bezwarunkowo przechodzi do kolejnego stanu: RunState (kodowanego jako 11). Na wejścia B są podane dwie jedynki.
W kolejnym stanie logika funkcji wzbudzających jest bardziej złożona.

part4-05.png

Automat musi doczekać się do zamknięcia okna pomiarowego. Licznik (20 bitowy) jest napędzany również sygnałem zegarowym (16MHz) i należy odliczyć czas pomiaru. W zależności od zewnętrznego sygnału MODE1S jest to 1000 (MODE1S=0) lub 1000000 (MODE1S=1). Dwa 20-bitowe komparatory porównują stan licznika odmierzającego czas z odpowiednią stałą i w zależności od trybu pomiaru przekazują wynik z odpowiedniego komparatora dalej. By odliczyć 1000 impulsów należy „wyłapać: stan 999 (liczniki liczą od zera), który w zapisie hex to 3E7, w zapisie bin to 00000000001111100111. Podobnie sprawa ma się z milionem (999999 w zapisie hex to F423F). Doczekanie się do wartości progowej przerzuca automat do kolejnego stanu (kodowanego jako 10).

part4-06.png

Tutaj następuje bezwarunkowe przejście do kolejnego stanu, toteż funkcje wzbudzenia dla przerzutników mają podane stałe wartości.
W tym stanie ustawiana jest flaga zakończenia pomiaru, którą można wczytać przez procka.
Projekt zakładał poolingowe rozwiązanie komunikacji z miernikiem częstotliwości zawartym w układzie PLD. Nie wyklucza to rozwiązania interrupt'owego. Wystarczy wypracowany sygnał gotowości pomiarowej przekazać na zewnątrz jako sygnał przerwania. Dla procków C51 wystarczy go zanegować i dać na INT1.

[gaweł]

Układ PLD
(cz. 3)

Pozostałe elementy stowarzyszone z automatem sterującym to licznik główny (zliczający wejściowe impulsy), trochę logiki związanej z „zabezpieczeniem” pomiaru oraz zespół pozwalający na „wydanie” informacji na zewnątrz. Ma to oczywiście swoje odbicie w zapisach VHDL'owych. Jak wcześniej zostało wspomniane, jest sygnał okna pomiarowego. Jest to sygnał, który zezwala 24-bitowemu licznikowi zliczać impulsy przychodzące z wejścia WAVE. Odpowiedni fragment słowa pisanego to:

Kod: Zaznacz cały

 WaveInstance : process ( Wave , MeasurementWindow , PLD_Reset , ResetWaveCnt )
  begin
    if PLD_Reset = '0' or ResetWaveCnt = '1' then
      WavePulseCnt <= ( others => '0' ) ;
    else
      if MeasurementWindow = '1' then
        if Wave'event and Wave = '0' then
          WavePulseCnt <= WavePulseCnt + 1 ;
        end if ;
      end if ;
    end if ;
  end process ;

Mamy tu 24-bitowy licznik synchroniczny (rejestr zliczający) z bramkowanym sygnałem zegarowym. Tą koncepcją można sobie wyobrazić następująco: 24-bitowy rejestr o wejściu równoległym i wyjściu równoległym realizuje wpis danych bramkowanym sygnałem WAVE (pin wejściowy w układzie PLD). Jeżeli do budowy takiego rejestru zostanie użyty przykładowo rejestr 74HCT273, to jego koncepcję działania pokazuje poniższy rysunek. Zespół rejestrów jest resetowany sygnałem z zewnątrz (PLD_RESET) lub wewnętrznym sygnałem (RESETWAVECNT) generowanym przez automat. Stan rejestru jest udostępniony na zewnątrz układu PLD przez dodatkowy zespół multiplekserowy.

part5_01.png

Istotnym elementem układu pomiarowego jest wykrycie nadmiaru w operacji zliczania (przekręcenie się licznika). Ten kawałeczek realizuje fragment automatu sterującego w stanie RUNSTATE. Odpowiedni opis VHDL'owy tego kawałeczka jest następujący:

Kod: Zaznacz cały

if WavePulseCnt ( 23 downto 4 ) = "11111111111111111111" then
  OverFlowFlag <= '1' ;
end if ;

Jeżeli najstarsze 20 bitów stanu licznika WAVEPULSECNT osiągnęło stan samych jedynek, to ustawiana jest flaga nadmiaru OVERFLOWFLAG. Może pojawić się pytanie: dlaczego tylko 20 bitów? Pamiętając, że automat synchroniczny jest taktowany sygnałem zegarowym o częstotliwości 16MHz (stan licznika jest weryfikowany z tą częstotliwością), natomiast licznik zlicza impulsy z wejścia WAVE, które mogą mieć większą częstotliwość, to wyłapanie stanu samych jedynek może zostać niezauważone (przykładowo w poprzednim testowaniu brakowało licznikowi do samych jedynek 2 impulsów, kolejne testowanie odbyło się po przekręceniu się licznika plus 2 impulsy → wszystkich samych jedynek można nie zauważyć). Komparację z pominięciem 4 najmłodszych bitów można interpretować jako większe równe od FFFFF0 hex.

part5_02.png

No i udostępnienie danych na zewnątrz. Wszystko jest „wydawane” via 8-bitową szynę danych. Opis słowny jest następujący:

Kod: Zaznacz cały

  CntRegInstance : process ( RD_Stb , PLD_Reset )
  begin
    if PLD_Reset = '0' then
      OutputRegister <= ( others => '0' ) ;
    else
      if RD_Stb'event and RD_Stb = '0' then
        case RegSel is
          when "00" =>
            OutputRegister <= WavePulseCnt ( 7 downto 0 ) ;
          when "01" =>
            OutputRegister <= WavePulseCnt ( 15 downto 8 ) ;
          when "10" =>
            OutputRegister <= WavePulseCnt ( 23 downto 16 ) ;
          when others =>
            OutputRegister <= StatusRegister ;
        end case ;
      end if ;
    end if ;
  end process ;
.
.
.
  StatusRegister ( 0 ) <= ReadyFlag ;
  StatusRegister ( 1 ) <= MeasurementWindow ;
  StatusRegister ( 2 ) <= '0' ;
  StatusRegister ( 3 ) <= '0' ;
  StatusRegister ( 4 ) <= '0' ;
  StatusRegister ( 5 ) <= '0' ;
  StatusRegister ( 6 ) <= RunReq ;
  StatusRegister ( 7 ) <= OverFlowFlag ;

W zależności od kombinacji linii REGSEL0 i REGSEL1 następuje wpis do rejestru wyjściowego odpowiednich danych: wpis do rejestru z multipleksera przetwarzającego po 8 bitów z jednego z 4 źródeł danych. Można to sobie wyobrazić następująco:

part5_03.png

W oparciu o zewnętrzny sygnał wyboru rejestru REGSEL0 i REGSEL1 multiplekser dostarcza na wejście rejestru odpowiednie dane. To będą poszczególne 8-bitowe kawałki licznika głównego impulsów z wejścia WAVE oraz składanka poszczególnych flag statusowych uzupełniona zerami. Sygnałem zewnętrznym RS_STB następuje wpis ich do rejestru wyjściowego, którego wyjście jest wyprowadzone na zewnątrz jako piny szyny danych PLDD[0..7]. Dane te mogą być już zgarnięte przez procka.
Z grubsza to tyle na temat zawartości układu PLD. Aktualny stan opisu VHDL'owego jest w załączniku. Być może coś się w nim zmieni, to udostępnię jego kolejną wersję. Na razie jest jak jest.

freqm.7z

[gaweł]

Układ PLD
(symulacja)

Nadeszła chwila na trochę testów (na razie takich wirtualnych → symulacji przez oprogramowanie). Wymaga to stworzenia odpowiedniego środowiska i wypracowania odpowiednich wymuszeń. Pierwszy plik testowy → sprawdzenie reakcji na zlecenie pomiaru w sytuacji, gdzie okno pomiarowe trwa 1ms. Zbiór testowy to:

Kod: Zaznacz cały

library IEEE;
use ieee.std_logic_1164.ALL;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.ALL;

entity freqm_1_tb_vhd is
end freqm_1_tb_vhd;

architecture behavior of freqm_1_tb_vhd is

  component FreqM port ( Wave      : in std_logic ;
                         Clk16MHz  : in std_logic ;
                         PLD_Reset : in std_logic ;
                         RD_Stb    : in std_logic ;
                         Run_Stb   : in std_logic ;
                         Mode1s    : in std_logic ;
                         PLDD      : out std_logic_vector ( 7 downto 0 ) ;
                         REGSel0   : in std_logic ;
                         REGSel1   : in std_logic ) ;
  end component ;

--Inputs
  signal Wave      : std_logic := '0';
  signal Clk16MHz  : std_logic := '0';
  signal PLD_Reset : std_logic := '0';
  signal RD_Stb    : std_logic := '1';
  signal Run_Stb   : std_logic := '1';
  signal REGSel0   : std_logic := '0';
  signal REGSel1   : std_logic := '0';
  signal Mode1s    : std_logic := '0' ;

--Outputs
  signal PLDD      : std_logic_vector ( 7 downto 0 ) ;

begin
  uut: FreqM port map ( Wave => Wave ,
                        Clk16MHz => Clk16MHz ,
                        PLD_Reset => PLD_Reset ,
                        RD_Stb => RD_Stb ,
                        Run_Stb => Run_Stb ,
                        Mode1s => Mode1s ,
                        PLDD => PLDD ,
                        REGSel0 => REGSel0 ,
                        REGSel1 => REGSel1 ) ;

  tb : process
  begin
-- Wait 100 ns for global reset to finish
    wait for 100 ns;
    Wave <= '0' ;
    PLD_Reset <= '1' ;
    RD_Stb <= '1' ;
    Run_Stb <= '1' ;
    REGSel0 <= '0' ;
    REGSel1 <= '0' ;
--    Mode1s <= '1' ;
    Mode1s <= '0' ;
      wait for 25 ns;
    for IntInx in 1 to 8 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
    PLD_Reset <= '0' ;
    wait for 25 ns;
    for IntInx in 1 to 2 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
    PLD_Reset <= '1' ;
    wait for 25 ns;
    for IntInx in 1 to 16 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
    for IntInx in 1 to 2 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
    Run_Stb <= '0' ;
    for IntInx in 1 to 2 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
    Run_Stb <= '1' ;
    for IntInx in 1 to 2 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
--    for IntInx in 1 to 600000 loop
    for IntInx in 1 to 600 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
--
    wait; -- will wait forever
  end process ;
end ;

Oprogramowanie symulacyjne wyprodukowało następujący obrazek:

part6_01.png

Występuje tu RESET układu PLD oraz zlecenie wykonania pomiaru (START). W powiększeniu to:

part6_02.png

• zbocze opadające na wejściu RUN_STB wpłynęło na zmianę stanu flagi żądania pomiaru (RUNREQ),
• stan RUNREQ=1 spowodowało przejście automatu ze stanu IDLESTATE do STARTSTATE,
• ze stanu STARTSTATE automat natychmiast przeszedł do stanu RUNSTATE,
• wystartowało okno pomiarowe.

Potem trochę to trwało (wirtualnie) aż rejestr TIMEREG doliczył się do odpowiedniej wartości:

part6_03.png

Pomiar czasu (zliczanie w rejestrze TIMEREG do wartości 3E7 hex) zatrzymał pomiar (automat przeszedł do STOPMEASUREMENTSTATE) i jednocześnie zamknął okno pomiarowe (zmiana stanu na LO → impulsy z wejścia WAVE zostały odcięte). W tym nowym stanie została ustawiona flaga gotowości pomiaru (READYFLAG weszło na stan HI).
Zmiana sterowań i kolejny test zachowania (odkomentarzowujemy i zakomentarzowujemy odpowiednie fragmenty) pomiar dla czasu trwania 1s:

Kod: Zaznacz cały

(. . .)
    Mode1s <= '1' ;
--    Mode1s <= '0' ;
(. . .)
    wait for 25 ns;
    for IntInx in 1 to 8 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
    end loop ;
(. . .)
    for IntInx in 1 to 600000 loop
--    for IntInx in 1 to 600 loop
      Clk16MHz <= '1' ;
      wait for 25 ns ;
      Clk16MHz <= '0' ;
      wait for 25 ns ;
(. . .)

No tym razem komp się nieźle napracował by ogarnąć taką liczbę impulsów zegarowych (zajęło mu to trochę czasu). Początek symulacji jest identyczny: automat zauważył to co trzeba:

part6_04.png

i dorachował się do tego co należy:

part6_05.png

Wynik jest zgodny z założeniami.
Kolejny test to wygenerowanie sygnału WAVE i odczyt danych pomiarowych, w końcu coś się zadziało.

part6_06.png

Odczyt danych:

part6_07.png

Na sztuki się zgadza.
Kolejny wariant, to dwa pomiary (jeden po drugim): sygnalizacja gotowości → odczyt danych pomiarowych → kolejne zlecenie.

part6_08.png

Odczyt danych pomiarowych i kolejne zlecenie.

part6_09.png

Kolejne zlecenie spowodowało wyzerowanie licznika głównego → tak miało być (trzeba dać szansę prockowi na odczyt danych → dane w liczniku są przechowywane tak długo, na ile się da).

part6_10.png

Jest tak jak być powinno.

part6_11.png

No i na koniec bardzo istotna informacja: oprogramowanie syntezy twierdzi, że maksymalna częstotliwość impulsów na wejściu CLK16MHZ jest 100MHz (to ma mniejsze znaczenie) oraz na wejściu WAVE jest również 100MHz (to już ma ogromne znaczenie).

part6_12.png

Komplet źródeł:

freqm-1.7z

[Zegar]

Chciałem poeksperymentować, ale napotkałem problem... W jakim przedziale czasowym należy przeglądać PC-towy śmietnik? Bezskutecznie przejrzałem część mojego wysypiska w poszukiwaniu FS741. Do tej pory 741 kojarzył mi się tylko z wiadomo czym.
U Majfrienda znalazłem taki: https://www.aliexpress.com/item/1005001749277569.html?spm=a2g0o.productlist.0.0.5d074a174bIy45&algo_pvid=8568ac64-dc8e-4d40-be56-5b789e5e8ef4&algo_exp_id=8568ac64-dc8e-4d40-be56-5b789e5e8ef4-0&pdp_ext_f=%7B"sku_id"%3A"12000017423477647"%7D&pdp_pi=-1%3B6.9%3B-1%3BUSD+2.97%40salePrice%3BUSD%3Bsearch-mainSearch
Trochę drogo...

[gaweł]

W jakim przedziale czasowym należy przeglądać PC-towy śmietnik? Bezskutecznie przejrzałem część mojego wysypiska w poszukiwaniu FS741.

Laptop (najprawdopodobniej DELL) z jakieś 10 .. 15 lat. Sądzę, że jak weźmiesz jakikolwiek laptop (nie koniecznie z tego okresu), to znajdziesz coś podobnego.

[gaweł]

Mutacja generatora kwarcowego

Tak sobie pomyślałem, że zastosowanie dedykowanego układu do obsługi rezonatora kwarcowego nie jest dobrym pomysłem. Zdaję sobie sprawę, że zdobycie takiego z pewnością będzie stanowić duży problem, a chciałbym, by ta konstrukcja była bardziej powielarna. Postanowiłem zbudować układ z ogólnie dostępnych elementów do „zmuszenia” rezonatora kwarcowego do pracy. Tutaj przypomniałem sobie stare rozwiązania oparte na linearyzowanych bramkach, a przykładowe rozwiązanie pokazuje rysunek (bramki logiczne muszą być wykonane w technologii bipolarnej):

qt07_il01.png

No i zbudowałem sobie taki układ badawczy, by sprawdzić jego zachowanie w rzeczywistości.

qt07_il02.jpg

Jakoś całość mnie nie zachwyciła, tj. układ całkiem nieźle sobie radził tylko w określonych granicach częstotliwości. Zmieniałem układy na wykonane w serii standard, szybkiej i bardzo szybkiej. Próbowałem zmieniać wartości elementów. Na powyższej focie wartości rezystorów wynoszą 510Ω i chyba dają najlepsze rezultaty w kooperacji z układem 74LS04.

Jednak jakoś to musi być rozwiązane, bo choćby do procka przyłącza się tylko kwarc (z ewentualnymi małymi kondensatorami) i to działa. Musi być jakiś sposób.
Pogooglałem i znalazłem wariant, który nawet sobie uprościłem.

qt07_il03.png

Skoro w sprzężeniu jest rezystor o dużej wartości, to może go trwale usunąć, oraz gdzieś mi się zapodziały kondki przewlekane o pikofaradowych wartościach → pominąłem w układzie badawczym.
W sumie zbudowałem kolejny wariant generatora, który na swoim wyjściu produkował przebieg elektryczny.

qt07_il04.jpg

Widać, że prościzna, że aż boli…
Okazuje się, że ten wariant całkiem sobie radzi z kwarcami. Tak jak w przypadku bipolarnych scalaczków układ się zawieszał (z generacją fali), ten radzi sobie całkiem, całkiem. Obmacałem wiele rezonatorów i było spoko.
Kłopoty zaczęły się dla 1.8MHz (ten się nie wzbudził). Gdzie jest granica, to trudno określić, bo w szufladzie następny był około 3,5MHz. Również kwarc zegarkowy nie wykazał chęci współpracy. Może jest to kwestia braku rezystora w sprzężeniu zwrotnym, w końcu dla energooszczędnych CMOS 1MΩ może mieć znaczenie (bo bipolarny to by tego nawet nie zauważył). Również dodatkowego sprawdzenia wymaga wpływ pokazanych na schemacie kondków, a które zostały usunięte. Będzie to wymagało jeszcze badań i eksperymentów w przyszłości. Kilka zrzutów z oscylka dla rosnących częstotliwości.

qt07_il05.jpg

Daje się zauważyć, że jak w górę idzie częstotliwość, to zmienia się składowa stała sygnału (tak jakby chciał się on oderwać od ziemi i poszybować w górę). To zapewne da się unormować do przebiegu cyfrowego. Może wystarczy bramka z wejściem Schmitta.

qt07_il06.png

qt07_il07.png

qt07_il08.png

qt07_il09.png

qt07_il10.png

qt07_il11.png

qt07_il12.png

qt07_il13.png

qt07_il14.png

Całość wygląda całkiem obiecująco (ale wymaga jeszcze trochę wysiłku).