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.
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.
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.
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
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.
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.
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.
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
Cool? Ranking DIY
