Elektroda.pl
Elektroda.pl
X
Sklep HeluKabel
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Problemy z komunikacją z przetwornikiem ADC, co zrobić?

ghost666 08 Kwi 2015 15:59 1794 8
  • Problemy z komunikacją z wykorzystaniem interfejsu cyfrowego to coś przed czym często stają inżynierowie projektujący systemy, wykorzystujące przetworniki analogowo-cyfrowe (ADC). Jakkolwiek nie jest to problem związany stricte z tego rodzaju układami, często właśnie przy nich się pojawia i może być on trudny do debugowania. W tym artykule opisane zostaną procedury analizy problemów z komunikacją w interfejsie cyfrowym i zaprezentowane przykładowe scenariusze co może działać niepoprawnie w naszym układzie.

    Obrazek warty jest tysiąc słów

    Jeśli nie możesz nawiązać komunikacji z układem z wykorzystaniem interfejsu cyfrowego, albo też odbierane informacje są bezsensowne, należy sięgnąć po oscyloskop i zbadać sygnały na liniach komunikacyjnych. Jeśli układ wykorzystuje interfejs SPI wystarczą cztery kanały. Konieczne jest zbadanie sygnałów C?S, SCLK, DIN oraz linii DOUT/D?R?D?Y. Jeśli interfejsem, z jakiego korzysta ADC jest I?C wystarczą dwa kanały na linie SDA i SCL. W przypadku tego drugiego interfejsu warto sprawdzić także, czy wykorzystuje się poprawny adres interfejsu.

    Komunikacja powinna zachowywać zależności czasowe, jakie opisane są w karcie katalogowej układu ADC. Sprawdzić należy czy zegar nie jest zbyt szybki, czy szerokości poszczególnych impulsów są dostatecznie duże i czy czasy charakterystyczne są utrzymane. Przebiegi powinny być czyste i schludne (w technicznym tego słowa znaczeniu). Rysunek pierwszy, zamieszczony poniżej, pokazuje jakimi zależnościami czasowymi charakteryzuje się komunikacja z wykorzystaniem interfejsu SPI układu ADS1220.

    Problemy z komunikacją z przetwornikiem ADC, co zrobić?
    Rys.1. Zależności czasowe interfejsu cyfrowego układu ADS1220


    Mając już dane z oscyloskopu, albo nawet zrzut przebiegu, można ocenić opisane powyżej zależności. Potwierdzić można zapisy i odczyty poszczególnych komunikatów, bez potrzeby wykorzystywania mikrokontrolera. Jeśli natomiast przebieg na oscyloskopie nie zgadza się z tym co widzimy na przykład na komputerze, to problem może leżeć w programie. Może on wynikać z nieodpowiednich komend mikrokontrolera albo problemów z komunikacją z komputerem, na przykład poprzez interfejs USB.

    Po prostu nie mówimy tym samym językiem

    Jednym z często popełnianych błędów, podczas implementacji interfejsu SPI jest wykorzystywanie różnych jego wersji. Dla osób których główne doświadczenie wiąże się z układami analogowymi może to być częsty problem. Występują cztery wersje interfejsu SPI, różniące się od siebie polaryzacją sygnału zegarowego (CPOL) i jego fazą (CPHA).





    Duża część przetworników ADC typu delta-sigma, produkcji firmy Texas Instruments pracuje z ustawieniami CPOL=0, CPHA=1, co oznacza, że dane taktowane są na opadającym zboczu sygnału zegarowego SCLK, a wystawiane na zboczu narastającym. Na rysunku drugim zaprezentowana jest przykładowa transmisja danych poprzez interfejs SPI skonfigurowany właśnie w ten sposób.

    Problemy z komunikacją z przetwornikiem ADC, co zrobić?
    Rys.2. Komunikacja z wykorzystaniem interfejsu SPI z ustawieniami: CPOL=0, CPHA=1.


    Nie wiem czy poprawnie mnie usłyszałeś

    Inną istotną kwestią i narzędziem przydatnym do debugowania pracy interfejsu cyfrowego jest możliwość odczytu rejestrów układu. Pomaga to w zrozumieniu sytuacji, gdy układ robi coś nieprzewidzianego. Jeśli przetwornik wymaga inicjalizacji przez mikrokontroler, to może okazać się, że wysyła on do ADC coś innego, niż nam się wydaje, zatem warto w takiej sytuacji odczytać status rejestrów konfiguracyjnych układu ADC, po jego inicjalizacji.

    W tym pokoju jest za głośno

    Szum w liniach komunikacyjnych, może powodować powstawanie błędów. Szczególnie zaszumiona linia zegarowa może być problemem. Dodatkowy szum w linii SCLK może powodować, że interfejs SPI odczyta błędnie jakieś dane, przed tym aż poprawne dane obecne będą na liniach.

    Jeśli w systemie obecny jest szum, szczególnie w linii zegarowej, dodatkowe impulsy na SCLK mogą spowodować, że DOUT przyjmie stan wysoki, co może zakończyć taktowanie danych. Dodatkowo, w niektórych układach dwa impulsy na linii SCLK mogą wprowadzić układ w cykl kalibracyjny. Konkretne zachowanie zależne jest od układu, jednakże jeśli zauważy się, że linia DOUT/D?R?D?Y przyjmuje wartość wysoką częściej niż powinna, albo też, że układ często przechodzi w stan kalibracji, można domyślić się, że szum w linii zegarowej jest przyczyną problemów.

    Nie przerywaj mi gdy mówię

    Taktowanie danych nie powinno odbywać się asynchronicznie do konwersji analogowo-cyfrowych w przetworniku. Linia D?R?D?Y układu ADC wskazuje kiedy dane na DOUT zostały odświeżone. Gdy D?R?D?Y przejdzie ze stanu wysokiego do niskiego, nowe dane mogą zostać odczytane korzystając z taktowania na SCLK, ale muszą zostać odczytane przed kolejnym wskazaniem D?R?D?Y. Jeśli dane nie zostaną odczytane przed kolejnym wskazaniem obecności danych, to dane z poprzedniego cyklu zostaną utracone. Zamiast tego na wyjściu DOUT udostępnione zostaną nowe dane, przez co powstaną błędy transmisji. Jeśli będziemy odczytywać dane z wyjścia, bez monitorowania stanu wyjścia D?R?D?Y okazać się może, że odczytujemy niepoprawne dane. Na rysunku trzecim pokazano w jaki sposób na oscyloskopie wygląda transmisja przerwana przez informację o obecności nowych danych, zaraz za szóstym cyklem SCLK. W takiej sytuacji, interfejs ADC interpretuje siódmy cykl SCLK jako początek nowych danych.

    Problemy z komunikacją z przetwornikiem ADC, co zrobić?
    Rys.3. Odczyt z ADC zostaje zakłócony przez sygnał /D?R?D?Y.


    Czy powiedziałeś to co właśnie myślę, że powiedziałeś?

    Debugowanie interfejsu cyfrowego pomaga, jeśli wiemy czego spodziewać się na wyjściu. Przyłóżmy zatem znane napięcie do wejścia przetwornika i sprawdźmy jakie jest napięcie referencyjne i wtedy zbierajmy testowe dane. Konieczny może być pomiar napięcia na wejściach - przetwornika i napięcia odniesienia - sygnał analogowy na wejściu i informacje odczytane z interfejsu cyfrowego powinny być takie same i zgadzać się z tym, czego się spodziewamy. Porównywanie surowych danych odczytanych z ADC z wartościami jakich się spodziewamy jest najlepsze, dzięki temu unika się konwersji np. w mikrokontrolerze, która także może być błędna.

    Słyszę Cię głośno i wyraźnie

    Opisane powyżej problemy to typowe przyczyny niepoprawnej komunikacji pomiędzy mikrokontrolerem a przetwornikiem ADC. Wiedząc jakie są podstawowe przyczyny występowania tych błędów, można ich uniknąć lub ułatwić sobie debugowanie istniejącego systemu.

    Źródło:

    http://e2e.ti.com/blogs_/b/precisionhub/archi...-can-t-talk-to-my-data-converter-what-s-wrong


    Fajne!
  • Sklep HeluKabel
  • #2 10 Kwi 2015 21:05
    bolek
    Specjalista - oświetlenie sceniczne

    Oscyloskop to może jest i dobry ale raczej do analogowych i powtarzalnych przebiegów. Dodatkowo, przeciętny warsztat raczej nie szarpnie się na oscyla z więcej niż dwoma kanałami. Nawet gdyby miał ich więcej to i tak wciąż będzie to pejczowanie
    Do takich tematów jedyne co się może naprawdę przydać to analizator stanu- np https://www.saleae.com/ lub jego sporo tańszy odpowiednik.
    Można nagrać jakiś odcinek czasu, w dodatku na kilkunastu kanałach, a jak by komuś było mało to można od razu zdekodować kilka standardów.

    Na marginesie nie tylko ADC wiszą na SPI czy I2C...

  • Sklep HeluKabel
  • #3 10 Kwi 2015 21:41
    ghost666
    Tłumacz Redaktor

    @bolek Masz w 100% rację, nie wiem czemu autor artykułu pisał tylko o oscyloskopie. Z mojej praktyki zasugerował bym zbadanie przebiegów (głównie sterujących) oscyloskopem, a potem zapięcie wszystkiego do analizatora stanów logicznych (część cyfrowych oscyloskopów ma przystawki tego rodzaju nawet).

    No tak, tutaj autor skupił się na ADC bo chyba są to jedne z najpopularniejszych rodzajów układów, zapinane na SPI czy inne interfejsy szeregowe.

  • #4 11 Kwi 2015 11:58
    Gostek
    Poziom 17  

    Opisane przypadki to podstawowe problemy z komunikacja szeregową. Analizator stanów logicznych nie na wiele się przyda kiedy n.p. zbocza są zniekształcone, sygnał jest zaszumiony lub występują inne problemy natury analogowej. Ich nie da się zobaczyć analizatorem, a w dodatku łatwo mozna dojść do błędnych wniosków.

    Zarówno do SPI jak i I2C w większości przypadków wystarczy dwukanałowy oscyloskop z oddzielnym wejściem wyzwalania (praktycznie każdy). Cyfrowy jest plusem, bo możemy zatrzymać przebieg i go zbadać, ale jeżeli w naszym projekcie jesteśmy na poziomie problemów z transmisją, to napewno możemy tymczasowo zmienić firmware i wyzwalać transmisję na tyle często, żeby można było użyć oscyloskopu analogowego.

    W przypadku SPI sygnał CS podłączamy do wejścia wyzwalania, a CLK i DI lub DO do kanałów pierwszego i drugiego. Przy dwu kanałowym oscyloskopie czasami trzeba kilka razy przeskakiwać między DI a DO itp, ale przy podstawowych problemach z komunikacją nie jest to problemem. Obserwujemy zazwyczaj tylko kilka bajtów, które zmieszczą się na ekranie każdego oscyloskopu.
    Jeśli chodzi o I2C, to sytuacja jest podobna. Jeśli na szynie mamy tylko jeden układ SLAVE, to oscyloskop wyzwalamy z sygnału CLK (opadające zbocze). Jeśli na szynie jest więcej układów SLAVE, to do wyzwalania można wykorzystać nie używany w tym momencie pin mikrokontrolera (wykorzystujemy go jak sygnał CS przy SPI).

    Autor pisze o oscyloskopie, ponieważ wie jak go używać.

  • #5 11 Kwi 2015 13:02
    bolek
    Specjalista - oświetlenie sceniczne

    Tu nie chodzi o to że "Wy" wiecie jak używać oscyloskopu ale o to co do czego się nadaje.

    Posiadam jedno i drugie, nie bez powodu napisałem tak jak napisałem.
    Tak jak Ghost przetłumaczył większość problemów wynika ze złych polaryzacji sygnałów i to bardzo dobrze widać na analizatorze. Ponadto bardzo dobrą cechą jest możliwość dekodowania ramek z poziomu softu- wyklucza to fakt że dekodująca osoba ma błędne wyobrażenie o sygnale bo wg niej przebieg będzie ok.
    Żeby zaśmiecić sygnał zakłóceniami trzeba się postarać chyba przynajmniej o środowisko małej spawarki, ewentualnie lecieć z wysokim zegarem na duże odległości i oberwać odbiciami- no ale to w zasadzie proszenie się o problemy. Spróbuj też oscylem zlokalizować byka który ujawnia się raz na jakiś czas. A tak np lubią robić sprzętowe interfejsy w prockach. Przeciętną cyfrówką nagrasz kilka batów i cześć pieśni

    Wg mnie jedynym miejscem gdzie oscyl da więcej niż analizator to magistrale "podwieszane" jak 1Wire czy CAN gdzie problemem są poziomy napięć.
    Zwróć jeszcze uwagę na jedną rzecz:cena takiego analizatora (~40zł)

  • #6 11 Kwi 2015 19:53
    Gostek
    Poziom 17  

    Ta "zła polaryzacja" dotyczy głównie tylko SPI, i to jeśli ktoś nie przeczytał najpierw aplikacji.
    Autor pisze o PODSTAWOWYCH problemach z nawiązaniem komunikacji, a nie o tym że jest problem raz na jakiś czas. Zdekodowanie ramki kilku bajtów z adresem i komendą na oscyloskopie to nie żaden wyczyn. A do zakłócenia sygnału wcale nie trzeba spawarki... Poza tym analizatorem nie zobaczysz, że zbocze jest za wolne i może nie mieścić się w specyfikacji odbiornika.

    A czy zastanawiałeś się dlaczego o wykorzystaniu oscyloskopu pisze autor ? I czym Autor się zajmuje w TI?

  • #7 11 Kwi 2015 20:57
    bolek
    Specjalista - oświetlenie sceniczne

    Heh :)
    Bo Ty jak przeczytasz specyfikacje to zawsze zrobisz dobrze?. Gratuluje (serio).
    Podstawowe problemy o których wspomniał autor można spokojnie ocenić analizatorem za kilka dych a nie cyfrowym oscylem za przynajmniej 10x tyle.

    Za wolne zbocze... no to trzeba chyba mocno przegiąć w rejestrami, których mało kto rusza bez powodu.
    Popatrz jakie kwiatki ma zasiane np STM w kwestii I2C a dowiesz się że wysłanie bajta to dopiero początek (problemów jakie mogą się przytrafić)

    Myślę że wystarczy, każdy swoje wnioski wyciągnie.

  • #8 11 Kwi 2015 21:23
    Gostek
    Poziom 17  

    Oczywiście że popełniam błędy, ale ważne jest by znać sposoby na szybkie ich diagnozowanie. Zbocza w szybkiej transmisji to normalna sprawa. A rejestry są po to żeby z nich korzystać. To że Ty nie miałeś takiej potrzeby, bądź nie spotkałeś się z takimi problemami, to nie znaczy że ich nie ma.
    Nawet w zwykłym I2C coś może obciążać jedną z szyn i tego nie zobaczysz analizatorem jeśli jego próg stanu wysokiego będzie niższy niż któregoś z układów na szynie. Twój analizator pokaże piękną zero jedynkową sekwencję, a jakiś odbiornik nie zobaczy nic... Właśnie po to używa się oscyloskopu. Analizator to zasadniczo okrojony oscyloskop z możliwością rejestracji i zaawansowanym wyzwalaniem.
    Diagram oka to jedna z podstawowych metod oceny sygnału cyfrowego, oczywiście niewykonalna analizatorem (a już napweno nie za 40zl) - podstawy transmisji.

  • #9 13 Kwi 2015 18:54
    maciej_333
    Poziom 34  

    Problem pojawić może się też wtedy, gdy przetwornik A/C dołączony jest poprzez optoizolatory. Są one wprawdzie szybkie, ale zobaczcie jak duży może być ich czas propagacji pomiędzy wejściem a wyjściem. Jeżeli wysyłamy zegar i komendę przez optoizolator, to nie ma to znaczenia. Po stronie przetwornika oba sygnały będą jednakowo opóźnione. Gorzej, gdy zaczynamy coś odczytywać. Wówczas master może odczytać nie to, co trzeba. Wystarczy tu czas propagacji optoizolatora większy od połowy okresu zegara. Kiedyś się na to natknąłem. Rozwiązanie problemu zajęło mi sporo czasu. Nie trzeba jednak ograniczać częstotliwości zegara. Można wykorzystać dodatkowe SPI slave mikrokontrolera. Polega to na zwrotnym przesłaniu odebranego przez przetwornik sygnału zegarowego. Taki sygnał wraz z odebranymi danymi dostarczamy do SPI slave mikrokontrolera.

    Stosowanie oscyloskopu, szczególnie cyfrowego jest tu przydatne. Koledzy już opisali dlaczego ma to sens. Analizator stanów logicznych się przydaje, ale raczej w późniejszym etapie. Inne jego zastosowanie to inżynieria wsteczna w jakimś urządzeniu.