DS18SW20 - emulator czujnika temperatury DS1820. Przykład programowej realizacji urządzenia 1-Wire slave (2)

Program sterujący

Cała magia emulatora czujnika temperatury DS1820 dzieje się w oprogramowaniu urządzenia. Jak wiemy, każda operacja mająca miejsce na magistrali 1-Wire inicjowana jest przez układ Master poprzez ściągnięcie tejże magistrali do logicznego „0” (przez czas 1…5 μs).

W związku z tym naturalnym sposobem na obsłużenie protokołu ze strony układu Slave jest wykorzystanie przerwania zewnętrznego (np. INT0) skonfigurowanego w ten sposób aby zachodziło przy opadającym zboczu sygnału. Użycie przerwania zewnętrznego jest o tyle niezbędne, że magistrala 1-Wire wymusza dość rygorystyczne wymogi czasowe, więc zastosowanie typowego portu I/O i tzw. pollingu jest niewystarczająca w przypadku, gdyby układ Slave miał wykonywać jeszcze inne czasowo istotne operacje niezwiązane z obsługą magistrali. Wykorzystanie przerwania zewnętrznego niesie za sobą tą dodatkową zaletę, że cała obsługa protokołu zostanie zamknięta w ramach jednej funkcji ISR a program główny może realizować inną, niezbędną z punktu widzenia konkretnej aplikacji, funkcjonalność.

Zadeklarujmy, zatem kilka podstawowych zmiennych globalnych: numer seryjny naszego urządzenia Slave, scratchpad (pamięć termometru), zmienną przechowującą aktualny stan procedury obsługi układu Slave oraz zmienną odpowiedzialną za żądanie pomiaru temperatury. Jak wiemy, zmienne globalne to w dużym uproszczeniu zło (z przymrużeniem oka), gdyż utrudniają optymalizację kodu, lecz w przypadku styku na poziomie program główny/funkcje narzędziowe a funkcje obsługi przerwań systemowych są niezbędną koniecznością. Specyfikację zmiennych globalnych naszego urządzenia pokazano na listingu 1.

Dalej, na listingu 2, pokazano plik nagłówkowy programu obsługi aplikacji definiujący zarówno ustawienia sprzętowe, jak i wprowadzający niezbędne definicje stałych poprawiających czytelność kodu (jak i ułatwiających jego modyfikacje).

W związku z tym, że obsługa protokołu odbywa się w całości w ramach procedury obsługi przerwania INT0 (oraz jak się okaże, przerwania Timera0) funkcja główna naszego programu obsługi ogranicza się wyłącznie do konfiguracji niezbędnych peryferiów mikrokontrolera i wykonywania pomiaru temperatury na żądanie użytkownika. Ciało tejże funkcji pokazano na listingu 3.

Jak widać, i o czym nie wspomniano wcześniej, w programie obsługi używany jest także timer sprzętowy (w tym przypadku 8-bitowy Timer0) jak i przerwanie od jego przepełnienia (TIMER0_OVF_vect). Użycie tego peryferium konieczne jest w przypadku, gdyby układ Master z jakiś powodów wysłał niepełną sekwencję sygnałów sterujących (np. tylko sygnał Reset bez jakichkolwiek dalszych komend) co spowodowałoby zmianę stanu procedury obsługi magistrali 1-Wire na predefiniowaną wcześniej wartość STATUS_WAITING_FOR_CMD i oczekiwanie na rozkaz sterujący uniemożliwiając tym samym dalsze, poprawne funkcjonowanie algorytmu obsługi. Timer ten każdorazowo ustawiany jest w taki sposób aby po upłynięciu zadanego czasu (zależnego od oczekiwanych operacji po stronie układu Master) przywrócić spoczynkowy stan procedury obsługi (STATUS_IDLE) w przypadku błędów po stronie układu nadrzędnego.

Przejdźmy zatem do właściwego programu obsługi układu Slave magistrali 1-Wire. Jak wspomniano wcześniej, stanem spoczynkowym układu Slave jest oczekiwanie na sygnał Reset a po jego wykryciu, wystawienie sygnału Presence i oczekiwanie na rozkaz sterujący.

Tą część algorytmu programu obsługi pokazana na listingu 4 (o wykonaniu poszczególnych części programu obsługi decyduje wartość zmiennej Status). Po wykonaniu tych czynności, układ Slave oczekuje (przez czas 2 ms) na odebranie komendy sterującej i w zależności od jej rodzaju realizuje pozostałe funkcje typowe dla emulowanego układu typu DS1820.

Nasze urządzenie obsługuje 6 rodzajów komend sterujących: CMD_SEARCH_ROM, CMD_READ_ROM, CMD_MATCH_ROM, CMD_SKIP_ROM, CMD_CONVERT_T oraz CMD_READ_SCRATCHPAD. Odbiór komendy sterującej realizuje część programu obsługi pokazana na listingu 5.

Następnie, w zależności od rodzaju odebranej komendy sterującej, realizowana jest odpowiednia część programu obsługi (o wykonaniu poszczególnych części programu obsługi jak zwykle decyduje wartość zmiennej Status). Rozkaz READ_ROM (czyli odczyt numeru seryjnego przez układ Master) realizuje część programu obsługi aplikacji pokazana na listingu 6.

Rozkaz MATCH_ROM (czyli wysyłania przez układ Master numeru ID aby zaadresować naszego Slave-a) realizuje część programu obsługi aplikacji pokazana na listingu 7.

Jak widać, przesłanie niepoprawnego adresu układu Slave powoduje dezaktywację naszego urządzenia (stan domyślny STATUS_IDLE wymuszający oczekiwanie na sygnał RESET), zaś przesłanie adresu zgodnego powoduje adresację urządzenia (STATUS_SLAVE_SELECTED) i oczekiwanie na przesłanie bajta realizowanej funkcjonalności (rozkazy CMD_CONVERT_T i CMD_READ_SCRATCHPAD). Skądinąd takie samo zachowanie powoduje przesłanie rozkazu CMD_SKIP_ROM (pokazane na listingu 5), który wymusza pominięcie adresacji konkretnego urządzenia i ma sens wyłącznie wtedy, gdy na magistrali 1-Wire znajduje się tylko jedno urządzenie typu Slave.

Dalej, na listingu 8 pokazano fragment algorytmu programu obsługi odpowiedzialny za realizację funkcji CMD_SEARCH_ROM, czyli wyszukiwania przez układ Master numerów ID podłączonych do magistrali układów Slave.

Tak jak wspomniano wcześniej poprawne zaadresowanie układu Slave powoduje przejście urządzenia w tryb oczekiwania (STATUS_SLAVE_SELECTED) na przesłanie bajta realizowanej funkcjonalności (rozkazy CMD_CONVERT_T i CMD_READ_SCRATCHPAD). Za ten etap programu obsługi odpowiada fragment algorytmu programu obsługi pokazany na listingu 9.

Jak widać, odbiór rozkazu CMD_CONVERT_T powoduje ustawienie zmiennej globalnej measureTemp wymuszającej wykonanie pomiaru temperatury realizowane w pętli głównej aplikacji i powodujące wpisanie (atomowe) wyników pomiaru do tablicy Scratchpad, zaś odebranie rozkazu CMD_READ_SCRATCHPAD powoduje przejście programu obsługi do fragmentu odpowiedzialnego za wysłanie (na żądanie Mastera) przez układ Slave zawartości tablicy Scratchpad, przy czym liczba bajtów, jaka zostanie przesłana zależy wyłącznie od przebiegu transmisji inicjowanej przez układ nadrzędny (od 1 do 9 bajtów). Odczyt przez układ Master liczby bajtów mniejszej niż cała zawartość scratchpad-a (9 bajtów) powoduje wystąpienie timeout-u i powrót stanu urządzenia Slave do pozycji wyjściowej (STATUS_IDLE) i oczekiwanie na sygnał RESET.

Uważny Czytelnik zastanowi się z pewnością, dlaczego rozkazy CMD_CONVERT_T i CMD_READ_SCRATCHPAD nie są obsługiwane od razu po detekcji sygnału RESET i wysłaniu sygnału PRESENCE (listing 5). Otóż nie jest to możliwe, gdyż wykonanie tych rozkazów wymaga wcześniejszej adresacji układu Slave dokonywanej dzięki obsłudze rozkazów CMD_SKIP_ROM i CMD_MATCH_ROM. Na listingu 10 pokazano fragment algorytmu programu obsługi odpowiedzialny za realizację funkcji READ_SCRATCHPAD.

Na koniec tej tematyki wspomniana wcześniej funkcja obsługi przerwania od przepełnienia licznika Timer0 niezbędna z punktu widzenia odmierzania tzw. czasu timeout, której to ciało pokazano na listingu 11.

Kilka niezbędnych słów uwagi wymaga tematyka czasu latencji procedury obsługi przerwania INT0 realizującej obsługę interfejsu 1-Wire, które to zagadnienie jest szczególnie istotne w przypadku wysyłania danych przez układ Slave. Jak wiemy odczyt danych przez układ Master inicjowany jest poprzez wygenerowanie opadającego zbocza sygnału (ściągnięcie magistrali do logicznego „0”) przez czas z zakresu 1…5 μs. Po wystąpieniu takiego zbocza sygnału układ Slave wystawia na magistralę bieżący bit danych a układ Master dokonuje jego odczytu, przy czym czas od wystąpienia opadającego zbocza sygnału do operacji odczytu nie może przekroczyć 15 μs. Zwykle implementuje się, że układ Master dokonuje odczytu przesłanego bitu na końcu okna odczytu, czyli po ok. 15 μs od wystąpienia opadającego zbocza sygnału. Jest to dla nas o tyle istotne, że procedura obsługi przerwania INT0 musi zostać napisana w taki sposób, aby zapewnić wystawienie bitu na magistralę w nieprzekraczalnym czasie, o którym wspomniałem powyżej a najlepiej jak najszybciej po zwolnieniu magistrali przez układ Master (po ustąpieniu ściągnięcia magistrali).

Jak wiemy standardowy czas latencji od wystąpienie przerwania do skoku do wektora przerwania dla mikrokontrolerów AVR wynosi 4 takty zegara taktującego, a więc bardzo mało. W takim razie to nie stanowi potencjalnego problemu przy taktowaniu zegarem o częstotliwości 8 MHz. Jest jednak małe, acz istotne „ale”. Skok do wektora przerwania nie jest równoznaczny z natychmiastową reakcją programu obsługi przerwania na zainicjowany proces odczytu. Zanim program przejdzie do tego miejsca wykonywanych jest szereg innych instrukcji, których obecność wynika z pracy kompilatora, który dba o integralność rejestrów procesora używanych w procedurze obsługi przerwania tak, aby ich wartości po wyjściu z tejże procedury pozostały niezmienione (odkłada je na stos). Co więcej, na liczbę tych niezbędnych operacji nie mamy większego wpływu, gdyż piszemy w języku wysokiego poziomu, a co za tym idzie, ten aspekt programowania pozostawiamy kompilatorowi. Na szczęście możemy podejrzeć plik deasemblacji (*.lss) i przekonać się, jak wygląda wygenerowany kod maszynowy co jednocześnie pozwala ocenić czas wykonania poszczególnych partii programu. Innym sposobem jest wykorzystanie wbudowanego w środowisko programistyczne symulatora.

Właśnie użycie pierwszej z możliwości pozwoliło mi ocenić czas odpowiedzi naszego urządzenia na żądanie odczytu przesłane przez układ Master, który w przybliżeniu wynosi 50 taktów zegara, czyli w granicach 6,25 μs. Potwierdziłem to również w symulatorze środowiska Microchip Studio. Jest to wartość w zupełności akceptowalna i pozwalająca zmieścić się w 15 μs oknie odczytu urządzenia Master. W przypadku zapisu do układu Slave latencja nie jest aż tak krytycznym elementem, gdyż odczyt stanu magistrali dokonywany przez układ podrzędny zachodzi dopiero po upłynięciu czasu 30 μs od wystąpienia opadającego zbocza sygnału. Niemniej jednak nawet w tym wypadku, jak i w ogóle w przypadku implementacji funkcji ISR, ważny jest sumaryczny, maksymalny czas obsługi zdarzenia (czyli od wejścia do wyjścia z funkcji ISR), który nie może przekroczyć wartości 60 μs, czyli czasu trwania pojedynczego bitu (gdyż z takim interwałem będzie wywoływane przerwanie INT0).

Przeprowadzone testy praktyczne potwierdzone wcześniejszą symulacją w środowisku Microchip Studio wykazały, że maksymalny czas obsługi zdarzenia wynosi około 51 μs, a więc całkiem sporo. Wynika to poniekąd z czasu oczekiwania (30 μs) na odczyt stanu magistrali dokonywany przez układ podrzędny (w przypadku zapisu przez układ Master) i jest pokłosiem przyjętego rozwiązania programowego implementacji magistrali 1-Wire w wersji Slave. Czas ten można byłoby wydatnie skrócić poprzez zrezygnowanie z oczekiwania wspomnianych 30 μs, lecz wymagałoby to wykorzystania dodatkowego timera (oraz przerwania od jego przepełnienia) oraz gruntownej modyfikacji i komplikacji kodu obsługi wszystkich przerwań, co z pewnością odbiłoby się na wielkości kodu wynikowego aplikacji. Nie zdecydowałem się na ten krok, gdyż zachowujemy odpowiedni margines bezpieczeństwa a jedyne zmiany, jakie postanowiłem wprowadzić to skrócenie czasu oczekiwania na odczyt stanu magistrali dokonywany przez układ podrzędny do wartości 25 μs (opcjonalnie można ustawić 20 μs), przez co sumaryczny, maksymalny (dla najgorszego przypadku) czas obsługi przerwania INT0 wynosi 46 μs. Jest to wartość w pełni bezpieczna. Co prawda podczas obsługi transmisji 1-Wire pozostaje wyłącznie około 24% czasu procesora na wykonywanie innych zadań (np. w pętli głównej), ale nasze urządzenie w zasadzie żadnych innych zadań nie wykonuje, gdyż pomiar temperatury inicjowany jest tylko i wyłącznie rozkazem przesłanym magistralą przez co w czasie pomiaru nie odbywa się żaden „ruch” w ramach tego medium.

Poza tym pomiar dokonywany przy udziale przetwornika ADC nie koliduje w żaden sposób z implementacją magistrali 1-Wire. Niemniej jednak Czytelnicy, którzy chcieliby samodzielnie zastosować omówione rozwiązania w swoim oprogramowaniu muszą te kwestie szczegółowo przeanalizować nawet wtedy, gdy zdecydują się na zwiększenie częstotliwości taktowania mikrokontrolera, co samo w sobie minimalizuje ryzyko potencjalnych problemów będąc tak naprawdę rozwiązaniem najprostszym, lecz nie pozbawionym wad. Główną wadą takiej solucji jest wydatne zwiększenie zapotrzebowania na moc co niejednokrotnie nie jest pożądane.

Uff, tyle w kwestii implementacji magistrali 1-Wire w wersji Slave i emulacji termometru DS1820. Wiem, że było to dość długie opracowanie, ale moim zdaniem bardzo wartościowe z punktu widzenia poznania zasad działania tego medium transmisyjnego i zastosowania go do swoich potrzeb. Już na sam koniec 2 funkcje niezwiązane bezpośrednio z samą realizacją obsługi magistrali 1-Wire, ale niezbędne do emulacji układu DS1820. Pierwsza z nich to funkcja dokonująca pomiaru napięcia przetwornika TC1047A i konwertująca otrzymane dane na format temperatury zgodny ze specyfikacją układu DS1820 a następnie zapisująca je w pamięci Scratchpad. Ciało tej funkcji pokazano na listingu 12.

Dla dociekliwych dodam, że pomiar napięcia przetwornika ADC, jego konwersja na temperaturę w standardzie układu DS1820, obliczenie CRC8 i aktualizacja scratchpad-a zajmuje ok. 270 μs, więc dokładnie tyle potrzeba aby po wysłaniu rozkazu CONVERT_T przystąpić do odczytu scratchpad-a, zapominając o magicznych 750 ms, jakie potrzebował układ DS1820 na konwersję temperatury. Druga i zarazem ostatnia funkcja to funkcja odpowiedzialna za odczyt adresu ID układu Slave z pamięci EEPROM mikrokontrolera (jeśli został tam zapisany) lub pozostanie przy adresie domyślnym utworzonym podczas definicji tablicy ID. Ciało tej funkcji pokazano na listingu 13.

Fakt istnienia indywidualnego (zamiast domyślnego) adresu urządzenia w pamięci EEPROM oceniany jest na podstawie wartości pierwszego bajta pamięci EEPROM. Jeśli jest on różny od wartości 0xFF to przyjmuje się, że użytkownik wpisał swój własny numer do pamięci EEPROM, w przeciwnym wypadku pozostawiany jest numer domyślny (inicjowany na wstępie programu obsługi aplikacji). Powyższa funkcja oblicza ponadto wartość ósmego bajta adresu, który to za każdym razem powinien być sumą CRC8. Ustalenie adresu urządzenia dokonywane jest jednorazowo na początku programu obsługi aplikacji.

Na koniec, w tabeli 1, pokażę pseudokod funkcji obsługujących nasze urządzenie DS18SW20 (uruchamiany po stronie układu Master). Jak widać, programowa realizacja układu DS1820 jak i interfejsu 1-Wire jest niezmiernie prosta i zarazem bardzo ciekawa i skłania do stosowania tego interesującego interfejsu komunikacyjnego we własnych zastosowaniach czego przykładem niech będą chociażby dwa z moich wcześniejszych projektów zrealizowane w tamtym czasie przy użyciu pakietu Bascom: c-button (kopiarka pastylek DS1990, EP 2/2009) oraz 1-Wire LED (4 segmentowy, 3-kolorowy wyświetlacz LED wyposażony w sprzęg 1-Wire, EP 04/2011).

Rysunek 8. Rzeczywiste przebiegi sygnałów sterujących magistrali 1-Wire dla przypadku rozkazu READ_ROM wysłanego do naszego urządzenia DS18SW20

Jako ciekawostkę, na rysunku 8 pokazano rzeczywiste przebiegi sygnałów sterujących magistrali 1-Wire dla przypadku rozkazu READ_ROM wysłanego do naszego urządzenia DS18SW20.

Robert Wołgajew, EP