Przeszukaj forum

Na płytce cały czas świeci sie dioda podpisana L nigdy wczesniej nie swieciła bez przerwy. A tu zrzut błędu podczas wgrywanie. Takie dodatkowe pytanie zna ktos jakis fajny kod do paska led adresowalneg LED RGB WS2812B ?

cześć Mam taki problem , mianowicie z kodem do arduino. Jeżeli do przekaźnika nie jest podłaczony żaden odbiornik to zostaje włączony lub wyłączony, jeżeli podłącze odbiornik to przekaźnik zawsze ustawi sie w takiej pozycji ze odbiornik nie świeci nie wazne jak go podłacze. chciał bym uzyskac efekt po naciśnieciu guzika 1 przesterowuje sie przekaznik 1 i zostaje w styku tak długo do puki nie wcisnę przycisku 2 raz. Chodzi tu o oświetlenie w suficie i włączanie poszczególnych lamp. Prosze o pomoc , walczę z tym już troszkę.

Witam Zaczynam swoją przygodę na studiach z programowaniem i na samym początku dostaliśmy takie zadanie, bardzo proszę o pomoc w rozwiązaniu. Zaimplementuj klasę Pizza jako immutable. Uwzględnij takie właściwości jak: ilość pomidorów ilość sera rozmiar pizzy (średnica) rodzaj ciasta (cienkie, średnie i grube) - jako ENUM Dodaj metody typpu setter, które zmieniają stan poprzez tworzenie nowych obiektów. Stwórz kilka obiektów klasy Pizza i spróbuj zmienić ich stan.

Wstęp Jeśli sięgnąłeś po ten artykuł, to prawdopodobnie jesteś programistą, a co więcej, chcesz być lepszym programistą! To bardzo dobrze, ponieważ rynek IT potrzebuje lepszych programistów, a wytwarzanie czystego kodu według przyjętych standardów programowania jest zdecydowanym krokiem w tę stronę. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Czym właściwie jest czysty i dobry kod? Na to pytanie nie ma jednoznacznej odpowiedzi. Istnieje jednak zbiór pewnych reguł i narzędzi, które skutecznie wspomogą pracę programisty, a stosowane w całym zespole, polepszą jego efektywność i skuteczność. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 Jak więc tworzyć oprogramowanie pozbawione błędów? Podstawową regułą jest stosowanie właściwie dobranych nazw opisujących zmienne, funkcje czy struktury – jeśli kwestia ta nie jest spełniona, to żadna konwencja nie zda egzaminu. Nazwa taka powinna być odpowiedzią na wszystkie ważne pytania – w jakim celu istnieje, co robi, jakiego jest typu i jak jest używana. Jeżeli nazwa zmiennej wymaga komentarza, to znaczy, że nie ilustruje swojej intencji (dobry kod jest samokomentujący!). Przedrostki określające typy zmiennych Przykładowe przedrostki określające typy zmiennych: diGripperOpen – cyfrowy sygnał wejściowy mówiący, że chwytak jest otwarty; doGripperOpen – cyfrowy sygnał wyjściowy mówiący, aby chwytak został otwarty; aiTemperatureSensor – analogowy sygnał wejściowy czujnika temperatury; giTemperatureSensor – grupowy sygnał wejściowy czujnika temperatury (cyfrowy sygnał zakodowany na przykład na 16 bitach); nIndex – zmienna typu int zawierająca dane licznikowe; rRadius – zmienna typu real zawierająca promień; bMP3Module_On – zmienna typu bool informująca o załączeniu modułu mp3; Nie bądźmy dowcipni (ale tylko w kodzie ;d) Jeżeli nazwy są dowcipnymi określeniami, mogą być zapamiętane wyłącznie przez osoby z identycznym co autor poczuciem humoru i tylko dopóki dane określenie nie wyjdzie z mody. Nazwa zmiennych i funkcji powinny odzwierciedlać ich znaczenie. Dowcipne hasła z najnowszego standupu Rafała Paczesia zostawmy na integrację po pracy. Jedno słowo na pojęcie Należy stosować zasadę jedno słowo na jedno abstrakcyjne pojęcie i trzymać się jej w całym swoim programie. Na przykład diHumiditySensor. Nie twórzmy zgadywanek! Należy unikać używania różnych określeń do jednego celu. Powoduje to brak jednoznaczności. Czujnik zmierzchu oprogramowany w kodzie musi mieć jedną nazwę – używanie zamiennej terminologii jak czujnik optyczny, czujnik zmierzchu czy czujnik zmierzchowy powodują tylko bałagan w kodzie. Jeśli w systemie, który programujemy mamy kilka czujników, dla ich rozróżnienia nazwijmy je zgodnie z ich rolą i lokalizacją – nie stosujmy na przykład: aiHumiditySensor, aiMoistureSensor, aiWetnessSensor a na przykład aiHumiditySensor_Room, aiHumiditySensor_Kitchen, aiHumiditySensor_Bathroom. Dodajmy znaczący kontekst Jeśli mamy grupę danych, możemy posłużyć się różnymi zabiegami (w zależności od możliwości języka w jakim programujemy), aby panował w nich ład i porządek, grupując np. dane adresowe jako addrFirstName, addrLastName, addrState i tak dalej. Dzięki temu inni programiści będą wiedzieli, że zmienne te są częścią większej grupy danych. Możemy również użyć struktury, klasy – wszystko w zależności od języka programowania. Stosujmy terminologię klienta Jeśli tylko to możliwe, to do nazewnictwa zmiennych stosujemy terminologie klienta – jeśli istnieją dwa lub więcej terminów klienta na jedno pojęcie, wybieramy jedno i konsekwentnie się do tego stosujemy. Na przykład jeśli programujemy system do zarządzania produkcją u klienta, który wytwarza pakiety baterii z ogniw, używajmy zmiennych nBatteryIndex, bBatteryPresent itd. Podsumujmy dobre nazwy w kodzie przedstawiają intencje; bez mylących i fałszywych wskazówek; bez zbyt subtelnych różnic; są spójne; można je wymówić; łatwo je wyszukać; nazwy zmiennych mają rzeczowniki; nazwy funkcji mają czasowniki; dowcipne nazwy mogą nie być zrozumiane; dodajemy znaczący kontekst; nazwy zmiennych, funkcji, podprogramów w języku angielskim; zmiana nazwy na czytelniejszą to nic złego. Stosujmy dobry, konsekwentny styl Jak zapewnić tę czytelność? Po pierwsze: nazwy - zmiennych, stałych, funkcji, klas, metod, struktur itd. Każda nazwa powinna być znacząca, chyba że ma marginalne znaczenie. Jednoliterowe nazwy mogą się nadawać do zmiennych tymczasowych, takich jak np. zmienne pętli, ale tylko i wyłącznie wtedy. Nazwy powinny odzwierciedlać zastosowanie – zmienna przechowująca indeks tablicy może nazywać się „index”, a funkcja dodająca do siebie dwie liczby – „add”. Trudno się nie zgodzić, że są to o wiele czytelniejsze nazwy niż np. „dupadupacycki” czy „qwert”. Jeśli chodzi o dokumentację i komentarze, to lepiej jest używać długich nazw zmiennych (o ile dany język programowania na to pozwala), procedur, programów i funkcji, które dobrze określają ich znaczenie, zamiast używać krótkich nazw i zaopatrywać ich długim komentarzem. Poza tym długie nazwy pomagają w przypomnieniu sobie działania programu jeśli zaglądamy do niego po długiej przerwie. Jaki sens mają szczegółowe komentarze? Nie powinno się pisać kodu wyłącznie czytelnego, bądź wyłącznie optymalnego. Kod powinien być zrównoważony i wypośrodkowany – na tyle zoptymalizowany na ile nie straci na czytelności. Argument czytelności można w ogóle pominąć dopiero wtedy gdy wydajność kodu jest niewystarczająca, jednak wtedy należy taki kod opatrzyć stosownym komentarzem. Komentarze – kiedy nie mają sensu? Niewiele jest rzeczy tak pomocnych, jak dobrze umieszczony komentarz. Jednocześnie nic tak nie zaciemnia modułu, jak kilka zbyt dogmatycznych komentarzy. Nic nie jest tak szkodliwe, jak stary komentarz szerzący kłamstwa i dezinformację. Komentarze nie są szminką dla złego kodu! Jednym z często spotykanych powodów pisania komentarzy jest nieudany kod. Napisaliśmy funkcję i zauważamy, że jest źle zorganizowana. Wiemy, że jest chaotyczny. Mówimy wówczas: „Hm, będzie lepiej, jak go skomentuję”. Nie! Lepiej go poprawić! Precyzyjny i czytelny kod z małą liczbą komentarzy jest o wiele lepszy niż zabałaganiony i złożony kod z mnóstwem komentarzy. Zamiast spędzać czas na pisaniu komentarza wyjaśniającego bałagan, jaki zrobiliśmy, warto poświęcić czas na posprzątanie tego bałaganu i poprawić nasz kod - czytelny kod nie wymaga komentarza. Komentarze – kiedy mają sens? W wielu przypadkach stosowanie komentarza jest jak najbardziej słuszne. Często musimy zastosować komentarz prawny z powodu korporacyjnych standardów klienta. Czasami przydatne jest umieszczenie w komentarzu podstawowych informacji – na przykład typu czy informacji o wartości zwracanej zmiennej i wtedy warto zawrzeć taką informację w komentarzu informacyjnym. Na etapie projektowania często praktyką są komentarze TODO jako notatki zagadnień, które pozostały jeszcze „do zrobienia”. Formatowanie kodu Pamiętajmy, że kod powinien być ładnie sformatowany. Należy wybrać zbiór prostych zasad, które rządzą formatowaniem kodu, a następnie w konsekwentny sposób je stosować. Jeżeli pracujemy w zespole kilku programistów, to wszyscy jego członkowie powinni przyjąć zbiór zasad formatowania i stosować się do nich. Bardzo dobrą praktyką jest stosowanie pionowych odstępów pomiędzy segmentami kodu oraz wcięć – do poszczególnych programów w pliku, do funkcji i bloków funkcji. Z naszego programu należy również usunąć cały martwy kod – to znaczy taki, który nigdy nie jest wykorzystany (na przykład kontrolują go nigdy niespełniane warunki) lub taki, który mógł służyć jedynie do testów. Zamiast stosować magiczne liczby, użyjmy stałych nazywanych – na przykład liczba 86 400 powinna być ukryta w stałej SECONDS_PER_DAY. Jeżeli wyświetlamy 70 wierszy na stronę, to liczba 70 powinna być ukryta w stałej LINES_PER_PAGE. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2

Reguła KISS, DRY oraz inne zasady dobrego programowania Reguła KISS (ang. Keep It Simple, Stupid), dosłownie zrób to prosto, idioto – Prostota (i unikanie złożoności) powinna być priorytetem podczas programowania. Kod powinien być łatwy do odczytania i zrozumienia wymagając do tego jak najmniej wysiłku. Większość systemów działa najlepiej, gdy polegają na prostocie, a nie na złożoności. Należy się więc starać, aby nasz kod podczas analizy nie zmuszał do zbytniego myślenia. Gdy po jakimś czasie do niego wrócimy i nie wiemy co tam się dzieje, to znak, że musimy nad tym popracować. Dobrą metodą jest również pisanie naszych programów raz jeszcze gdy już poznaliśmy dokładnie proces, wprowadziliśmy wszystkie zmiany jakie zgłosił nam klient w trakcie odbioru oraz po wyprowadzeniu wszystkich początkowych błędnych założeń w trakcie programowanie offline. Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac » Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 DRY (ang. Don't Repeat Yourself, pol. Nie powtarzaj się) – reguła stosowana podczas wytwarzania oprogramowania, zalecająca unikanie różnego rodzaju powtórzeń wykonywanych przez programistów - na przykład unikanie tych samych czynności podczas kompilowania, unikanie wklejania (lub pisania) tych samych (lub bardzo podobnych) fragmentów kodu w wielu miejscach. Wielokrotne użycie tego samego kodu to podstawa programowania (Zmiana implementacji tylko w jednym miejscu oraz lepsza czytelność kodu oraz łatwość w utrzymaniu). Code for the Maintainer – czyli programuj tak jakbyś to robił dla osoby, która będzie później utrzymywać ten kod. Praca przy cudzym kawałku kodu to (przeważnie) najbardziej wymagająca i największa część pracy każdego programisty. Nie powinniśmy utrudniać sobie tego zadania. Zadbajmy więc o to, aby nie trzeba było się zbytnio głowić nad kawałkiem Twojego kodu. Pisz kod w taki sposób w jakim chciałbyś go otrzymać od kolego po fachu. Boy scout rule – zawsze pozostaw po sobie kod czystszy niż go zastałeś. REP - Reuse-release equivalence principle – ponowne użycie kodu to nie kopiowanie funkcji czy podprogramu z jednego projektu do drugiego. Jeżeli chcemy użyć ponownie kod, to należy go wydzielić do biblioteki, którą później możemy użyć ponownie. Klasy oraz funkcje, które są przeznaczone do ponownego wykorzystania, powinny być w jednej paczce, aby mogła stać się reużywalną biblioteką. Nie powinny się tam znaleźć te, które nie są przeznaczone do ponownego wykorzystania. W skrócie - albo wszystkie są reużywalne, albo żadne. Zdecydowanie ułatwi to edycje biblioteki oraz rozbudowę. Nie zawsze zasada KISS lub DRY jest słuszna! Weźmy np. zasadę DRY – Don’t Repeat Yourself – piszemy kod, który jest reużywalny, nie powtarzamy logiki zawartej w jednym miejscu w aplikacji, w innym. Tylko, że z tego rodzą się czasem klasy czy funkcje potwory. Okazuje się, że mają wiele rozglłęzień, skomplikowaną strukturę – tylko po to, żeby nie powtórzyć się w innym miejscu. I tu mamy problem – jest to świadome naginanie reguły KISS – Keep It Simple Stupid – która mówi o tym, żeby kod był tak prosty, jak to tylko możliwe. Wniosek nasuwa się jeden – nie istnieje srebrna kula. Nie istnieje też żaden złoty środek. Nie ma idealnego scenariusza, w którym weźmiemy garść złotych myśli (nasze reguły) i mamy gotowy przepis na sukces. Trzeba pamiętać o tym, żeby nie mieć klapek na oczach. Należy umiejętnie żonglować poszczególnymi zasadami, żeby osiągnąć satysfakcjonujący, końcowy rezultat. Zasady tylko wspomagają nas jako programistów, są narzędziem, które musimy umiejętnie wykorzystać. Zmiana osoby w projekcie a jakość kodu – jaki ma to wpływ na projekt i dochód? Wraz ze wzrostem bałaganu w oprogramowaniu niewątpliwie spada efektywność zespołu, co w znacznym stopniu paraliżuje projekt. Wobec spadku efektywności osoba odpowiedzialna za dany projekt zwykle dodaje do projektu więcej osób w nadziei, że podniesie to wydajność zespołu i uda się wyprowadzić problem tak, aby klient odebrał oprogramowanie. Jednak nowe osoby nie są zaznajomione z projektem oraz procesem jaki się tam odbywa, zasadą działania współpracujących ze sobą klas, czujników itd. Nie wiedzą, na jakie zmiany projektu mogą sobie pozwolić, a jakie spowodują jego naruszenie czy też zaprzestanie działania innych części kodu projektu. Dodatkowo, tak jak wszyscy pozostali w zespole, są pod ogromną presją zwiększenia wydajności swojej pracy, często w nadgodzinach czy dniach dla nich domyślnie wolnych. Należy tutaj pamiętać, że praca programisty to nie to samo, co człowieka na produkcji. Efektywność programisty to ok 6 godzin na dobę, ponieważ jest to praca umysłowa, wymagająca skupienia oraz kreatywnego myślenia. Należy mieć również na uwadze fakt, że to nie kierownictwo, ale programista jest fachowcem w programowaniu i zarządzaniu kodem i to programista musi umieć wywrzeć na swoich przełożonych świadomość jak ważny jest czysty kod. Nic nie ma tak głębokiego i w długim czasie degradującego wpływu na prowadzenie projektu, jak zły kod. Po pierwszym nieudanym projekcie spowodowanym złym kodem, lider projektu powinien wyciągnąć wnioski, aby zapobiec podobnym sytuacjom w przyszłości. Jednym z działań mającym zapobiegać bałaganowi w kodzie jest refaktoryzacja. Spowoduje to wprawdzie dodatkowe obłożenie czasowe (refaktoryzacja jest kosztowna czasowo, ale jest istotnym elementem zarządzania projektem informatycznym), które należy wziąć pod uwagę w trakcie ustalania harmonogramu projektu, ale zmniejsza prawdopodobieństwo pisania całego kodu od nowa. Podsumowanie Podsumowując, nie istnieje coś takiego, jak szablon dobrych zasad projektowania. Styl pisania kodu należy dostosować do projektu jaki jest tworzony, jego zagadnień czy problematyki – należy jednak być w tym bezwzględnie konsekwentnym. Jeśli będziemy w taki sposób pracować, efektywność naszej pracy będzie stale rosnąć. Jeśli czytelnik artykułu jest początkującym programistą, to stosując powyższe metody zoptymalizuje i uporządkuje swój kod, a co za tym idzie, jego projekty będą bardziej satysfakcjonujące i być może dzięki temu stanie się zawodowym programistą czego z całego serca życzę. Spis treści serii artykułów: Czysty kod w praktyce - część 1 Czysty kod w praktyce - część 2 Bibliografia: Martin R. - Czysty kod. Podręcznik dobrego programisty https://pl.wikipedia.org/ https://i1.wp.com/blog.knoldus.com/wp-content/uploads/2018/06/cleancode.png?fit=743%2C656&ssl=1 https://www.wykop.pl/cdn/c3201142/comment_kIUd4zw6h9I4Wt4s2yRz977DpSEBAUOv.jpg https://i.ytimg.com/vi/Fevz-Kb4bxc/maxresdefault.jpg https://cdn5.vectorstock.com/i/1000x1000/77/09/clean-code-vector-4247709.jpg https://www.perforce.com/sites/default/files/image/2019-09/image-blog-social-writing-clean-code_0.png https://3.bp.blogspot.com/-lcAjDyJMDzw/UpOnmQVcPyI/AAAAAAAALYQ/Zqf4yEU-z-s/s640/good_code.png https://1024kb.pl/wp-content/uploads/2018/08/var-1024x516.png https://res.cloudinary.com/teepublic/image/private/s--yz3dO1aO--/t_Resized Artwork/c_fit,g_north_west,h_954,w_954/co_ffffff,e_outline:48/co_ffffff,e_outline:inner_fill:48/co_ffffff,e_outline:48/co_ffffff,e_outline:inner_fill:48/co_bbbbbb,e_outline:3:1000/c_mpad,g_center,h_1260,w_1260/b_rgb:eeeeee/c_limit,f_jpg,h_630,q_90,w_630/v1536857572/production/designs/3150589_0.jpg https://ronjeffries.com/xprog/wp-content/uploads/Photo-Dec-07-1-45-14-PM.jpg https://i0.wp.com/image.slidesharecdn.com/cleancode-110520031623-phpapp02/95/clean-code-5-728.jpg?w=584&ssl=1 https://cloudogu.com/images/blog/2018/CleanCode_TheartofProgramming.jpg https://slideplayer.com/slide/12686823/76/images/6/What+is+clean+code+Clean+code+can+be+read%2C+and+enhanced+by+other+developers.+It+has+meaningful+names..jpg https://octoperf.com/img/blog/are-you-buying-quality-software/clean-code.png https://media.makeameme.org/created/clean-code-clean.jpg https://image.slidesharecdn.com/cleancode-vortrag-03-2009-pdf-121006112415-phpapp02/95/clean-code-pdf-version-5-728.jpg?cb=1349523162 https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/cde14740-68df-45f4-ab1f-e36ee4f16a47/cleancode-7.png

Witam. Chcialbym poprosic o pomoc w dokonczeniu kodu do mojego malego projektu. Mianowicie chcialbym zrobic szafke zamykana silnikiem krokowym sterowanym przez arduino. Do mojego projektu wykorzystalem mechanizm osi Z z mojej starej drukarki 3D wraz z silnikiem i stepstickiem, ktory ma byc sterowany za pomoca arduino Nano. Po wcisnieciu przelacznika (takiego od swiatla w pokoju) w pozycji gornej na pin 13 w arduino zostaje podany stan wysoki co prowadzi do obracania sie silnika w prawo i tym samym uniesienie klapy od szafki. Zas wylacznik w pozycji dolnej podaje stan niski na pin 13 co sprawia, ze silnik sie kreci w lewo i zamyka klape. Tyle udalo mi sie zrobic. Schody zaczely sie gdy musze dodac przelaczniki typu endstop aby arduino wiedzialo kiedy ma zatrzymac silnik, poniewaz w tej chwili pracuje nieustannie albo w jedna albo w druga strone. Nie mam pojecia co nalezy dopisac lub co zmienic w istniejacym kodzie aby to dzialalo jak nalezy. Z gory dziekuje za pomoc. Oto moj kod : // Sterownik silnika krokowego do zamykania szafki // Arduino nano + silnik nema ze stepstickiem int Index; const int buttonPin = 13; // Przelacznik bistabilny int buttonState = 0; // Status przelacznika void setup() { pinMode(8, OUTPUT); //Enable pinMode(2, OUTPUT); //Step pinMode(5, OUTPUT); //Direction pinMode(buttonPin, INPUT); //Wylacznik digitalWrite(8,LOW); } void loop() { // Odczyt stanu przelacznika: buttonState = digitalRead(buttonPin); // Jesli przelacznik jest w pozycji gornej -5V- to stan wynosi HIGH - Obrot silnika w prawo: if (buttonState == HIGH) digitalWrite(5,HIGH); for(Index = 0; Index < 200; Index++) { digitalWrite(2,HIGH); delayMicroseconds(500); digitalWrite(2,LOW); delayMicroseconds(500); } // Odczyt stanu przelacznika: buttonState = digitalRead(buttonPin); // Jezeli przelacznik jest w pozycji dolnej -GND- to stan wynosi LOW - Obrot silnika w lewo: if (buttonState == LOW) digitalWrite(5,LOW); for(Index = 0; Index < 2000; Index++) { digitalWrite(2,HIGH); delayMicroseconds(500); digitalWrite(2,LOW); delayMicroseconds(500); } }

Witam, buduję swojego jeżdżącego robota sterowanego z aplikacji na telefon. Znalazłem w internecie poniższy kod: #include <math.h> /*BTS7960 Motor Driver Carrier*/ const int MotorRight_R_EN = 4; // Pin to control the clockwise direction of Right Motor const int MotorRight_L_EN = 5; // Pin to control the counterclockwise direction of Right Motor const int MotorLeft_R_EN = 8; // Pin to control the clockwise direction of Left Motor const int MotorLeft_L_EN = 9; // Pin to control the counterclockwise direction of Left Motor const int Rpwm1 = 6; // pwm output - motor A const int Lpwm1 = 7; // pwm output - motor B const int Rpwm2 = 2; // pwm output - motor A const int Lpwm2 = 3; // pwm output - motor B long pwmLvalue = 255; long pwmRvalue = 255; byte pwmChannel; const char startOfNumberDelimiter = '<'; const char endOfNumberDelimiter = '>'; int robotControlState; int last_mspeed; void setup(){ /* For Arduino Mega 2560 Serial1 RX - pin 19 Serial1 TX - pin 18 */ Serial1.begin(9600);//Default Bluetooth Baudrate for HC-05 //Setup Right Motors pinMode(MotorRight_R_EN, OUTPUT); //Initiates Motor Channel A1 pin pinMode(MotorRight_L_EN, OUTPUT); //Initiates Motor Channel A2 pin //Setup Left Motors pinMode(MotorLeft_R_EN, OUTPUT); //Initiates Motor Channel B1 pin pinMode(MotorLeft_L_EN, OUTPUT); //Initiates Motor Channel B2 pin //Setup PWM pins as Outputs pinMode(Rpwm1, OUTPUT); pinMode(Lpwm1, OUTPUT); pinMode(Rpwm2, OUTPUT); pinMode(Lpwm2, OUTPUT); stop_Robot(); }// void setup() void loop(){ //int i = 0; if (Serial1.available()) { processInput(); } }// void loop() void processInput (){ static long receivedNumber = 0; static boolean negative = false; byte c = Serial1.read (); switch (c){ case endOfNumberDelimiter: if (negative) SetPWM(- receivedNumber, pwmChannel); else SetPWM(receivedNumber, pwmChannel); // fall through to start a new number case startOfNumberDelimiter: receivedNumber = 0; negative = false; pwmChannel = 0; break; case 'f': // Go FORWARD go_Forward(255); //Serial.println("forward"); break; case 'b': // Go BACK go_Backwad(255); break; case 'r': turn_Right(255); break; case 'l': turn_Left(255); break; case 'c': // Top Right move_RightForward(255); break; case 'd': // Top Left move_LeftForward(255); break; case 'e': // Bottom Right move_RightBackward(255); break; case 'h': // Bottom Left move_LeftBackward(255); break; case 's': stop_Robot(); break; case 'x': pwmChannel = 1; // Rpwm1 break; case 'y': // Lpwm1 pwmChannel = 2; break; case '0' ... '9': receivedNumber *= 10; receivedNumber += c - '0'; break; case '-': negative = true; break; } // end of switch } // void processInput () void stop_Robot(){ // robotControlState = 0 if(robotControlState!=0){ //SetMotors(2); analogWrite(Rpwm1, 0); analogWrite(Lpwm1, 0); analogWrite(Rpwm2, 0); analogWrite(Lpwm2, 0); robotControlState = 0; } }// void stopRobot() void turn_Right(int mspeed){ // robotControlState = 1 if(robotControlState!=1 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, 0); analogWrite(Lpwm1, mspeed); analogWrite(Rpwm2, mspeed); analogWrite(Lpwm2, 0); robotControlState=1; last_mspeed=mspeed; } }// void turn_Right(int mspeed) void turn_Left(int mspeed){ // robotControlState = 2 if(robotControlState!=2 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, mspeed); analogWrite(Lpwm1, 0); analogWrite(Rpwm2, 0); analogWrite(Lpwm2, mspeed); robotControlState=2; last_mspeed=mspeed; } }// void turn_Left(int mspeed) void go_Forward(int mspeed){ // robotControlState = 3 if(robotControlState!=3 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, mspeed); analogWrite(Lpwm1, 0); analogWrite(Rpwm2, mspeed); analogWrite(Lpwm2, 0); robotControlState=3; last_mspeed=mspeed; } }// void goForward(int mspeed) void go_Backwad(int mspeed){ // robotControlState = 4 if(robotControlState!=4 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, 0); analogWrite(Lpwm1, mspeed); analogWrite(Rpwm2, 0); analogWrite(Lpwm2, mspeed); robotControlState=4; last_mspeed=mspeed; } }// void goBackwad(int mspeed) void move_RightForward(int mspeed){ // robotControlState = 5 if(robotControlState!=5 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, mspeed*0.4); analogWrite(Lpwm1, 0); analogWrite(Rpwm2, mspeed); analogWrite(Lpwm2, 0); robotControlState=5; last_mspeed=mspeed; } }// void move_RightForward(int mspeed) void move_LeftForward(int mspeed){ // robotControlState = 6 if(robotControlState!=6 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, mspeed); analogWrite(Lpwm1, 0); analogWrite(Rpwm2, mspeed*0.4); analogWrite(Lpwm2, 0); robotControlState=6; last_mspeed=mspeed; } }// move_LeftForward(int mspeed) void move_RightBackward(int mspeed){ // robotControlState = 7 if(robotControlState!=7 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, 0); analogWrite(Lpwm1, mspeed*0.4); analogWrite(Rpwm2, 0); analogWrite(Lpwm2, mspeed); robotControlState=7; last_mspeed=mspeed; } }// void move_RightBackward(int mspeed) void move_LeftBackward(int mspeed){ // robotControlState = 8 if(robotControlState!=8 || last_mspeed!=mspeed){ SetMotors(1); analogWrite(Rpwm1, 0); analogWrite(Lpwm1, mspeed); analogWrite(Rpwm2, 0); analogWrite(Lpwm2, mspeed*0.4); robotControlState=8; last_mspeed=mspeed; } }// void move_LeftBackward(int mspeed) void stopRobot(int delay_ms){ SetMotors(2); analogWrite(Rpwm1, 0); analogWrite(Lpwm1, 0); analogWrite(Rpwm2, 0); analogWrite(Lpwm2, 0); delay(delay_ms); }// void stopRobot(int delay_ms) void SetPWM(const long pwm_num, byte pwm_channel){ if(pwm_channel==1){ // DRIVE MOTOR analogWrite(Rpwm1, 0); analogWrite(Rpwm2, 0); analogWrite(Lpwm1, pwm_num); analogWrite(Lpwm2, pwm_num); pwmRvalue = pwm_num; } else if(pwm_channel==2){ // STEERING MOTOR analogWrite(Lpwm1, 0); analogWrite(Lpwm2, 0); analogWrite(Rpwm1, pwm_num); analogWrite(Rpwm2, pwm_num); pwmLvalue = pwm_num; } }// void SetPWM (const long pwm_num, byte pwm_channel) void SetMotors(int controlCase){ switch(controlCase){ case 1: digitalWrite(MotorRight_R_EN, HIGH); digitalWrite(MotorRight_L_EN, HIGH); digitalWrite(MotorLeft_R_EN, HIGH); digitalWrite(MotorLeft_L_EN, HIGH); break; case 2: digitalWrite(MotorRight_R_EN, LOW); digitalWrite(MotorRight_L_EN, LOW); digitalWrite(MotorLeft_R_EN, LOW); digitalWrite(MotorLeft_L_EN, LOW); break; } }// void SetMotors(int controlCase) I nie mogę zrozumieć jakie zdanie mają zmienne : startOfNumberDelimiter oraz endOfNumberDelimiter ? Co one w tym programie robią ?