ethanak

@damboTo "ułatwienie dla leni" to po prostu Arduinowy dodatkowy preprocesor (mam nadzieję że wiesz o co chodzi) i nie ma to nic wspólnego z poprawnością czy niepoprawnością danego rozwiązania. Zawsze moje rozwiązanie będzie lepsze od jednego wielgaśnego pliku .ino, w którym i tak wszyscy do wszystkiego mają dostęp. Nauka ma postępować etapami, czyli najpierw odzwyczajenie się od nawyków automatycznego wstawiania deklaracji funkcji, voidów czy inkludowania Arduino.h (za czym idzie uświadomienie sobie istnienia deklaracji) - potem możemy bawić się w enkapsulację, interfejsy, pięćset plików nagłówkowych i inne mądre rzeczy które robią wyłącznie Wielcy Mistrzowie C++ z kolegą @dambo na czele Problem w tym, że autorzy Arduinowego preprocesora zakładają, że każdy użytkownik to leń i jełop co nie potrafi sobie - za przeproszeniem - tyłka podetrzeć i trzeba zrobić Wielki Wspaniały Automat który zrobi to za użytkownika. Na szczęście można z owych ułatwień nie korzystać, co każdemu z pewnością może wyjść na zdrowie.

Zaproponuj lepsze rozwiązanie.

Owszem, zadziała. Tyle że lepiej od razu przyzwyczaić się do normalnego C++ bez Arduinowych ułatwień dla leni, czyli: void mojafunkcja(void); // tu średnik jest potrzebny void loop() { mojafunkcja(); } void mojafunkcja(void) // a tu oczywiście nie { if (trzeba_coś_zmienić()) { ustaw_docelowe_pozycje(); } porusz_serwami(); delay(20); } Chodzi o deklaracje wyprzedzające - czyli funkcja loop musi wiedzieć jakiego typu jest mojafunkcja(). Oczywiście, pod warunkiem że będziesz je poprawnie deklarować. Najlepiej zrobić sobie plik np. "common.h" z zawartością: // żeby drugi raz się przypadkowo nie włączył #ifndef COMMON_H #define COMMOH_H //i tu deklaracje funkcji extern void stac(void); extern void siad(void); extern void idz(int tempo); // a tu zmienne porozrzucane po różnych plikach extern int pozycje_serw[16]; //i co tam sobie jeszcze wymyślisz #endif Wtedy w każdym pliku .ino (głównym) i .cpp (z funkcjami) musisz tylko wpisać włączenie tego pliku i wszystkie funkcje będą się widzieć nawzajem. Przykładowo: w pliku głównym wstawiasz coś w stylu: #include "common.h" int pozycje_serw[16]; a w pliku funkcje.cpp: #include <Arduino.h> // tym razem samo się nie wstawi #include "common.h" void stac(void) { // tu ciało funkcji } W ten sposób w pliku .ino możesz wywoływać funkcję "stac", a w funkcji "stac" możesz odwołać się do tablicy pozycje_serw. Dobrze również wszelkie definicje (np numerki serw) umieścić właśnie w common.h - po to, aby wszyskie funkcje miały dostęp do tych informacji (o ile jest to pottrzebne).

Przede wszystkim zmień te definicje, bo program jest absolutnie nieczytelny. Czy za miesiąc będziesz pamiętał że SERVO11 to (no, odpowiedz bez zastanowienia, udo czy kolano?) Nie byłoby lepiej cos takiego: #define SERVO_KOLANO_P 1 #define SERVO_UDO_P 2 i dalej w setup: pwm.setPWM(SERVO_KOLANO_P, MED); pwm.setPWM(SERVO_UDO_P, 250); // czymkolwiek by było 250 Dalej: tak jak mówiłem, na dzień dobry nie możesz mieć żadnych pętli wewnątrz programu z wyjątkiem głównej loop. Wyobraź sobie, że w tej głównej pętli wywołujemy funkcje przesuwające każde serwo o jakiś kawałek o ile jest taka potrzeba, aby osiągnąć jakieś docelowe położenie, i ta funkcja wywoływana jest okresowo np. co 20 msec. Wtedy pozostaje Ci tylko ustalić czasy i docelowe położenia serw, a one w jakiś magiczny sposób same się poruszą... Czyli w skrócie funkcja loop będzie wyglądać tak: void loop() { if (trzeba_coś_zmienić()) { ustaw_docelowe_pozycje(); } porusz_serwami(); delay(20); } A funkcja poruszająca serwami to dla każdego serwa: if (serwo_nie_jest_na_pozycji()) { porusz_serwem_kawałek();// gdzie ten kawałek zależny jest od zadanej prędkości poruszania się serwa } Czy coś Ci to mówi?

@Chumanistaczy tak jest w każdym mikrokontrolerze? Jeśli w dokumentacji biblioteki (w tym przypadku Wiringa/Arduino) nie mam wyraźnie napisane, że po resecie jest zero na wyjściu to zakładam, że jest hgw co i włos mi z głowy nie spadnie, jak wrzucę jedną instrukcję zerującą wyjście. Mała redundancja nikomu jeszcze nie zaszkodziła

Przynajmniej chwila uśmiechu w czasie czekania od szóstej rano, aż Imć Pan Kurier raczy wrzucić mi paczuszkę z Botlandu do paczkomatu Ciekawe, czy dzisiaj jeszcze to dostanę...

@Chumanistadawno takiego potworka nie widziałem Teraz dorób do tego regulację temperatury... A poza tym warunek początkowy to sam z siebie się weźmie? Jesteś na 100% pewien, że pinMode(11, OUTPUT) ustawi zero na pinie 11?

Jeden ale piętrowy. jeśli za mało to włącz; inaczej jeśli za dużo to wyłącz

Zgadza się

Będzie. Ten z pierwszego posta też będzie. Oba będą działać źle (Twój lepiej, ale nie całkiem dobrze). Zacznijmy jeszcze inaczej: pokazujesz początkującemu użytkownikowi kod, informując go że coś tam robi (w tym przypadku, że powyżej 200 pompka jest wyłączona). Pokaż dokładnie miejsce w kodzie, gdzie jest to sprawdzane. Bo faktycznie, powyżej 200 pompka jest wyłączona. Powyżej 175 też. A nawet powyżej 1020.

Po pierwsze: nic takiego w Twoim kodzie nie ma. Po drugie: jeśli poziom wzrośnie powyżej 200 to coś się jednak ma stać. Wiesz co? Czy w ogóle rozumiesz słowo "histereza"?

Nie kompilacja a tworzenie podglądu. Zacznij używać słów zgodnie z ich znaczeniem.

Nic takiego w tym kodzie nie widzę. Kompilacja pierwowzoru też przebiegła pomyślnie, co nie znaczy że ów pierwowzór ma jakikolwiek sens. Zdanie "Ciotkę parowozu przetaczaj po sznyclach" też jest poprawne składniowo, prawda?

No ale przecież kompilacja kodu OpenSCAD-a to jakieś ułamki sekund - to nie gcc. Owszem, stworzenie mesha czy eksport do STL trochę trwa, ale nie ma to nic wspólnego z rodzajem interfejsu (w końcu nieważne czy te wszystkie kuleczki i wałeczki ustawiasz myszką czy wpisujesz z klawiatury). Chcesz powiedzieć, że w Fusionie plik STL tworzony jest natychmiast, a OpenSCAD potrzebuje na to pół godziny???

A to niedobrze byś napisał. Po co dwa razy czytasz A1, raz żeby wyświetlić a drugi raz aby użyć w programie? Czemu jakiś delay a nie uczciwa histereza? Dlaczego 10 sekund?