Arduino Polska Forum

Pełna wersja: Dobre zasady programowania w Arduino...
Aktualnie przeglądasz uproszczoną wersję forum. Kliknij tutaj, by zobaczyć wersję z pełnym formatowaniem.
Stron: 1 2 3 4 5
Cześć

Od kilku miesięcy uczę się programować Arduino. Jak pewnie każdy zrobiłem stację pogodową Wink
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 Smile

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 Wink 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 Smile

Z góry dziękuję....

PWL
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.
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 ? Smile

Na Atmedze stawiają drukarki 3D i to działające, więc sam procek jest aż na wyrost do wiekszosci zadań amatorów Smile
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
(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 ? Smile...

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 Wink

PWL
(Nie wiem dlaczego nie mogę edytować własnego wpisu)...

sensors.setWaitForConversion(0) ? - doczytam jutro Smile

PWL
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
(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 ? Smile

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?
Albo postawić babcie by patrzyła na czajnik, słaby pomysl z tym kolejnym uC jak jeden się nudzi
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ć.
Stron: 1 2 3 4 5