atlantis86

Większość osób myśląc o cyfrowej telekomunikacji, myśli o współczesne mikroelektronice: smartfonach, komputerach i Internecie. Nie każdy zdaje sobie sprawę z tego, że idea przesylania informacji zakodowanej w ciągach zer i jedynek jest dużo, dużo starsza. Pierwszym urządzeniem tego rodzaju był telegraf skonstruowany przez Emille'a Baudot w latach siedemdziesiątych XIX wieku. Urządzenie po stronie nadajnika posiadało klawiaturę złożoną z pięciu przycisków, które operator musiał wciskać w różnych kombinacjach. Urządzenie wysyłało na linię ciąg impulsów, odpowiadających wciśniętej kombinacji. Odbiornik interpretował ten sygnał drukując na papierowej taśmie odpowiednią literę lub cyfrę, w jej naturalnej formie. Na początku XX wieku idea to została udoskonalona. Nadajnik został wyposażony w klawiaturę podobną do tych stosowanych w maszynach do pisania. Tak narodził się dalekopis. Transmisja danych pomiędzy tymi urządzeniami przypominała standardowy interfejs szeregowy. Z tą różnicą, że z przeciwieństwie do TTL UART-a czy RS323 poszczególne stany logiczne nie były kodowane przez wartości napięć, ale przez fakt przepływu (bądź nie) prądu w obwodzie. Normalnie przez linię płynął prąd o ustalonej wartości (zazwyczaj 60, 40 lub 20 mA). To był stan domyślny. Rozpoczęcie nadawania kolejnego znaku wymagało nadania bitu startu, czyli chwilowego przerwania obwodu. Potem nadajnik oczekiwał na pięć bitów z kodem znaku w alfabecie Baudot (zwanym także międzynarodowym alfabetem telegraficznym). Na końcu pojawiały się bity stopu w trakcie których odebrany znak był drukowany na papierze. Ktoś zapewne zauważył już, że używając pięciu bitów można było zakodować maksymalnie 32 znaki - zdecydowanie za mało, aby pomieścić wszystkie litery alfabetu, cyfry i znaki interpunkcyjne. To prawda. Stosowano pewną sztuczkę - dwie kombinacje bitów były zarezerwowane do przełączana pomiędzy dwoma rejestrami zawierającymi litery oraz cyfry i inne znaki. Ne stosowano także rozróżnienia na male i duże litery. Dalekopis chociaż w pełni cyfrowy, był urządzeniem elektromechanicznym, radzącym sobie bez pojedynczego tranzystora (chociaż oczywiście w latach osiemdziesiątych i dziewięćdziesiątych produkowano nowoczesne, elektroniczne wersje). Dalekopisy były powszechnie używane do przesyłania wiadomości przez wojsko i państwowe służby. Poczta wykorzystywała je do transmisji telegramów. Stosowano je także w roli terminali komputerowych, przed pojawieniem się monitorów CRT. Ślad tej zaszłości historycznej zachował się w nomenklaturze stosowanej w systemach uniksowych, gdzie terminal jest oznaczany skrótem TTY - od angielskiego słowa "teletype", czyli właśnie dalekopis. Przepraszam za ten przydługi wstęp, nie byłem jednak pewien, czy wszyscy będą jeszcze kojarzyć o jakie urządzenie chodzi... Przechodząc do sedna sprawy. Na co dzień pracuję w krakowskim Muzeum Inżynierii Miejskiej. Jakiś czas temu został nam przekazany dalekopis T100, wyprodukowany w latach siedemdziesiątych w Czechoslowacji, na licencji Siemensa. Ponieważ posiadaliśmy już taki eksponat, zostałem poproszony o sprawdzenie możliwości uruchomienia go i wykorzystywania w roli interaktywnej instalacji, zamiast "martwego" eksponatu ukrytego w muzealnej gablocie. Tak rozpoczęły się moje eksperymenty. Najpierw skonstruowałem prosty interfejs USB, oparty na starym mikrokontrolerze AT89C2051 i układzie FTDI. Do generowania pętli prądowej 40 mA używałem zestawu kilku baterii 9V oraz rezystorów o dużej mocy. Komunikacja z dalekopisem ruszyła bez problemu - pojawiła się jednak inna trudność. Okazało się, że uszkodzony jest moduł wzywaka - urządzenia odpowiedzialnego m.in. za zdalne włączanie silnika dalekopisu przy połączeniu przychodzącym, sygnalizowanym odwróceniem kierunku przepływu prądu w linii. Naprawa tego modułu okazała się bardziej skomplikowana niż początkowo sądziłem, ostatecznie postanowiłem więc wymontować wadliwą część i sterować silnikiem za pomocą przekaźnika, zamontowanego w moim interfejsie. Finalna wersja interfejsu zawiera mikrokontroler PIC32MX270F256B oraz moduł GSM SIM800L. Wykorzystałem także 2MB pamięć SPI flash, do wykonywania elektronicznej kopii przychodzących wiadomości. W osobnej obudowie znajduje się generator pętli prądowej, złożony z zasilacza transformatorowego oraz zestawu kondensatorów dużej mocy. Całość można obecnie oglądać na wystawie "Uwaga! Nieprzyjaciel podsłuchuje." w Muzeum Inżynierii Miejskiej w Krakowie. Po wysłaniu SMS-a na podany numer można oglądać dalekopis podczas pracy.

Jasne, że byłoby lepiej. I tak naprawdę już to zrobiłem. Głębiej w tym dziale na forum znajdziesz mój projekt o nazwie eMPeDocles, w którym wykorzystałem właśnie Raspberry Pi Zero oraz kodek na I2S. Wtedy moim priorytetem było uzyskanie jak najlepszej jakości dźwięku stereo. Teraz wystarczył mi przyzwoity dźwięk mono w konstrukcji mającej udawać stare radio, więc upchnąłem to na kawałku niezbyt skomplikowanego PCB. Jak już mówiłem - projekt miał po części charakter eksperymentalny, chciałem zobaczyć jaki uzyskam efekt, licząc się z tym, że daleko mu będzie do HiFi.

Tutaj niestety muszę rozczarować. Maskownica na ekran (podobnie jak i obudowa) była jednym z elementów oryginalnego sterownika z którym były problemy. Moje zadanie ograniczało się do wykonania nowej elektroniki sterującej i napisania nowego softu. Jak wspominałem, wykonałem na za pomocą biblioteki u8glib2. Jest na GitHubie razem z dokumentacją. Bardzo prosta w obsłudze, wystarczy przejrzeć parę przykładów.

Tym razem opisywany projekt to drobiazg, częściowo o charakterze eksperymentalnym. Pomimo wszystkich swoich zalet, płytka Raspberry Pi Zero posiada jedną wadę - brak standardowego, analogowego wyjścia audio. O ile kompozytowy sygnał wideo jest ciągle dostępny na pinach (które rzecz jasna trzeba sobie wlutować), to sygnał audio nie został nigdzie wyprowadzony. W większości przypadków nie jest to żadnym problemem - można w końcu korzystać z HDMI w roli źródła dźwięku, albo ewentualnie zakupić nakładkę z układem DAC (co by nie mówić - standardowe, oparte na PWM wyjścia audio RasPI nie oferuje powalającej jakości dźwięku). Istnieją jednak projektu, w których analogowy sygnał audio byłby przydatny. Istnieje na szczęście pewne rozwiązanie - poprzez edycję plików konfiguracyjnych można przekierować PWM generujący dźwięk na inne piny złącza GPIO. W tym przypadku generowany jest tylko sygnał mono. Wykorzystany został tylko jeden kanał PWM, a obsługa audio w Raspbianie została skonfigurowana w taki sposób, aby na wyjście trafiała suma prawego i lewego kanału stereo. Za pinem znajduje się filtr dolnoprzepustowy oraz popularny układ wzmacniacza audio na lm386. Płytka jest zasilana z zasilacza 9V - to na[pięcie po przefiltrowaniu zasila wzmacniacz. Obwód zasilania jest wyposażony w zabezpieczenie przed odwrotnym podpięciem zasilania, oparte na tranzystorze MOSFET. Napięcie 5V do zasilania "Maliny" jest uzyskiwane za pomocą stabilizatora liniowego. Dodatkowo na płytce wyprowadzone zostało złącze, przeznaczone do podłączenia enkodera obrotowego i kilku przycisków. Linie te są zabezpieczone diodami oraz dodatkowo inwerterami, pełniącymi funkcję buforów (tak, wiem - to dość spory overkill). Na wolnym miejscu zostawiłem trochę uniwersalnych pól montażowych, przeznaczonych adaptacji z myślą o konkretnym zastosowaniu. W celu ograniczenia zakłóceń obwód audio posiada wydzieloną masę analogową. Płytka może być przydatna wszędzie tam, gdzie potrzebujemy analogowego sygnału audio, jakość nie jest kluczowa, a posiadany monitor z wejściem HDMI nie potrafi obsłużyć dźwięku. Przykłady: kiosk odtwarzający multimedia albo proste proste radio internetowe w stylu retro. ja prawdopodobnie wykorzystam to urządzenie właśnie do budowy odbiornika radiowego. Stąd obecność enkodera obrotowego.

Jesli chodzi o projektowanie, to albo Eagle, albo KiCAD. W tej chwili nie pamiętam już który został użyty w tym przypadku, musiałbym sprawdzić. Proces wykonania płytki zupełnie standardowy. Termotransfer za pomocą laminatora, trawienie w B327 a potem cynowanie stopem Lichtenberga.

Jakiś czas temu na portalu z ogłoszeniami natknąłem się na ofertę sprzedaży zabytkowego układu scalonego AY-3-8500. Jest to dość specyficzny element, wykorzystywany na przełomie lat siedemdziesiątych i osiemdziesiątych do budowy konsol do gier pierwszej generacji. Układ scalony zawiera w swojej strukturze kompletną logikę, niezbędną do generowania kilku prostych gier, m.in. kultowego "Ponga". Wykorzystywany był m.in. w kultowym ELWRO/Ameprod TVG-10 - jedynej polskiej konsoli do gier, jaka trafiła do masowej sprzedaży. Oczywiście nie byłbym sobą, gdybym go wtedy nie kupił i nie spróbował odpalić. Zacząłem więc szukać w Sieci informacji na temat tego układu. Efekty tych poszukiwań przeszły moje oczekiwania - natknąłem się na stronę, której autor zajął się podobnym projektem. Była tam cała niezbędna dokumentacja, karty katalogowe, a także projekt płytki drukowanej konsoli wykorzystującej posiadany przeze mnie układ scalony. No cóż... Postanowiłem nie wyważać otwartych drzwi i wykorzystałem ten wzór, prowadzając jednakże pewne modyfikacje w swojej implementacji tego projektu. Największa z nich dotyczyła kontrolerów , które zbudowałem w oparciu o niewielkie, plastikowe obudowy. Musze przyznać, że tworzą one całkiem poręczne "pady". Każdy z kontrolerów jest wyposażony w potencjometr służący do kontrolowania położenia paletki oraz przycisk do serwowania. Sama konsola została umieszczona w typowej plastikowej skrzynce. Na przednim panelu znajdują się przełączniki dźwigniowe dwu i trzypozycyjne służące do konfiguracji trybu rozgrywki, a także przełącznik obrotowy, do wyboru właściwej gry. Układ AY-3-8500 pozwala na korzystanie z pistoletu świetlnego. Dwie z generowanych przez niego gier wymagają posiadania takiego sterownika. Zdecydowałem się jednak zrezygnować z jego budowy. Na płytce są wyprowadzone odpowiednie piny, więc w przyszłości będzie możliwa taka rozbudowa. Niestety strona na której znalazłem oryginalny projekt niedługo później przestała działać, jednak wciąż można się do niej dostać przez Wayback Machine. Konsola przez jakiś czas była dostępna na wystawie "Game start/game over" w krakowskim Muzeum Inżynierii Miejskiej. Przetrwała - grupy gimnazjalistów nie były w stanie jej zniszczyć. W ramach ciekawostki mogę dodać, że mojemu sześcioletniemu siostrzeńcowi spodobała się ta gra sprzed kilku dekad.

Tak, wiem. Po prostu nauczenie się pisania aplikacji pod Androida jest czymś, co odkładam na później już od jakiegoś czasu. Głownie z uwagi na brak czasu właśnie. Między innymi z tego powodu nie przyglądałem się prostszym metodom tworzenia takich aplikacji - zakładam, że za jakiś czas nauczę typowej metody. Bluettoth umieściłem w projekcie ze względu na to, że miałem wolne piny i miejsce na płytce, może kiedyś jeszcze się za to zabiorę. Serial Bluetooth Terminal raczej odpada, gdy użytkownik nie jest "techniczny".

Kolejny projekt złożony jakiś czas temu, jeśli mnie pamięć nie myli gdzieś około 2014-2015 roku. Wszelkie swoje projekty budowałem wówczas na AVR-ach, jednocześnie na wszelkie możliwe sposoby broniąc się przed wykorzystywaniem Arduino. Musiałem jednak przyznać, że użytkownicy tych płytek mieli do swojej dyspozycji całkiem fajne zabawki, jak na przykład Ethernet Shield. Przyszło mi więc do głowy wykonanie czegoś podobnego. Tak powstała prezentowana płytka. Jej sercem jest mikrokontroler Atmega644PA. Był to wtedy jeden z moich ulubionych układów, z uwagi na relatywnie sporą (jak na ośmiobitowce) pamięć oraz dwa moduły UART. Jeden interfejs szeregowy jest wyprowadzony w formie USB, za pomocą popularnego układu FT232, co znacząco ułatwia debugowanie, a w pewnym momencie eksperymentowałem także z programowaniem układu poprzez bootloader. Woląc zabezpieczyć się przed potencjalnymi problemami, interfejs USB został odizolowany od reszty konstrukcji układem ISO7221A. Najciekawszym elementem tej płytki jest chyba jednak układ Wiznet W5100 - dokładnie ten sam, który znalazł zastosowanie w Ethernet Shieldach Arduino. Muszę przyznać, że przylutowanie niewielkiego scalaka w obudowie LQFP było dla mnie wtedy sporą trudnością, jednak jak widać udało się. Z perspektywy czasu muszę jednak przyznać, że projekt PCB posiada kilka błędów i niedopatrzeń. Przede wszystkim dzisiaj bezwzględnie zastosowałbym dwustronny laminat. Zadbałbym też o to, żeby ścieżki interfejsu Ethernet tworzyły prawidłowe linie różnicowe. Wersja poprawiona nigdy nie powstała, bo niedługo potem przerzuciłem się na mikrokontrolery PIC32. Nie wspominając już o pojawieniu się modułów ESP8266, na których znacznie prościej realizuje się rozmaite konstrukcje sieciowe... Pomimo wszystkich tych niedociągnięć konstrukcyjnych płytka działa poprawnie. Od strony programowej moduł wykorzystywał bibliotekę Ethernet, pożyczoną z Arduino. Musiałem ją delikatnie przeportować, pozbywając się z kodu wszelkich odwołań do bibliotek Arduino, jednak ciągle pozostała ona całkiem używalna. Kod pod ten moduł pisałem w Atmel Studio, rzecz jasna generując projekt w C++. Uprzedzając pytania o gniazdko jack: niestety, muszę rozczarować tych, którzy sądzą, że ma ono coś wspólnego z dźwiękiem. Początkowo sądziłem, że płytka finalnie stanie się częścią pewnego projektu, który przewidywał podłączenie klucza telegraficznego i wysyłanie "tweetów" za pomocą alfabetu Morse'a. Do tego miało właśnie służyć gniazdko. Projekt został ostatecznie zarzucony a płytka była jedynie używana w celach edukacyjnych i do testowania fragmentów kodu, pod inne projekty na wczesnym etapie rozwoju.

Projekt powstał jakiś czas temu na prośbę znajomego. Głównym celem było stworzenie modułu sterownika do wędzarni, który zastąpiłby dotychczas stosowany kontroler. Jak się dowiedziałem poprzednia elektronika miała jakieś bugi w kodzie. Z uwagi na brak dostępu do źródeł czy jakiejkolwiek dokumentacji ich usunięcie byłoby wyjątkowo kłopotliwe. Dlatego postanowiłem zbudować hardware'od podstaw i napisać własny software w oparciu o informacje odnośnie działania urządzenia. Sterownik powstał w oparciu o płytkę Arduino Nano, głownie ze względu na chęć uniknięcia w przyszłości problemów, które doprowadziły do całej sytuacji - użytkownik miał mieć dostęp do kodu i możliwość wprowadzania własnych modyfikacji przy pomocy ogólnodostępnych narzędzi. Urządzenie tak naprawdę nie robi zbyt wiele. Poprzez ADC odczytywana jest temperatura mierzona przez dwa analogowe czujniki. Kontrolowana jest także praca sporej elektrycznej grzałki oraz dwóch wentylatorów. Użytkownik może w menu zaprogramować określoną sekwencję etapów, w jakich te urządzenia są włączane i wyłączane. Koniec etapu może nastąpić po upływie określonego czasu albo wystąpieniu określonej temperatury na czujniku, generowany jest wówczas sygnał dźwiękowy. Program może być zapisywany do pamięci EEPROM. Interfejs urządzenia korzysta z graficznego wyświetlacza, odziedziczonego po oryginalnym projekcie sterownika. Na szczęście zastosowano wyświetlacz ze standardowym i dobrze udokumentowanym kontrolerem. Za wyświetlanie menu i ekranów z informacjami odpowiedzialna jest popularna biblioteka u8g2. Na płytce przewidziane jest także miejsce pod moduł Bluetooth, co potencjalnie może umożliwić kiedyś stworzenie aplikacji sterującej urządzeniem z poziomu smartfona. Je jednak z tego zrezygnowałem, głównie ze względu na brak biegłości w tworzeniu programów pod Androida.