Artykuły

Mając już radio z wyświetlaczem, koniecznie trzeba oprogramować możliwość prezentowania napisów RDS. Cóż to takiego? Nie będę wyjaśniał dokładnie jak działa ten system, bo to materiał na osobny artykuł. W skrócie powiem tylko, że w zasadzie tekst sprowadza się do ośmiu znaków widocznych jednocześnie i jest traktowany bardzo niekonsekwentnie. Teoretycznie mając dłuższy wyświetlacz, można by go składać w bardziej czytelne, dłuższe komunikaty, lecz w praktyce co stacja, to własny pomysł i czasem ta czytelność stawałaby się dyskusyjna. Dlatego postanowiłem się ograniczyć do ośmiu znaków, wyświetlanych w dolnym wierszu wyświetlacza użytego w poprzednim projekcie.

Niedawno prezentowałem projekt odbiornika radiowego sterowanego Arduino, wykorzystującego jedną z popularnych płytek tunera, do której można było się dostać za pomocą magistrali I²C Wspomniałem wówczas, że płytka ta może zaoferować nam także tak zwaną usługę RDS, czyli wyświetlania tekstów wplecionych w sygnał radiowy. O szczegółach – za chwilę, gdyż by cokolwiek wyświetlić, potrzebny jest wyświetlacz. Więc zacznijmy najpierw od niego. O tych urządzeniach, zbudowanych na bazie układu HD44780, pisałem już wiele razy. To chyba najliczniejsza rodzina, choć obecnie już nieco ograniczona. Wyświetlacze zawierają od ośmiu do osiemdziesięciu znaków w czterech, dwóch lub w jednym wierszu, a każdy znak dostaje dla siebie pole 5x7 pikseli.

Nawet w elektronice są takie rzeczy, które nigdy się nie zestarzeją. Ich przedstawicielem jest niewątpliwie wyświetlacz multipleksowany. O czym mowa? O tym za chwilę. Najpierw – o bohaterze artykułu słówko.

Wyświetlacz widoczny nieco niżej pochodzi z kalkulatora Brda, produkowanego w Polsce od 1976 roku jako kopia – trudno rzec czy licencyjna, czy nie – modelu amerykańskiego NSC. Kiedy tamten pojawił się na świecie? Zapewne wcześniej. Bardzo podobny mogliśmy zobaczyć w pierwszym kieszonkowym kalkulatorze Packarda z roku 1972. A więc można przyjąć, że technologia ma już ponad pół wieku, a idea jeszcze więcej, bo multipleks uprawiano także na wyświetlaczach żarnikowych i wyładowczych. I oczywiście powszechnie stosuje się nią obecnie.

Skoro nasze radio działa jak należy, czas na obiecany programator. W tym celu pozmieniamy znaczenie trzech z pięciu przycisków znajdujących się na płytce edukacyjnej TME: skanowanie zostawiamy, natomiast przyciski w górę i w dół będą zmieniać jeden z dziewięciu programów. Środkowy przycisk natomiast będzie zapisywał w aktualnym programie stację, którą właśnie słychać, czyli wybraną przyciskami skanowania. Brakło możliwości przełączania się w mono, ale każdy kto chce, może sobie dołożyć szósty przycisk i pozostawić procedurę, która dotąd tkwiła w poprzednich szkicach.

Zabawa, nauka i tworzenie czegoś praktycznego – dziś spotykamy się pod takim hasłem. Z prostego, acz działającego radia przedstawionego w poprzednim artykule będę chciał zrobić coś bardziej użytecznego. Równie ważną rzeczą, którą poznamy, a o którą padały już nieraz pytania, jest nieulotna pamięć EEPROM, która zachowuje swoją zawartość po odłączeniu zasilania. Aż się prosi, by w oparciu o nią zrobić programator – ale to za chwilę.

Kto z nas nie budował kiedyś odbiornika radiowego? Lata temu wymagało to wiedzy, środków i czasu, bo dobrej klasy odbiornik fal ultrakrótkich, zwłaszcza stereofoniczny, to nie była migająca lampka do złożenia w dziesięć minut, ale skomplikowane urządzenie wymagające zestrojenia i zwykle ten etap był najtrudniejszy. Wielu w ogóle rezygnowało z budowy części odpowiedzialnej za największą częstotliwość, czyli z głowicy, przystosowując fabryczne rozwiązania do własnych potrzeb.

Ze względu na ewoluujące środowisko chmury Arduino, czeka nas ponownie skrócony przewodnik wpleciony między rozważania nad naszym projektem termostatu. Pominę rzeczy oczywiste jak choćby potrzebę stworzenia konta – najlepiej przez mail Google, ponieważ w ten sposób łatwiej połączymy chmurę z telefonem. I jak to było już wiele razy – znów nie zrobimy wszystkiego naraz, a etapami. Pierwszym będzie nawiązanie współpracy chmury, Arduino i smartfona. A jak wiadomo, najlepiej do tego celu użyć nieśmiertelnego programu Blink, teraz z dopiskiem Cloud.

Żeby nie było – nie jest tak, że nie nadaje się bezwzględnie, ale sprawia problemy natury logicznej. Ale od początku. W poprzednim artykule stworzyliśmy termostat ustawiany za pomocą potencjometru – jak to zwykle bywa w przypadku grzejników, choć formalnie tam najczęściej nie używa się potencjometrów, ale z zewnątrz wygląda to tak samo. Jest to wygodne i intuicyjne, ale ma jedną wadę. Jest egoistyczne – to znaczy, że nie da się nastaw dokonywanych potencjometrem dokonywać równocześnie jeszcze w inny sposób. Dlaczego? Nie mamy władzy nad gałką, którą można przestawiać tylko ręką. Owszem, istnieją potencjometry z silnikiem, które można aktualizować niezależnie, ale to zbyt drogie rozwiązanie do takich zadań. Cokolwiek nastawimy za pomocą potencjometru, musi takim pozostać, bo żadna siła nie przekręci jego gałki, gdy jakiś alternatywny czynnik wpłynie na zmianę nastawionej wartości. Dlatego powstały enkodery. Zachowują się – logicznie – jak potencjometry, ale nie mają wskaźnika, obracają się dookoła i ich położenie rzeczywiste nic nie oznacza. Wykorzystuje się tam fakt relatywnych zmian tylko podczas kręcenia. Nastawy dokonywane za pomocą enkodera można uzupełniać innymi źródłami.

Skoro termometr już pracuje, czas powołać do życia jakiś element, którym będziemy mogli zmieniać temperaturę. Na płytce siedzi potencjometr. Wydaje się on wygodnym elementem do zbudowania termostatu. Wszak takie pokrętła znajdziemy w grzejnikach. Opanujmy go zatem.