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

AtXmega128A1 - Podłączenie potencjometrów do ADC

KJ 13 Cze 2016 21:22 2895 32
  • #1 13 Cze 2016 21:22
    KJ
    Poziom 31  

    No więc tak - przeszukałem trochę forum trochę internetu i sensownego rozwiązania prostego i powszechnego wydawałoby się problemu nie znalazłem. Chodzi o podłączenie potencjometrów do ADC w AtXmega128A1 i generalnie wszystkich Xmegach bo po notach katalogowych patrząc wszędzie wygląda to dość podobnie. W zwykłej atmedze wszystko było jasne i oczywiste potencjometr między 0 a 5V ślizgacz do wejścia adc referencja ustawiona na AVCC i pomiar był w zakresie 0 do 1024 dla całego zakresu potencjometru od masy do VCC do tego bardzo stabilny z minimalnymi oscylacjami najmniej znaczącego bitu. W Xmedze oczywiście "poprawiono" także stary 10bitowy ADC który teraz jest 12 bitowy i pracuje w zakresie napięć wejściowych od 0,2 do sam już dobrze nie wiem ilu V bo przekopałem tyle not że zgłupiałem do reszty jednak na pewno nie jest to 3,3V tylko mniej. Jak w takim razie podłączyć potencjometry do tego cuda tak aby nie mieć żadnych martwych pól na końcach regulacji? Jedyne co mi przychodzi do głowy to zasilać potencjometr z jednej strony napięciem 0,2V z drugiej strony źródłem napięcia referencyjnego niższego od 3.3V które podłącze także do aref w xmedze - blokując przy okazji jeden z kanałów ADC. Puki co wykorzystałem te procesory w jednym projekcie i najwięcej problemów miałem właśnie z ADC gdyż za radą kolegi który podobno już tak robił i mu działało podłączyłem tradycyjnie potencjometry między masę a 3.3V. Oczywiście w praktyce nie działało bo nie miało prawa. W zasadzie to działało ale martwa strefa zaczynała się w 2/3 potencjometru a drugą miałem na dole od masy do ok 0,2V więc w sumie zostało mi niecałe 2/3 kąta obrotu gałki co było totalnie nieakceptowalne i skończyło się sporymi przeróbkami pcb. Dolnego ofsetu i tak nie udało się pozbyć a górny tylko zmniejszyłem do akceptowalnego poziomu przez wstawienie diod między 3.3V a górne zasilanie potencjometrów. W związku z czym potrzebuję sensownego rozwiązania tego problemu. Na chwilę obecną widzę dwie możliwości. Pierwsza to zasilanie potencjometrów dziwacznymi napięciami typu 0.2V i np 2,5V które trzeba jakoś uzyskać Drugie rozwiązanie to zasilić potencjometry z 5V i zastosować inny uC - np atmegę8 jako przetwornik który będzie się komunikował np po i2c z xmegą. Problem w tym że jeden zestaw potencjometrów trzeba podłączyć do kilku uC więc procesor - przetwornik musiałby być masterem na magistrali i "wpychać" cyklicznie dane do wszystkich slaveów a tych danych nie jest tak mało w funkcji czasu w sytuacji gdy mamy 8 potencjometrów i 5 slaveów i nie chcemy mieć za bardzo opóźnień. Kolejny problem którego nie potrafię rozwiązać w obecnym projekcie to niestabilność odczytu napięcia z ADC. Najmniej znaczące 2-3 bity to w zasadzie generator liczb losowych który trzeba pominąć więc zostaje rozdzielczość w najlepszym wypadku 10bit czyli taka jak w starej medze tyle że o gorszej stabilności pomiaru. Podejrzewam że problem tutaj leży po stronie nie najlepszego layoutu PCB - ścieżki biegną dość daleko przez urządzenie i blisko linii cyfrowych w dodatku każdy z 8 potencjometrów jest podłączony do pięciu uC a całe urządzenie jest rozbite na dwie płytki złączone taśmą przez którą przechodzą linie ze ślizgaczy potencjometrów i kupa innych sygnałów cyfrowych. Tak więc w tym urządzeniu już nie dam rady sprawić aby było lepiej bez przebudowy całości. Pytanie więc jak projektować aby mieć mniej problemów w nowym ?

    0 29
  • Arrow Multisolution Day
  • #2 13 Cze 2016 21:39
    2675900
    Użytkownik usunął konto  
  • #3 13 Cze 2016 22:06
    KJ
    Poziom 31  

    Płytka płytką - to można poprawić. Natomiast to czego nie można poprawić to fakt że dopuszczalny zakres napięć wejściowych dla ADC w xmedze nie jest od 0 do + zasilania jak było w zwykłej medze. Przez co nie widzę innego sposobu na otrzymanie potencjometru którego kręcenie od bandy do bandy zmienia wartość zmiennej od 0 do 4096 niż wydziwianie z napięciami zasilającymi końce tego potencjometru.

    0
  • #4 13 Cze 2016 22:13
    2675900
    Użytkownik usunął konto  
  • #5 13 Cze 2016 22:39
    KJ
    Poziom 31  

    No właśnie do VCC - delta V gdzie delta V wynosi Vref*0,05 tak przynajmniej wynika z tego dokumentu. Więc przy założeniu że Vref= 3,3V użyteczny zakres napięć dla unsigned mode (które notabene przy przywaleniu wejścia ADC do masy daje odczyt na dzień dobry 200 a nie 0) wynosi 0 do 3,14V każde napięcie powyżej 3,14V zostanie odczytane jako 4096 tak wiec aby nie mieć martwej strefy na końcu regulacji napięcie na górnym końcu potencjometru nie może wynosić 3,3 tylko musi wynosić 3,14V a wtedy i tak będę miał regulacje od 200 do 4096.

    0
  • #6 13 Cze 2016 22:46
    2675900
    Użytkownik usunął konto  
  • #7 13 Cze 2016 22:51
    KJ
    Poziom 31  

    Przeszkadza to w tym że na końcu kręcenia potencjometrem zostaje kawałek który nie powoduje już zmiany wartości bo napięcie na ślizgaczu przekracza 3,14V a wartość odczytana stoi na 4095... Sam fakt że zmienna leci od 200 do 4095 nie przeszkadza w niczym bo można sobie to 200 najnormalniej na świecie odjąć od wyniku ... Problemem jest jak już wspomniałem kilkukrotnie martwa strefa na końcu regulacji

    0
  • Arrow Multisolution Day
  • #8 13 Cze 2016 22:52
    Marek_Skalski
    Moderator Projektowanie

    Wybrałeś wyjątkowo podły układ do tego zadania. Stary, drogi, a przetwornik ma schrzaniony i tyle. Offset od dołu, który jest niestabilny. Można kalibrować, ale zabiera kawałek zakresu. Offset od góry, który jest ograniczony napięciem referencyjnym, a to nie może być wyższe niż VCC-0,6V. Kiedyś też chciałem z nich korzystać i napotkałem tę samą barierę; albo utrata części zakresu, albo referencja 2,5V. Realnie, zamiast teoretycznych 12 bitów miałem 10. Uśrednianie nie pomagało, bo nie było na to czasu.

    Piotrus_999 napisał:
    Zreszta w signed mode mozesz od zera do maks.

    Niestety nie możesz, ponieważ maksymalne napięcie przyjmowane przez ADC, to VCC-0,6V. To dla zasilania 3,3V daje tylko 2,7V. Po odjęciu dolnego offsetu, zakres przetwarzania to tylko 2,5V/3,3V czyli 76%. Błąd samego przetwornika dochodzi do 5 LSB, a szum to 2mV, więc realnie nie da się uzyskać więcej niż 10 bitów użytecznych. Jeżeli masz aplikację zasilaną niższym napięciem, to jest jeszcze gorzej. Przy 2V zostaje zaledwie 1,2V zakresu pomiarowego. Porażka.
    Ja zdecydowałem się na uC od ST. Cenowo korzystniejsze, jak potrzebuję więcej wyprowadzeń, to bez problemu dostanę, lepsze peryferia i duuużo szybsze przetwarzanie danych. Nawet bez Event system. Jak potrzebuję układ o niskim poborze mocy, to mam naprawdę niski pobór mocy, np. STM32L4xx, albo moje ulubione STM32L031.

    0
  • #9 13 Cze 2016 22:56
    KJ
    Poziom 31  

    Czyli nie tylko ja mam problem ... Wynika z tego ze sensowne rozwiązanie problemu to zewnętrzny ADC i danie sobie spokój z wewnętrznym lub faktycznie przesiadka na inną rodzinę uC. Z tego co piszesz jest jeszcze weselej z tym górnym ofsetem. To by wyjaśniało czemu miałem martwą prawie 1/3 kąta obrotu.

    0
  • #10 13 Cze 2016 23:02
    2675900
    Użytkownik usunął konto  
  • #11 13 Cze 2016 23:05
    KJ
    Poziom 31  

    Co do wykłócania się o to która rodzina uC jest lepsza - ta którą umiesz programować ... Podobnie jak język programowania najlepszy jest ten który znasz. Cena konkretnego uC przy urządzeniach budowanych w ilości 1szt nie mającej trafić do produkcji nie ma wiele do gadania - przynajmniej w moim przypadku. Co do ogarniania bądź nie ogarniania cortexów - nie każdy fascynuje się programowaniem samym w sobie:P Ja np go nie trawię - piszę bo jest mi to niezbędne do zrealizowania celów które sobie postawiłem a nie celem samym w sobie i szczerze mówiąc nie mam chęci ani czasu an wgłębianie się w bardziej skomplikowane procesory jak np. STMy czy inne ARM.

    0
  • #12 13 Cze 2016 23:15
    2675900
    Użytkownik usunął konto  
  • #13 13 Cze 2016 23:21
    KJ
    Poziom 31  

    W sumie używamy ... filozofia programowania x86 czy x64 aż tak bardzo od 8080 nie odbiega :) To że od strony rdzenia to jest w sumie arm który emuluje procek x86 czy x64 dla programisty nie ma większego znaczenia. Inna kwestia że w czasach 8080 trzeba było się naprawdę wysilić aby stworzyć funkcjonalna aplikację a dziś ? Flashplayer potrafi całkowicie zmulić na kilkadziesiąt sekund komputer o konfiguracji: Core i7 5820K/32GB ram/GF GTX980/Win7. Ale cóż taki obrano kierunek rozwoju oprogramowania.

    0
  • #14 13 Cze 2016 23:45
    2675900
    Użytkownik usunął konto  
  • #15 13 Cze 2016 23:57
    KJ
    Poziom 31  

    Co nie zmienia faktu że od powstania x86 czy x64 powstało sporo lepszych i wydajniejszych architektur a dalej używamy w większości domowych komputerów zabytku jakim jest x86/x64 którego wydajność i tak marnujemy na zasobożerne i nie wnoszące wiele nowej funkcjonalności oprogramowanie które jest bezustannie i bezskutecznie łatane w sposób który powoduje jego coraz większą zasobożerność i pogorszenie się funkcjonalności do poziomów nieraz wręcz absurdalnych ;) oraz że zrobił się mały oftop.

    0
  • #16 14 Cze 2016 07:10
    94075
    Użytkownik usunął konto  
  • Pomocny post
    #17 14 Cze 2016 09:32
    tmf
    Moderator Mikrokontrolery Projektowanie

    Niestety, jak widzę najwięcej mają do powiedzenia koledzy, którzy z tymi MCU nie mieli do czynienia. Po kolei:
    - zakres od dołu to nie +150mV, a -150mV, więc jeśli jeden koniec podłączysz do GND, to stracisz 150mV z zakresu, ale nic nie zostanie obcięte.
    - zakres od góry to Vcc-0,6V, ale to żaden problem, bo łączysz drugi koniec potencjometru do Vcc i wybierasz wzmocnienie 1/2, w efekcie masz zamiast 3,3V -> 3,3V/2. Do tego wybierasz stosowną referencję i problem znika.
    Kolejna sprawa - przeszkadza ci offset od dołu to wybierasz tryb różnicowy przetwornika. Na jedno wejście podajesz wtedy GND, obojetnie - z zewnątrz (jeśli ma być superstabilnie), lub wybierasz podanie GND z wnętrza układu, oczywiście takie GND ma mniejszą stabilność, bo nie jest filtrowane i wpływ na nie ma praca samego MCU.
    Aby uzyskać deklarowane parametry ADC należy bardzo dobrze zaprojektować PCB. W zależności od użytej XMEGA należy także przemyśleć taktowanie przetwornika (mamy na wejściu układ S&H, więc impedancja wyjścia próbkowanego sygnału nie może być zbyt duża dla wyższych częstotliwości). W niektórych XMEGA jest możliwość określenia czasu próbkowania. Pamiętać też należy o wyłączeniu buforów cyfrowych związanych z danym pinem IO i w ogóle, że sygnały w okolicy pinu ADC nie powinny się zmieniać w czasie próbkowania, a najlepiej uśpić MCU. Ale to są zasady generalne.

    0
  • Pomocny post
    #18 14 Cze 2016 18:41
    Marek_Skalski
    Moderator Projektowanie

    Pracowałem z Xmega. Kilka lat temu zbudowałem i sprzedałem kilka różnych urządzeń na specjalne zamówienie. Działają do dzisiaj. Coś tam jednak wiem o produktach Atmel'a.
    Wracając do tego nieszczęsnego ADC. Proponujesz tryb różnicowy, czyli z definicji redukujesz zakres do 11-bitów. Wybór wzmocnienia 1/2 oznacza dodatkowy błąd wzmocnienia i liniowości. Do tego nadal pozostaje problem wewnętrznych szumów i offsetu, który mocno zależy od temperatury. Realnie zamiast poprawy, jest jeszcze gorzej, bo taki przetwornik będzie miał parametry gorsze niż stara megi8 z 10-bitowym i leniwym układem. To nie jest rozwiązanie. Usypianie i ścieżki, to jak sam zauważyłeś standard i jest to już uwzględnione w parametrach podawanych przez Atmel'a. Niestety, mam gdzieś na "śmietniku" kilkanaście układów typu xmega256A3BU, albo xmega128A1U, których parametry fajnie wyglądały na papierze, ale jeżeli wskazania z ADC oscylują ±4 jednostki, to dla mnie to nie jest stabilne. Jeżeli chcę wprowadzić szum dla poprawy jakości przetwarzanie, to wprowadzam szum, o znanej mi charakterystyce, np. szum w rozkładzie Gauss'a.
    Wybacz mi proszę wątek osobisty, ale chociaż potrafię zrozumieć Twoje przywiązanie do produktów xmega, to nie potrafię zrozumieć dlaczego z takim uporem bronisz słabego ADC i próbujesz nam wszystkim wmówić, że to my nie wiemy jak z niego korzystać. Ten układ nigdy nie był dobry, nie jest i nie będzie. Może następna generacja, będzie lepsza? O ile Microchip pozwoli na następną generację, która nie ma czym konkurować z innymi produktami na rynku.

    0
  • #19 14 Cze 2016 18:59
    KJ
    Poziom 31  

    Pomiar różnicowy nie wchodzi w grę - braknie pinów :/ Ostatecznie decyduję się na nie korzystanie z wewnętrznego ADC xmegi bo tak jak się spodziewałem sensownego sposobu na jego wykorzystanie w tym przypadku niema a realne parametry rzeczywiście są gorsze od tego co można uzyskać na zwykłej atmedze. W sumie z mojego punktu widzenia i w odniesieniu do mojej aplikacji jedynym plusem xmegi okazuje się być spora ilość timerów która w zasadzie skłoniła mnie do zainteresowania się tą rodziną uC. Co do layoutu pcb - zrobiłem go z grubsza tak samo jak w innych urządzeniach wykorzystujących zwykłe atmegi nie spodziewałem się większych problemów gdyż wcześniej także ich nie miałem. Rzeczywistość okazała się jednak zdecydowanie mniej ciekawa :/

    0
  • #20 14 Cze 2016 19:45
    tmf
    Moderator Mikrokontrolery Projektowanie

    @KJ Ale do trybu różnicowego nie potrzebujesz żadnych dodatkowych pinów. To tylko zmiana konfiguracji ADC, wybierasz tryb różnicowy z wewnętrznym napięciem odniesienia. Możesz też wykorzystać klasyczny tryb, tylko wprowadzić ADC w tryb signed, dzięki czemu masz co prawda tylko 11 bitów, ale od zera, a nie od ofsetu -150mV.

    Dodano po 22 [minuty]:

    Marek_Skalski napisał:

    Wracając do tego nieszczęsnego ADC. Proponujesz tryb różnicowy, czyli z definicji redukujesz zakres do 11-bitów. Wybór wzmocnienia 1/2 oznacza dodatkowy błąd wzmocnienia i liniowości.


    Po pierwsze 11 bitów do odczytu pozycji potencjometru to chyba aż nadto. Chyba, że autor ma superprecyzyjny potencjometr wieloobrotowy. Druga sprawa, to jeśli to tylko odczyt potencjometru, to niech sobie składa i 64k pomiarów, uzyska dodatkowe teoretyczne 8 bitów rozdzielczości :) To żart, jakby ktoś nie załapał.
    Wybór wzmocnienia 1/2 oznacza wg noty błąd wzmocnienia <1% (dla wzmocnień do 64 razy) i błąd ofsetu <1mV. Doprawdy tragiczne parametry... Warto też wspomnieć, że XMEGA ma sprzętową kalibrację ofsetu i błędu nieliniowości dla przetwornika, więc jeśli ktoś potrzebuje superdokładnych pomiarów to można sobie ADC dodatkowo skalibrować. Szumy dla tego układu to całe 120uV przy korzystaniu z wewnętrznej referencji i aż 60 uV przy korzystaniu z zewnętrznego napięcia referencyjnego.

    Marek_Skalski napisał:
    Do tego nadal pozostaje problem wewnętrznych szumów i offsetu, który mocno zależy od temperatury. Realnie zamiast poprawy, jest jeszcze gorzej, bo taki przetwornik będzie miał parametry gorsze niż stara megi8 z 10-bitowym i leniwym układem.


    Przepraszam Marku, ale piszesz jakieś rzeczy wyssane z palca. Zajrzyj proszę do noty. Pierwsze egzemplarze XMEGA A1 miały istotnie kłopoty z ADC, ale od kilku lat nie ma ich na rynku...

    Marek_Skalski napisał:
    To nie jest rozwiązanie. Usypianie i ścieżki, to jak sam zauważyłeś standard i jest to już uwzględnione w parametrach podawanych przez Atmel'a. Niestety, mam gdzieś na "śmietniku" kilkanaście układów typu xmega256A3BU, albo xmega128A1U, których parametry fajnie wyglądały na papierze, ale jeżeli wskazania z ADC oscylują ±4 jednostki, to dla mnie to nie jest stabilne.


    Nawet jeśli byłoby to +/-4 LSB (w nocie do układu w erracie jest napisane, że mamy +/-2 LSB to i tak nie byłoby przecież źle, szczególnie jeśli mierzymy napiecie z potencjometru. Ok, 4 LSB oznacza efektywnie 10-bitowy ADC. Tylko, że mamy pasmo 2 Msps, a ATMega 8 dla 1 Msps ma 8-bitów max, bardziej prawdopodobne jest max 6-7 bitów rozdzielczości. Więc istotnie ADC XMEGI jest tragiczny...

    Marek_Skalski napisał:
    Wybacz mi proszę wątek osobisty, ale chociaż potrafię zrozumieć Twoje przywiązanie do produktów xmega, to nie potrafię zrozumieć dlaczego z takim uporem bronisz słabego ADC i próbujesz nam wszystkim wmówić, że to my nie wiemy jak z niego korzystać.


    Po pierwsze nie bronię, tylko piszę jak jest. Przeczytaj proszę ten wątek od początku i bzdurne informacje o ADC jakie w nim padły. Proszę zachowaj chociaż trochę obiektywizmu.
    Wiele STM nie ma nawet wyprowadzonego VRef, ale to oczywiście oznaka doskonałego ADC...

    0
  • #21 14 Cze 2016 21:04
    94075
    Użytkownik usunął konto  
  • #22 14 Cze 2016 21:06
    jnk0le
    Poziom 18  

    Sporo zależy od rewizji układu. W odświeżonej serii z USB również sporo poprawili w tej kwestii.

    Cytat:
    36.
    Errata
    36.1 ATxmega64A1and ATxmega128A1 rev. H

    - Bandgap voltage input for the ACs can not be changed when used for both ACs simultaneously
    - VCC voltage scaler for AC is non-linear
    - The ADC has up to ±2 LSB inaccuracy
    - ADC gain stage output range is limited to 2.4 V
    - Sampling speed limited to 500 ksps for supply voltage below 2.0V
    - ADC Event on compare match non-functional
    - Bandgap measurement with the ADC is non-functional when VCC is below 2.7V
    - Accuracy lost on first three samples after switching input to ADC gain stage
    - The input difference between two succeeding ADC samples is limited by VREF
    - Increased noise when using internal 1.0V reference at low temperature

    0
  • #23 14 Cze 2016 21:09
    2675900
    Użytkownik usunął konto  
  • #24 15 Cze 2016 11:40
    deus.ex.machina
    Poziom 32  

    IMHO szkoda ADC do odczytu położenia potencjometru - kiedyś sprawę odczytu potencjometru załatwiało się prosta konwersja R->t - wystarczy sprawdzić jak zrobiona jest obsługa joysticka analogowego w starych PC.

    0
  • #25 15 Cze 2016 12:00
    tmf
    Moderator Mikrokontrolery Projektowanie

    @deus.ex.machina Ale po co sobie komplkować życie, skoro na pokładzie są dostępne dwa oddzielne ADC, każdy z 8-krotnym multiplekserem analogowym? No i w dodatku autor jakoś nie ma chyba innych potrzeb związanych z ADC?

    0
  • #26 15 Cze 2016 13:37
    deus.ex.machina
    Poziom 32  

    tmf napisał:
    @deus.ex.machina Ale po co sobie komplkować życie, skoro na pokładzie są dostępne dwa oddzielne ADC, każdy z 8-krotnym multiplekserem analogowym? No i w dodatku autor jakoś nie ma chyba innych potrzeb związanych z ADC?


    Jak widać po wątku nie jest to takie oczywiste... jak to mówią kto bogatemu zabroni?

    0
  • #27 15 Cze 2016 13:44
    KJ
    Poziom 31  

    Nie ma innego zapotrzebowania na kanały ADC za to jest spore na piny I/O więc piny adc i tak były by zajęte czymś innym. Do tego do pomiaru wypełnienia albo częstotliwości potrzeba timerów które są dla mnie bardziej cenne niż wejścia ADC. Bogatemu nikt nie zabroni ale nie wydaje mi się żeby 10 czy 12 generatorów a'la gameport w PC wyszło taniej niż procesor z ADC nadającym się do czytania tych potencjometrów bezpośrednio - nie te czasy nie ta technologia... że już nie wspomnę o komplikacji układu.

    0
  • #28 15 Cze 2016 14:39
    deus.ex.machina
    Poziom 32  

    KJ napisał:
    Nie ma innego zapotrzebowania na kanały ADC za to jest spore na piny I/O więc piny adc i tak były by zajęte czymś innym. Do tego do pomiaru wypełnienia albo częstotliwości potrzeba timerów które są dla mnie bardziej cenne niż wejścia ADC. Bogatemu nikt nie zabroni ale nie wydaje mi się żeby 10 czy 12 generatorów a'la gameport w PC wyszło taniej niż procesor z ADC nadającym się do czytania tych potencjometrów bezpośrednio - nie te czasy nie ta technologia... że już nie wspomnę o komplikacji układu.


    Jak już napisałem - kiedyś było inaczej i robiono to inaczej - dziś jest inaczej i stad takie watki jak ten.

    Co do do twoich problemów ja spróbowałbym je rozwiązać tak:

    PWM DAC (sprzętowy, soft), filtr RC. Takim napięciem zasilić wszystkie potencjometry (po prostu budujesz sobie własny programowalny Uref).
    Odczyt z potencjometrów, na linie wejściowe ADC dać kondensatorki (22 - 47n) by odfiltrować śmieci i ustabilizować odczyt (nie wiem jaka masz rezystancje tych potencjometrów i jak dużą możesz mieć zwłokę - myślę ze w wypadku potencjometrów więcej niż 100 odczytów (użytecznych) na sekundę nie ma sensu). Nie wiem jakie masz przerwanie w systemie ale zwyczajnie robiłbym kilka odczytów (4 - 16) wynik dzielił bez reszty do jakiejś sensownej skali jeśli wystarczy 8 bitów to jak myślę pozbędziesz się wszystkich problemów z niestabilnością LSB).
    Offset możesz stworzyć na jakimś LED (maja niezłą stabilność temperaturowa) i dzielniku.

    0
  • #29 30 Sie 2016 02:03
    KJ
    Poziom 31  

    Z tego co widzę jedynym sensownym wyjściem jest podłączenie zewnętrznego ADC o sensownych parametrach. Żadna z podanych tutaj metod nie poprawiła stabilności odczytów na tyle aby to było wyraźnie odczuwalne. Ofsetu od dołu zlikwidować się w prosty sposób nie da przy obecnej formie urządzenia więc pozostało mi pogodzić się z tym faktem. Odczyty dalej mają niestabilność na poziomie 4-5 bitów. Wynika to albo ze złego projektu płytki albo z faktu że ten nieszczęsny adc w xmedze po prostu taki jest. Znalazłem kilka artykułów w sieci gdzie opisywano podobny problem - szczególnie godny uwagi jest ten: Link. Autor opisuje podobny problem wraz z możliwymi rozwiązaniami. Jednak zastosowanie się do nich niewiele zmieniło. Ostatecznie podjąłem decyzję o przeprojektowaniu urządzenia na zewnętrzny ADC. Oraz o nie korzystaniu z przetwornika w xmegach w przyszłych projektach.

    0
  • #30 30 Sie 2016 08:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    @KJ Artykuł który linkujesz odnosi się do pierwszych wersji XMEGA128A1, które miały problemy z ADC, które zostały wyeliminowane w kolejnych rewizjach układu. Zobacz w notach sekcję opisującą błędy.Tak jak pisałem offset od dołu eliminuje się w prosty sposób, przy pomocy multipleksera - programowo łączysz wejście ADC z masą i mierzysz ofset, który potem odejmujesz od pomiarów, lub przełączasz ADC w tryb różnicowy (z wewnętrznym odniesieniem) - masz wtedy "tylko"" 11 bitów, ale nie ma ofsetu. Jeśli wyniki ci skaczą o 4-5 bitów to zdecydowanie masz skaszaniony projekt płytki lub pomiar ADC. Dodanie zewnętrznego ADC tego nie poprawi, bo kaszana jak była tak będzie.

    0