Jeśli pisałeś kiedyś jakikolwiek program to z pewnością znasz uczucie ulgi, gdy po skończonym kodowaniu program działa bez błędów za pierwszym razem. Na studiach, na pracowni komputerowej, nie było to takie trudne; niestety w realnym życiu takie sytuacja zdarzają się już rzadziej, ale z drugiej strony daje nam to możliwość analizowania i poprawiania naszych błędów, co jest doskonałą okazją do nauki.
Weźmy za przykład projektowanie interfejsu Inter-Integrated Circuit, czyli popularnego I²C. Wielu projektantów docenia ten interfejs z uwagi na jego prostotę, ale to nie znaczy, że można zapominać o tym, że nadal stoi za nim ponad 60 stronicowa specyfikacja. Więc jeśli w prototypie jaki właśnie uruchamiamy I²C nie chce działać tak jak powinno, nie załamujmy się, tylko przystąpmy do debugowania i nauki. W poniższym, artykule zidentyfikujemy dwie podstawowe bolączki, tego interfejsu, które najczęściej powodują, że nie funkcjonuje on poprawnie. Oczywiście, oprócz identyfikacji problemów zajmiemy się także analizie jak mu zaradzić.
Problem pierwszy - niedopasowane poziomy napięć.
Urządzenie slave wysyła do mastera sieci sygnał, gdy ma dane, które chce przesłać. Robi to ściągając linię danych do stanu niskiego. Jest to problemem, szczególnie wtedy gdy stan niski (VOL) jednego urządzenia, nie jest "dostatecznie niski", aby zarejestrowały go inne układy w sieci. Próg stanu niskiego interfejsu I²C definiowany jest przez specyfikację jako wartość równą 30% napięciu zasilania. Z kolei wszystko powyżej 70% napięcia zasilającego układ traktowane jest jako stan wysoki. Graficzna reprezentacja tych poziomów napięć pokazana jest na rysunku 1.
W idealnym przypadku chcielibyśmy, aby nasze napięcie VOL było możliwie bliskie 0 V. Niestety nie zawsze jest to możliwe - pasożytnicze potencjały, czy rezystancje w torze interfejsu powodują, że VOL wzrasta powyżej zera. Dotychczasowo produkowane bufory interfejsu I²C posiadają zdefiniowany na sztywno offset napięciowy stanu VOL równy około 0,5 V. Teraz jednakże Texas Instruments opracowało nową architekturę tego typu statycznego offsetu, co sprawia że efektywny offset dla tego bufora kształtuje się na poziomie około 0,2 V dla np. układu TCA9802.
Problem drugi - nieodpowiednie czasy narastania
Zaletą I²C jest to, że na jednej linii elektrycznej układ może komunikować się z wieloma urządzeniami - tak długo, jak pojemność sieci jest nie większa od 400 pF. Jednakże, nawet jeśli pojemność jest mniejsza to istnieje szereg innych czynników które mogą ograniczyć stosowanie naszego interfejsu w urządzeniu. Często spowodowane jest to faktem, że czasy narastania przebiegów cyfrowych są zbyt duże. Może to być spowodowane zbyt dużą ilością urządzeń w sieci, nadmierną pojemnością ale też np. zbyt małym prądem drivera lub zbyt wolnym czasem narastania na jego wyjściu.
Nowy driver, opracowany przez TI, charakteryzuje się zupełnie inną architekturą (patrz rysunek 2). W układzie tym do sterowania siecią wykorzystano zintegrowane źródło prądowe, zamiast podciągnięcia do zasilania poprzez opornik.
Sterowanie sieci źródłem prądowym pozwala na uzyskanie szybszego narastania napięcia na wyjściu, jak i bardziej kontrolowanego opadania napięcia. Dzięki temu otrzymujemy driver zapewniający o wiele lepszą a integralność sygnału.
Na rysunku 3 widzimy porównanie przebiegów na wyjściu klasycznego drivera (niebieski) i nowego, opartego na źródle prądowym (zielony) dla obciążonej sieci. Jak widać na oscylogramie nowy sterownik interfejsu zapewnia o wiele lepszą kontrolę nad zboczami jak i eliminuje drgania napięcia.
Nowa architektura drivera, zaproponowana przez TI, rozwiązuje częste problemy z interfejsami I²C, jakie obserwuje się w bardziej rozbudowanych sieciach. Wykorzystanie układów z rodziny TCA980X pozwala uprościć projektowanie jak i uruchamianie urządzeń wykorzystujących interfejs I²C.
Żródło: Link
Weźmy za przykład projektowanie interfejsu Inter-Integrated Circuit, czyli popularnego I²C. Wielu projektantów docenia ten interfejs z uwagi na jego prostotę, ale to nie znaczy, że można zapominać o tym, że nadal stoi za nim ponad 60 stronicowa specyfikacja. Więc jeśli w prototypie jaki właśnie uruchamiamy I²C nie chce działać tak jak powinno, nie załamujmy się, tylko przystąpmy do debugowania i nauki. W poniższym, artykule zidentyfikujemy dwie podstawowe bolączki, tego interfejsu, które najczęściej powodują, że nie funkcjonuje on poprawnie. Oczywiście, oprócz identyfikacji problemów zajmiemy się także analizie jak mu zaradzić.
Problem pierwszy - niedopasowane poziomy napięć.
Urządzenie slave wysyła do mastera sieci sygnał, gdy ma dane, które chce przesłać. Robi to ściągając linię danych do stanu niskiego. Jest to problemem, szczególnie wtedy gdy stan niski (VOL) jednego urządzenia, nie jest "dostatecznie niski", aby zarejestrowały go inne układy w sieci. Próg stanu niskiego interfejsu I²C definiowany jest przez specyfikację jako wartość równą 30% napięciu zasilania. Z kolei wszystko powyżej 70% napięcia zasilającego układ traktowane jest jako stan wysoki. Graficzna reprezentacja tych poziomów napięć pokazana jest na rysunku 1.
W idealnym przypadku chcielibyśmy, aby nasze napięcie VOL było możliwie bliskie 0 V. Niestety nie zawsze jest to możliwe - pasożytnicze potencjały, czy rezystancje w torze interfejsu powodują, że VOL wzrasta powyżej zera. Dotychczasowo produkowane bufory interfejsu I²C posiadają zdefiniowany na sztywno offset napięciowy stanu VOL równy około 0,5 V. Teraz jednakże Texas Instruments opracowało nową architekturę tego typu statycznego offsetu, co sprawia że efektywny offset dla tego bufora kształtuje się na poziomie około 0,2 V dla np. układu TCA9802.
Problem drugi - nieodpowiednie czasy narastania
Zaletą I²C jest to, że na jednej linii elektrycznej układ może komunikować się z wieloma urządzeniami - tak długo, jak pojemność sieci jest nie większa od 400 pF. Jednakże, nawet jeśli pojemność jest mniejsza to istnieje szereg innych czynników które mogą ograniczyć stosowanie naszego interfejsu w urządzeniu. Często spowodowane jest to faktem, że czasy narastania przebiegów cyfrowych są zbyt duże. Może to być spowodowane zbyt dużą ilością urządzeń w sieci, nadmierną pojemnością ale też np. zbyt małym prądem drivera lub zbyt wolnym czasem narastania na jego wyjściu.
Nowy driver, opracowany przez TI, charakteryzuje się zupełnie inną architekturą (patrz rysunek 2). W układzie tym do sterowania siecią wykorzystano zintegrowane źródło prądowe, zamiast podciągnięcia do zasilania poprzez opornik.
Sterowanie sieci źródłem prądowym pozwala na uzyskanie szybszego narastania napięcia na wyjściu, jak i bardziej kontrolowanego opadania napięcia. Dzięki temu otrzymujemy driver zapewniający o wiele lepszą a integralność sygnału.
Na rysunku 3 widzimy porównanie przebiegów na wyjściu klasycznego drivera (niebieski) i nowego, opartego na źródle prądowym (zielony) dla obciążonej sieci. Jak widać na oscylogramie nowy sterownik interfejsu zapewnia o wiele lepszą kontrolę nad zboczami jak i eliminuje drgania napięcia.
Nowa architektura drivera, zaproponowana przez TI, rozwiązuje częste problemy z interfejsami I²C, jakie obserwuje się w bardziej rozbudowanych sieciach. Wykorzystanie układów z rodziny TCA980X pozwala uprościć projektowanie jak i uruchamianie urządzeń wykorzystujących interfejs I²C.
Żródło: Link
Fajne? Ranking DIY
