Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Problem z dodaniem funkcji do kodu arduino.

Saper 123233 19 Oct 2021 22:33 387 10
e-mierniki
  • #1
    Saper 123233
    Level 5  
    Witam , buduje zasilacz warsztatowy i mam problem z dodaniem funkcji która włączała by kanał 1 lub 2 za pomocą przekaźnika dodam że kod działa lecz tylko bez fragmentu który próbuję dodać.
    Chodzi o to aby po wciśnięciu i puszczeniu switch-a włączyć kanał a po ponownym wciśnięciu wyłączyć.
    Proszę o pomoc , poniżej wklejam kod do arduino.

    Z góry dziękuję .

    Code: c
    Log in, to see the code
    Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
  • e-mierniki
  • Helpful post
    #2
    ADB-6
    Level 28  
    A rezystorami podwiesiłeś wejścia do plusa? Może kontroler nie widzi zmiany stanu logicznego?
  • e-mierniki
  • Helpful post
    #3
    To_Ja92
    Level 13  
    Sprubuję pomóc, choć przynajmniej w tym poście - pytająco:

    1. Dlaczego piny które nie są rekonfigurowane w trakcie pracy zamiast w setup() konfigurowane są wielokrotnie w loop()? (wywołania pinMode() )

    2. Jaki cel mają puste pętle "while (...) {}"? Zasadniczo psuje to wzorzec narzucony przez Arduino. Słuszną drogą jest bieżące i cykliczne sprawdzanie warunków, i reakcja na nie. Również delay'e lepiej zastąpić użyciem millis() i (najlepiej) gotowych klas liczników które z tejże korzystają.

    2a. Jeśli już robić puste pętle to słuszniej jest tak jak na końcu kodu - while (blabla);

    3. " ; //Jeśli przycisk jest wciśnięty" - ten średnik ma jakiś cel ?

    4. "{}{" - bardzo brzydko robić wiele klamr w jednej linii, pomijając estetykę kodu - jaki cel mają te "gołe" klamry (bez pętli/if'a) ? Nie widzę tutaj ani zmiennych lokalnych do przesłonięcia ani innego uzasadnienia. A kod zaciemniają skutecznie.

    5. Chodzi o to aby po wciśnięciu i puszczeniu switch-a włączyć kanał a po ponownym wciśnięciu wyłączyć.
    Tymczasem po analizie "na oko" napisanego kodu wynika że wykonuje on kolejno co następuje:
    inicjalizuje piny, czeka aż przycisk będzie wciśnięty, wyłącza kanał, czeka sekundę, czeka aż przycisk będzie wciśnięty, włącza kanał, czeka sekundę, potem ten sam cykl dla 2giego kanału/przycisku, wykonuje pozostałą część funkcji loop, i tak w koło macieju.

    6. Proszę uwzględnić filtrowanie drgań styków, czy to na drodze programowej (np. limit minimalnego czasu pomiędzy reakcją na przycisk) tudzież na drodze analogowej (po za mikrokontrolerem, wymaga fizycznej rozbudowy układu).

    Teraz (w trakcie pisania) zdałem sobie sprawę że może opcja czekania 1 sekundy pomiędzy reakcjami na przycisk miało mieć na celu zrealizowanie faktu że jeden przycisk ma na przemiennie włączać/wyłączać kanał. To jest podejście do rzyci - trzymanie przycisku będzie skutkowało cyklicznym włączaniem / wyłączaniem w tempie 0,5Hz. Tu trzeba najzwyczajniej w świecie zrealizować softwarowo taki t-flip-flop. Najprościej chyba będzie (oczywiście pisząc program "zgodnie ze sztuką" i bez stosowania delay'ów i - niech ręka boska broni - "while (cośtam) {}") zapamiętać poprzedni stan przycisku, i przy każdej analizie najpierw reagować (wł/wył kanał) jeśli poprzedni = puszczony i obecny = wciśnięty po czym (zawsze) zaktualizować zapamiętany stan przycisku do aktualnego. Do tego oczywiście wspomniana wcześniej filtracja drgań styku poprzez np. uwarunkowanie reakcji od tego że od poprzedniej minęło nie mniej niż X czasu, gdzie X powinno być w zakresie kilku(set) ms.

    Acha, jeszcze jedno, warto wyrzucić wszystkie stałe w "jedno miejsce", zamiast powtarzania numerów pinów w każdym digitalWrite(xxx, yyy) zrobić stałe tudzież makra i je powstawiać wszędzie gdzie potrzebne. Późniejsza ewentualna zmiana jakiegoś pinu nie będzie wymagała przeszukiwania całego kodu "a gdzie to jeszcze trzeba to zmienić".

    ADB-6 wrote:
    A rezystorami podwiesiłeś wejścia do plusa?

    Moim skromnym zdaniem: pinMode(50, INPUT_PULLUP); podwiesił ;)

    @edit: z rozpędu w 1. napisałem init() chodziło mi oczywiście o setup()
  • #4
    Saper 123233
    Level 5  
    Witam
    1. Zmieniłem wywołania na int teraz jest troszkę lepiej.
    2. Uczę się programować od około 2 miesięcy z czego od ponad 3 tygodni walczę z tym zasilaczem może to być śmieszne.
    Wiem,że mógł bym zrobić to na szybko bez bajerów ale uznałem,że jak robić to porządnie i raz a nie potem dodawać opcje co chwila.
    3. Poprawiłem błąd.
    4. Jak już wspomniałem uczę się i staram się tak robić aby działało lecz wiem,że zawiłość kodu nie pomaga w zrozumieniu go przez kogoś kto chce pomóc.
    5. jest dokładnie tak jak opisałeś program czeka na w ciśniecie przycisku i dopiero potem wykonuje się dalsza część kodu.
    Dokładnie po dokonanych zmianach jest tak wykonuje się pętla void setup przechodzi do void loop i program czeka gdy zewrę pin 50 i jednocześnie pin 52 do masy i potem puszczę 50 a potem 52 wtedy przechodzi pętla dalej lecz wyświetlacz jest aktualizowany tylko w przypadku zmiany stanu pinuw 50 lub 52 .
    czy funkcja milis rozwiązała by ten problem gdybym użył milis zamiast delay ?

    6 Tak ten delay to włączanie na przemiennie kanału to jedyne na co wpadłem.
    Zrealizowanie softwarowego t-flip-flop-a, mógł byś rozwinąć temat np jakiś przykład lub link.
    PS. uporządkowaniem kodu miałem zająć się gdy będzie poprawnie działać gdyż od około tygodnia siedzę przy tym 11-12h dziennie ciągle coś dodaję usuwam i moim zdaniem nie ma sęsu porządkować nie działającego kodu choć jak już wspomniałem zdaję sobie sprawę ,że utrudnia to zrozumienie kodu innym którzy chcieli by pomóc , a dodatkowo jestem początkującym i dość żartobliwie ujmując męczę się z tym od dłuższego czasu a bardziej doświadczonemu napisanie i skonfigurowanie tego zajęło by tyle co nic .
    Aktualny kod.

    Moderated By Kuniarz:

    Proszę poprawić wklejanie kodu - proszę użyć znaczników SYNTAX tak jak w pierwszym poście.




    Code: c
    Log in, to see the code

    Dziękuję za poświęcony czas .
  • #5
    To_Ja92
    Level 13  
    Mówią że milczenie jest złotem, ale przepraszam z góry wszystkich, nie mogłem się powstrzymać od skomentowania.

    - W pierwszym poście autor elegancko używa tagu [ code ]
    - Pojawiają się pierwsze odpowiedzi z chęcią pomocy.
    - Autor odpowiada i wkleja "na goło" nową wersję kodu.
    - Moderator zwraca uwagę na ów "goły" nieotagowany kod, i robi to - wbrew krążącym po internetach stereotypie elektrody - całkowicie słusznie.
    - Autor zamiast poprawić post tworzy kolejny tylko po to by umieścić w nim ten sam kod zamknięty w tagi [ code ]
    - Pomijając powyższe - autorowi nie chce się wkleić prawidłowo kodu (zachowując wcięcia) tylko robi copypaste z poprzedniego posta. Skąd ten wniosek? Jeżeli klikniemy przycisk "cytuj" nad ów postem to jego źródłowy tekst zawiera te wcięcia.

    Ciekawi mnie czy znajdzie się ktoś zdesperowany do dalszych prób udzielenia pomocy. Czy ja mam ochotę? Skoro autor świadomie utrudnia pomagającym zadanie to myślę że odpowiedź ciśnie się sama.

    @edit:
    Widzę że po (lub w trakcie) pisania mojego posta autor (lub może moderator) złączył te 2 posty z kodem do kupy. Aczkolwiek ostatni podpunkt (wcięcia) pozostaje w mocy.
  • #6
    Saper 123233
    Level 5  
    @toja92 chciałem naprawić błąd lecz przy prubie wyskoczyła taka informacja ''Przepraszamy, ale twoja wiadomość była modyfikowana przez moderatora i nie możesz nic w niej zmienić. Jeżeli pragniesz cokolwiek zmienić w wiadomości skontaktuj się z administratorem.'' wiec wybierając mniejsze zło wstawiłem kolejny post a co do pomocy to przybyłem to aby prosic o pomoc lecz jesli masz zamiar dalej się wywyższac zamiast pomuc to dziękuje i tak dla jasności jesli nie masz zamiaru pomuc lub nakierowaqc na dobry trop tylko wytykac mi z wielkim obuzeniem błedy zamiast napisac jak człowiek człowiekowi to dziękuje w trakcie pisania swego posta mogłes pomyslec o tym iż megę nie mieć ''elki''jak i korzystania z niej w jednym palcu ludzie tacy jak ja nie zaglądają tu aby truć innym głowe bzdetami tylko jak ja po 3 tygodniowej walce sie zaczynają poddawać i szukają ratunku pozdrawiam
    ps. dawniej użytkownicy pomaghali a nie jak teraz same cebyle i każdy się wywyzsza bo on wie cos wiecej.
    ps. nie licze juz na jakie kolwiek odpowiedzi zkoro irytuję cie błedy osoby wchodzącej w arduino i elke , bede szukał jak zwykle odpowiedzi sam Dziekuje administratorowi za poprawienie błedu bo przypadkiem mogłem nie wiedzieć jak go poprawić.
  • #7
    To_Ja92
    Level 13  
    Quote:
    przy prubie wyskoczyła taka informacja

    W takim razie serdecznie zwracam honor w kwestii zdublowanego posta. A gniewem obarczam w zamian silnik (i ustawienia) elektrody ;)

    Quote:
    jesli masz zamiar dalej się wywyższac zamiast pomuc (...) pomuc (...) nakierowaqc (...) po 3 tygodniowej walce

    Tak, mam zamiar dalej "się wywyższać" i wytykać błędy, bo czy nie przez wytknięcie błędów dojdziemy do rozwiązania? Chyba że chodziło o gotowca, trzeba było napisać wprost.
    Jeśli spędziłeś 3 tygodnie na walce to czemu nie spędzisz 3 minut więcej żeby poprawnie napisać i sformatować post, te 3 minuty więcej twojej pracy to 15 minut mniej pracy innych żeby zrozumieć treść/kod i +10 do chęci niesienia pomocy.

    Quote:
    1. Zmieniłem wywołania na int teraz jest troszkę lepiej.

    Hmm, może zmieniłeś coś innego, tutaj ja strzeliłem gafę w poprzednim poście - chodziło mi oczywiście o setup(). Mówiąc pełnym zdaniem - wywołania pinMode umieszczamy w wnętrzu funkcji setup(). Ich obecność w loop() powoduje to że inicjalizujesz te piny non-stop cały czas.

    Quote:
    2. Uczę się programować od około 2 miesięcy z czego od ponad 3 tygodni walczę z tym zasilaczem może to być śmieszne.

    Ucz się ucz, nauka to potęgi klucz, sam może mam większy staż a dalej nie wiem wszystkiego.
    Quote:
    Wiem że mógł bym zrobić to na szybko bez bajerów, ale uznałem że jak robić to porządnie i raz a nie potem dodawać opcje co chwila.

    Może dobrze a może nie dobrze, ale jeśli kolega się uczy to może lepiej budować projekt małymi krokami. Aczkolwiek patrząc na kod tak chyba zresztą jest. Zrobić coś małego, zrozumieć jak działa, zrozumieć czemu nie działa. Potem rozbudowywać.
    Quote:
    3. Poprawiłem błąd.

    Przypomnę że mowa była o "osieroconym średniku". Więc strzelę sobię taką dygresję. Kod piszemy ładnie, starannie i czytelnie. Przede wszystkim jak się dopiero uczymy, jak będziesz mieć za sobą miliony linijek napisane, to intuicja sama będzie tym sterować, pierwsze miesiące? Musi być na tip-top. Posprzątać, porobić wcięcia, porobić komentarze, nie spać i trzymać fason. Pytanie po co? Ano po to że w ten sposób będziesz widział co napisałeś, w bałaganie ciężko się rozeznać i ciężej zrozumieć jak wielka jest różnica pomiędzy tym jak chciałeś żeby działało, jak w rzeczywistości działa i jak działać powinno.
    Quote:
    4. Jak już wspomniałem uczę się i staram się tak robić aby działało lecz wiem,że zawiłość kodu nie pomaga w zrozumieniu go przez kogoś kto chce pomóc.

    Odpowiedź jak wyżej, podkreślę jednak że ów zawiłość nie pomaga w zrozumieniu kodu bardziej tobie niż "komuś".
    Quote:
    5. jest dokładnie tak jak opisałeś program czeka na w ciśniecie przycisku i dopiero potem wykonuje się dalsza część kodu.

    Wiem że tak jest, pytanie brzmi czy tak być powinno? A nie chciał kolega może zrobić tak by możliwe było asynchroniczne obsługiwanie przycisków i wyświetlacza?
    Quote:
    czy funkcja milis rozwiązała by ten problem gdybym użył milis zamiast delay ?

    Ale jeśli kolega myśli o trywialnej zamianie jednej na drugą to nie nie nie i nie. millis() zwraca liczbę milisekund od uruchomienia programu, zasadniczo bezwzględnie ta liczba jest do niczego, ale licząc sobie różnice od aktualnego czasu a zapamiętanego wcześniej można tworzyć sobie warunki które np. zaczną być prawdziwe po x czasie od ów zapamiętania sobie w zmiennej. Przede wszystkim ta metoda pozwala unikać blokowania wykonania programu funkcją delay(). Aczkolwiek przynajmniej jako początkującemu proponuję kontynuować korzystanie z delayów w jakiś krótkich akcjach rzędu ułamka sekundy, przykładowo niech to będzie opóźnienie zapobiegające drganiom styku przycisku czy czekanie aż jakieś peryferium np. lcd zmieli wysłaną komendę i będzie gotów na kolejną.

    Quote:
    6 Tak ten delay to włączanie na przemiennie kanału to jedyne na co wpadłem.

    Zawsze lepsze takie coś niż nic. Nie idealne, ma mankamenty i można lepiej. o czym niżej.

    Quote:
    Zrealizowanie softwarowego t-flip-flop-a, mógł byś rozwinąć temat np jakiś przykład lub link.

    Mógłbym, ale zrobię to w postaci takiej ściągawki, a ewentualnie do swojego kodu sobie dostosujesz.
    Uzupełnię to o limitowanie minimalnego czasu.
    Code: c
    Log in, to see the code
    Mam nadzieję że nie namieszałem nic.


    Quote:
    uporządkowaniem kodu miałem zająć się gdy będzie poprawnie działać

    Złe podejście, powody wymieniałem wyżej.
    Quote:
    utrudnia to zrozumienie kodu innym którzy chcieli by pomóc

    Jeszcze raz wykrzyczę, że przede wszystkim utrudnia TOBIE!

    A teraz przejrzę kod aktualny i znów "wywyższę się i wytknę błędy", tak by kolega grzecznie je poprawił zamiast dalej męczyć się tygodniami nad niedziałającym kodem. Albo działającym ale inaczej niż autor miał na myśli.
    Pominę czepianie się o wcięcia, bo w wklejce ich nie ma. Pominę analizę części związanej "z miliamperami", wyświetlaczem itp. jako leżącej po za problemem z którym kolega tu przyszedł (a i biblioteki od wyświetlacza w zasadzie nie znam). Żeby się nie myliło z poprzednim postem, będę literkował.
    A) pinMode( - była mowa że mają być w setup a nie w loop (ani nie w init jak to pierwotnie z rozpędu napisałem :D ).
    B) numery pinów (A4, A5, 50, 52) zrobić w postaci stałych lub makr. Pisałem w pierwszym poście dlaczego.
    C) int(A4, HIGH); //kanał 1 Ja strzeliłem byka z tym intem, a kolega uwieżył że mówię dobrze, a wyszła z tego bzdura. Niestety, czasem mylą się nawet najlepsi, ci co się wywyższają (jak ja) tym bardziej, szczególnie jak skupią się na wywyższaniu zamiast na treści. Oczywiście wracamy do digitalWrite() i jako że te linijki prawdopodobnie mają na celu włączenie obu kanałów przy starcie (a nie lepiej zostawić wyłączone?) to proponuje przenieść do setup().
    D) dalsza częśc z pętlami while (digitalRead, polecam dobrze sformatować kod i przede wszystkim zrobić wcięcia. I sobie przeanalizować co się dzieje. Usiądź do tego kodu tak jak by był kogoś i pierwszy raz go widzisz i próbujesz zrozumieć co robi, a zauważysz że między tym co myślisz że robi teraz a tym co faktycznie się dzieje jest drastyczna różnica. Dosłownie udawaj że jesteś mikroprocesorem i wykonujesz sobie w głowie czy na kartce ten program instrukcja po instrukcji.
  • #8
    Saper 123233
    Level 5  
    Witam troszkę pogrzebałem przestudiowałem bibliotekę u8glib i teraz wsad wygląda tak.
    Uporządkowałem troszkę kod jak radziłeś ale czy wystarczająco sam oceń w każdym razie na tę chwilę bardziej go''poukładać'' nie umiem , co do mojej nie obecności na forum to jak wspomniałem bibliotekę i starałem się wpleść twój przykład z użyciem ''milis'' lecz nie bardzo mi to wychodzi ( wgrywa się bez błędów lecz gdzieś czegoś brakuje lub coś pomieszałem ) ale czuję,że jestem na dobrej drodze .
    Gdybyś mógł rzucić okiem w kod i napisać co jest nie tak był bym wdzięczny.
    PS. do drugiego kanału wystarczy zdublować zmienne mn. czas aktualny itp. oczywiście z dopiskiem naprzykład ''czas aktualny 2 '' ?
    [
    Code: c
    Log in, to see the code
  • #9
    To_Ja92
    Level 13  
    Quote:
    PS. do drugiego kanału wystarczy zdublować zmienne mn. czas aktualny itp. oczywiście z dopiskiem na przykład ''czas aktualny 2 '' ?

    W najprostszym rozwiązaniu tak, na upartego można by korzystać z wspólnych przy założeniu że nie będziemy używać wielu przycisków jednocześnie, wtedy zaoszczędzimy te kilka bajtów w pamięci (cóż za herezja w 2021 roku :D ). No ale jako uczącemu się polecam iść drogą najprostszą niż potem kopać się z koniem bo coś nie działa.
    Warto byś te zmienne ponazywał tak żeby było dokładnie wiadomo do czego się odnoszą. Te nazwy które ja użyłem były bardziej ukierunkowane na to żeby wytłumaczyć o co mi chodzi.

    A teraz co do reszty. Zabieram się za przejrzenie kodu i po kolei wypiszę tutaj wszystkie swoje uwagi.

    Code: C
    Log in, to see the code

    Jak pisałem, nazwy powinny zawierać informacje do czego się odnoszą, np. że chodzi o przycisk X.
    Oczywiście nazwa jest nazwa i służy dla programisty... no właśnie. Pisz i nazywaj rzeczy tak że jak rzucisz projekt, dostaniesz amnezji, zapomnisz swojego imienia i gdzie mieszkasz to jak przypadkiem znów ten kod znajdziesz to zrozumiesz co kiedyś miałeś na myśli.
    Warto tutaj dodać komentarz który wyjaśni do czego te zmienne służą.
    Może zaproponuję takie rozwiązanie. (Pamiętaj że to kwestia nazewnictwa estetyki i przejrzystości oraz to że nazwy nie wpływają na działanie skompilowanego programu. Btw, pozwoliłem sobie zrobić nazwy angielskie, wtedy brzmi to bardziej kompaktowo.
    Code: C
    Log in, to see the code

    Teraz osiągamy tutaj 3 rzeczy z punktu widzenia kogoś kto nie zna kodu i chce go poznać (czyli np. ciebie po miesiącu przerwy) - Nazwy zmiennych jednoznacznie odnoszą się do obiektu z którym mają związek ( taka bieda obiektowość). Nazwy zmiennych są krótkie, zwarte ale jednoznaczne. Komentarze opisują szczegółowo co do czego służy i robią to raz w jednym miejscu.

    Code: C
    Log in, to see the code

    Bardzo fajnie że tak jak prosiłem zamiast pisać numery pinów 10x w całym kodzie zrobiłeś sobie nazwy ale... zrobiłeś to na 2 sposoby jednocześnie, taki duplikat. Zdecyduj się czy chcesz zostać przy makro czy przy stałej.
    Po za tym to są stałe, więc koniecznie słowo kluczowe const przed typem.

    Code: C
    Log in, to see the code

    Ale tutaj już korzystasz z "A4" zamiast sobie zrobić nazwę.
    Jak sobie zrobisz makro albo const'a to tam też umieść komentarz do czego to wyjście, o np. tak:
    Code: C
    Log in, to see the code

    (kurcze, cały czas estetyka, ale serio czepiam się bo te 50% nadkładu czasowego zaoszczędzi 80% w przyszłości po przerwie w pracy oraz drugie tyle przy szukaniu błędów.)

    Oj, ale teraz doczytałem dalej... ii... widzę że jest funkcja drawMenu którą sobie wywołujesz w loop() wewnątrz czegoś co należy do biblioteki u2g. Więc nadszedł ten moment że pobieżnie musiałem (tak, teraz) zapoznać się z ogólną ideą jak działa ów u2g. A to co chyba nam do szczęścia potrzebne w pełni znajduje się tu: https://github.com/olikraus/u8glib/wiki/tpictureloop
    Oczywiście to sobie przestudiuj koniecznie i ze zrozumieniem 2 razy zanim przejdziesz do dalszej części mojej odpowiedzi!

    Zakładam że funkcja drawMenu ma zajmować się rysowaniem. I u2g zakłada że ów funkcja nie modyfikuje niczego i na nic nie czego, jedynie rysuje i musi rysować to samo nawet jak wywołasz ją wielokrotnie pod rząd (w linku wyjaśnione dlaczego). Więc w procedurę rysowania nie możesz wplatać obsługi przycisków itp.

    Zakładam więc że wyprujesz stąd wszystko co nie jest bezpośrednio rysowaniem obrazu i wrzucisz to normalnie w loop(), i tak to potraktuję dalej.

    Code: C
    Log in, to see the code

    A dokładnie ta ostatnia linia, nie wiem czy sam to widzisz, ale w tłumaczeniu na język ludzki brzmi to tak:
    Quote:
    Jeśli teraz przycisk jest wciśnięty a przy poprzednim sprawdzeniu był puszczony to wystaw 0 na wyjście A4.

    Za każdym razem przycisniecie przycisku powoduje zmiane wyjścia na 0... oczywiście ciągła zmiana z 0 na 0 nic nie zmienia nie ? Czekam na twoją propozycję co z tym fantem zrobić.

    (Uwagi estetyczne) roznica_czasu_od_ostatniej_reakcji można sie pozbyć, ja ją zrobiłem po to by wyjaśnić co ma na celu to odejmowanie. Nie po to żebyś żywcem kopiował. No i nazwy tych zmiennych skróć, sam wymyśl na jakie a będzie to ładniej i czytelniej wyglądać.

    Code: C
    Log in, to see the code

    Tutaj oczywiście odsyłam do tego jak działa picture loop w u8g. Jeśli to zostawimy wewnątrz picture loopa (czyli poniekąd wewnątrz drawMenu() to niby nic złego się nie stanie, po prostu każdy oddzielnie rendenerowany fragment ekranu odczyta sobie za każdym razem wejścia analogowe. Odczyty nic nie zmieniają ale mogą się zmienić w czasie, wiec jeśli akurat wyświetlana wartość trafi między dwa oddzielnie rysowane fragmenty i zmieni się napięcie to na ekranie pojawi się trochę jednej wartości i trochę innej. Przynajmniej tak to widzę.
    Ogółem dla przyzwoitości warto wszystkie dane potrzebne do rysowania ekranu "ustalić" sobie przed picture loopem. oczywiście jakieś skalowanie przeliczanie może zostać gdzie jest jako że jest deterministyczne i nie modyfikuje niczego na zewnątrz.
    Proponowane rozwiązanie, zrobić sobie zmienne globalne na [iodczytanenapiecie[/i], aktualizować je wewnątrz loop() i odczytywać je wewnątrz drawMenu()

    uffff... skończyłem
  • #10
    Saper 123233
    Level 5  
    Bardzo ci dziękuję za pomoc wreszcie działa rozwiązanie banalne ale to dzięki tobie na to wpadłem.
    Za kilka dni wstawie kod tylko go uporządkuje bo na te chwilę to więcej myślałem nad problemem niż grzebałem w kodzie dziękuje.
    Code: c
    Log in, to see the code
  • #11
    To_Ja92
    Level 13  
    Jeszcze parę bubli jest, podpowiem - // ZMIANA ZAKRESU NAPIECIA na pewno nie zadziała do końca jak powinna.

    Ale co ważniejsze, kompilator wywali ci że w funkcji drawMenu odwołujesz się do nieistniejących zmiennych.
    Jeśli to wyrzucamy po za drawMenu to albo trzeba przekazać przez argumenty, albo zrobić jako zmienne globalne żeby "się widziały".
    Tutaj jeszcze widzę że LOKALNA zmienna odczytanenapiecie1 jest zadeklarowana parę linijek niżej niż jest wykorzystana (napiecie1 = odczytanenapiecie1 * (49.50 / 1024.0);)
    no nie o to mi tu chodziło, namieszałeś, do poprawy.

    Ale same przyciski od kanałów powinny prawdopodobnie działać, to już musisz ty zweryfikować, ja tutaj tylko "mam oczy więc paczam", w kompilator tego nie wrzucam to i przeoczyć coś mogę.
    Swoją drogą, zrób sobie eksperyment z opóźnieniem minimalny_czas_reakcji i posprawdzaj kiedy to zaczyna głupieć. Dla lepszego psucia pozbądź się na czas eksperymentu obsługi wyświetlacza (ten fragment z u8g i drawMenu), to dlatego że wyświetlacz być może (nie wiem jakie) może wprowadzać jakieś zauważalne opóźnienie które skutkiem ubocznym spowolni sprawdzanie przycisków tak mocno że drganie styków przestanie broić.

    PS. prędkość odświeżania (i wykonywania loop'a) możesz najprościej sprawdzić tworząc sobie zmienną którą będziesz powiększał o 1 w funkcji loop i rysował jej zawartość na ekranie, wtedy będzie ładnie widać jak szybko zasuwa.