Elektroda.pl
Elektroda.pl
X
Elektroda.pl
AdexAdex
Proszę, dodaj wyjątek dla 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 13 Lut 2019 11:00 12036 175
  • #121
    LChucki
    Poziom 31  
    katakrowa napisał:
    Twierdzisz kolego, że łatwiej napisać soft jednocześnie obsługujący enkoder, LCD oraz generowanie sygnału niż 2 osobne ?
    Powyższe stwierdzenie jest chyba prawdą jedynie w przypadku małych umiejętności programisty

    Proszę https://www.elektroda.pl/rtvforum/topic3552750.html
    Pomiar częstotliwości (sprzęt+przerwania), czasu (sprzęt), oscyloskop (DMA), obsługa LCD (DMA), USB (sprzęt+przerwania), klawiatury bo na enkoder nie ma miejsca. Ile uC kolega widzi?
  • AdexAdex
  • #122
    acctr
    Poziom 16  
    khoam napisał:
    Akurat kernel w linuksie ma charakter monolityczny, a POSIX to inna bajka

    A co ma do tego kernel? Przytoczylem ta analogię jako przykład podejścia budowy systemu skladającego się z wielu specjalizowanych narzędzi.

    Problemem wielomodulowego systemu jest zaprojektowanie dobrego interfejsu i jego utrzymanie. Mówię tutaj o ewolucji poprzez dodawanie nowych modulów i rozszerzanie ich funkcjonalności. Pokusa dodawania nowych rzeczy styka się z kontraktem wobec wcześniejszych wersji modułów, czyli zachowaniem wstecznej kompatybilności.
    Do tego dochodzi konieczność tworzenia bardzo dobrej specyfikacji protokołów i jej utrzymania dla kolejnych wersji.

    Urządzenie 'standalone' takich problemów nie generuje. Poza tym łatwiej jest je sprzedać, co widać na aliexpress (poza wyjatkami typu arduino, ale to inna bajka).
  • AdexAdex
  • #123
    katakrowa
    Poziom 21  
    LChucki napisał:
    Pomiar częstotliwości, czasu, oscyloskop, obsługa LCD, USB, klawiatury bo na enkoder nie ma miejsca. Ile uC kolega widzi?
    LChucki napisał:
    Pomiar częstotliwości, czasu, oscyloskop, obsługa LCD, USB, klawiatury bo na enkoder nie ma miejsca. Ile uC kolega widzi?


    Czy ja napisałem, że się nie da. Nie! Napisałem, że łatwiej jest pisać kilka małych programów ( modułów) niż jeden obsługujący wszystko i jest to zasada! Modułowowść / obiektowość jest podstawą programowania w dzisiejszych czasach właśnie dlatego, że tak jest łatwiej modelować i programować większe systemy. Brak modułowości zawsze usztywnia projekt wieszcząc tym samym krótszy jego żywot.

    Urgon napisał:
    Albo na przykład na to, ile informacji krąży wte i nazad, gdy komputer startuje i BIOS, a potem ładujący się system odpytują poszczególne urządzenia, czym są i co potrafią. Następnie niech kol. katakrowa pokaże nam swoją implementację takiego protokołu. Powodzenia...


    Widzę, że brak merytorycznych argumentów powoduje już wymyślanie chorych oderwanych całkowicie od omawianego od projektu wyzwań.
    Gwarantuję Ci kolego, że też mogę wymyślić Ci problemy, które w życiu rozwiązałem a Ty nawet nie będziesz wiedział od której strony za to się zabrać.
    Więc proszę trzymajmy się merytorycznie konstrukcji generatora DDS i nie koncentrujmy się na "przechwalankach" czego to Urgon w życiu nie ogarnął / zobaczył.


    Dla tych, którzy jednak byliby zainteresowani konstrukcją modułową narysowałem bardziej czytelne "schematy" blokowe proponowanego rozwiązania z uwzględnieniem stosowanych na nich elementach aby możliwa była ich szybka wycena i porównanie z innymi propozycjami (jeśli takowe w ogóle zostaną przedstawione).

    Wspólny projekt generatora DDS na elektroda.pl Wspólny projekt generatora DDS na elektroda.pl

    Jak wcześniej napisałem mógłbym zająć się:

    - opracowaniem protokołu ;
    - przygotowaniem prostego penlu z LCD;
    - przygotowaniem oprogramowania panelu na PC jako aplikacji ;

    Gdyby ktoś zaprojektował w płytki generatorów ( prosty i bardziej zaawansowany ) to byłby już ładny działający komplet, który można uruchamiać w 8 różnych konfiguracjach. Więc spory wybór i dla każdego coś by się znalazło.
    Koszty takiego generatora to od 30zł do 100zł - w zależności od wybranej konfiguracji. no i finalnie pozostało by mieć nadzieję, że ktoś drobi jakiś fajny moduł generatora dla bardziej specjalistycznych zastosowań.
  • #124
    Urgon
    Poziom 36  
    AVE...

    @katakrowa

    Pamiętam, jak pierwszy raz pisałem komunikację po I2C ze sprzętową obsługą. Komunikacja dwukierunkowa Master<>Slave. Nie udało mi się przekonać tych układów do rozmowy, a to przecież "prosty" program był, coś w stylu:
    M: Hej, masz coś dla mnie?
    S: Tak, proszę cię bardzo.
    M: To masz ode mnie to. Nara!
    S: Okej, nara!
    Postępowałem zgodnie z dokumentacją, erratą i notą aplikacyjną. Okazało się jednak, że dokumentacja ma błąd. Odkrycie tego zajęło mi kilka tygodni i kosztowało zrobienie przelotki USB-I2C oraz kupienie taniego analizatora logicznego. Pisanie kodu, zwłaszcza na wiele układów na raz to ledwo 10% roboty. Reszta to sprawienie, by działał.

    Obsługę LCD do innego projektu napisałem sam od zera w jeden wieczór. Debugowanie problemów zajęło mi dwa kolejne (problemy z połączeniami były). Musiałem tak zrobić, bo wszystkie powszechne biblioteki dla PICów były niedorobione albo zupełnie źle napisane. Czytanie enkodera to pół godziny googli i 10 minut kodowania. Problem pojawił się przy przeliczaniu wartości (float na słowo binarne i z powrotem, opcja biblioteczna generowała bzdury). W obecnej formie program czyta enkoder, pisze na LCD i dokonuje złożonych operacji matematycznych na liczbach zmiennoprzecinkowych i na 32-bitowych typach long long int. I nikt nie ma problemu z pisaniem takich rzeczy, oprócz ciebie, katakrowa. Widać też, że nie masz za bardzo pojęcia, o czym piszesz...

    Mój przepis na "modułowy" generator DDS:
    1. Jeden mikrokontroler, który obsługuje wszystko. Cały interfejs zajmie mniej niż 10-20% kodu.
    2. Na płytce 4-8 gniazd na moduły DDS AD9833, filtry, wzmacniacze operacyjne (w tym mnożące) kilka sztuk DACów MCP4802 albo inne, do regulacji amplitudy sygnału wyjściowego.
    3. Przetwornica boost i buck-boost do generowania wyższych napięć dodatniego i ujemnego dla części analogowej, sterowana wyjściem PWM mikrokontrolera.
    4. Wersja podstawowa ma obsadzone tylko dwa kanały, cena będzie bliżej 80-90PLN, ale 2x10MHz ucieszy każdego.
    Użytkownik zależnie od potrzeb obsadza sobie tyle kanałów, ile chce. Program wykryje, ile modułów jest (w nieużywanych pin FSYNC byłby zwarty do masy).

    Jest taka zasada: nie twórz bytów ponad miarę. Każdy powinien się do niej stosować.
  • #125
    katakrowa
    Poziom 21  
    Urgon napisał:
    Pamiętam, jak pierwszy raz pisałem komunikację po I2C ze sprzętową obsługą. Komunikacja dwukierunkowa Master<>Slave. Nie udało mi się przekonać tych układów do rozmowy, a to przecież "prosty" program był, coś w stylu:

    Cóż mogę napisać. Przykro mi, że masz takie złe wspomnienia. Ja mam dobre.
    Zawsze zamiast i2s można użyć jeszcze łatwiejszy w implementacji UART ( po TTL ) Choć jeśli na jednej linii "wieszamy" klika urządzeń to to już łamie standardy ale wciąż jest możliwe do zrobienia bo w sumie moduły tylko słuchają i odpowiadają tylko gdy są po adresie wywołane do odpowiedzi więc kolizje nie mają prawa wystąpić. Wszystko kwestia mądrego zaprojektowania protokołu.
    UART miałby tę zaletę, że Z PC można by sterować generatorem przez zwykłego max232.

    Urgon napisał:
    Mój przepis na "modułowy" generator DDS:
    1. Jeden mikrokontroler, który obsługuje wszystko. Cały interfejs zajmie mniej niż 10-20% kodu.

    Tak. Tylko, że jak będziesz kręcił enkoderem to będziesz miał zakłócenia w sygnale wyjściowym spowodowane nierówną praca układu. Uniemożliwi to także wyciśnięcie Maximum częstotliwości z jednego uC jako generatora. Dlaczego tak Wam szkoda te 3,50zł które oddziela projekt "jakoś" od "dobrze" ;-)

    Pozostałe punkty są jedynie doprecyzowaniem układu "monolitycznego" a nie modułowego. i cały czas chcecie tworzyć skomplikowany kod jednego uC, który trzeba będzie przerabiać jeśli pojawi się na rynku nowy iC DDS ryzykując tym, że w pewnym momencie aplikacja nie zmieści się już w uC.
  • #126
    rb401
    Poziom 36  
    katakrowa napisał:
    ktoś wcześniej wspominał o komplikacjach w kodzie wynikających z jednoczesnej obsługi generatora i panelu w jednym programie a to rozwiązanie własnie robi takie połączenie tworząc kod zypełnie niemodyfikowalnym przez początkujących ( a to też był jeden z postulatów by początkujący mogli coś dorobić ).

    katakrowa napisał:
    I powstaje naprawdę skomplikowana magistrala zupełnie niepotrzebnie komplikując także program głównego uC ?


    Masz rację. Ale Ty patrzysz przez pryzmat AVR, gdzie rzeczywiście jest strasznie pod górkę robić np. DDS i obsługiwać panel. Sam kiedyś nawet zrobiłem taki wieloAVRowy potworek bo inaczej się nie dało.
    Ale w STM32 tych problemów po prostu nie ma. Generacja DDS odbywa się praktycznie całkowicie sprzętowo (DMA) i jedynie to przy zmianach częstotliwości czy kształtu, trzeba kilka rejestrów zapisać. A jednoczesna obsługa panelu, czy sterowanie jakimiś kostkami po I2C czy SPI w ogóle tu nie koliduje z generatorem. Procesor będzie i tak większość czasu się nudził.
    STM32 to zupełnie nowa jakość niż AVR w tym względzie i twoje obawy nie mają podstaw.
    Dlatego moim zdaniem z AVRem nie ma się poco pchać do DDS, tym bardziej że cenowo różnica jest nieznaczna a nawet w pojedynczych wypadkach AVR wychodzi drożej a z pewnością AVR mocno komplikuje pisanie programu.

    katakrowa napisał:
    Kolejna dramatyczna komplikacja kodu uC centralnego.


    Ale co to za komplikacja, jeśli i tak trzeba pewne rzeczy wyliczyć i wpisać do kostki przez I2C czy SPI. Jedna mało skomplikowana funkcja więcej.
    Ale z pewnością komplikacją i sprzętową, i programową jest przechodzenie przez protokół po RS tam i z powrotem, i robienie tego na dwóch uC, skoro i tak jest to w jednej skrzynce i żadnej odczuwalnej różnicy w działaniu nie będzie.

    katakrowa napisał:
    I powstaje naprawdę skomplikowana magistrala zupełnie niepotrzebnie komplikując także program głównego uC ?


    Nie rozumiem co widzisz skomplikowanego w wypuszczeniu na pinach np. I2C (i też SPI jak trzeba) skoro widzę że sam narysowałeś w poście #105 tą koncepcję (tzn. I2C jako magistralę między modułami).

    Rozumiem, chciałbyś by poszczególne moduły były całkowicie autonomiczne w kwestii sterowania. Ale jeśli moduły nie są to jakieś osobne skrzynki łączone kablami, to raczej to podejście to taka sztuka dla sztuki. Zwiększająca znacznie komplikację sprzętową konstrukcji a użytkowo kompletnie nic nie wnosząca.


    katakrowa napisał:
    - jest szansa na to, że w przyszłości ktoś doda moduł na jakimś nowym iC DDS bo nie będzie musiał wgryzać się w kod centralnego uC a jedynie będzie musiał przeczytać notę z opisem protokołu ...


    Moim zdaniem, zupełnie niepotrzebnie się tego boisz.
    Kod w module podstawowym może być też przejrzysty i modułowy.
    Zależy kto i jak go napisze. Jeśli to będzie przemyślane i ładnie udokumentowane, wtedy napisanie "drivera" do dowolnego swojego generatora może być tylko kwestią napisania np. dwóch swoich funkcji (lub klasy z tymi metodami). Jednej zwracającej np. zakresy nastaw parametrów i opcje danego modułu a druga ustawiająca moduł do generacji zadanego sygnału. Obiektowo może to być szczególnie przyjemne w realizacji.
    Dużo prostsze w realizacji niż obsługa jakiegoś pośredniego protokołu międzymodułowego.

    Jeśli program dodatkowo będzie w jakimś przyjaznym dla początkujących środowisku np. w Arduino, to tym bardziej nie ma stresu.
  • #127
    katakrowa
    Poziom 21  
    rb401 napisał:
    Moim zdaniem, zupełnie niepotrzebnie się tego boisz.


    Dla mnie to nie jest żaden problem. Ale wcześniej w dyskusji poniesiono argument, że program będzie skomplikowany i początkujący się zniechęcą. Więc to nie jest moja obawa,
  • #128
    Urgon
    Poziom 36  
    AVE...
    katakrowa napisał:

    Urgon napisał:
    Mój przepis na "modułowy" generator DDS:
    1. Jeden mikrokontroler, który obsługuje wszystko. Cały interfejs zajmie mniej niż 10-20% kodu.

    Tak. Tylko, że jak będziesz kręcił enkoderem to będziesz miał zakłócenia w sygnale wyjściowym spowodowane nierówną praca układu. Uniemożliwi to także wyciśnięcie Maximum częstotliwości z jednego uC jako generatora. Dlaczego tak Wam szkoda te 3,50zł które oddziela projekt "jakoś" od "dobrze"

    Niby jakie zakłócenia, jeśli sygnał nie jest generowany przez mikrokontroler, tylko przez moduł DDS? Dla AD9833 to wygląda tak:
    1. FSYNC = 0.
    2. Przesyłasz cztery słowa nowej wartości.
    3. FSYNC = 1.
    4. Układ DDS dopiero wtedy zmienia parametry sygnału.
    Można to robić za każdym pokręceniem enkoderem, albo w formie menu, gdzie nowa wartość zostanie wysłana po wciśnięciu przycisku OK.

    katakrowa napisał:
    Pozostałe punkty są jedynie doprecyzowaniem układu "monolitycznego" a nie modułowego. i cały czas chcecie tworzyć skomplikowany kod jednego uC, który trzeba będzie przerabiać jeśli pojawi się na rynku nowy iC DDS ryzykując tym, że w pewnym momencie aplikacja nie zmieści się już w uC.

    "Skomplikowany kod" to dla ciebie obsługa SPI/I2C + obsługa LCD alfanumerycznego + obsługa przycisków i enkodera + przeliczanie wartości częstotliwości na słowa bitowe, i robienie tego wszystkiego w jednym układzie. To akurat jest prościzna. Pisanie i debugowanie protokołu, który pozwoli dwóm mikrokontrolerom porozumienie się, co nowy moduł potrafi, a czego nie to dopiero komplikacja.

    A jak chcesz w "monolitycznym" projekcie zmienić układ DDS, to w kodzie zmienia się tylko zakresy i kawałek kodu, który tworzy i wysyła nowe słowa bitowe do układu...
  • #129
    LChucki
    Poziom 31  
    katakrowa napisał:
    Napisałem, że łatwiej jest pisać kilka małych programów ( modułów) niż jeden obsługujący wszystko i jest to zasada! Modułowowść / obiektowość jest podstawą programowania w dzisiejszych czasach właśnie dlatego, że tak jest łatwiej modelować i programować większe systemy.

    O jakiej modułowości w DDS można mówić? Różnej jakości przetworniki, na 99% równoległe więc złącze na przetwornik (jak w dokumentacji zaproponowanej w #116 [https://www.elektroda.pl/rtvforum/viewtopic.php?p=17774535#17774535] czyli nie ma tam miejsca na dodatkowy uC. Jakie moduły mają mieć jeszcze uC? Osobny do LCD? Enkodera? USB?

    katakrowa napisał:

    Brak modułowości zawsze usztywnia projekt wieszcząc tym samym krótszy jego żywot.

    To nie skalowalna centrala telefoniczna o pojemności 1000 do 100'000NN, gdzie pracuje kilkaset CPU. Mowa o prostym generatorze.

    rb401 napisał:
    Ty patrzysz przez pryzmat AVR

    Też tak mi się wydaje. Faktycznie, gdy AVR ma generować DDS, obsługiwać kolorowy wyświetlacz dużej rozdzielczości, realizować stos uSB problemy się mnożą. To wszystko można szybciej, taniej, lepiej zrobić na ARM i modułowość na siłę nie jest potrzebna.
  • #130
    Użytkownik usunął konto
    Poziom 1  
  • #131
    khoam
    Poziom 39  
    LChucki napisał:
    AVR ma generować DDS

    Wydaje mi się, że w trakcie dyskusji zgłoszono pomysł, że do generowania DDS będzie użyty dedykowany układ - kwestia wyboru samego procesora staje się tym samym mniej istotna.

    LChucki napisał:
    obsługiwać kolorowy wyświetlacz dużej rozdzielczości

    No pewnie byłoby fajnie, ale z ankiety wynika, że większość zagłosowała za LCD.
  • #132
    LChucki
    Poziom 31  
    khoam napisał:

    LChucki napisał:
    obsługiwać kolorowy wyświetlacz dużej rozdzielczości

    No pewnie byłoby fajnie, ale z ankiety wynika, że większość zagłosowała za LCD.

    Na razie na LCD ale graficzny jest sensowniejszy, zwłaszcza gdy można używać własnych przebiegów.
  • #133
    katakrowa
    Poziom 21  
    Marek_Skalski napisał:
    Czy jeszcze nie zauważyłeś, że walczysz o idee fix ze wszystkimi udzielającymi się w temacie?


    To była jedynie propozycja więc nie rozumiem skąd aż taka niechęć. Poza tym ja ułatwiam a wy komplikujecie czego efektem będzie to, że nie powstanie ani forumowy DDS ani DSO. W najlepszym wypadku powstanie układ jakich na aukcjach za kilka dolarów są do wyboru tysiące.
    Czekam z niecierpliwością na alternatywne konstruktywne propozycje :-)
  • #134
    krisRaba
    Poziom 30  
    Może wróćmy do tematu ;)

    rb401 napisał:
    Ale w STM32 tych problemów po prostu nie ma. Generacja DDS odbywa się praktycznie całkowicie sprzętowo (DMA) i jedynie to przy zmianach częstotliwości czy kształtu, trzeba kilka rejestrów zapisać. A jednoczesna obsługa panelu, czy sterowanie jakimiś kostkami po I2C czy SPI w ogóle tu nie koliduje z generatorem. Procesor będzie i tak większość czasu się nudził.
    STM32 to zupełnie nowa jakość niż AVR w tym względzie i twoje obawy nie mają podstaw.
    Dlatego moim zdaniem z AVRem nie ma się poco pchać do DDS, tym bardziej że cenowo różnica jest nieznaczna a nawet w pojedynczych wypadkach AVR wychodzi drożej a z pewnością AVR mocno komplikuje pisanie programu.

    Tutaj mogę tylko potwierdzić, że przykładowo jeden mój sterownik komunikuje się z masterem, jednocześnie steruje BLDC z czujnikami halla, silnikiem DC z impulsatorem, czyta sygnały z enkodera, mruga sobie LEDami statusowymi, zawiaduje kilkoma taśmami "ynteligentnych" LEDów, czyta trochę analogów.. i coś tam jeszcze. Wszystko na jednym STM ;) Modułowo jest wewnątrz, w sofcie, i trochę na PCB, ale generalnie ze względu na różnorakie wsparcie sprzętowe, to CPU jeszcze nie stęka ;)

    Z drugiej strony podoba mi się koncepcja modułowości @katakrowa , bo projekt będzie bardziej otwarty na przyszłe dodatki. Choć akurat moje frameworki, gdzie chciałem przewidzieć wszystko w przód w którymś miejscu okazywały się za ciasne i mało elastyczne.. bo klient miewa różne oryginalne pomysły :D
    Stąd sam nie jestem pewien, czy brałbym taką wersję, czy monolityczny (optymalizowany pod bieżące klocki na PCB). W debugowaniu kilku MCU jednocześnie trochę uciążliwe może być śledzenie i poprawianie kilku wsadów. Pojawia się fix do części głównej i nagle trzeba podegrać wszystkie moduły, bo po tym "drastycznym" fixie mogą nie gadać. Niby można, ale sam nie wiem. Miałem kiedyś projekt multimaster, gdzie było kilkanaście równorzędnych modułów i na początkowym etapie, gdy już wszystko było podegrane, ale znalazłem jeszcze jakiegoś babola, trzeba było znów podegrać wszystkie moduły, to coś mnie trafiło :D

    LChucki napisał:
    Na razie na LCD ale graficzny jest sensowniejszy, zwłaszcza gdy można używać własnych przebiegów.

    Popieram.

    I jedna rzecz, która może być fajnym "ficzerem", to w przypadku dwóch kanałów, załóżmy dla wspólnej częstotliwości, możliwość ustawienia offsetu czasowego między kanałami, np. pierwszy powiedzmy sinus startuje z triggerem, a drugi kanał, np trójkąt 40ms (lub inny zadany czas) później ;)
    Czy ktoś jeszcze widzi sens takiego czegoś? :)
  • #135
    katakrowa
    Poziom 21  
    krisRaba napisał:
    I jedna rzecz, która może być fajnym "ficzerem", to w przypadku dwóch kanałów, załóżmy dla wspólnej częstotliwości, możliwość ustawienia offsetu czasowego między kanałami, np. pierwszy powiedzmy sinus startuje z triggerem, a drugi kanał, np trójkąt 40ms później ;)
    Czy ktoś jeszcze widzi sens takiego czegoś? :)


    Zdecydowanie tak. Po pierwsze synchronizacja przy starcie po drugie ustawiane z panelu opóźnienia czasowe.
  • #136
    Urgon
    Poziom 36  
    AVE...

    Używając dwóch układów AD9833 lub AD9850 lub innych DDS, taktowanych jednym zegarem, można prosto uzyskać takie sygnały, gdyż generalnie te układy pozwalają ustawić nie tylko częstotliwość, ale też i fazę.

    AD9833 ma dwa rejestry dla częstotliwości i dwa dla fazy generowanego sygnału. Pisząc do rejestru sterującego dwa słowa 8-bitowe można przełączać uklad między tymi rejestrami, co pozwala na prostą implementację modulacji FSK i PSK w formie binarnej z częstotliwością przełączania około 2,22(2)MHz...
  • #137
    rb401
    Poziom 36  
    khoam napisał:
    Wydaje mi się, że w trakcie dyskusji zgłoszono pomysł, że do generowania DDS będzie użyty dedykowany układ - kwestia wyboru samego procesora staje się tym samym mniej istotna.


    Ale zauważ istotną sprawę, że choć są różne dedykowane układy DDS tu wyżej wymienione, to tak właściwie przy kryterium cenowym projektu, jedyną realną wobec założeń, pozostaje i tak właściwie tylko opcja syntezy DDS na uC.
    A to dlatego że tanie kostki np. AD9833 nie dają np. piły (ważnej według mnie) czy szumu ani regulowanego PWM. A dopiero gdzieś od koło 80zł za dedykowaną kość (z tabelą próbek w RAM) pojawia się ta możliwość, ale znów szkoda do takiej kostki minimalistycznego otoczenia. Czyli koncepcja gadżetu na takiej kości traci sens.
    Tak że to sprawa kompromisu a nie możliwości technicznych dostępnych na dziś.


    krisRaba napisał:
    Z drugiej strony podoba mi się koncepcja modułowości @katakrowa , bo projekt będzie bardziej otwarty na przyszłe dodatki.


    Mnie też się podoba ten pomysł, choć proponowana konkretna realizacja, w świetle założeń tego projektu ("użytkowy gadżet") nie ma przekonującego sensu praktycznego.

    Ale moim zdaniem, z samej idei pomysłu "modułowości" kolegi katakrowa nie warto rezygnować.
    Jeśli na PCB będą tylko wyprowadzone sygnały (magistral I2C i SPI, zasilania itp.) na punkty do których można wlutować goldpiny i wpinać shield'y, to mamy system który można składać jak z klocków. Będzie można dokładać generatory jakie kto chce i które będą sterowane takim samym zunifikowanym interfejsem użytkownika (LCD enkoder), przełączalnym między generatorami za pomocą np. dodatkowego przycisku.

    Czyli na starcie, dla kogoś kto będzie miał tylko płytkę podstawową (panel i DDS) nie będzie żadnej różnicy zarówno w obsłudze jak i w cenie. I nie trzeba na tym etapie podejmować żadnych wyborów. Dopiero dopięcie shield'a, ujawni ten charakter konstrukcji bo pojawi się możliwość przełączania interfejsów różnych generatorów i konstrukcja zyska nowy wymiar.

    Jeśli jeszcze konstrukcja oprogramowania będzie przyjazna tej modułowości, to nie będzie żadnym problemem dopiąć swojego shield'a generatora, zrobionego pod jakieś całkiem specyficzne własne potrzeby i dopisać swój "driver".
  • #138
    khoam
    Poziom 39  
    rb401 napisał:
    Ale zauważ istotną sprawę, że choć są różne dedykowane układy DDS tu wyżej wymienione, to tak właściwie przy kryterium cenowym projektu, jedyną realną wobec założeń, pozostaje i tak właściwie tylko opcja syntezy DDS na uC.


    Chciałbym zwrócić uwagę, że u chińczyka jest dostępny w tej chwili dwukanałowy generator DDS FeelTech FY3200S w aktualnej cenie 50$ z przesyłką poleconą, z całkiem niezłymi parametrami (user manual w załączeniu). Moja propozycja jest taka, aby chociaż z grubsza założyć, że koszt generatora" Elektroda DDS" będzie porównywalny zarówno w cenie, jak i funkcjonalności.
    Oczywiście wspomniany przeze mnie chiński generator nie jest przeznaczony dla profesjonalistów, czyli akurat dla mnie świetnie się nadaje ;) Planowałem jego zakup, ale wstrzymał mnie ten wątek.

    rb401 napisał:
    A to dlatego że tanie kostki np. AD9833 nie dają np. piły (ważnej według mnie) czy szumu ani regulowanego PWM. A dopiero gdzieś od koło 80zł za dedykowaną kość (z tabelą próbek w RAM) pojawia się ta możliwość, ale znów szkoda do takiej kostki minimalistycznego otoczenia. Czyli koncepcja gadżetu na takiej kości traci sens.
    Tak że to sprawa kompromisu a nie możliwości technicznych dostępnych na dziś.


    Mogę sobie wyobrazić sytuację, kiedy takie moduły z dedykowanymi układami DDS będą wymienne w generatorze, bez wymiany "płyty głównej" z procesorem. W zależności od potrzeb konkretnego użytkownika i jego finansów. Oprogramowanie może również rozpoznawać rodzaj zainstalowanego modułu DDS, lub przynajmniej jego kolejne wersje ;)
  • #139
    Slawek K.
    Poziom 33  
  • #140
    Urgon
    Poziom 36  
    AVE...

    Zaprojektowałem pod AD9834 płytkę, miał to być dwukanałowy generator DDS do 40MHz (wspólny kwarc 100MHz), ale zapomniałem wpierw rozrysować schemat i przypadkiem wykasowałem sobie wartości komponentów w filtrze. Teraz nie pamiętam, skąd te wartości wziąłem, więc pewnie zaprojektuję całość od nowa...
  • #141
    gdL
    Poziom 27  
    Podsumowując dotychczasowe wyniki ankiety:

    1/ Chcecie mieć 2 kanały DDS (67%), pozostałym osobom w większości (25%) wystarczy jeden kanał.
    2/ Większości osób (łącznie do 100kHz - 18%, do 500kHz - 6% i do 2MHz - 33%) wystarczą generowane częstotliwości do 2MHz.
    3/ Rozdzielczość DAC to (co ciekawe) w większości 12bit - czemu?
    4/ Chcecie wyświetlacza. Niewielką przewagę ilościową ma wyświetlacz alfanumeryczny nad graficznym. Raczej nie preferujecie opcji TFT.
    5/ Zdecydowana większość (47% ) chce ceny <100PLN, na kolejnym miejscu mamy opcję 100-200zł (35% osób).
    6/ Jako zasilanie najczęściej wybieracie akumulator i USB (46%) - urządzenie ma być więc w pełni przenośne. Na drugim miejscu z niemal taką samą ilością głosów jest zasilacz zewnętrzny i samo USB.

    Analiza tych opcji skłania mnie do skupienia się póki co na gadżecie do sklepiku elektrody. Urządzenie w pełni przenośne i typowo amatorskie. Cieszy mnie to, bo mamy w zasadzie gotową konstrukcję tego typu.
    Co do realizacji można się dalej zastanawiać. Pasmo do 2MHz z zadowalającą jakością nie jest tak łatwo zrealizować dla generatora DDS, można natomiast zrobić to dla pewnych przebiegów, jak prostokąt i sinus.
    W realizacji będę skupiał się na niskiej cenie, co poprawi dostępność gadżetu dla użytkowników posiadających niewielką ilość punktów.
  • #142
    And!
    Admin grupy Projektowanie
    Zaczynają się kształtować wyniki, wpasowują się one w urządzenie mogące być gadżetem do sklepiku elektroda.pl

    "W realizacji będę skupiał się na niskiej cenie, co poprawi dostępność gadżetu dla użytkowników posiadających niewielką ilość punktów."
    Jak dla mnie dobre podejście.

    1/ Chcecie mieć 2 kanały DDS (67%), pozostałym osobom w większości (25%) wystarczy jeden kanał.
    Dajmy 2 kanały, realizacja albo 1xMCU z 2xDAC wbudowanym, albo 2xMCU z wbudowanym DAC, albo wykorzystanie DAC zewnętrznego.

    2/ Większości osób (łącznie do 100kHz - 18%, do 500kHz - 6% i do 2MHz - 33%) wystarczą generowane częstotliwości do 2MHz.
    ~100kHz sobrze wpisuje się to we wbudowane DAC 1MSPS (i więcej w pierwszym poście pojawiły się STM z 4.5-13MSPS), może częstotliwości >100kHz <8MHz generować jako prostokąt przy pomocy timera (timerów)? Kolejny krok to obsługa programowa gotowość obsługi zewnętrznego modułu na ADXXXX który można zakupić i dołączyć we własnym zakresie. Można nawet dać wsparcie dla różnych rodzajów ADXXXX np. AD9850 / 9833.
    Widzę że są dostępne i zainteresowani mogliby we własnym zakresie rozbudować urządzenie:
    AD9833 35zł
    AD9850 45zł

    3/ Rozdzielczość DAC to (co ciekawe) w większości 12bit - czemu?
    DAC może mieć taką rozdzielczość, ale nie musimy wykorzystywać pełnej rozdzielczości przy generowaniu wyższych częstotliwości.
    Np. STM32F051K4T6 - 1x 12b DAC, ATXMEGA32A4U - 2x 12b DAC.

    4/ Chcecie wyświetlacza. Niewielką przewagę ilościową ma wyświetlacz alfanumeryczny nad graficznym. Raczej nie preferujecie opcji TFT.
    LCD alfanumeryczny jest większy (może lepsza czytelność), oraz tańszy.
    Graficzny (np. OLED lub inny np 128x64px), można zrobić czytelniejsze menu i pokusić się na wbudowane pesudo DSO :)
    Alfanumeryczny potrzebuje więcej pinów sterujących a czasem ujemne napięcie kontrastu, bardziej popularne są wersje 5V niż 3.3V.
    Graficzny monochromatyczny potrzebuje bardziej skomplikowane i czasochłonne sterowanie, kolorowy (RGB) jeszcze bardziej komplikuje (programowo) sterowanie i narzut czasowy...
    Chociaż wyświetlacze graficzne adaptują się w konstrukcjach dość dobrze: https://www.elektroda.pl/rtvforum/topic3554244.html

    A może wspierać jeden i drugi rodzaj wyświetlacza programowo tak jak robią to testery elementów na M328?

    Cenowo LCD wypada lepiej i jest większy wymiarami:
    LCD alfanumeryczny:
    5V 2x16znaków 9zł
    Graficzny OLED:
    Niebieski monochromatyczny 0.96" 128x64px 5/3.3C SPI/I2C 27zł
    TFT:
    Kolorowy 1,8'' 128x160px SPI 3.3V 29zł

    5/ Zdecydowana większość (47% ) chce ceny <100PLN, na kolejnym miejscu mamy opcję 100-200zł (35% osób).
    Na tym trzeba się skupić jako kryterium optymalizacji, niska cena i funkcjonalność ułatwią pojawienie się w gadżetach.

    6/ Jako zasilanie najczęściej wybieracie akumulator i USB (46%) - urządzenie ma być więc w pełni przenośne. Na drugim miejscu z niemal taką samą ilością głosów jest zasilacz zewnętrzny i samo USB.
    Optymalizacja kosztowa to zewnętrzny powerbank / zasilacz / USB od PC. USB jednocześnie może pełnić funkcję komunikacyjną aby np. wgrać swój kształt przebiegu.
  • #143
    Janusz_kk
    Poziom 28  
    gdL napisał:
    3/ Rozdzielczość DAC to (co ciekawe) w większości 12bit - czemu?

    Bo 8 bitów to cienizna, do audio się nie nadaje, gdzie indziej też tak sobie, za duże zniekształcenia,
    sam mam Fy3200 za 180zł i ma 12 bit i jak patrzę na oscylu to jest to absolutne minimum
    dla generatora.

    Dodano po 31 [sekundy]:

    Więc się nie dziwię że społecznośc ma takie wymagania :)
  • #144
    drobok
    Poziom 32  
    Społeczność ma wymagania z czapy, dds do audio powinien mieć te 300kHz max przy i te 12-16 bitów (pomijając fakt, że lepiej by było użyć przetwornika z karty dźwiękowej 24 bity i bufora, albo generatora sinusa a nie dds), do innych zastosowań można dać większą częstotliwość i mniejszą rozdzielczość.
  • #145
    TechEkspert
    Redaktor
    No nieźle, wychodzi na to że do audio lepszy jest zwykły analogowy generator sinus + pomiar/stabilizacja częstotliwości, natomiast DDS o mniejszej rozdzielczości zapewni generowanie wyższych częstotliwości o dowolnych kształtach.
  • #146
    krisRaba
    Poziom 30  
    Myślę, że powyższe podsumowanie to dobry kierunek na start. Zasilanie z USB, to zarówno opcja biurkowa (z PC lub ładowarki) jak i przenośna (powerbank). Małe, poręczne, co ułatwia pracę w terenie. Może być niezależne, tj. działa z przycisku/pokrętła, oraz sterowane - jakiś prosty protokół do wgrywania przebiegów, sterowania zdalnego itp. przez USB. Optuję za wyświetlaczem graficznym lub obsługą graficznego i alfanumerycznego ;)

    Ja bym prosił tylko jeszcze o uwzględnienie "placu" na dołączenie jakiegoś taniego modułu typu HC-05. Wtedy można to też dość łatwo pożenić z jakąś apką czy terminalem na smartfonie. Zastanawiam się, czy nie dodać jako "ficzer" dwóch rzeczy - pomiaru prądu na jakimś ACS712 czy podobnym oraz różnicowego pomiaru napięcia. Nie chodzi o budowanie DSO, może to być pomiar "multimetro-podobny", czyli uśrednienie i wartość, albo dodatkowo oscylogram, bez jakichś wybujałych parametrów, ale żeby był... jak np. kol.@LChucki dał w swojej sondzie.
    Generator może mieć wyjścia BNC, a dodatkowo inne rzeczy (plus zdublowane wyjście generatora) na jakiejś drobnej listwie sprężynowej, by wpinać po prostu przewody.
  • #147
    Użytkownik usunął konto
    Poziom 1  
  • #148
    TechEkspert
    Redaktor
    W przypadku tego projektu, pierwsza wersja to mogą być gotowe moduły + przewody połączeniowe + płytka stykowa.

    Kojarzę że @leonow32 kiedyś prezentował swoje moduły z różnymi mikrokontrolerami, może jest szansa że w tym temacie coś nam podpowie także w zakresie późniejszej produkcji takich modułów.
  • #149
    krisRaba
    Poziom 30  
    Też mi się wydaje, że należy wykonać pierwszą wersję, podstawa monolit, z opcją doczepiania czegoś, jak HC-05, czy dodatkowa płytka z ADxxxx, wyprowadzeniem SPI/I2C/GPIO/whatever na złącze goldpin, by dało się coś z tym jeszcze zrobić w ramach wolnego czasu. Może potem takie mody wejdą do wersji drugiej...
    W tej wersji bym nie porywał się na jakieś kosmiczne parametry. Pocket-gen, z opcjonalnym softem na PC i/lub smartfon, itp, jak już pisałem wyżej. Realne mi się wydaje wybranie 32-bit MCU z dobrym 2xDACem, DMA, mocą obliczeniową i FPU.. i wycisnąć z tego ile się da. Do tego dobre komponenty w torze analogowym, ale sensowne cenowo...
    Może warto jeszcze rozważyć dodanie wyjścia 4..20mA? ;) To nie jest jakieś rocket-science, a mielibyśmy coś w rodzaju kalibratora dla automatyków ;) Można sobie wygenerować PWM, zmierzyć napięcie/prąd (opcje o których pisałem wcześniej), wygenerować określony przebieg, zadać prąd w pętli...
    Albo te rzeczy zrobić właśnie jako druga płytka, jeśli nie każdy będzie tym zainteresowany i wtedy można brać wersję bazową lub rozbudowaną ;)
  • #150
    gdL
    Poziom 27  
    Tak sobie czytam, jak wymusić wysoką prędkość GPIO na STM32 i okazuje się, że nie jest tak fajnie jak się wydaje...

    https://vjordan.info/log/fpga/stm32-bare-metal-start-up-and-real-bit-banging-speed.html

    Czy ktoś mógłby mi przybliżyć jak można poprawić rezultat mojego generatora na ATMEGA16/32 przy użyciu rozsądnego cenowo STM32? Proszę o cokolwiek - artykuły, wpisy na blogach lub nawet lepiej - własne doświadczenie.
    Myślałem też o zewnętrznym DAC i prędkość magistrali też nie zachwyca... Zakładając, że STM32 musiałby jeszcze w rozsądny sposób kontrolować jakie dane lecą po magistrali lub na GPIO - nie jest tak wesoło.

    Ogólnie Chińczycy zrobili podobny do mojego generator na ATMEGA328 - Link
    Tylko ta cena w PL - 250zł. Na Ali jest za $23 - wzmacniacz wyjściowy jest beznadziejny, bo zniekształcenia skrośne mocno zniekształcają przebiegi.