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

Wspólna Sprawa - Projekt DSO na elektroda.pl - Temat podstawowy

Marek_Skalski 18 Mar 2019 21:41 35289 691
  • #541 18 Mar 2019 21:41
    TechEkspert
    Redaktor

    Marek_Skalski napisał:

    Myślicie, że znajdziemy kogoś zdolnego, aby napisać aplikację pod Windows'a i Linux'a, która będzie działać jak te dla Lab-Nation albo Red-Pitaya



    Może trochę bagatelizuję i upraszczam, ale gdy płytka będzie poprawnie wykonywać akwizycję danych, oraz przesyłać dane wybranym interfejsem i protokołem do komputera to napisanie wersji alfa aplikacji wydaje się być rzeczą znacznie prostszą niż ukończenie prac nad sprzętem.

    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • Computer Controls
  • #543 19 Mar 2019 00:19
    Marek_Skalski
    Moderator Projektowanie

    Tak, pomyliłem się - 20 mV. Czy uda nam się zejść do poziomu 2 mV? Wzmocnienie 1000x przy paśmie 10 MHz, to dla wzmacniacza efektywne BW = 10 GHz. Spróbujmy :)

    @TechEkspert Doświadczenia z innych projektów pokazują dość szybkie opracowanie kwestii sprzętowych i dużo więcej czasu spędzonego na oprogramowaniu. Po części ze względu na pomysły, po części ze względu na problemy z uzyskaniem założonych funkcji.

    Jak tylko dostanę odpowiedź od producenta płytek, to podzielę się tym z Wami. Schematy i wymiary są dostępna na stronie, więc nie powinno być problemów z dopasowaniem wymiarowym płytek AFE, ADC, LCD.

  • #544 19 Mar 2019 00:25
    -XantiO-
    Poziom 19  

    Marek_Skalski napisał:
    @-XantiO- Masz na myśli interfejs programowy czy sprzętowy? Programowo można sporo zrobić przez panel dotykowy. Czy to znaczy, że rezygnujemy z mechaniki typu enkodery, przyciski, kontrolki...? Zaproponowałem wyświetlacz 7" 1024x600, ponieważ na takim samym pracuję z STM3H743 w innym projekcie i wydaje mi się wystarczający do przenośnego urządzenia. Jeżeli ktoś będzie chciał więcej, to można spróbować przenieść to na 10" lub użyć monitora.
    Myślicie, że znajdziemy kogoś zdolnego, aby napisać aplikację pod Windows'a i Linux'a, która będzie działać jak te dla Lab-Nation albo Red-Pitaya


    Najchętniej zostałbym przy fizycznych przyciskach i enkoderach lecz przy tej wielkości wyświetlacza to chyba nie będzie miało sensu i postawmy w pełni na obsługę przez ekran dotykowy.

    Co do aplikacji na linuxa i winzgroze to skoro pisać już będę w Pythonie z PyQt5 to nie widzę problemu aby robić aplikację multi platformową. Co najwyżej ktoś by przydał się do pomocy i do code review. Dodatkowo można zaimplementować SCPI do sterowania z PC co po części ułatwi kilka spraw odnośnie komunikacji.


    Ktoś za lub przeciw aby pisać aplikacje w Pythonie?

    Co Ty na to Marku?

  • #545 19 Mar 2019 00:31
    Marek_Skalski
    Moderator Projektowanie

    Moje doświadczenie to wiele lat pisania w asm i kilka lat w C, z nieśmiałymi próbami w C++. Pythona używają moi koledzy w pracy do pisania programów testowych, ale dla mnie to zupełnie egzotyczny język. Nie wyobrażam sobie pisania GUI w C czy C++ na takiej platformie, więc to raczej kwestia pozyskania wsparcia dla Ciebie. Jeżeli zostaniesz sam, to szybko się wypalisz i zostawisz projekt. Niestety, ja tutaj nie pomogę. Zanim się nauczę, to minie zbyt dużo czasu ;)

    Jak wygląda licencja na Qt5? Czy możemy dowolnie korzystać z takiego programu?

  • #546 19 Mar 2019 00:42
    -XantiO-
    Poziom 19  

    Qt napisał:
    Usage under (L)GPL v3 license

    Możemy stosować chyba Open Source wersje. Więc do tego projektu powinno być ok.

    Fajnie tylko byłoby mieć jakiś projekt GUI na kartce abym wiedział co chcemy osiągnąć.

    I jak już powoli dochodzimy do etapu dzielenia projektu na moduły to warto byłoby utworzyć dodatkowe tematy dla każdego modułu, etapu co uporządkuje nieco pracę.
    No i miejmy nadzieję, że przynajmniej pojawią się osoby mnie dopingujące i napędzające do działania coby do wypalenia się nie doszło :)

  • Pomocny post
    #547 19 Mar 2019 08:41
    MODI
    Poziom 16  

    Marek_Skalski napisał:

    Co do płytek, to wspólnie z @_lazor_ zastanawiamy się jeszcze czy na pewno najtańsza płytka MYS-7Z007S-C-S czy może MYS-7Z010-L-C-S? Chodzi o to czy na pewno wystarczy nam zasobów w dalszej perspektywie. I nie chodzi tylko o I/O. Różnica w kosztach nie jest duża, ale każdy droższy element, to mniejsza szansa na popularyzację. Decyzja powinna zostać podjęta najdalej w 1920, aby zdążyły dotrzeć na czas integracji.

    Zmienić na tańszą można w każdej chwili jeśli wystarczy zasobów.
    Większe z kolei są http://www.myirtech.com/list.asp?id=502
    Ale to kolejne zwiększenie kosztów na które póki co nie ma konieczności. Pinów w wersji lite powinno wystarczyć

  • Pomocny post
    #548 19 Mar 2019 09:02
    stmx
    Poziom 25  

    Nikt nie wspomniał o C# I mono a takie aplikacje bardzo fajnie się pisze w C#. Sam popełniłem oscyloskopy w C# I działa bardzo dobrze na pc-tach, RPi I innych platformach.

    PS pisanie o V/podz w przypadku wersji na komputer gdzie tych posialem może być dużo więcej, jest bez sensu. Proponuję pisać o zakresach np. -100mV do 100mV albo -5V do 5V etc etc

  • Computer Controls
  • #549 19 Mar 2019 10:22
    szwedoman
    Poziom 9  

    Osobiście jestem też za c# i nie rezygnowałbym z fizycznego encodera nawet jednego. Ciężko jest manipulować cursorami albo poziomami triggera na wyświetlaczu dotykowym ze względu na brak precyzji nawet. Precyzja w przesuwaniu oscylogramu czy innych elemntów będzie o wiele większa dając nawe jeden fizyczny encoder.

  • #550 19 Mar 2019 10:38
    TWl
    Poziom 20  

    Kilka pytań i odpowiedzi: ;-)

    @Marek_Skalski: czy dobrze rozumiem, że cały projekt ma być Open Source i Open Hardware - tzn pełna dokumentacja (schematy, layouty, gateware, firmware, software) dostępne na otwartych licencjach? Jeśli tak, to jakich narzędzi (oprócz Vivado) zamierzamy używać?

    @Marek_Skalski: jeśli chodzi o rejestrator to mogę się tym zająć (FPGA + sterowniki + userspace)

    C# (wybaczcie dyletanckie pytania ale totalnie się nie znam na tym środowisku):
    - czy GUI w Mono jest w stanie działać na fbdev pod linuxem (tzn bez X-serwera i innych waylandów)? Pytam, bo nie jestem pewien jak wydajnie będzie to działać w środowisku X11.
    - czy da się w miarę prosty sposób (a la ctypes w Pythonie) wywoływać natywne funkcje C/C++ z poziomu Mono?

    Fizyczne przyciski i enkodery: jestem za (touchscreeny są dobre do dostępu do zaawansowanych funkcji, ale podstawa czasu, czułość, trigger level i kursory powinny moim zdaniem mieć prawdziwe gałki).

    Pojawiały się też propozycje przeniesienia tej dyskusji na EEVblog. Co powiecie na projekt na ohwr.org? Jest tam gitlab, issue tracker, wiki, osobne forum (per projekt) i sporo ambitnych projektów przyciągających uwagę ludzi z całego świata.

    Pozdrwaiam,
    TW

  • #552 19 Mar 2019 19:56
    Marek_Skalski
    Moderator Projektowanie

    Założenia podstawowe projektu
    Tak jak pisałem na samym początku w założeniach: Projekt jest wspólny, ma otwarty charakter i nie jest komercyjny. Warunki konieczne:
    - dokumentacja elektroniczna (schematy, PCB, partlisty) jest dostępna i przygotowana w oprogramowaniu, które nie wymaga zakupu licencji. Tutaj się zastanawiam czy KiCad czy Circuit Maker. KiCad'a nie potrafię zrozumieć, drażni mnie, ale CM mimo bazowania na środowisku uznanym w przemyśle (Altium), też jest irytujący. Nie wiadomo też kiedy ktoś postanowi wprowadzić opłaty albo zamknąć serwery.
    - oprogramowanie (niezależnie od języka i platformy) też musi być dostępne w formie kodów źródłowych i wersji skompilowanej. Praca nad nim nie może wymagać zakupu licencji.
    - praca jaką wykonujemy nie wiąże się z wynagrodzeniem, a powstałe autorskie prawa majątkowe zostają zniesione. Mam nadzieję, że znajdziemy model licencji, który będzie satysfakcjonujący, np. CERN, MIT, GPL?.
    - zapewniam finansowanie na etapie wersji alfa i beta. Alfa to opracowanie pierwszej wersji działającego urządzenia, które nie musi spełniać wszystkich założeń projektu, ale jest, działa i można je testować. Beta zaczyna się w momencie zakończenie testów alfy i po przyjęciu założeń do budowy bety. Beta kończy się po zakończeniu testów, jeżeli urządzenie działa zgodnie z założoną specyfikacją.

    Jak dalej prowadzimy projekt?
    Ze względu na związek z elektroda.pl, chcemy ten projekt prowadzić na Forum. Być może będzie to w zamkniętej grupie, aby uzyskać trochę większy komfort pracy.
    Z drugiej strony dostaję też sygnały, aby przejść na język angielski, co pozwoli zaistnieć w świecie i uzyskać większe wsparcie. Czy mamy z czym się pokazać? Nie ukrywam, że moje możliwości dotyczące sponsorowania projektu też są ograniczone. Jeżeli przyjdzie mi sfinansować budowę kilkudziesięciu zestawów dla wszystkich zainteresowanych, to nie dam rady. Nie jestem jeszcze milionerem. :)

    Może spróbujmy dokończyć wersję alfa i wtedy wyjdziemy do ludzi? Jak to mądrze ujął @And: "Warto najpierw wejść na Giewont a dopiero później na Mount Everest." Dlatego też obniżyliśmy wymagania dotyczące konstrukcji - zamiast 4x 250 MSps 200MHz+, proponujemy tylko (2+)2x 100 MSps i 10 MHz. Może będzie drożej, ale jest to realny cel.

    Jest też trzecia opcja, aby temat był związany z Forum i prowadzony w sposób przyszłościowy i po angielsku, ale dopóki Szef nie da zielonego światła, to nie mogę nic powiedzieć ;)

    Wiem, że opracowano całą masę różnych DSO typu Open Hardware. Spora część tych projektów jest martwa. Albo brakło energii do kontynuacji prac nad sprzętem, albo brakło determinacji do odrobaczania oprogramowania, albo brakło finansowania. Są też projekty wyjątkowo dobre i dość przeciętne, które mają się dobrze, ale pozostają zamknięte, ponieważ służą zarabianiu pieniędzy.
    Jak wspomniałem w jednym z tematów, tu nie chodzi tylko o zaprojektowanie DSO. Bardziej zależy nam na stworzeniu modularnej platformy i związanej z nią społeczności, która będzie miała warunki do dalszej rozbudowy projektu. Niska bariera wejścia, pełny dostęp do materiałów oraz wsparcie przy zamówieniach grupowych na Forum powinny pomóc w popularyzacji tego sprzętu. Jeżeli powstanie coś sensownego.

  • #553 19 Mar 2019 20:00
    stmx
    Poziom 25  

    TWl napisał:
    - czy GUI w Mono jest w stanie działać na fbdev pod linuxem (tzn bez X-serwera i innych waylandów)? Pytam, bo nie jestem pewien jak wydajnie będzie to działać w środowisku X11.
    Mnie na RPi dzieła bez problemu. Są wrapery typu libopentk np. i mozesz bez X-ów.

    Dodano po 1 [minuty]:

    Marek_Skalski napisał:
    Mam nadzieję, że znajdziemy model licencji, który będzie satysfakcjonujący, np. CERN, MIT, GPL?.
    Marku - GPL ma akurat sens bo nie pracuje się dla kogoś za darmo a przy okazji "kredyt" dla autorów i konieczność otwarcia źródeł ma sens

  • Pomocny post
    #554 19 Mar 2019 21:03
    MODI
    Poziom 16  

    stmx napisał:

    Marek_Skalski napisał:
    Mam nadzieję, że znajdziemy model licencji, który będzie satysfakcjonujący, np. CERN, MIT, GPL?.
    Marku - GPL ma akurat sens bo nie pracuje się dla kogoś za darmo a przy okazji "kredyt" dla autorów i konieczność otwarcia źródeł ma sens

    Proponuje kernel+ sterowniki na licencji GPL2 jak większość w linuxie.
    GUI z kolei musi być GPL3/LGPL3 aby być zgodnym z licencją QT.
    Co do licencji na kod na FPGA i sam druk nie mam pojęcia.
    Widzę że kolega @TWl programuje w VHDL tak jak ja, więc proponuje na ten język postawić. Środowisko Vivado pozwala mieszać VHDL i Verilog w razie czego.

  • #555 19 Mar 2019 21:14
    Marek_Skalski
    Moderator Projektowanie

    Jakieś 15 lat temu próbowałem zapoznać się z FPGA Xilinx. Jako elektronik,wybrałem projektowanie układu przez rysowanie schematów w edytorze z podstawowych elementów - bramek, przerzutników, itp. Dla mnie to było bardziej naturalne niż pisanie. Po czasie stwierdziłem, że to zabiera za dużo czasu i wróciłem do mikrokontrolerów. Wiem, że jest święta wojna między Verilog i VHDL, dlatego sprawę zostawiam Wam. Chętnie się podszkolę.

  • #556 19 Mar 2019 22:01
    Janusz_kk
    Poziom 20  

    Marek_Skalski napisał:
    KiCad'a nie potrafię zrozumieć, drażni mnie

    Ale Kicad jest naprawdę łatwy do opanowania, prosty w użyciu i wspierany przez cern,
    daje to gwarancję że szybko nie zniknie albo że ktoś go ograniczy do demo.

    Co do założeń:
    Marek_Skalski napisał:
    zamiast 4x 250 MSps 200MHz+, proponujemy tylko (2+)2x 100 MSps i 10 MHz. Może będzie drożej, ale jest to realny cel.

    Widzę że wreszcie zeszliśmy na ziemię, jestem za podstawową wersją, uważam że w tej
    podstawowej drogie fpga będzie niewykorzystane i szkoda kasy, 100Mhz obsłuży prawie każde
    lepsze cpld, do tego procek z usb do sterowania, wyświetlacz to smartfon lub tablet z aplikacją po usb.

    Dodano po 2 [minuty]:

    Marek_Skalski napisał:
    Jest też trzecia opcja, aby temat był związany z Forum i prowadzony w sposób przyszłościowy i po angielsku

    jeśli już to jako tłumaczenie, bo nie wszyscy mieli w szkole angielelski, ja się uczyłem rosyjskiego i już nie mam szans
    się nauczyć lepiej angielskiego niż marne dukanie dokumentacji.

  • Pomocny post
    #557 20 Mar 2019 00:36
    TWl
    Poziom 20  

    MODI napisał:

    Co do licencji na kod na FPGA i sam druk nie mam pojęcia.

    Na FPGA proponuję Solderpad a na PCB CERN OHL.

    Cytat:

    Widzę że kolega @TWl programuje w VHDL tak jak ja, więc proponuje na ten język postawić.

    Programuję w VHDL ale nie znoszę tego języka. Prywatnie wolę Veriloga, mix VHDL-Verilog też jest OK.

    @Marek_Skalski: Co Cię szczególnie irytuje w KiCadzie? Pytam serio, bo może jest to łatwe do poprawienia. Jaka jest ostatnia wersja, której używałeś? CM dla mnie odpada, podobnie jak wszystkie programy, które dane trzymają "w chmurze". To zbyt duże ryzyko dla projektu. Zwykły AD jest bardzo dobrym programem ale jego cena jest zaporowa.

    TW

  • #558 20 Mar 2019 00:50
    Marek_Skalski
    Moderator Projektowanie

    @szwedoman Zgadzam się, że warto mieć pokrętła. Wystarczy spojrzeć jak "wygodny" jest interfejs dotykowy/klikany w Red Pitaya. Nie jestem nerwowy, ale jak na to patrzę, to zastanawiam się jak długo trzeba medytować po takich pomiarach ;)
    Wada pokręteł to dodatkowa przestrzeń obok wyświetlacza, trochę mechanicznego design'u (to akurat spokojnie mogę zrobić) oraz koszt elementów mechanicznych, ich interfejsu i montażu. Jak tylko znajdę chwilę, to spróbuję coś zaprojektować dla podstawowej wersji 2-kanałowej.

    @TWl Nie potrafię zrozumieć logiki stojącej za tworzeniem zupełnie osobno obudowy, symbolu i modelu elementu. Wyrosłem na Eagle, w którym zrobienie modelu elementu to dla mnie kilka kliknięć. W KiCad jest filozofia, której nie potrafię zrozumieć. Ostatnio próbowałem chyba 1,5-2 lata temu. Już łatwiej było mi się odnaleźć w DipTrace.

    @Janusz_kk Dla osób aktywnie działających w projekcie komunikacja po angielsku chyba nie będzie problemem. Dla osób obserwujących i chętnych do wykonania urządzenia, będzie przetłumaczona dokumentacja po polsku. Obiecuję. W czasie prac nad dwiema pierwszymi wersjami będzie też na bieżąco raportowany postęp w pracach. Jak nie będzie postępu, to też będę o tym pisał. :)

    @stmx Zgadzam się z Tobą. Od teraz będziemy operować napięciem wejściowym, a nie zakresami pomiarowymi. Liczba podziałek na graticuli to zwyczajowo ±5 w pionie i tak samo w poziomie, ale pojawiają się już DSO z nieregularnymi podziałkami, np. ±4 działki w pionie i ±6 w poziomie, aby lepiej wykorzystać powierzchnię ekranu.

  • #561 20 Mar 2019 08:14
    max-bit
    Poziom 25  

    Spokojnie wiem
    Zacytuję:
    "Programuję w VHDL ale nie znoszę tego języka. Prywatnie wolę Veriloga, mix VHDL-Verilog też jest OK. "

    Jak to coś wnosi do projektu :) to ja jestem.

    A ja prywatnie wole ASIC i co z tego ?

    Dodano po 8 [minuty]:

    I jeszcze po prostu pojawia się tu koncert życzeń albo osobistych kto co lubi ...
    A chciał bym zauważyć że nawet opisu blokowego nie ma ... a to słabo ...
    Trzeba zrobić blok diagram założenia i wymagania poszczególnych modułów.
    Później ustalić interkonektory specyfikacje komunikacji bloków ...
    a następnie można sobie troszeczkę dywagować jak ma być oprogramowana jednostka (dana) wykonawcza.
    Tak mi się wydaje ... z mej wiedzy ale może jest ona jakaś nie aktualna :)

  • #562 20 Mar 2019 08:39
    Marek_Skalski
    Moderator Projektowanie

    Jak próbowałem metodycznie, to pisaliście że to dyrdymały i trzeba działać.... i to szybko, zanim dotrze do nas, że to bez sensu ;)

    Staram się prowadzić temat etapami. Schemat blokowy był prezentowany wcześniej, zanim wybraliśmy ADC. Część specyfikacji jest przygotowana. Problemem jest silnik Forum, który nie pozwala na modyfikację plików. Migracja w chmurę, np. google documents, nie każdemu odpowiada i może rodzić problemy z RODO. Za kilka dni mam zamiar otworzyć tematy dedykowane poszczególnym modułom. Powinno to ułatwić komunikację.
    Interkonektory, o których wspominasz są powiązane z kształtem systemu. Dlatego konieczne były pewne ustalenia początkowe, np. ADC, rejestrator, wyświetlacz.
    Dla AFE nie ma tego wcale tak dużo: wejście z BNC, wyjście różnicowe dla ADC, zasilanie ±X.X V, ew. jakieś pomocnicze dla części sterującej i linia diagnostyczna (I2C/SMBus, może SPI, może UART).

    Język ma znacznie. Jeżeli każdy z nas będzie chciał pisać oprogramowanie układowe w innym języku, to nigdy nie dojdziemy do porozumienia. Nie ma tu wielu osób chętnych do pracy, dlatego narzucanie jakiegoś języka traktuję jako ostateczność i chętnie dowiem się jakie są Wasze oczekiwania i możliwości. Myślę, że potrafimy dojść do porozumienia i wypracujemy jakiś standard w tej kwestii dla FPGA oraz procesora. Język programowania musi być adekwatny do zadania, żywy, z dostępnymi darmowymi narzędziami. Użycie Brainf**k nie wchodzi w grę ;) Obecnie dyskusja dotyczy Python albo C# dla aplikacji i VHDL albo Verilog dla FPGA. Idę o zakład, że nie sposób przedstawić jednoznacznych argumentów dla któregokolwiek z tych języków, dlatego zdecyduje większość i stąd ten koncert życzeń.

  • #563 20 Mar 2019 08:49
    Grzegorz_madera
    Poziom 32  

    Marek_Skalski napisał:
    Wada pokręteł to dodatkowa przestrzeń obok wyświetlacza, trochę mechanicznego design'u (to akurat spokojnie mogę zrobić) oraz koszt elementów mechanicznych, ich interfejsu i montażu.

    I niska trwałość enkoderów. Jak już mają być przełączniki mechaniczne to przyciski. Klawisz, a pod nim mikroswitch na PCB. Tani, łatwy w wymianie i względnie trwały. To taka moja luźna sugestia na podstawie doświadczeń z chińskimi oscyloskopami i ich enkoderami.

  • #565 20 Mar 2019 09:29
    szwedoman
    Poziom 9  

    Grzegorz_madera napisał:
    Marek_Skalski napisał:
    Wada pokręteł to dodatkowa przestrzeń obok wyświetlacza, trochę mechanicznego design'u (to akurat spokojnie mogę zrobić) oraz koszt elementów mechanicznych, ich interfejsu i montażu.

    I niska trwałość enkoderów. Jak już mają być przełączniki mechaniczne to przyciski. Klawisz, a pod nim mikroswitch na PCB. Tani, łatwy w wymianie i względnie trwały. To taka moja luźna sugestia na podstawie doświadczeń z chińskimi oscyloskopami i ich enkoderami.

    Jeżeli o trwałość chodzi to można zastosować enkodery optyczne albo umożliwić wymianę enkodera po uszkodzeniu. Przyciski są dobrą opcją ale dochodzi programowanie krzywych przyśpieszenia przy przesuwaniu wskaźników i tutaj każdy użytkownik może mieć do tego inne preferencje. Moim zdaniem bardziej intuicyjne jest pokrętło by przesuwać element w miarę możliwości precyzyjnie niż polegać na zaprogramowanym skoku po naciśnięciu przycisku. Oczywiście kilka przycisków do szybkiego wywoływania funkcji jest idealnym rozwiązaniem w połączeniu z enkoderem. A co do rozmiarów przy wyświetlaczu 7" dołożenie pewnej szerokości panelu przy krótszej krawędzi wyświetlacza nie spowoduje zmniejszenia mobilności urządzenia a umożliwi ergonomiczną pracę oraz umiejscowienie dodatkowych (np. slot na kartę micro sd) elementów w miejscu łatwo dostępnym.

  • #566 20 Mar 2019 09:35
    LChucki
    Poziom 29  

    Enkodery tak czy nie?
    Dla mnie wzorem jest Tektronix i wszystko jasne.

  • #567 20 Mar 2019 09:45
    .Wiśnia
    Poziom 28  

    wyprowadzenie tematu poza elektrode nie jest dobre dla tych co chcą sie uczyć nie tylko programowania, projektowania ale tez calej otoczki zwiazanej z projektem, dyskusje na temat rozwiazan są bardzo pouczajace .
    Moze tak Panowie Włodarze wspomoga odpowiednimi zmianamu na forum .

  • #568 20 Mar 2019 10:46
    -XantiO-
    Poziom 19  

    stmx napisał:
    Python się do tego nie nadaje. Lubię jak mam napisać skrypcik. Jednak myślę że wybór powinien byc między C++ a C#.


    Jakie argumenty są przeciw Pythonowi?
    Jeśli C# to mogę też coś pomóc ale tu już nie będę w stanie szybko pisać softu bo nie będę ukrywał, że to nie mój ulubiony język.

    Marek_Skalski napisał:
    @szwedoman Zgadzam się, że warto mieć pokrętła. Wystarczy spojrzeć jak "wygodny" jest interfejs dotykowy/klikany w Red Pitaya. Nie jestem nerwowy, ale jak na to patrzę, to zastanawiam się jak długo trzeba medytować po takich pomiarach
    Wada pokręteł to dodatkowa przestrzeń obok wyświetlacza, trochę mechanicznego design'u (to akurat spokojnie mogę zrobić) oraz koszt elementów mechanicznych, ich interfejsu i montażu. Jak tylko znajdę chwilę, to spróbuję coś zaprojektować dla podstawowej wersji 2-kanałowej.

    Mechanicznie to rozwiązać na enkoderach to nie problem. Jeśli chcesz mogę wstępnie zrobić projekt panelu przedniego w SolidWorksie.

  • #569 20 Mar 2019 18:11
    Thorgus
    Poziom 12  

    Oprogramowanie takich układów ma sens tylko w C/C++ język C# nie jest przeznaczony do systemów wbudowanych lecz do aplikacji biznesowych

  • #570 20 Mar 2019 21:40
    stmx
    Poziom 25  

    Thorgus napisał:
    język C# nie jest przeznaczony do systemów wbudowanych lecz do aplikacji biznesowych
    Doprawdy? Dobrze, ze o tym nie wiedzialem jak pisałem frontend oscyloskopu i analizatora stanów logicznych. Dzięki Tobie teraz wiem że to się nie mogło udać i że magia istnieje - bo się udało