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

Wspólny projekt generatora DDS na elektroda.pl

gdL 09 Lut 2019 18:19 7404 159
  • #31 09 Lut 2019 18:19
    krisRaba
    Poziom 26  

    And! napisał:
    Ważne aby zbadać jakie są oczekiwania co do takiego generatora DDS i spróbować je wspólnie spełnić.
    Spróbujmy dostarczyć do sklepiku elektroda.pl coś "eleganckiego".

    Ja chętnie bym przytulił coś niewielkiego, zasilanego bateryjnie lub z li-ion, generacja sinus, trójkąt, prostokąt z zadanym wypełnieniem, może przemiatanie częstotliwości ze stałą amplitudą oraz zmiana wypełnienia prostokąta od początkowego do końcowego w zadanym czasie. Nie musi być to przyrząd wzorcowy ;) Do tego mam klocki biurkowe...

    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • Texa Poland
  • #32 09 Lut 2019 18:27
    khoam
    Poziom 23  

    piotrva napisał:
    Poza tym, żeby to zrobić dobrze potrzeba DMA. Jakoś nie kojarzę w Arduino jednolitego wsparcia dla DMA...

    W Arduino HAL nie ma wsparcia dla DMA, ale są odpowiednie biblioteki np. dla platformy Arduino Zero.
    Nie bardzo rozumiem konieczności użycia DMA w tym projekcie. Zakładam, że jest to projekt amatorski, do samodzielnego wykonania, który nie będzie seryjnie sprzedawany i nie będzie musiał konkurować na rynku z innymi komercyjnymi produktami.

    Dodano po 1 [minuty]:

    gdL napisał:
    FastGPIO, dzięki Nie wiem jak z kompatybilnością pod innymi platformami sprzętowymi - działa np. dla ESP32? Bo w sumie to dla Atmega da się to też zrobić bezpośrednio.

    Tak, jak pisałem to biblioteka tylko dla AVR. Nie sądzę, aby było potrzebne coś takiego dla ESP32.

    Dodano po 3 [minuty]:

    gdL napisał:
    99% czasu na nie-generowanie sygnału zjada niestety obsługa wyświetlacza.

    Przepraszam, mógłbyś wyjaśnić dlaczego tak się dzieje? Jest to dla mnie jakieś nieporozumienie.

  • #33 09 Lut 2019 18:36
    gdL
    Poziom 27  

    khoam napisał:

    Przepraszam, mógłbyś wyjaśnić dlaczego tak się dzieje? Jest to dla mnie jakieś nieporozumienie.


    Odświeżanie LCD działa tylko przy zmianie wyświetlanych parametrów, dlatego jeśli urządzenie jest zostawione samo sobie, to generuje czysty przebieg. Ale jak użytkownik coś zmienia, to update LCD zajmuje chwilę. Wtedy urządzenie nie generuje sygnału, tylko wykonuje procedury obsługi LCD (w przerwaniu).
    Pewnie możnaby zbudować bardziej ekonomiczne funkcje obsługi wyświetlania, np. oparte o timery bez delay. No ale korzystam tu z wbudowanych bibliotek ARDUINO.
    Czy masz pomysł jak to poprawić?

  • #34 09 Lut 2019 18:37
    TechEkspert
    Redaktor

    gdL napisał:
    1MSPS to 10^6 próbek na sekundę. Jak policzę ile daje mi ATMEGA w projekcie to 13 próbek na 100kHz, jakieś 1.3MSPS, czy to możliwe? Jeśli tak, to nie jest najgorzej, tylko jak wspominacie dokładność drabinki nie jest za wielka. A gdyby zastosować tam bardziej precyzyjne rezystory, np 0.1%?
    Zewnętrzny DAC pewnie by wymagał szybkiej szyny, zgaduję, że bez STM32 lub ESP32 nie da rady. Ale na ESP32 dałoby się zrobić rysowanie próbek w przeglądarce oraz inne funkcje 'smart' i to mi się nawet podoba.


    Jeżeli dobrze policzyłeś ilość sampli to jest to możliwe, zoptymalizowane "walenie" stanami logicznymi po porcie mikrokontrolera ATmega może być całkiem wydajne, problemem pozostaje liniowość takiego DAC, oraz gorsze wsparcie dla mechanizmów DMA itp.

    Taktujesz mikrokontroler 20MHz, otrzymujesz 1.3MSPS, jeśli dobrze liczę to pobranie wartości z pamięci, oraz wystawienie na port + pozostałe procedury obsługi generowania kolejnych sampli zajmują jakieś 769ns czyli jakieś 154 takty mikrokontrolera.

  • #35 09 Lut 2019 19:10
    khoam
    Poziom 23  

    gdL napisał:
    Wtedy urządzenie nie generuje sygnału, tylko wykonuje procedury obsługi LCD (w przerwaniu).
    Pewnie można by zbudować bardziej ekonomiczne funkcje obsługi wyświetlania, np. oparte o timery bez delay. No ale korzystam tu z wbudowanych bibliotek ARDUINO.

    Nie wiem dlaczego w przerwaniu obsługujesz wyświetlacz, ale na pewno jego działanie nie może mieć wpływu na blokowanie tych funkcji, które są z punktu widzenia urządzenia ważniejsze.

    Jeżeli obsługa wyświetlacza następuje tylko w wypadku zmiany wyświetlanych parametrów (i bardzo dobrze) to nie potrzeba moim zdaniem do tego przerwań. To musi być tylko jakaś funkcja w pętli loop(), która uruchomi się po spełnieniu określonych warunków - co najważniejsze funkcja ta nie powinna blokować przerwań. Zakładam, że to właśnie w przerwaniach będzie kontrolowany sygnał wyjściowy z DDS.

    Jest bardzo wiele bibliotek Arduino do obsługi wyświetlacza LCD :)

  • #36 09 Lut 2019 19:23
    gdL
    Poziom 27  

    khoam napisał:

    Nie wiem dlaczego w przerwaniu obsługujesz wyświetlacz, ale na pewno jego działanie nie może mieć wpływu na blokowanie tych funkcji, które są z punktu widzenia urządzenia ważniejsze.

    Jeżeli obsługa wyświetlacza następuje tylko w wypadku zmiany wyświetlanych parametrów (i bardzo dobrze) to nie potrzeba moim zdaniem do tego przerwań. To musi być tylko jakaś funkcja w pętli loop(), która uruchomi się po spełnieniu określonych warunków - co najważniejsze funkcja ta nie powinna blokować przerwań. Zakładam, że to właśnie w przerwaniach będzie kontrolowany sygnał wyjściowy z DDS.

    Jest bardzo wiele bibliotek Arduino do obsługi wyświetlacza LCD :)


    W zasadzie to próbowałem Twojego podejścia ze sprawdzaniem flagi czy wyświetlacz wymaga odświeżania, ale sam fakt sprawdzania tej flagi powodował dramatyczne zniekształcenie przebiegu i - niestety - były to zniekształcenia ustawiczne, a nie tylko podczas interakcji użytkownika z urządzeniem. Zrezygnowałem z tego podejścia na rzecz rozwiązania szybszego i dającego optymalne rezultaty.
    Przebieg jest generowany cały czas w głównej pętli, a wszystkie pozostałe elementy są obsługiwane w jak najkrótszych przerwaniach. Najdłuższym przerwaniem jest niestety czekanie na obsługę LCD i to powoduje największe zniekształcenia sygnału.

    Jeśli chodzi o biblioteki obsługi wyświetlacza, znalazłem taką. Jest znacznie szybsza o standardowej, ale w warunkach DDS i tak będzie powodować duuże zniekształcenia.

    +++ FPS TEST +++++++++++++++++++++++++++++++++++++++++++++++++++++

    LiquidCrystal (classic) : 72,37fps
    LiquidCrystal (francesco malpartida): 287,85fps
    LiquidCrystalNew (this library) : 383fps best result

  • Texa Poland
  • #37 09 Lut 2019 19:35
    khoam
    Poziom 23  

    gdL napisał:
    W zasadzie to próbowałem Twojego podejścia ze sprawdzaniem flagi czy wyświetlacz wymaga odświeżania, ale sam fakt sprawdzania tej flagi powodował dramatyczne zniekształcenie przebiegu i - niestety - były to zniekształcenia ustawiczne

    Wszystko zależy od tego, jak to robisz. Flaga taka powinna być ustawiana tylko przez te zadania (np. działające w przerwaniach), które żądają zmiany wyświetlanych parametrów, ponieważ wiedzą, że takie parametry się zmieniły. Każdorazowe sprawdzanie, czy zachodzi konieczność zmiany wyświetlanych parametrów może być faktycznie czasochłonne i zupełnie niepotrzebne.

    gdL napisał:
    Jeśli chodzi o biblioteki obsługi wyświetlacza, znalazłem taką. Jest znacznie szybsza o standardowej,

    Znam tę bibliotekę. Bardzo rozbudowana i uniwersalna, do projektów na płytce stykowej świetnie się nadaje :) Nie użyję jej w żadnym projekcie.
    Rozważ ewentualnie zastosowanie wyświetlacza z I2C.

  • #38 09 Lut 2019 19:46
    gdL
    Poziom 27  

    khoam napisał:

    Wszystko zależy od tego, jak to robisz. Flaga taka powinna być ustawiana tylko przez te zadania (np. działające w przerwaniach), które żądają zmiany wyświetlanych parametrów, ponieważ wiedzą, że takie parametry się zmieniły. Każdorazowe sprawdzanie, czy zachodzi konieczność zmiany wyświetlanych parametrów może być faktycznie czasochłonne i zupełnie niepotrzebne.


    Chodziło mi o to, że samo sprawdzanie tej flagi w prostym warunku lub nawet rzadko z timera zniekształca generowany przebieg. Pomijając już fakt i okoliczności jej ustawiania.
    Możnaby to robić każdorazowo w pętli bez optymalizacji, ale niestety wtedy zakończy się to znacznym obniżeniem ilości próbek na sekundę, czyli pogorszy szybkość generatora. DDS jest niestety bardzo wymagające.

  • #39 09 Lut 2019 20:04
    khoam
    Poziom 23  

    gdL napisał:
    Jeśli chodzi o biblioteki obsługi wyświetlacza, znalazłem taką.

    Przypomniała mi się jeszcze jedna istotna rzecz: funkcje clear() oraz home() dla LCD są bardzo czasochłonne, zajmuje ponad 2ms, czyli całą wieczność :) W bibliotece, którą wskazałeś ten czas określony jest na min. 2900 mikrosekund.

    gdL napisał:
    Chodziło mi o to, że samo sprawdzanie tej flagi w prostym warunku lub nawet rzadko z timera zniekształca generowany przebieg.

    A czy kontrola tego generowanego przebiegu jest wykonywana w przerwaniach?

  • #40 09 Lut 2019 20:26
    piotrva
    Moderator na urlopie...

    Na razie bez opisu dzielę się swoim DDS, który powstał w przeciągu 90 minut zajęć w czasie studiów.
    https://gitlab.com/piotrva/stm32-dds
    Wspólny projekt generatora DDS na elektroda.pl

    Częstotliwości 10Hz - 100kHz, sinus, piła, trójkąt, prostokąt
    Regulacja cyfrowa amplitudy i offsetu (w zakresie pracy DAC)
    Próbki 8-bit, podstawowo 256 próbek na okres, dla wyższych częstotliwości próbki są powielane w buforze generatora (wtedy w 256 próbkach mieszczone są np. 2 lub 4 okresy, nieużywane próbki podlegają decymacji).
    Transfer między pamięcią RAM a DAC za pomocą DMA.

  • #41 09 Lut 2019 22:11
    And!
    Admin grupy Projektowanie

    Ten temat mnie zaskakuje, najpierw okazuje się, że ATmega Arduino i przetwornik 2R2 osiąga więcej sampli na sekundę niż STM z wbudowanym DAC 1MSPS, a później pojawia się kolejny projekt na STM+TFT.

    @piotrva czym się różni gitlab od github?

    Co do obsługi LCD na HD44780, zatrzymanie programu piszącego do LCD (przez przerwanie) nie powinno zakłócić treści obrazu,
    taki wyświetlacz przyjmuje komendy zarówno z szybkością 1 na sekundę, jak i 1000 na sekundę.

    Chyba pora na ankietę oczekiwań, jakie informacje można zebrać?
    -przedział cenowy
    -zakres częstotliwości
    -rozdzielczość DAC
    -rodzaj wyświetlacza
    -funkcje
    ?

    Ankiety googlowe sprawdziły się temacie DSO:
    https://docs.google.com/forms/d/e/1FAIpQLSfDl...ilyQ-BmqiCN_uojti5gE7-WjDYbC0y88QnHg/viewform
    https://docs.google.com/forms/d/e/1FAIpQLSfDl...BmqiCN_uojti5gE7-WjDYbC0y88QnHg/viewanalytics

  • #42 09 Lut 2019 22:59
    piotrva
    Moderator na urlopie...

    No fakt, że udało się wyciągnąć więcej sampli na sekundę i de facto gdyby podać to na DAC z wejściem równoległym to już byłby efekt porównywalny z moim pod względem parametrów napięciowych i lepszy pod względem prędkości.

    Co do gitlab vs github - są to dwie alternatywy serwerów, ja korzystam z pierwszej z nich, gdyż można tworzyć bez ograniczeń repozytoria prywatne, czyli takie do których dostęp mają tylko autoryzowaniu współtwórcy. Inne serwisy tej klasy (github, bitbucket) ograniczają tę funkcję.

    Ale idąc dalej tą drogą - zastanawiam się ile udałoby się osiągnąć machając pinami STM32 za pomocą DMA. Z racji architektury 32-bitowej bez problemu można by wypychać dowolnie szerokie dane (dowolnie bo 32-bitowe przetworniki to chyba fikcja xd).

  • #43 09 Lut 2019 23:13
    Janusz_kk
    Poziom 18  

    Trzymacie sie tak kurczowo atmeg przez arduino ale one są starawe, akurat do generatora lepsza byłaby atxmega64A3U która ma
    dwa DAC-i 12bit 1 Ms i ma 2 ADC 12bit 2Ms czyli mozna na tym zrobić i generator i minioscyl, ma DMA, zegar 32Mhz i da się
    polutować. ADC ma przełączalny wzm różnicowy od1/2x do 64x. Więc to co robiłeś na zwykłej medze z opornikami tu zrobisz duzo lepiej i z lepszymi parametrami.

  • #45 09 Lut 2019 23:23
    Janusz_kk
    Poziom 18  

    Za 14 zł w tme jest ATXMEGA32A4U-AU z 1 przetw ADC i dwoma DAC tak jak wyżej pisałem.
    No i juz nie dwa razy droższa :)

  • #47 09 Lut 2019 23:28
    khoam
    Poziom 23  

    Janusz_kk napisał:
    Za 14 zł w tme jest ATXMEGA32A4U-AU z 1 przetw ADC i dwoma DAC tak jak wyżej pisałem.


    Jest nawet Arduino HAL dla tego procesora :)
    Link

  • #48 10 Lut 2019 00:15
    rb401
    Poziom 34  

    piotrva napisał:
    1. Zrezygnować z Arduino zupełnie. Mnie osobiście to odstrasza (podobnie jak przedmówcę). BluePill (którą to płytkę bardzo lubię) nie ma DAC'a. Najlepiej wejść w STM32 product selector i poszukać wśród dostępnych modeli w tabeli parametrycznej te z DAC a potem sprawdzić ich dostępność i ceny w sklepach. Przykładowy uC spełniający minimalne wymagania podałem pare postów wyżej.

    2. STM32F051K4T6, ewentualnie z tej samej serii (STM32F051K4..) w innych obudowach, np. w QFN są jeszcze tańsze


    Moim zdaniem godnym uwagi do tego projektu (przynajmniej do wersji budżetowej, amatorskiej jaką proponuje autor wątku) jest STM32F100R6T6, dostępny od ręki za ~4zł (plus wysyłka ale pojedyncze sztuki można zwykłym listem dostać).
    Jest to co prawda najwolniejszy z STM32 z mizerną pamięcią, za to z podwójnym DAC. Zaryzykuję stwierdzenie że to najtańszy (w ilościach od sztuki) STM32 z DAC.
    Ale i tak przebija we wszystkim ATMEGA jeśli przyjąć ją za poziom odniesienia osiągów tego projektu.
    Istnieje też do tego konkretnie procesora biblioteka do mbed, tak że wysokopoziomowe sprawy, obsługa wyświetlacza, enkodera, strumienia po RSie itp. mogły by używać gotowców z tego środowiska. Co ułatwiło by mniej biegłym w programowaniu modyfikacje kodu, jakieś np. zmiany typu wyświetlacza, dodanie bajerów itp. .
    A sprawa samego generowania przebiegów, to już klasyczna "kręcioła" timer, dma, dac jaką np. Ty zastosowałeś w projekcie, który tu pokazałeś.
    Użycie mbed (w sensie OS2 nie wersji CLI) ma też tą zaletę że jeśli projekt ma być wspólny to bardzo prosto się to na mbed robi, może dużo prościej niż na github a dodatkowo nie potrzeba nawet mieć kompilatora u siebie.

    Tak teraz widzę że dołączenie tej ciekawej cenowo kostki STM32F100R6T6 do środowiska Arduino nie jest trudne do zrobienia, bo metodologia jest opisana w projekcie stm32duino. Wygląda na to że w Arduino przeportowanie z ATmegi na ten STM32 może być prostsze niż się by wydawało.

  • #49 10 Lut 2019 08:26
    drobok
    Poziom 29  

    Jak już chcecie iść po kosztach to stm32f105 ma więcej pamięci i da się go kupić za 12zł, do tego jakiś opamp drobnica i byłby jako taki generator na bardzo niską częstotliwość / z b. małym próbkowaniem.
    Co do bazowego kodu. Ci co się znają napiszą sterowniki a mniej rozgarnięci w programowaniu niskopoziomowym mogą się zająć wyższą warstwą.

  • #50 10 Lut 2019 11:11
    Urgon
    Poziom 36  

    AVE...

    1. DAC R2R nie za bardzo ma sens, bo traci się przynajmniej jeden bit w formie błędu, i to z rezystorami 0,1% - gdzieś o tym czytałem z rok temu. Tak czy siak drabinki R2R to nieporozumienie biorąc pod uwagę mnogość gotowych przetworników na rynku. Na pewno da się dobrać coś w korzystnej cenie i o przyzwoitych parametrach.

    2. Na ebaju można kupić moduły z AD9833 za 3-7 dolarów. Sam układ, co ciekawe, można mieć bezpośrednio od Analog Devices za jakieś 4,5USD przy zamówieniach hurtowych. Moduły z AD9850 stoją po 15 dolców. Zapewne są i inne układy DDS, tańsze i droższe, ale mnie się szukać nie chce.

    3. Wyjście z generatora można przepuścić rzez DAC, na przykład MCP4921, który jest dość tani, ewentualnie wziąć MCP4821 i op-amp w konfiguracji mnożącej, jak ktoś tam radził wcześniej. W ostateczności robić to potencjometrem też można - kiedyś innych opcji nie było i jakoś ludzie sobie radzili.

    4. Szczerze pisząc, to mi się wydaje, że większości do szczęścia wystarczyłby generator sinus o możliwie szerokim zakresie regulacji częstotliwości i amplitudy i generator prostokąta o regulowanych parametrach w możliwie szerokim zakresie. Takie rzeczy da się zrealizować prościej używając rozwiązań używanych przez radioamatorów. Sam myślałem o czymś takim na bazie kilku generatorów PLL dyscyplinowanych zegarem rubidowym, ale przez kolesia od EEVBlog ich ceny wzrosły czterokrotnie...

  • #51 10 Lut 2019 12:18
    willyvmm
    Poziom 27  

    Witam.
    Przedewszytskim przy tym projekcie należy od samego początku określić główny cel.
    Tanio czy dobrze za przyzwoitą cenę.

    Tanio nie ma sensu, moduł dds z aliexpress + arduino załatwia sprawę.
    Kiedyś przymierzam się do czegoś takiego i skończyło się jak wyżej.

    Dobrze za przyzwoitą cenę, wymaga trochę więcej pracy, i, zaprzęgniecia najlepiej fpga. W fpga trzeba zaimplementować najtrudniejszą cześć, czyli akumulator fazy. (kto pamięta SID'a? On jest właśnie takim dds'em).
    Xilinx oferuje np gotowe ip dds do wykorzystania. Ale myślę że korzystając z taniego max10 Intela byłoby to do zrobienia na 1 chipie + dac + układ wyjściowy.
    Jeszcze słowo dlaczego fpga. Pozwoli to na DOWOLNY wybór częstotliwości. Przy odrobinie wysiłku pozwoli również na rozszeżenie funkcjonalności o generator arbitralny kosztem tylko firmware.


    Pozdr.

  • #52 10 Lut 2019 12:34
    lukaszd82
    Poziom 27  

    Tylko z założenia miał to być gadżet elektroda. A jak wiadomo tu ogranicza nas budżet... To może niech gulson poda do jakiej kwoty? I raczej fpga odpadnie...
    Taki gadżet byłby i tak lepszy niż to co mamy w sklepiku i unikalny...
    Jak ktoś potrzebuje sprzętu na co dzień to najpewniej kupi coś o przyzwoitych parametrach. Amatorzy korzystający kilka razy w roku nie wydadzą dużej kwoty. Bądźmy realistami. Czytajmy założenia od początku.
    Jeśli jest zapotrzebowanie na coś lepszego to jaki problem zebrać grupę docelową w odpowiednim wątku, określić budżet i możliwe do realizacji w jego zakresie cele. A później opracować w tej grupie temat i pochwalić się ogółowi wynikami pracy?
    Na chwilę obecną w wątkach o dso i dds tylko krytyka, każdy ma wygórowane cele. Zróbmy na początek coś działającego w niższym budżecie dla amatorów. Wypali to na bazie tych doświadczeń można robić coś trudniejszego...
    Nie startujmy od razu z wysokiego pułapu bo nic z tego najpewniej nie będzie.
    Doceńmy autorów wspomnianych tematów, że chcą zrobić coś za darmo, ale na miarę swoich możliwości. Mają być to proste ale uniwersalne konstrukcje, proste w naprawie, z pełnymi źródłami... Zawsze to jakiś początek i bezcenna wiedza dla obserwujących te tematy, początkujących. ”Zawodowcy” mogą pomóc stworzyć coś w przyjętych ramach. Wiemy, że oni potrzebują innego sprzętu, ale nie o to chodziło w tych projektach.

  • #53 10 Lut 2019 12:37
    drobok
    Poziom 29  

    Można by w gadżetach oferować shield do np cycloneIV, czy tam innego ustrojstwa np oscyloskop albo dds. Wtedy koszt samej jednostki wykonawczej odpadnie.

  • #54 10 Lut 2019 12:39
    willyvmm
    Poziom 27  

    Akurat w tym temacie jest działacze urządzenie jako baza.
    Tyle że ma 2 wykluczające je z użycia cechy.
    Częstotliwość jest "na oko"
    Dotknięcie panelu kontrolnego powoduje że przestaje na chwilę generować.

  • #55 10 Lut 2019 12:41
    lukaszd82
    Poziom 27  

    Jeśli to ma być gadżet to można go opracować od nowa, by działał przyzwoicie ale ograniczy nas budżet za gotowe urządzenie. Więc niech poda go w przybliżeniu gulson. Wiadomo, że na etapie prototypu wyjdzie drożej, ale można przeliczyć wtedy na co "nas stać".

  • #60 10 Lut 2019 13:47
    And!
    Admin grupy Projektowanie

    Przegląd możliwości sprzętowych mamy już chyba zakończony, mamy zewnętrze specjalizowane układy DDS sinus, całe stado STM w atrakcyjnej cenie i z wbudowanym DAC, jest nawet XMega z 2xDAC.

    @gdL potrzebne jest zrobienie ankiety jakie są wymagania i wtedy możemy spróbować dopasować jakieś rozwiązania optymalizując koszty i możliwości. Wtedy będziemy rozmawiać o konkretach i w ramach narzuconych ograniczeń/wymagań.