logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak usprawnić program oscyloskopu na Atmega32 do przesyłu danych do PC?

18 Wrz 2018 15:20 1269 15
  • #1 17447136
    Konto nie istnieje
    Konto nie istnieje  
  • #2 17447350
    wozniakoss
    Poziom 12  
    Aby przyspieszyć komunikację po uarcie:
    - włącz bit u2x w rejestrze ucsra
    - przesyłaj dane w formacie Hex a nie bin.
    Zmniejszysz ilość przesyłanych znaków.

    Aby przyspieszyć działanie programu:
    - przenieś konwersję adc na przerwania.
    W momencie oczekiwania na koniec konwersji będziesz wysyłać dane po uarcie.
    Mam nadzieję że pomogłem.
  • #3 17447383
    Konto nie istnieje
    Konto nie istnieje  
  • #4 17447537
    tmf
    VIP Zasłużony dla elektroda
    wozniakoss napisał:
    Aby przyspieszyć komunikację po uarcie:
    - włącz bit u2x w rejestrze ucsra
    - przesyłaj dane w formacie Hex a nie bin.


    Ta ostatnia porada raczej nie za bardzo przyśpieszy komunikację. W 1 bajt to 1 bajt, w hex, to już 2 bajty...
    wozniakoss napisał:
    Aby przyspieszyć działanie programu:
    - przenieś konwersję adc na przerwania.

    Niekoniecznie to przyśpieszy. Trzeba dobrze przemyśleć przerwanie. ADC może samplować nawet 1 Msps (przy ograniczeniu rozdzielczości do 7-8 bitów, co jest wystarczające dla takiego oscyloskopu). A więc przerwanie będzie co 16 taktów MCU. Biorąc pod uwagę samo wejście i wyjście z przerwania mamy już 5-6 taktów. Aby się wyrobić trzeba to napisać w asemblerze. Przy niższym taktowaniu ADC będzie łatawiej, ale też niesądzę aby Bascom się wyrobił.
    Ogólnie jak sądzę dosyć wąskim gardłem jest bascom. Obsługę UART dla maksymalnego przyśpieszenia należałoby też sensownie napisać, tak, aby bufor nadajnika zawsze był pełny.
  • #5 17447594
    wozniakoss
    Poziom 12  
    Cytat:
    .Ta ostatnia porada raczej nie za bardzo przyśpieszy komunikację. W 1 bajt to 1 bajt, w hex, to już 2 bajty...

    Racja, pomyliło mi się to z różnicą między Dec, a Hex,. Ale rzeczywiście najszybciej jest binarnie. Mój błąd, biję się w pierś.

    A tu wąskim gardłem jest póki co prędkość uartu i sposób jego obsługi.
    Jak autor tematu dojdzie do sensownej implementacji komunikacji to wtedy można myśleć o zmianie języka, co polecam jako dalszy krok nauki :).
  • #7 17447896
    Konto nie istnieje
    Konto nie istnieje  
  • #8 17447963
    _lazor_
    Moderator Projektowanie
    Nie wiem jak bardzo złożone ma peryferia atmega32, ale chyba DMA ma z wsparciem dla ADC. Jeśli posiada DMA to warto skonfigurować DMA w taki sposób by dane z ADC przesyłał do RAM, ale na pewno przerwania nie będą optymalne.
    Dlaczego przerwania nie będą optymalne? Gdyż wymagają przełączenia kontekstu (context switch), co kosztuje sporo cykli (około 12 z tego co znalazłem), a DMA chociaż wywłaszcza szynę danych to nie powoduje zmiany kontekstu.
  • #9 17448017
    tmf
    VIP Zasłużony dla elektroda
    _lazor_ napisał:
    Nie wiem jak bardzo złożone ma peryferia atmega32, ale chyba DMA ma z wsparciem dla ADC. Jeśli posiada DMA to warto skonfigurować DMA w taki sposób by dane z ADC przesyłał do RAM, ale na pewno przerwania nie będą optymalne.

    ATMega nie ma DMA, niestety. Z AVR DMA mają tylko XMEGA.
    _lazor_ napisał:
    Dlaczego przerwania nie będą optymalne? Gdyż wymagają przełączenia kontekstu (context switch), co kosztuje sporo cykli (około 12 z tego co znalazłem), a DMA chociaż wywłaszcza szynę danych to nie powoduje zmiany kontekstu.

    Mniej, to ok. 5-6 cykli (łącznie z wyjściem z ISR). Niemniej i tak jest na styk, jeśli chcemy wycisnąć pełnię możliwości z ADC.
  • #10 17448062
    trol.six
    Poziom 31  
    Z mojej praktyki, granicą mozliwości jest 250k sampli/sek. W zależności od egzemplarza, czasem jest lepiej czasem gorzej. Zauważyłem też, że czasem jest lekka poprawa wraz z czasem samplowania. Można skorzystać z "Auto Triggered" co daje aż ;) 2 cykle samplowania zamiast 1,5 cykla.

    Po wyłączeniu przetwornika czas pierwszej konwersji to 13 cykli. Tutaj taki mały test jaki kiedyś zrobiłem.

    Jak usprawnić program oscyloskopu na Atmega32 do przesyłu danych do PC?

    Z tym że uwaga, przy czasie próbkowania 13 zegar ADC jest ten sam co przy 1,5 oraz 400k sampli. Widać że przebieg 200k jest lepszej jakości, gdzie czas próbkowania to 1,5 cykla.

    Bufor jest przydatny jeśli transfer ciągły się nie wyrabia.
    .
  • #11 17448322
    Konto nie istnieje
    Konto nie istnieje  
  • #12 17448464
    miszczo997
    Poziom 28  
    tmf napisał:
    Trzeba dobrze przemyśleć przerwanie. ADC może samplować nawet 1 Msps (przy ograniczeniu rozdzielczości do 7-8 bitów, co jest wystarczające dla takiego oscyloskopu). A więc przerwanie będzie co 16 taktów MCU

    Samplować, czy taktować?
    goreckidiy napisał:
    14,745 600MHz

    Skoro chcesz wyciągnąć jak najwięcej z tej atmegi to zmieniłbym kwarc na 20Mhz, albo i większy.
  • #13 17449010
    Konto nie istnieje
    Konto nie istnieje  
  • #14 17449233
    miszczo997
    Poziom 28  
    Ja to widzę tak:
    1.Przykładowo ustawiasz taktowanie przetwornika na 1MHz co da około 76ksps(1MHz/13) i jest to maksymalna ilość sampli jaką możesz uzyskać. Czas pojedynczej konwersu wynosi 1/76000=~13,15us. Tryb free run.
    2. Uruchamiasz timer, który w przerwaniu będzie odczytywał wartość konwersji. Przerwanie musi wywoływać się w odstępach dłuższych niż wyznaczone wcześniej 13us tak, aby dać przetwornikowi czas na dokonanie pomiaru. Górnej granicy tego czasu nie ma. W ten sposób zrealizujesz dowolną podstawę czasu jak w oscyloskopach, czyli np 10us,20us,50us,100us etc. Ilość taktów dostępnych dla tego przerwania (przy maksymalnym samplowaniu) w Twoim przypadku wynosi 14,75*13=~191 taktów zegara. Powinno na spokojnie wystarczyć.
    3. Zbieranie każdej ramki zaczynasz od odrzucenia pierwszego wyniku pomiaru, dopiero kolejne 1024 wartości będą zebrane w identycznych odstępach czasu.
    4. Po zebraniu całej tablicy próbek wyłączasz przerwanie od timera i wysyłasz zebrane dane przez uart.

    Tutaj rzeczywiście kwarc 20MHz dużo nie da. Sens miałoby to wtedy, gdybyś kreślił od razu wykres wyświetlaczu.
    goreckidiy napisał:
    Chcę uzyskać 1MHz

    Taktowanie przetwornika 1MHz, czy samplowanie 1MSPS? Tego drugiego nie osiągniesz, bo musiałbyś taktować przetwornik z częstotliwością 13MHz. Wyżej policzyłem ile maksymalnie można wyciągnąć z tego przetwornika(wg dokumentacji).
    goreckidiy napisał:
    ogranicza mnie bardziej czas konwersji lub zapisu do pamięci RAM.
    Czas zapisu do pamięci ram jest pomijalnie krótki.
    goreckidiy napisał:
    UART z prędkością 921600 bodów/s.

    Szacując, przy prędkości 921600 jesteś w stanie wysłać maksymalnie około 100 000 bajtów danych w ciągu sekundy, czyli ~100 ramek z wynikami konwersji. Czas zebrania 1 bufora to 1024*13us= ~13,3ms. Oznacza to, że w ciągu sekundy jesteś w stanie zebrać ~75 buforów, a przez uart wysłać 100. Dlatego też nie widziałeś różnicy pomiędzy buforowaniem danych, a ich bezpośrednim wysyłaniem.
    Możesz próbować zwiększyć taktowanie przetwornika, ale obawiam się, że granica jego możliwości jest już blisko.
    Możesz też poczytać o próbkowaniu w czasie ekwiwalentnym, ale wtedy potrzebujesz zaimplementować jakieś wyzwalanie pomiaru.
  • #15 17449390
    Konto nie istnieje
    Konto nie istnieje  
  • #16 17456772
    djfarad02
    Poziom 19  
    Pinczaiewicz napisał:
    Niektóre nowsze FTDI mogą pracować po stronie UART nawet i 3MB/s ale czy USB wyrobi?

    oryginał FT232 2MB/s wyrabia spokojnie (sprawdzone) i USB również się wyrabia, przy ciągłym strumieniu nadchodzącym z uartu. 3MB/s raczej też, ale nie jestem pewien czy na pewno sprawdzałem dla tej prędkości.
REKLAMA