Zaloguj
- funkcja emulatora i skanera 1-Wire,
- obsługa prędkości standardowej i overdrive,
- akceptacja napięcia magistrali do 15 V,
- wbudowany enkoder i wyświetlacz LCD 20×4,
- komunikacja przez USB z programem terminalu VT100.
Skaner wyświetla w czasie rzeczywistym zdarzenia na magistrali w czytelnej formie. Dane do komputera są wysyłane po USB. Odbierać je można dowolnym programem terminalu emulującym protokół VT100. Dzięki temu nie trzeba pisać aplikacji na komputer i bez problemu urządzenie będzie współpracowało z praktycznie każdym systemem operacyjnym. Przykładowy ekran terminala pokazuje rysunek 1.
Jak widać, uzyskanie różnorodnych barw nie stanowi problemu. Ze względu na wymaganą emulację VT100 jako terminal nie nadają się programy takie jak BrayTerminal czy Termite. Jedyną wadą, jaką znalazłem w TeraTerm, jest wyświetlanie tekstu z atrybutem BLINK jako wyróżniony (bez migania). W przypadku Linuxa mogę polecić MiniCom dla trybu tekstowego i PUTTY dla graficznego.
Oczywiście można napisać własną aplikację. Protokół komunikacji jest zawarty w specyfikacji VT100. Nie trzeba emulować wszystkich komend.
Instalacja sterowników
W przypadku systemu WinXP i starszych konieczne jest zainstalowanie sterowników FTDI (do pobrania ze strony https://bit.ly/2Ejx4kV). W Win7 i nowszych odpowiednie sterowniki powinny już być w systemie, ale niewykluczone, że konieczna będzie ich aktualizacja.
W przypadku układów FT200/201/220/221 sterowniki wirtualnego portu COM (VCP) nie są ładowane do systemu. Zatem należy po zainstalowaniu sterowników w menedżerze urządzeń zaznaczyć „Załaduj VCP” (rysunek 2) lub lepiej programem FT_PROG zapisać ustawienia z zaznaczoną opcją „Virtual COM Port”, a nie domyślną „D2XX Direct” (rysunek 3).
Mikrokontraoler emulatora sprawdza konfigurację układu FT220 (pamięć MTP) i po wykryciu niezgodności wgrywa poprawną konfigurację. Trzeba jednak pamiętać, że zmiany tej pamięci są widziane dopiero po enumeracji urządzenia USB (resecie FTDI). Jeśli więc urządzenie było podłączane po raz pierwszy i mikrokontroler skonfigurował pamięć, konieczne jest chwilowe odłączenie urządzenia od USB.
Warto zauważyć, że układy FT22x/FT20x przy cenie porównywalnej do FT232 oferują dużo większe możliwości, takie jak dostęp do dodatkowego 1 kB EEPROM, pełne wykorzystanie możliwości FIFO, szybka komunikacja I2C i SPI, a co najważniejsze, możliwość konfigurowania układu z poziomu mikrokontrolera bez potrzeby sięgania po FT-PROG.
Komendy sterujące
Z terminalu można wydawać komendy do emulatora/skanera. Komendy mogą zawierać parametr lub nie. Dostępne są też komendy emulujące enkoder priorytetowy w urządzeniu.
1. Komendy bez parametru (naciśnięcie wybranego klawisza):
- ? – wyświetlenie spisu komend
- SPACJA – start/stop przechwytywania
- TABULATOR – emulacja naciśnięcia przycisku enkodera
- SHIFT + ‘+’ – zwiększenie temperatury emulowanej przez DS18B20
- SHIFT + ‘–’ – zmniejszenie temperatury
2. Komendy bez parametru (wydanie komendy zatrzymuje przechwytywanie):
- :v – wersja programu
- :n – nazwa programu
- :R – restart
Komendy kończymy znakiem CR lub CR+LF.
3. Komendy z parametrem:
- :Ex – echo on/off gdzie x=1 on, x=0 off
- :txx – ustawienie temperatury emulowanego DS18B20, gdzie xx to temperatura w zapisie dziesiętnym
- :e – typ emulowanego układu, zakres 01...FF. Na poziomie komend podstawowych (ReadRom, SkipRom, SearchRom) można emulować dowolny układ, ale komendy specyficzne dla danego układu są emulowane tylko dla numerów seryjnych, DS18B20 i DS2431
- :ix – alarm/IRQ on/off. Włącza lub wyłącza generowanie alarmu przez slave po wygenerowaniu sygnału reset przez mastera
- :cxx – filtrowanie ramek dla wybranej komendy (0 – wyłącza filtrowanie)
- :fxx – filtrowanie ramek dla wybranej rodziny (28 – DS18B20, 01 – nr seryjny), 0 – wyłącza filtrowanie. Gdy aktywne są oba filtry, wyświetlane będą tylko ramki ze zgodnym kodem rodziny i komendą
- :px – włączenie/wyłączenie zasilania pasożytniczego dla DS18B20
- :sx – włączenie synchronizacji oscyloskopu, gdzie:
- x=1 – tylne zbocze sygnału reset
- x=2 – tylne zbocze sygnału presence
- x=3 – zgodna komenda ustawiana rozkazem „:c”
- x=4 – zgodny kod rodziny ustawiany rozkazem „:f”
Synchronizacja oscyloskopu funkcjonuje tylko, gdy przechwytywanie jest włączone.
Na rysunku 4 został pokazany ekran z działania komendy „:i1”, widać tam przedłużony reset do około 2,5 ms, a na rysunku 5 pokazano ekran z działania komendy „:i0” ze „standardowym” resetem 700 μs. Standardowym napisałem w cudzysłowie, bo najczęściej sygnał ten trwa 480 μs, układy DS248x generują impuls o czasie ok. 500 μs, ale niektóre układy jak np. DS2408 wymagają co najmniej 660 μs. Komendą „:i1” warto przetestować programy masterów dostępnych w internecie, wyniki mogą być zaskakujące.
Format ramki skanera
Przykładowa ramka została pokazana na rysunku 6, składa się z następujących pól:
- 98 – nr linii
- 13 – długość danych
- Ack – potwierdzenie (ACK) lub brak NAK)
- [55 Match ROM] – kod komendy i jej opis tekstowy
- [28 DS18B20 – kod rodziny i opis tekstowy
- 53 63 61 77 65 – ID układu
- (33) – CRC na zielono, gdy zgodna, na czerwono, gdy błąd
- [4e Write Scratchpad] – subkomenda i opis
- 53 4c 00 – dane subkomendy
Jeśli włączone jest filtrowanie ramek, to pomiędzy ACK/Nak pojawi się „{fx}”, gdzie x rodzaj filtrowania (c-CMD, F-family). Na rysunkach 7, 8 i 9 zostały pokazane przykładowe ekrany skanowanych ramek.
Emulacja wyświetlacza LCD
W oknie terminalu emulowany jest wyświetlacz LCD. Okno to pojawia się, gdy na wyświetlaczu LCD nastąpią zmiany spowodowanie manipulacją enkoderem lub komendą wydaną z terminalu (rysunek 10). Znaczenie poszczególnych informacji na wyświetlaczu było omówione przy okazji opisu emulatora.
Ciekawostki
Skanowanie programowe działało poprawnie przy prędkości 15 kb/s. W overdrive także, ale tylko, gdy zero nadawał host (poziom niski 7 μas). Natomiast gdy odpowiadał slave (3...4 μs), program za późno odczytywał stan bitu. Aby rozwiązać ten problem, użyłem UART-u pracującego z przepływnością ponad 2 Mb/s, nieosiągalną, jakby się wydawało, dla AVR.
Pisanie oprogramowania ujawniło kilka błędów Windows (testowano na XP). Gdy konwerter USB-UART/SPI/IIC wysyła dane, a port nie jest otworzony po stronie komputera (np. uruchomiony program terminalu), to Windows interpretuje te dane jako dane myszy/klawiatury!!!. W efekcie kursor zaczyna poruszać się w przypadkowy sposób, otwierają się okna, bufor klawiatury przepełnia się. W Linuksie takich problemów nie stwierdziłem. Błąd Windows łatwo naprawić. Każde otwarcie portu powoduje uaktywnienie linii DTR i RTS. W przypadku FT22x można programowo odczytać stan tych linii i nie wysyłać danych, gdy port nie jest otwarty.
Kolejny problem pojawił się podczas chęci uzyskania „okienka zakotwiczonego” w programie terminalu (emulowany wyświetlacz LCD). W tym celu należy zapytać terminal o aktualną pozycję kursora, aby odtworzyć jego pozycję po narysowaniu okienka. Wszystko wydaje się proste, ale okazało się, że czasem nie dostaje odpowiedzi na to zapytanie. Testy wykazały, że następuje to w chwili przesuwania okienka aplikacji (od momentu złapania belki) i po otworzeniu menu. Okazało się, że w tym czasie aplikacja „wisi”. W Uniksie taki problem nie występuje, ponieważ aplikacja dostaje zdarzenie po wykonaniu czynności, np. wybranie pozycji menu, zmiana wymiaru okna, zmiana pozycji okna, a odświeżaniem pozycji okna zajmuje się system, nie zakłócając pracy programu. Problem rozwiązałem przez dodatkowe pytanie o pozycję kursora co 1 s ale to nie rozwiązuje problemu, tylko go maskuje. Innym rozwiązaniem może być użycie funkcji RESTORE i SAVE protokołu VT100.
