Dobre zasady programowania w Arduino... - Wersja do druku +- Arduino Polska Forum (https://forum.arduinopolska.pl) +-- Dział: Korzystanie z Arduino (https://forum.arduinopolska.pl/dzial-korzystanie-z-arduino) +--- Dział: Piaskownica (https://forum.arduinopolska.pl/dzial-piaskownica) +--- Wątek: Dobre zasady programowania w Arduino... (/watek-dobre-zasady-programowania-w-arduino) |
Dobre zasady programowania w Arduino... - PierwszyWolnyLogin - 29-04-2019 Cześć Od kilku miesięcy uczę się programować Arduino. Jak pewnie każdy zrobiłem stację pogodową która gromadzi dane z kilku termometrów, zaspisuje na SD, wysyła przez BT itd itp. Działa, gra i buczy, jestem dumny i blady Teraz będę zabierał się za ciut bardziej zaawansowane projekty - minn. sterownik pomp do nietypowego domowego C.O. / C.W.U. Dawno temu, za czasów IBM XT/AT programowałem bazy danych z dBase i Clipperze więc całkowitym ignorantem w dziedzinie programowania nie jestem, mimo tego, że już nic nie pamiętam Ale do rzeczy... Problem jaki widzę w Arduino to ograniczenia samego procesora - czyli jedna pętla, brak jakiejkolwiek wielozadaniowości itd. W typowym "termometrze" czy też regulatorze temperatury PID musimy po kolei robić różne rzeczy jak: 1. Zmierzyć temperaturę, 2. Obliczyć parametry pętli PID, 3. Odpowiednio wysterować czy to wyjście PWM, czy stycznik, 4. Obsłużyć jakieś przyciski, enkoder, poruszać się po menu, 5. Obsłużyć sytuacje awaryjne, typu brak chłodzenia, brak wody. Problem jaki widzę to zdarzenia które długo trwają - jak np. odczyt temperatury z DS18B20 - trwa prawie sekundę, w czasie której można tylko czekać, a jeśli zdarzy się błąd pomiaru to trzeba go ponowić... Pytanie - jak pisać programy, żeby działały płynnie, nie zacinały się, obsługiwały poprawnie takie elementy jak cyfrowe termometry, styczniki, wyjścia PWM, jednocześnie reagując na kręcenie gałką enkodera, łażenie po menu etc. Czy możecie polecić jakąś literaturę na ten temat, może macie rady które mogą się przydać? Chcę się zabrać za nowy projekt czegoś w rodzaju stabilizatora temperatury, z obsługą enkodera obrotowego, menu, ustawianiem parametrów enkoderem etc... Chcę to zrobić dobrze Z góry dziękuję.... PWL RE: Dobre zasady programowania w Arduino... - Jarewa0606 - 29-04-2019 https://www.freertos.org https://docs.espressif.com/projects/esp-idf/en/latest/ Wielozadaniowość i zadania. Inym słowem ESP-IDF ale najlepsze efekty są przy minimum dwurdzeniowym mikrokontrolerze. RE: Dobre zasady programowania w Arduino... - error105 - 29-04-2019 Z DSem dam Ci jeden przykład, jak woda stoi na gazie to patrzysz na nią czy się gotuje czy zostawiasz i wracasz po jakimś czasie ? Na Atmedze stawiają drukarki 3D i to działające, więc sam procek jest aż na wyrost do wiekszosci zadań amatorów RE: Dobre zasady programowania w Arduino... - PierwszyWolnyLogin - 29-04-2019 A jakieś pomysły na poprawienie płynności działania ale na Atmegach? Jak na razie mam tylko jeden - zrezygnować z termometrów cyfrowych na rzecz PT100 może ze wzmacniaczem operacyjnym. Odczyt będzie bez porównania szybszy i nie powinien blokować pętli... Jeszcze jeden pomysł, ale nie wiem czy możliwy. Czy w przypadku DS18B20 można mu wydać polecenie odczytu temperatury, wrócić do obsługi pętli i za 1s pobrać gotowe odczyty? PWL RE: Dobre zasady programowania w Arduino... - PierwszyWolnyLogin - 29-04-2019 (29-04-2019, 19:47)error105 napisał(a): Z DSem dam Ci jeden przykład, jak woda stoi na gazie to patrzysz na nią czy się gotuje czy zostawiasz i wracasz po jakimś czasie ? ... O ile dobrze zrozumiałem to mogę odczytywać temperaturę co jakiś czas, a nie za każdym okrążeniem. Tak jasne. Chociaż nie zawsze, ale powiedzmy, że w większości wypadków można co kilka sekund co najmniej... Problem jest z czasem odczytu temperatury - wynosi prawie sekundę a to potrafi zadławić. Podobny problem jest z zapisem danych na SD - też trochę trwają, chociaż szczerze mówiąc nie wiem jak długo PWL RE: Dobre zasady programowania w Arduino... - PierwszyWolnyLogin - 29-04-2019 (Nie wiem dlaczego nie mogę edytować własnego wpisu)... sensors.setWaitForConversion(0) ? - doczytam jutro PWL RE: Dobre zasady programowania w Arduino... - error105 - 29-04-2019 Jak ci aż tak na częstym sprawdzaniu zależy (co przy CO nie wiem czy jest wymagane) to daj analogowy czujnik i w każdej pętli sobie czytaj wsrtosc. Ja wolę wysłać zapytanie, i tylko sprawdzać czy jest już odpowiedz. Tylko tak też łatwo można zablokować program, bo możesz wysylac zapytania co 10ms i zawsze będziesz czekal RE: Dobre zasady programowania w Arduino... - Jarewa0606 - 29-04-2019 (29-04-2019, 19:47)error105 napisał(a): Z DSem dam Ci jeden przykład, jak woda stoi na gazie to patrzysz na nią czy się gotuje czy zostawiasz i wracasz po jakimś czasie ? Ja bym zostawił i wrócę jak zagwizda gwizdek w czajniku. A nie prościej na wasze problemy zatrudnić drugi mikrokontroler np. attiny który będziecie obsługiwał czujniki a my tylko do niego lukniemy czy są dane? RE: Dobre zasady programowania w Arduino... - error105 - 29-04-2019 Albo postawić babcie by patrzyła na czajnik, słaby pomysl z tym kolejnym uC jak jeden się nudzi RE: Dobre zasady programowania w Arduino... - kaczakat - 30-04-2019 Jak swoją wiedzę będziesz opierał tylko na demach załączonych do bibliotek pokazujących jak najszybciej coś sprawdzić czy działa to Atmega będzie tak mulić. Oczywiście DS18B20 jest wolny, bo odczyt trawa około 20ms, pisząc swoje podkręcone funkcje można zejść do 7ms (całkowicie poza specyfikacją), ale dalej się nie przeskoczy. Odczyt analogowy to dla porównania 100us, ale znowu robi się z 8x i wyciąga średnią. Z DS właśnie setWaitForConversion(0) wyłącza wbudowany w bibliotekę czas oczekiwania na zakończenie pomiaru - ale jak sam zadbasz o to by nie pytać czujnik o temperaturę wcześniej niż za 750ms przy 12bitach to wyłączasz i z 1 s tracisz na komunikację jakieś 25ms, 20 na odczyt z jednego czujnika i 5 na zlecenie wszystkim czujnikom pomiaru, wracasz za sekundę po nowy odczyt i zamykasz cykl. Temperatury też zwykle nie ma sensu mierzyć co 1s, zlecasz pomiar w 9s i odczytujesz w 10 (co 10s) i już masz obciążenie uC na poziomie 0.25% dla DS. Proszę jak łatwo zejść z 80% obciążenia do poniżej 1%. No ale można też wiele rzeczy robić w między czasie. Może to zakłócić co prawda komunikację i trzeba na to uważać, ale jeśli 1 bit w one wire trwa 60us to można wyłączyć blokowanie przerwań (swoja wersja biblioteki) i sobie stukać drobiazgi w tym czasie. Jak coś się zepsuje w komunikacji - od tego jest CRC by sprawdzać czy poszło dobrze czy źle - to można ponowić. |