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 11 Lut 2019 22:09 7398 159
  • Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • Texa Poland
  • #92 12 Lut 2019 08:59
    gdL
    Poziom 27  

    Pojawiło się wiele dyskusji i rozważań technicznych dotyczących budowy wspólnego urządzenia DDS. Część pomysłów jest świetna, ale zdecydowana większość niestety jest bardzo wymagająca. Dużo osób ma spore wymagania, bo uważa, że jesteśmy w stanie stworzyć sprawne urządzenie konkurujące z konstrukcjami renomowanych producentów.
    Część osób podkreśla, że na Aliexpress pojawiły się niedrogie moduły DDS, umożliwiające generowanie sinus i prostokąta - urządzenie można więc podzielić na dwa moduły - wykonawczy i sterowania/UI (procesor).
    Niewielka grupa osób sugeruje użycie FPGA/CPLD .

    Celem dalszego sprecyzowania Waszych oczekiwań dodałem ankietę - ANKIETA: https://goo.gl/forms/qFlNwbO7Se47mYVO2
    WYNIKI ANKIETY: Link

    Pamiętajcie, że wszelkie dane zbierane przez ankietę są anonimowe.
    Po głosowaniu będzie można dalej dyskutować o uczestnictwie w tworzeniu urządzenia.

  • #93 12 Lut 2019 10:08
    sawron piotr
    Poziom 1  

    Witam,

    to czego mi najbardziej brakuje w tych "porcelanowych cudeńkach z expresso" to opcji synchronizacji
    SYNC IN oraz SYNC OUT

    Druga sprawa to proszę pomyślcie o przekształceniu projektu na "progresywny" czy "etapowy/stopniowy"
    Ja bym chciał wykonać generator, tylko do pewnego etapu, który wpisze się w moje bieżące zapotrzebowanie i nic ponad to.
    Z tak ogromną wiedzą jak na forum nie da się tutaj przewidzieć na którym etapie może udać się generator idealny w swojej klasie, ale zawsze na każdym etapie potencjalnie będzie mógł stać się idealnym. Takie podejście również daje szanse na większe uznanie dla niektórych mniej popularnych realizacji.


    Wspólny projekt generatora DDS na elektroda.pl

  • #94 12 Lut 2019 12:50
    katakrowa
    Poziom 20  

    Moja propozycja:
    Wspólny projekt generatora DDS na elektroda.pl

    Cała konstrukcja modułowa. Następujące moduły składały by się na urządzenie:

    Generatory.
    Każdy kanał na osobnej płytce z uC. To pozwoli na dowolność rozbudowy kanałów. Ktoś potrzebuje 1 to polutuje sobie 1, ktoś inny chce 5 to polutuje sobie 5. Teoretycznie można porobić moduły generatorów na innych uC a wciąż będę kompatybilne z całością.
    Każdy moduł potrafiłby generować jeden sygnał jednocześnie. W konfiguracji byłyby:
    - [A] prostokąt ;
    - [P] piła ;
    - [C] sinus ;
    - [D] trójkąt ;
    - [X] odczytywana próbka z RAM ( której zawartość można przesłać do modułu portem szeregowym ).

    Taki moduł sterowany byłby poprzez UART. I przykładowo wysłanie do niego rozkazu: [A][10MHz] spowodowało by przełączenie go w odpowiedni tryb. W zależności od zastosowanego w module uC zmieniłby się jego "możliwości".
    Moduł też powinien zwracać po zadaniu mu pytania odpowiedź z informacją o tym jakie przebiegi potrafi generować tak aby "panel" potrafił nim zarządzać.

    Powyższe rozwiązanie nie wyklucza robienia generatorów z drogimi konwerterami bez konieczności wprowadzania jakichkolwiek zmian w pozostałej części projektu.

    Panel.
    Zadanie panelu to wysyłanie komend do generatorów. Panelem może być dowolny PC z portem szeregowym lub USB z przejściówką np. CH340G. Jedną z form panelu może być prosty uC z wyświetlaczem i kilkoma przyciskami.

    Wstępnie rozkazy wysyłane do generatorów:

    Ogólna struktura rozkazu: [adres generatora][kod rozkazy][parametry]

    Przykłady:
    Rozkaz 1: [1][reset] - zeruje wszystkie parametry pierwszego generatora ;
    Rozkaz 2: [1][sinus][1000000] - zaczyna generować sinus 1MHz na pierwszym generatorze ;
    Rozkaz 3: [1][square][100] - zaczyna generować kwadrat 100Hz na pierwszym generatorze ;
    Rozkaz 4: [2][amplitude][100] - ustawia amplitudę sygnału na 100% na drugim generatorze;
    Rozkaz 5: [2][data][..............] - wysyła porcję danych do bufora "data" z przebiegiem próbki do drugiego generatora;
    Rozkaz 6: [2][signalX][1] - zaczyna odtwarzać próbkę z bufora DATA ;

    Rozkaz [7]: [2][getConfig] - generator zwraca swoją konfigurację:
    - [sin][1][1000000][square][1][5000][data][1024] - przykładowo może to oznaczać, że generator potrafi generować sin od 1 Hz do 1 MHz, kwadrat do 5kHz oraz ma 1024 słowa na próbkę danych.

    W powyższej propozycji podstawą jest ustalenie standardu transmisji pomiędzy modułami.
    Sama koncepcja nie wyklucza zbudowania urządzenia małego i przenośnego jak i wielkiego stacjonarnego z 10 kanałami.
    Definiuje jedynie pewne standardy modułów, które mogą z urządzeniem współpracować. Co do samego protokołu komunikacji trzeba go zaprojektować tak aby był naturalny i wygodny do obsługi przez "maszynę stanów".

    Dla mnie bardzo ciekawa mogłaby być aplikacja sterująca na PL lub Android. W takiej aplikacji można generować wówczas przedziwne przebiegi ( wysyłane później do bufora generatora ). Proste zarządzanie generatorem natomiast bez trudu ogarnie mały AVR.

    Podsumowanie:
    Warto zwrócić uwagę, że w najprostszej formie działające już urządzenie to moduł generatora podpięty do PC przez RS232 i można nim sterować przez dowolny terminal. Same moduły mogą być też robione pod dedykowane zastosowania. Ja np. pierwszy mogę zaprojektować dedykowany do testów Audio z taniutkim DAC CS4334 zamiast drabinki rezystorowej. Ktoś inny może sklecić coś dedykowane do cyfrówki albo z zaawansowanymi sygnałami PWM itd ... itp .. Sama komunikacje PC z "panelem" nie wyklucza zastosowanie WIFI czy BT.

  • Texa Poland
  • #97 12 Lut 2019 13:56
    katakrowa
    Poziom 20  

    gdL napisał:
    Można było, ale przez to nie wymagała logowania. No ale spaliłeś xD

    Generalnie ankieta jest bardzo ograniczona i nastawiona na budowę "konkretnego" zbudowanego "na sztywno" generatora i nie przewiduje modułowości ani skalowalności rozwiązania.
    Oczywiście jakiś obraz zapotrzebowania daje ale w sumie czemu nie uszczęśliwić 100% uczestników ankiety a tylko część ?

    Zanim zacznie się pracę warto oderwać się od lutownicy oraz KiCada/Eagle i pomyśleć o temacie szerzej. Z podejściem na konkretne rozwiązanie powstanie generator jakich w internecie jest "pierdyliard" z gotowymi PCB i programami. Warto chyba zrobić coś bardziej uniwersalnego i coś co daje szanse na rozwój już w założeniach projektowych.

  • #98 12 Lut 2019 14:22
    gdL
    Poziom 27  

    Można spróbować modułowo, ale nawet Google się z tego wycofało. Duże firmy z branży też już coraz rzadziej klepią coś modułowo. Częściej dają opcje software do dokupienia.
    Kolega wcześniej zaproponował rozwiązanie modułowe i w sumie to byłoby bardzo ok, gdyby jeszcze moduł się jakoś przedstawiał mikrokontrolerowi zarządzającemu UI, żeby ten wiedział, co ma wyświetlać w opcjach.
    No nie wiem. Z jednej strony kusi, z drugiej strony gdybyśmy coś zrobili od początku do końca chyba byłoby lepiej. A czym większy projekt tym łatwiej utknąć.
    No i nikt się nie zdeklarował do pracy. Ale będzie osobna anonimowa ankieta. Ewentualne zgłoszenia również na PW. Jeśli będzie masa krytyczna to można zaczynać coś większego.
    Jak nie, może zrobimy chociaz cokolwiek :-)

  • #99 12 Lut 2019 14:39
    katakrowa
    Poziom 20  

    gdL napisał:
    Kolega wcześniej zaproponował rozwiązanie modułowe i w sumie to byłoby bardzo ok, gdyby jeszcze moduł się jakoś przedstawiał mikrokontrolerowi zarządzającemu UI, żeby ten wiedział, co ma wyświetlać w opcjach.

    Jak najbardziej zostało to uwzględnione:
    Rozkaz [7]: [2][getConfig] - generator zwraca swoją konfigurację:
    - [sin][1][1000000][square][1][5000][data][1024] - przykładowo może to oznaczać, że generator potrafi generować sin od 1 Hz do 1 MHz, kwadrat do 5kHz oraz ma 1024 słowa na próbkę danych.

    gdL napisał:
    No nie wiem. Z jednej strony kusi, z drugiej strony gdybyśmy coś zrobili od początku do końca chyba byłoby lepiej. A czym większy projekt tym łatwiej utknąć.

    Właśnie rzecz w tym, że w takim rozwiązaniu modułowym jest łatwiej.
    Każdy koncentruje się na jednym fragmencie układanki a jedyne co musi poznać to protokół komunikacji.
    Ja z przyjemnością opracuję protokół oraz aplikację na PC. Sam panel do zmiany ustawień właściwie mam gotowy z projektów wzmacniaczy ( CPU + LCD + enkoder ).
    Kluczem w mojej propozycji jest jednak protokół. Kolejna osoba niech zrobi najprostszy generator na AVR sterowany tym protokołem i już mamy komplet.
    Jak zadziała ( a w sumie nie ma powodu aby nie zadziałało ) można zacząć się bawić budowaniem modułów generatora z lepszymi parametrami, rozbudowę aplikacji o fikuśne przebiegi.

    p.s. Na swoim diagramie zapomniałem o sygnale synchronizującym pomiędzy modułami generatorów.

  • #100 12 Lut 2019 14:54
    gdL
    Poziom 27  

    Bardzo mi się to podoba, bo jest to realna propozycja współpracy przy tworzeniu urządzenia. Sądzę, że inni użytkownicy forum też się z tym zgodzą.
    Poczekamy jeszcze trochę, może pojawi się jeszcze jakiś ciekawy pomysł w tym temacie. A jak przejdziemy do działania, obiecuję, że będę wołał :-)

  • #101 12 Lut 2019 16:31
    Urgon
    Poziom 36  

    AVE...

    A ja uważam, że pomysł modułowy jest mało sensowny, podnosi niepotrzebnie koszty i generalnie komplikuje całą sprawę niepotrzebnie. Za około 61 złotych można mieć generator funkcyjny do 10MHz z przyzwoitymi parametrami (a nawet z modulacją FM/FSK/PSK i wobulatorem (kwestia firmware'u), a po dodaniu dwóch buforów na op-anpach, w tym jednego odwracającego także wyjściem komplementarnym). Dodać do tego moduł ładowarki USB z zabezpieczeniami i ogniwo 18650 (sprzedam za złotówkę od sztuki - koszty wysyłki) i mamy przenośny sprzęt na kieszeń każdego początkującego elektrodowicza. Nie ma sensu tworzyć bytów ponad miarę.

    Oczywiście można zaprojektować bajerancki sprzęt, ale będzie też odpowiednio droższy i bardziej skomplikowany. Ponadto większość i tak pewnie nie wykorzysta wszystkich funkcji. Serio, jak wielu użytkowników nie może żyć bez przebiegów arbitralnych powyżej pasma audio?

    Jak będziecie myśleć o modułach, funkcjach i komplikacjach tak, jak teraz, to ten generator nie powstanie nigdy, albo powstanie jakiś koszmarek kosztujący więcej i będący gorszej jakości, niż nowe generatory arbitralne od Rigola czy innej budżetty elektronicznej...

  • #102 12 Lut 2019 16:32
    acctr
    Poziom 14  

    gdL napisał:
    Duże firmy z branży też już coraz rzadziej klepią coś modułowo. Częściej dają opcje software do dokupienia.

    Podajesz przyklady podejścia komercyjnego a tutaj tworzy się projekt otwarty. Np w linuksie bardzo dobrze sprawdza się podejście modulowe - jest dużo specjalizowanych narzędzi typu grep, sed, cat,..., które implementują interfejs POSIX.

  • #103 12 Lut 2019 17:04
    khoam
    Poziom 23  

    Urgon napisał:
    Oczywiście można zaprojektować bajerancki sprzęt, ale będzie też odpowiednio droższy i bardziej skomplikowany.

    Zaczynam się zastanawiać dla kogo (jak grupa docelowa) taki produkt będzie przede wszystkim przeznaczony? Dla profesjonalistów raczej nie, bo zawsze będę narzekać, że sami zrobiliby lepszy, co jest oczywiście zrozumiałe. Ewentualnie kupią sobie sprzęt komercyjny, również profesjonalny. Dla amatorów/hobbystów? Też już chyba nie, bo jak będzie zbyt wydumany, to taniej będzie nabyć coś tańszego i prostszego w obsłudze na alipowoli. Wynika z tego, że muszą powstać dwie wersje produktu, tak żeby:

    katakrowa napisał:
    ale w sumie czemu nie uszczęśliwić 100% uczestników


    Dodano po 1 [minuty]:

    acctr napisał:
    Np w linuksie bardzo dobrze sprawdza się podejście modulowe


    Akurat kernel w linuksie ma charakter monolityczny, a POSIX to inna bajka :)

  • #104 12 Lut 2019 17:46
    katakrowa
    Poziom 20  

    khoam napisał:
    Wynika z tego, że muszą powstać dwie wersje produktu, tak żeby:


    Ale ja własnie proponuję rozwiązanie modułowe. Jeśli profesjonalista ma pomysł na zrobienie super modułu generatora co generuje sinusy 20GHz to bez problemu będzie mógł podpiąć do proponowanego zestawu nie musząc robić interfejsu i całej części zarządzającej.
    Amator jak będzie chciał proste rozwiązanie to zlutuje sobie 1 albo max 2 płytki czyli: prosty generator na AVR + panel. Każda z płytek wielkości pudełka od zapałek więc zapakuje w "mydelniczkę" i będzie miał tani generator.
    Nie jest też wielką sztuką zaprojektować te płytki jako jednostronne aby każdy mógł je za grosze zrobić w domu.
    Jak w przyszłości "Amatorowi" przyjdzie ochota na kolejny kanał to dorobi kolejną płytkę i dopnie ją do istniejącego już zestawu ( "magistrali" ). Sam panel wykrywa parametry podłączonych modułów więc w prosty sposób będzie można się cieszyć urządzeniem z dwoma kanałami.

    Jak chcemy ciąć po kosztach to nic nie stoi też na przeszkodzie zrobić jako jeden moduł układ, który ma 3 kanały wyjściowe. Wystarczy mu nadać 3 adresy a panel da sobie z nim radę.

    Same modułu można by łączyć złączmi IEC np. 6 pin każdy moduł miałby take złącze wejściowo/wyjściowe ( jako magistrala z "przelotką" ) tak aby bez podłączać kolejne moduły.
    Wstępnie taka magistrala miałaby sygnały:
    - 2 przewody dla i2s ( wydaje mi się najsensowniejsze );
    - VCC 5V
    - GND
    - SYNC
    (czyli wstępnie 5 "drucików")

  • #105 12 Lut 2019 17:50
    khoam
    Poziom 23  

    katakrowa napisał:
    Wstępnie taka magistrala miałaby sygnały:

    Nie odbierz tego osobiście, ale naprawdę nie potrzebuję takiej magistrali w generatorze DDS i to właśnie starałem się wyjaśnić.

  • #106 12 Lut 2019 18:00
    katakrowa
    Poziom 20  

    khoam napisał:
    Nie odbierz tego osobiście, ale naprawdę nie potrzebuję takiej magistrali w generatorze DDS i to właśnie starałem się wyjaśnić.

    A w czym ona przeszkadza ? Ani to to nie kosztuje ani w niczym nie przeszkadza a czy Ci się to podoba czy nie jakoś panel musi komunikować się z generatorem. Przecież ta cała "magistrala" sprowadza się do 5 ścieżek do których przylutujesz złącze IEC albo nie ...
    Chyba, że chcesz na siłę użyć jednego uC do generowania sygnału i zarządzania "panelem" co jest wg mnie bez sensu w sytuacji kiedy uC kosztuje 2zł a złożoność programu przez to rośnie kilkukrotnie ...

    Wspólny projekt generatora DDS na elektroda.pl

    W powyższy sposób dodając kilka linijek kodu do programu uzyskujemy coś co można rozbudowywać i rozwijać zamiast "sztywnej" konstrukcji spełniającej oczekiwania jedynie niewielu.

  • #107 12 Lut 2019 18:30
    Urgon
    Poziom 36  

    AVE...

    Dlaczego robienie tego na modułach to idiotyzm:

    1. Koszty.
    Potrzeba dodać złącze, magistralę, protokół na tyle elastyczny, by bez modyfikacji softu pracował z każdym nowym modułem, a to oznacza konieczność użycia lepszego, większego mikrokontrolera. Dodatkowo każdy moduł musi mieć swój mikrokontroler.

    2. Niepotrzebna komplikacja softu.
    Im bardziej rozbudowany program, tym bardziej skomplikowane będzie jego tworzenie, tym łatwiej o błędy, tym mniej osób będzie chętnych nad tym siedzieć. Nie mówiąc już o czasie potrzebnym na jego rozwój.

    3. Nie ma takiej potrzeby.
    Większość i tak kupi najtańszy moduł z najprostszymi funkcjami.

    4. Jakość.
    Będzie bardzo ciężko zrobić coś, co dorówna lub przewyższy komercyjnym produktom będąc od nich tańszym rozwiązaniem.

    5. Moduły nie mają sensu.
    Kiedyś na rynku było sporo modułowych oscyloskopów. Teraz chyba nikt ich już nie robi, bo efektywniej i taniej jest po prostu zaoferować monolityczne urządzenie. Co więcej, koszt dodania do modułu rozszerzeń jakiegoś interfejsu użytkownika będzie definitywnie niższy od kosztu tworzenia modułu bazowego z miejscem na kilka modułów rozszerzeń.

    Wiem, że taki projekt byłby kul i w ogóle zarąbisty, ale nie ma on praktycznego sensu. Proszę, udowodnij mi, że się mylę i daj jakieś rozsądne argumenty, że Twoje rozwiązanie jest lepsze od wersji monolitycznej...

  • #108 12 Lut 2019 18:44
    katakrowa
    Poziom 20  

    Urgon napisał:
    Potrzeba dodać złącze, magistralę, protokół na tyle elastyczny, by bez modyfikacji softu pracował z każdym nowym modułem, a to oznacza konieczność użycia lepszego, większego mikrokontrolera. Dodatkowo każdy moduł musi mieć swój mikrokontroler.


    3zł na moduł ... Ale ok "koszty". Magistralę podstawową opisałem powyżej. Ciężko nazawać to jakimiś kosztami.

    Urgon napisał:
    2. Niepotrzebna komplikacja softu.
    Im bardziej rozbudowany program, tym bardziej skomplikowane będzie jego tworzenie, tym łatwiej o błędy, tym mniej osób będzie chętnych nad tym siedzieć. Nie mówiąc już o czasie potrzebnym na jego rozwój.


    Raczej ułatwienie. Łatwiej napisać 2 programy niż jeden obsługujący generator i panel jednocześnie.

    Urgon napisał:
    3. Nie ma takiej potrzeby.
    Większość i tak kupi najtańszy moduł z najprostszymi funkcjami.


    To już raczej kwestia indywidualna.

    Urgon napisał:
    4. Jakość.
    Będzie bardzo ciężko zrobić coś, co dorówna lub przewyższy komercyjnym produktom będąc od nich tańszym rozwiązaniem.


    Tu modułowość nie odgrywa żadnej roli. I trudności będą niezależnie od przyjętej architektury.

    Urgon napisał:
    5. Moduły nie mają sensu.
    Kiedyś na rynku było sporo modułowych oscyloskopów. Teraz chyba nikt ich już nie robi, bo efektywniej i taniej jest po prostu zaoferować monolityczne urządzenie. Co więcej, koszt dodania do modułu rozszerzeń jakiegoś interfejsu użytkownika będzie definitywnie niższy od kosztu tworzenia modułu bazowego z miejscem na kilka modułów rozszerzeń.


    "moduły nie mają sensu" ... Dobrze, że nie wiedzą o tym projektanci sterowników przemysłowych ani projektanci rozwiązań serwerowych i sieciowych bo mielibyśmy przekichane.

    Urgon napisał:
    Wiem, że taki projekt byłby kul i w ogóle zarąbisty, ale nie ma on praktycznego sensu. Proszę, udowodnij mi, że się mylę i daj jakieś rozsądne argumenty, że Twoje rozwiązanie jest lepsze od wersji monolitycznej...


    Nie mam zamiaru nic udowadniać. To była moja propozycja pewnej ogólnej koncepcji, która miałaby choć nikłą szansę na rozwój i to, że ktoś sam z siebie coś do tego dorobi czym poszerzy zbiór dostępnych w ramach projektu modułów. Dla mnie bez sensu jest urządzanie "monolityczne" - udowodnij, ze ma sens ... A ja to zaneguję mówiąc, że nie odpowiadają mi parametry albo cena zaproponowanego urządzania. W moim rozwiązaniu zwiększając koszt urządzania o 10 zł i dodając góra 50 -100 linijek kodu uzyskujesz uniwersalność, której w urządzeniu "monolitycznym" nie będzie. nie będzie szansy na rozwój oprogramowania ( bo po co skoro projekt w pewnym momencie będzie skończony ).

  • #109 12 Lut 2019 19:46
    And!
    Admin grupy Projektowanie

    Mimo że ankieta trwa i należy poczekać na większą ilość głosów, to nie wytrzymałem i podejrzałem jej wyniki.

    Obecnie da się zauważyć pewną sprzeczność:
    1. Kryterium cenowe: większość odpowiedzi <100zł
    2. Częstotliwość: 35% głosów do 2MHz, 25% 20MHz -> jeżeli chcemy DDS na DAC i spełnić kryterium 1 należy ograniczyć się do setek KHz i ew. wyjście "cyfrowe - prostokąt" z opcjami 1/2/4/8MHz
    3. Ilość kanałów: przewaga głosów na 2, to być może da się zrealizować
    4. Rozdzielczość DAC: 60% głosów 12b -> jeżeli chcemy spełnić kryterium 1 to 8b próbki będą tu być może lepszym rozwiązaniem - zobaczymy
    5. Wyświetlacz: większość odpowiedzi to alfanumeryczny LCD -> to korzystnie wpływa na cenę, ale warto rozpoznać TFT/LCD/OLED graficzne gdyż ich cena czasem jest zbliżona do LCD alfanumerycznych, kwestia rozpoznania co daje lepszą wygodę obsługi, sterowania, optymalizuje koszty, upraszcza zasilanie itp.
    6. Zasilanie: pół na pół USB i akumulator-> kompromisem może być USB i zasilanie np. z power bank.

    Ad. 2. krok w kierunku sinus i wykorzystanie "zewnętrznego" układu generatora może znacząco zwiększyć zakres częstotliwości do kilku kilkunastu a nawet kilkudziesięciu MHz, ale chcieliśmy generator DDS.
    Może płytka powinna mieć wyjścia sterujące do popularnych modułów generatorów na ADxxx (np AD9850 lub 9833)?


    Zobaczmy jak dalej będą rozwijać się wyniki ankiety.

    @katakrowa przedstawiony schemat można zinterpretować nawet jako system pomiarowy/generatorów ze wspólną szyną sterowania/akwizycji takie LXI. To jest bardzo ciekawy pomysł, ale na początek może warto zbudować coś mniej modułowego, a otwartego na przyszłą modułowość? (w sumie wystarczy jeden port komunikacyjny).

    Proponuję wystartować od z nieco mniejszym rozmachem, spróbować zaprojektować użyteczny gadżet - generator DDS - dla odwiedzających elektroda.pl

  • #110 12 Lut 2019 20:07
    katakrowa
    Poziom 20  

    And! napisał:
    Proponuję wystartować od z nieco mniejszym rozmachem, spróbować zaprojektować użyteczny gadżet dla odwiedzających elektroda.pl


    Ale w tym nie ma żadnego rozmachu - nie przesadzajmy, że oprogramowanie komunikacji między dwoma uC z adresacją to jakieś wyzwanie. Jeśli wychodzimy z założenia, że to problem to znaczy, że zabierają się za to ludzie bez podstawowej wiedzy z programowania uC więc w ogóle bez sensu brać się za taki projekt bo i tak nic sensownego nie ma prawa wyjść.
    Dodanie jednego identyfikatora do uC generatora to żaden rozmach.
    Na dobrą sprawę ten projekt, który przedstawiłem w wersji podstawowej zrobiłbym za 3 - 4 popołudnia ( góra 20 - 30 godzin roboczych ) w tym kod + płytki PCB ( jednostronne ).

    Składałby się z ( teoretycznie mogą być na jednej PCB z możliwością przecięcia ):
    1. Panelu z LCD + enkoderem ( Attiny2313 );
    2. Generatora sygnałów bazującego na AVR ( także Attiny2313 wstępnie same sin, triangle, square ) ;
    Jak nie wlutuje złącza IEC to nie będzie magistrali i będzie miał jeden kanał. kolejne kanały to powielenie płytki generatora.

    Zalety:
    - jedno oprogramowanie do obsługi różnych generatorów o różnych parametrach ;
    - sterowanie z PC lub sterowanie z panelu ;
    - każdy sam zadecyduje ile chce wydać na generator i wybierze moduły, na które go stać ;
    - bardziej zaawansowani elektronicy otrzymują gotową platformę to testowania różnych zintegrowanych układów DDS.

  • #111 12 Lut 2019 20:13
    And!
    Admin grupy Projektowanie

    Ja to rozumiem. Natomiast takie jest moje zdanie, że dobrze mieć jeden samodzielny działający moduł na początek,
    a jeżeli da się go rozbudować do sieci urządzeń to tym lepiej...

    Natomiast co do opracowania skalowalnego, uniwersalnego, kompatybilnego w przód i wstecz protokołu komunikacji to nie są to proste rzeczy :) (tak bardzo ogólnie pisząc, bo wiadomo że do zastosowania o którym piszesz jest to realizowalne).

  • #112 12 Lut 2019 22:36
    rb401
    Poziom 34  

    katakrowa napisał:
    Zalety:
    - jedno oprogramowanie do obsługi różnych generatorów o różnych parametrach ;
    - sterowanie z PC lub sterowanie z panelu ;
    - każdy sam zadecyduje ile chce wydać na generator i wybierze moduły, na które go stać ;
    - bardziej zaawansowani elektronicy otrzymują gotową platformę to testowania różnych zintegrowanych układów DDS.


    Ale ja bym nieco inaczej postawił granice między modułami i komunikację, tak by i Twoją koncepcję i koncepcje prostego, taniego a użytecznego gadżetu powiązać jakimś kompromisem.

    W zarysie widziałbym to tak.
    Podstawowy moduł to DDS plus panel użytkownika (min. LCD, enkoder, jakieś przyciski) na w miarę tanim ale wydajnym uC z wewnętrznym DAC. Sygnały: sinus, trójkąt, prostokąt, piła, szum gdzieś do 100kHz. Drugie wyjście PWM.
    Czyli coś w kształcie tego co zaprezentował kolega gdL, tyle że nie na AVR a raczej STM32.

    A postulowaną przez Ciebie modułowość, załatwiło by na płytce miejsce na złącza, np. takie goldpinowe jak Arduino, gdzie były by wyprowadzone z głównego uC magistrale I2C, SPI, jak i zasilania oraz połączenia rezerwowe między modułami.
    Wtedy cena i prostota podstawowego, samodzielnego DDS była by praktycznie niezmieniona (doszło by jedynie trochę ścieżek i otworów na goldpiny).
    Warto też dać do modułu głównego jakiś minimalistyczny sprzętowo ale izolowany sprzęg do PC by moc tez sterować z aplikacji jak postulujesz. To też mało kosztuje a może być czasami przydatne i wygodniejsze niż operowanie enkoderem.

    A w razie potrzeby można by dołączać moduły jak shield'y do Arduino, na których to, nie musiały by być żadne lokalne uC bo sterowanie i identyfikację czy, i jaki moduł dołączony załatwia się po magistralach protokołami kości jakie tam będą.

    Przykładowo. Nakładka, generator w.cz. (np. do 120Mhz) na jakimś PLL, opcjonalnie modulowany AM, FM przebiegami z DDS na module głównym.
    Moim zdaniem taki komplet stał by się atrakcyjny dla "radiowców" np. serwisantów radyjek (przestrojki itp.).

    A jeśli potrzebny był by komuś system wielogeneratorowy sterowany jakimś protokołem z PC jak przedstawiłeś wyżej, to po prostu można użyć kilku głównych modułów tylko bez obsadzania wyświetlacza i manipuladeł i tak dobrać protokół by można sterować jedną linią każdym z osobna (np. lokalne adresy ustawione zworkami).

  • #113 12 Lut 2019 22:47
    And!
    Admin grupy Projektowanie
  • #114 12 Lut 2019 23:02
    allanrid
    Poziom 10  

    @katakrowa podoba mi się pomysł modułowej konstrukcji. Trochę z racji tego, że daje możliwość dopasowania modułów do potrzeb, które zmieniają się z czasem. Zaczynając swoją przygodę z elektroniką to konstrukcje modułowe wywierały na mnie zawsze największe wrażenie. Koledzy piszą, że w naszych czasach odchodzi się od konstrukcji modułowej a jednak Arduino i podobne projekty istnieją. Jednak dzisiaj największym wyzwaniem w tego typu konstrukcji może okazać się nie elektronika i oprogramowanie, ale konstrukcja mechaniczna. Gdyby powstały 3-4 dobre modułu mogło by się okazać, że projekt zaczął by się rozwijać również poza Elektrodą.

  • #115 13 Lut 2019 10:05
    katakrowa
    Poziom 20  

    allanrid napisał:
    Ale ja bym nieco inaczej postawił granice między modułami i komunikację, tak by i Twoją koncepcję i koncepcje prostego, taniego a użytecznego gadżetu powiązać jakimś kompromisem.


    W ten sposób otrzymujemy jedynie "nieszczęśliwą karykaturę" dwóch dobrych pomysłów jednocześnie skutecznie eliminując wszystkie zalety każdego z nich.

    rb401 napisał:
    W zarysie widziałbym to tak. Podstawowy moduł to DDS plus panel użytkownika (min. LCD, enkoder, jakieś przyciski) na w miarę tanim ale wydajnym uC z wewnętrznym DAC.


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

    And! napisał:
    A postulowaną przez Ciebie modułowość, załatwiło by na płytce miejsce na złącza, np. takie goldpinowe jak Arduino, gdzie były by wyprowadzone z głównego uC magistrale I2C, SPI, jak i zasilania oraz połączenia rezerwowe między modułami.

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

    rb401 napisał:
    Wtedy cena i prostota podstawowego, samodzielnego DDS była by praktycznie niezmieniona (doszło by jedynie trochę ścieżek i otworów na goldpiny).
    Warto też dać do modułu głównego jakiś minimalistyczny sprzętowo ale izolowany sprzęg do PC by moc tez sterować z aplikacji jak postulujesz. To też mało kosztuje a może być czasami przydatne i wygodniejsze niż operowanie enkoderem.


    Prostoty już nie ma cena też wymusza zakup kilku układów. W mojej propozycji panel w ogóle nie jest wymagany wystarczy sam PC jak ktoś nie chce panelu. Panel jest opcją.

    rb401 napisał:
    A w razie potrzeby można by dołączać moduły jak shield'y do Arduino, na których to, nie musiały by być żadne lokalne uC bo sterowanie i identyfikację czy, i jaki moduł dołączony załatwia się po magistralach protokołami kości jakie tam będą.


    To tak jakby włożenie do komputera nowej karty graficznej wymagało upgrade BIOS'a.
    Kolejna dramatyczna komplikacja kodu uC centralnego. Dodanie każdego nowego modułu wymagałoby w tym przypadku przeprogramowania panelu i kolejnej komplikacji jego kodu. w mojej propozycji panel nie wymaga żadnej modyfikacji a dołączać będzie można generatory DDS, które dziś nawet nie są jeszcze udokumentowane. odpowiednikiem "sterownika" jest odpowiedź na "ramkę" getConfig, w której moduł przedstawia się panelowi i pokazuje mu swoje możliwości.

    rb401 napisał:
    A jeśli potrzebny był by komuś system wielogeneratorowy sterowany jakimś protokołem z PC jak przedstawiłeś wyżej, to po prostu można użyć kilku głównych modułów tylko bez obsadzania wyświetlacza i manipuladeł i tak dobrać protokół by można sterować jedną linią każdym z osobna (np. lokalne adresy ustawione zworkami).


    Moja propozycja wszystko wyżej uwzględnia. Jedyna jej wada to taka, że na każdym module trzeba zastosować uC za gigantyczne 2zł lub 3,50zł.
    Adresów nie trzeba ustalać zworkami bo każdy uC ma EEPROM, w którym ten adres można przechowywać wystarczy jedynie opracować procedurę programowania tego adresu z poziomu panelu ( np. przez naciśnięcie switcha na module ).


    Konstrukcja wg mojej propozycji będzie :
    - co najwyżej droższa o 1uC do sterowania wyświetlaczem ( czyli max. 4zł );
    - daje możliwość dodawania dowolnych modułów w przyszłości nie przebudowując panelu i aplikacji PC ;
    - dwa podstawowe elementy Panel + 1 moduł generatora już tworzą urządzenie, które chcecie stworzyć ;
    - projektując 3 płytki generatora dajemy użytkownikom możliwość wyboru zakresu kosztów i parametrów z jakich skorzystają ;
    - 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 ...

    i wiele innych zalet, których w "monolitycznym" rozwiązaniu nigdy nie będzie ...

  • #116 13 Lut 2019 10:20
    LChucki
    Poziom 24  

    katakrowa napisał:

    Urgon napisał:
    2. Niepotrzebna komplikacja softu.
    Im bardziej rozbudowany program, tym bardziej skomplikowane będzie jego tworzenie, tym łatwiej o błędy, tym mniej osób będzie chętnych nad tym siedzieć. Nie mówiąc już o czasie potrzebnym na jego rozwój.

    Raczej ułatwienie. Łatwiej napisać 2 programy niż jeden obsługujący generator i panel jednocześnie.

    Raczej utrudnienie, łatwiej pisać soft na jeden uC niż na kilka.

    gdL napisał:
    b). Ewentualne dodanie modułu FTDI / podobnego i napisanie oprogramowania PC bazującego na porcie szeregowym celem zaopatrzenia generatora w zewnętrzną obsługę z poziomu PC przez USB, w najprostszej formie rysowanie przebiegu i jego wysyłanie do generowania – może wymagać użycia ATMEGA 32A zamiast 16A.

    To już było https://www.elektroda.pl/rtvforum/viewtopic.php?p=16745868#16745868
    USB izolowane galwanicznie, własne przebiegi, uC nie jest przetaktowany.

    Sensu rozwijania generatora na AVR nie widzę. Najlepiej coś z DMA. Ze względu na cenę lepiej wybrać ARM niż Xmega. Jednak bardziej kuszące jest rozwiązanie na FPGA / CPLD. Mam nawet PCB.


    PS
    Drabinka R-2R to nieporozumienie. Przy 8-bit, na rezystorach 1% uzyska się jakieś 6-7 bitów. 0,1% kosztują ok 50gr/szt, co przy R-2R gdzie R uzyskujemy z równoległego połączenia rezystorów 2R wymaga łącznie 26 rezystorów. Koszt rezystorów to ok 13zł, przetwornik, gwarantujący lepsze parametry jest 2 razy tańszy.

  • #117 13 Lut 2019 10:40
    katakrowa
    Poziom 20  

    LChucki napisał:
    Raczej utrudnienie, łatwiej pisać soft na jeden uC niż na kilka.


    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 ogarniętego strachem przed koniecznością implementacji prostej komunikacji.
    Szczerze mówiąc większej bzdury nie czytałem dawno ...

  • #118 13 Lut 2019 10:52
    khoam
    Poziom 23  

    katakrowa napisał:
    Powyższe stwierdzenie jest chyba prawdą jedynie w przypadku małych umiejętności programisty ogarniętego strachem przed koniecznością implementacji prostej komunikacji.
    Szczerze mówiąc większej bzdury nie czytałem dawno ...

    Takie porównania nie mają najmniejszego sensu. Tak, jak już pisałem wcześniej, napisanie softu to 50% pracy, a reszta to testowanie i bug fixing - oczywiście bardzo często można się spotkać z argumentacją typu "ale ja pisze soft bez błędów", ale to można włożyć między bajki. Nie sądzę, aby kryterium "łatwości" napisania softu miało jakiekolwiek znaczenie, bo to zawsze będzie pojęcie wyjątkowo subiektywne.

    Co do samego pomysłu magistrali sterującej, również dobrze można byłoby łączyć poszczególne modułu np. poprzez USB, bez potrzeby definiowania dedykowanych i unikalnych rozwiązań.

  • #119 13 Lut 2019 10:54
    LChucki
    Poziom 24  

    katakrowa napisał:
    LChucki napisał:
    Raczej utrudnienie, łatwiej pisać soft na jeden uC niż na kilka.


    Twierdzisz kolego, że łatwiej napisać soft jednocześnie obsługujący enkoder, LCD oraz generowanie sygnału niż 2 osobne ?

    Naturalnie. Jaki problem aby DMA generowało przebieg, pętla główna obsługiwała LCD a przerwania modyfikowały DMA aby uzyskać modulację?

    katakrowa napisał:

    Powyższe stwierdzenie jest chyba prawdą jedynie w przypadku małych umiejętności programisty ogarniętego strachem przed koniecznością implementacji prostej komunikacji.

    Komunikacja to "pikuś". Właśnie początkujący mają problem aby realizować wiele zadań równocześnie i używają kilku uC.

    Myślę, że kolega nie potrafi używać przerwań i DMA dlatego napisał:
    katakrowa napisał:

    Szczerze mówiąc większej bzdury nie czytałem dawno ...

    Bzdurą jest używanie kilku uC do prostych zadań. Zdarzenia z enkodera są bardzo rzadkie, nie ma problemu aby obsłużyć enkoder na przerwaniach. LED alfanumeryczny, czy graficzny mono a nawet kolor o małej rozdzielczości nie problem obsłużyć w pętli głównej czy przez DMA. Nie widzę w generatorze DDS potrzeby stosowania kilku uC.

    Gdy używa się kilku uC problematyczne staje się debugowanie, właściwie wszystko się komplikuje. Kilka uC ma sens, gdy brakuje zasobów albo urządzenie składa się z kilku niezależnych modułów.

  • #120 13 Lut 2019 10:54
    Urgon
    Poziom 36  

    AVE...

    Kol. katakrowa, polecam obaczyć, jak wygląda na przykład protokół USB czy Bluetooth LE, gdzie celem jest właśnie taka modułowość, że każdy moduł zgłasza, czym jest i co potrafi. 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...