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

Buduję prymitywny oscyloskop [Atmega32][Bascom]

18 Wrz 2018 15:20 765 15
  • #1 18 Wrz 2018 15:20
    2661034
    Użytkownik usunął konto  
  • #2 18 Wrz 2018 17:38
    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.

    0
  • #3 18 Wrz 2018 17:59
    2661034
    Użytkownik usunął konto  
  • #4 18 Wrz 2018 19:20
    tmf
    Moderator Mikrokontrolery Projektowanie

    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.

    0
  • #5 18 Wrz 2018 19:40
    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 :).

    0
  • #6 18 Wrz 2018 19:52
    M. S.
    Poziom 34  

    Cytat:
    921600 bodów/s


    Niezłe przyspieszenie. 921600 zmian sygnału/s^2.

    0
  • #7 18 Wrz 2018 21:28
    2661034
    Użytkownik usunął konto  
  • #8 18 Wrz 2018 21:54
    _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.

    0
  • #9 18 Wrz 2018 22:16
    tmf
    Moderator Mikrokontrolery Projektowanie

    _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.

    0
  • #10 18 Wrz 2018 22:43
    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.

    Buduję prymitywny oscyloskop [Atmega32][Bascom]

    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.
    .

    0
  • #11 19 Wrz 2018 05:51
    2661034
    Użytkownik usunął konto  
  • #12 19 Wrz 2018 08:42
    miszczo997
    Poziom 27  

    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.

    0
  • #13 19 Wrz 2018 14:41
    2661034
    Użytkownik usunął konto  
  • #14 19 Wrz 2018 17:15
    miszczo997
    Poziom 27  

    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.

    0
  • #15 19 Wrz 2018 18:47
    3227441
    Użytkownik usunął konto  
  • #16 23 Wrz 2018 19:24
    djfarad02
    Poziom 17  

    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.

    1