Jak zaprogramować ATmega8 w Bascom do obsługi wielu wątków jednocześnie?

Witam. potrzebuję zaprogramować atmega8, tak aby uP kontrolował temperaturę i sterował tranzystorem a jednocześnie obsługiwał rs232 w jakiejś pętli, która zbiera dane na PC do wizualizacji. Moje pytanie to jak zaprogramować atmega najlepiej w bascomie aby wykonywał kilka wątków jednocześnie. Aby jedna pętla nie blokowała innej pętli. pozdrawiam.

BASCOM i wątki - czarno to widzę.
To co chcesz zrobić nie wymaga stosowania wątkó, tylko dobrze zorganizowanej pętli.

Pętla mogłą by wyglądać tak:
Odczyt temperatury z ADC.
Ustawienie przekaźnika w zależności od temperatury.
Wysłanie temperatury przez RS-232.

Można by też gdzieś do tej pętli wrzucić odczyt danych z RS-232, na przykłąd w celu modyfikacji nastaw.
Odczyt na zasadzie:
Sprawdzić, czy odebrano znak (ustawiona flaga RXC w UCSRA), jeżeli tak, to jeżeli jest to znak drukowalny (kody 32 - 126 i 160-255, według ISO 8859) dodać znak do bufora i przesłać go z powrotem przez RS-232 (echo).
Jeżeli odebrano znak o kodzie 8 (backspace) a w buforze są jakieś znaki to skasować jeden. Z powrotem przesłać znaki o kodach 8, 32 i 8 (backspace, spacja, backspace) - spowoduje to skasowanie znaku z terminala.
Jeżeli odebrano znak o kodzie 10 (Line Feed), to przetworzyć zawartość bufora (sprawdzić poprawnosć, wydłubać komendy, uaktualnić nastawy itp.).
Tą sekwencję też można gdzieś do pętli wstawić i niczego nie będzie blokowała.
Żeby oszczędzić sobie kłopotu, szybkość transmisji musiał byś wybrać dość małą (powiedzmy 9600bps) i wtedy możesz odbierać znaki jak napisałem - po jednym w każdym obiegu pętli.
Przy większych prędkościach to już raczej tylko na przerwaniach, żeby nie "zgubić" znaku.

Może FreeRTOS;

http://www.freertos.org/

Pozwala na pracę w trybie rzeczywistym
Widziałem tam aplikację na AVR Atmega32

Dodano po 1 [minuty]:

Ale to nie w Bascomie

Dodano po 1 [minuty]:

tylko w GCC

Dodano po 1 [minuty]:

Z tym, że tu raczej nie mówimy o programowaniu wątkowym tylko o pracy systemu w czasie "prawie" rzeczywistym.

Dodano po 12 [minuty]:

z przełączaniem w osi czasowej , czy jakoś tak. Co zabiera dużo RAM na oddzielne stosy dla podprogramów ?!?! poprawcie mnie jeśli się myle.

Pewnie stąd minimalnym prockiem była Atmega32

Też się zastanawiam jakby można było puścicić np. 4-5 wątków "równolegle" na atmeg8:)(np. 2x I2C + LCD + RS232(kodowanie/dekodowanie komunikatow)). Nie chciałbym wgrywać FREERTOS bo ten uC jest chbya za maly aby można było wgrać ten SO (poprawcie mnie jeżeli się myle). Może komuś się to udało? Jeżeli tak to bardzo prosiłbym o wypowiedz na ten temat:) lub jakieś wskazówki jak to zrobić.

ludzie o jakich wy wątkach mówicie na takich prockach - tak jak wyżej kolega shg podpowiedział - odpowiednia organizacja pętli głównej a do tego ewentualne użycie przerwań i robicie bez problemu wszystko o co tu pytacie. Przecież wszyscy tak robią - wystarczy troszkę zaczytać i popatrzeć przykłady programów w Bascom, C lub asemblerze co kto woli i proszę

albo "zaczytać" jakąś książkę - i też się dużo wyjaśni. Bo podejrzewam, że pytacie o wątki myśląc o poczciwym PCcie a też do końca nie wiecie jak one naprawdę działają i stąd te skróty myślowe, że wątki same coś za programistę zrobią

pozdrawiam

Pętla ma tą drobną wadę, że jeśli w nią wrzucisz jakieś funkcje warunkowe to nigdy nie wiesz, co jaki czas się dokładnie obróci takie tam. Przy jednym warunku to jeszcze nic, ale już przy n rozgałęzieniach, policzenie najgorszego możliwego czasu obrócenia pętli staje się utrudnione.

Bo jak warunek nie spełniony to sprawa krótka skok, a jak spełniony to trzeba coś po drodze wykonać, zazwyczaj nikt nie dba o to ile jedno i drugie trwa, chyba że sobie cykle z assemblerze wyliczy, a więc pracując na pętli musisz stosować przerwania, co by ci jakieś zdarzenie sprzętowe nie uciekło .

Być może dla 1 tranzystora, 1 czujnika temperatury i 1 komunikacji z UARTEM na niskich baudach szkoda zachodu i tu pętla wystarcza. Poprostu użyjesz szybszego zegara i wszystko będzie OK .

Dla zapewnienia poprawności transmisji wystarczy, że wpropwadzisz sprzętową kontrolę transmisji CTS/DTR {oczywiście dla szybkości rzędu 38400 i wyżej} lub jakieś CRC itd. Wizualizacja też ma swój czas opóźnienia więc masz jeszcze kupę czasu na ustawienie tranzystora i odczytanie przetowornika A/C.
Tranzystor to zatrzask, a temperatura jest wolno zmienna.

RTOS natomiast na sztywno dzieli czas pomiędzy kilka funkcji , przełączając procesor.

Gdybyś chciał wiedzieć dokładnie na osi czasu co się dzieje z jakimś określonym urządzeniem, a nie chciał przerywać pracy procesora w sposób zakłócający ten okres, [przerwania] to RTOS jest bardzo mile widziany

Odczyta czujnik i obliczy wynik w ściśle określonych na osi czasowej odcinakch czasu. Następnie wykona transmisję , i w kolejnym kroku zinterpretuje wynik , jeśli któraś z czynności nie będzie miała nic do roboty to poprosu procesor zatrzyma się na przydzielony czas, po czym przyjdzie kolejne zadanie i kolejne zadanie itd.

Natomiast z czystym sumieniem będziesz mógł powiedzieć, że dany pomiar lub inne zadanie jest wykonane, co ściśle określony czas itd.itd.
Niestety przy RTOSie należy zapomnieć o przerwaniach sprzętowych lub stworzyć ich obsługę pośrednią (driver).

W każdym innym przypadku, np pętla z warunkami, użyłbyś zegara i przerwania zegarowego. Potem drabinki priorytetów, a potem to już troszkę loteria z megahercową częstotliwością działania, czy wygra UART czy Timer itd itd.

Zazwyczaj wszystko działa dobrze, a jak nie to zawsze jest jeszcze wyrocznia WatchDog tak sobie piszę

W sumie wykorzystanie całego systemu RTOS wcale nie jest w tym wypadku konieczne:) możesz taki pseudo RTOS zoorganizować samodzielnie, ale przy 1 cylku na takt zegara , to z tymi czynnościami procsor klasy AVR wyrobi się w pętli.

Dodano po 9 [minuty]:

RTOS pozwala np. na robienie naraz kilku jakiś szczególnie długich obliczeń logarytmów, funkcji trygonometrycznych etc. równolegle w ten sposób że rozpoczyna obliczenie, przerywa wykonuje obsługę czegoś tam i wraca do dalszych obliczeń, i znów przerywa wysyła coś tam itd. itd itd.
Jak już policzy co ma policzyć to w międzyczasie z n razy mógł zrobić coś innego.
W pętli to mogłoby zaboleć ... bo procesor byłby zablokowany na jednym obliczeniu,a co najwyżej sprzęt zostałby obsłużony w przerwaniu.

Dodano po 9 [minuty]:

Natomiast jeśli Atmega ma pracować jako akwizytor do zbierania danych oraz wykonawca zadań specjalnych od wyższej inteligencji programu na PC, to jej moc obliczeniowa pozwoli na zdecydowanie więcej działań w każdym obiegu pętli programowej.

Nie sadze aby było tam tyle zadań dla procesora ze ta wielowątkowość jest potrzebna. Nie znam bascoma wiec nawet nie wiem czy da sie to tam zrealizować

Tym bardziej że wielowątkowość też zabiera trochę czasu. I przydaje sie tam gdzie ma znaczenie wykonywanie wielu operacji jednocześnie a nie jest konieczny czas tego wykonania. A program tak czy siak będzie wykonywał sie na jednym rdzeniu procesora.

Od tego są przerwania by zadania realizować wtedy kiedy trzeba i od tego są bufory aby szybko zbierać dane które mogą zniknąć za jakąś chwilke.

Cała reszta jest już tylko kwestią gustów, chyba że mamy tak dowalony obliczeniami procek, że zaczynamy sie martwić czy nadąży.
Wtedy pozostaje asembler, w którym wiele rzeczy można przyspieszyć. A potem jedynie mocniejszy procesor.

Zwykle jest tak że procesor i dany algorytm ma określoną możliwość przerobu, i nic tutaj poza szybkimi algorytmami sie nie poradzi.

Ja osobiście w takich projektach krytycznych dziele program zawsze na kawałki, takie które nie mogą czekać, na takie które mogą trochę czekać i na takie które jak sie nie doczekają to sie nic nie stanie

Pragnę uściślić metodę programowania "w pętli". Przecież gdy jakiś warunek nie jest spełniony, program nie musi "ryć w miejscu", wystarczy ustawić jakąś flagę i szurum-burum dalej... a dalsze działanie odczytuje stan flagi i albo coś robi, albo przekazuje dalej moc procesorka... Na tym z grubsza polega programowanie zoptymalizowane pod względem wykorzystania mocy procesora, jakby się uparł, to można nazwać to wątkami, tylko przestrzeń rejestrów jest wspólna i trzeba ją kontrolować - najlepiej trzymać kopie wartości w RAM.
Jako przykład polecam : https://www.elektroda.pl/rtvforum/topic530034.html#2731627

Light-I ja nie twierdzę że wpływ niespełnienia warunku jest, czy nie jest istotny dla mocy procesora, generalnie chodziło mi o sprawy czasowe dotyczące testowania warunków co ściśle określony czas .

Jeśli realizacja 1 warunku zawiera 100 cykli, a jego niespełnienie tylko 1 cykl porównania.

Kolejny warunek znów daje 100 cykli jeśli spełniony i 1 cykl jeśli niespełniowny.

To najlepszy wypadek da czas testowania pierwszego warunku po 2 cyklach , najgorszy aż po 200 cyklach takie tam .

Poprawnie żeby zachować stabiloność musiałbyś uzupełnić brakujace rozkazy NOP lub wait chyba że nie zależy ci akurat na testowaniu co określony czas tylko ogólnie na testowaniu.
Liczba niezależnych timerów w mikroprockach jest niestety ograniczona więc praca w przerwaniach ....

Dodano po 22 [minuty]:


trol.six napisał:

Cytat:

Tym bardziej że wielowątkowość też zabiera trochę czasu.

Tak głównie sterowanie przełączeniem procesora z jednego stosu na drugi stos oraz odtworzenia i zapisania stanu rejestrów na te stosy, czysty asm oczywiście - przynajmniej tak ujmują to autorzy FreeRtosa w przykładzie. To dość dużo więc dla zdarzeń szybkozmiennych 1 rozkazowych szkoda Zachodu.
Ale jeśli dany proces ma już kika, kilkaset linii ... i będzie trwał kika ms szkoda byłoby zając procek na tak długo jednym zadaniem
Przykłąd przeliczenie poziomu napięcia z przetwornika AC na dB S/N = 20 log U1/U2
Przy małych rożnicach napięc U1/U2 algrytm jest bardzo szybki, a przy większych nieco wolniejszy i nie wiemy z góry ile to obliczenie będzie trwać


Sam autor nie określa, ostatecznych zastosowań, więc trudno powiedzieć ile ticków na dany proces efektywnie wykorzysta moc procka

Natomiast podział na procesy, które mogą poczekać i na te które nie mogą czekać jest, w przypadku procesów ciągle powtarzalnych jest nie do końca słuszny.
Jeśli czas trwania procesów oczekujacych jest dłuższy od okresu powtórzeń, bo kiedy w końcu te procedury oczekujące mają się wykonać??. Recepta szybszy procesor itd.

Rozumiem , że rozmawiamy o zadaniach których czas powtórzenia jest liczony conajmniej w skali setek lub tysięcy cykli, wtedy stosowanie RTOS to jak strzelanie z armaty do muchy co ja mówie nawet haubicy

Jeżeli nam procesor liczy kupe czasu coś, i ma oddać troche swojego cennego czasu podczas tego liczenia, a nie da sie tego zrealizowac na przerwaniach, to jak najbardziej.

Kończąc ten gigantyczny i niewiele wnoszący offtop pytam:

W jaki sposób realizowany jest pomiar temperatury? Przetwornik/1-wire/../?

Sterowanie tranzystorem - coś bardziejsz szczegółowo? Może da się to zrobić sprzętowym PWMem.

Transmisja do PC - Jaka prędkość? Sprzętowy RS232 załatwi sprawę.

W bascomie może i wygląda to kiepsko, ale bez trudu można to zrobić i nie trzeba żadnego RTOSa (sic!) ani wielowątkowości.

to jak sterować np.: 3 diodami led z czego każda ma inną częstotliwość mrugania i do tego dochodzi pomiar i transmisja? czy to będzie led czy silnik to czas nie może się zmienić.

Bez problemu mozna zrobic obsluge klawiatury matrycowej, LCD, RS, ADC na jednym timerze + petla glowna a efekt sekwencyjnego wywolywania kodu jest i tak niewidoczny dla uzytkownika.

Jak chcesz migac 3 diodami, np. 1 co sekunde, 2 co dwie sekundy, 3 co trzy sekundy to bez problemu zrobisz to na timerze wywolywanym co sekunde. A i tak jest to przerost formy nad tescia.

Jezeli chodzi o obsluge uarta to robisz odczyt danych na przerwaniu, wysylanie na drugim przerwaniu, a analize ramki w petli glownej zeby przerwania nie trwaly za dlugo. Oczywiscie zakladam ze chcesz wysylac/odbierac ramki zlozone z kilku bajtow.
A ja i tak czesto robie ogolna analize ramki juz w przerwaniu odbioru miejac oczywiscie swiadomosc ile to mniejwiecej bedzie trwalo.

Tak właśnie to niestety wygląda

Najpierw pomysł jest dość prosty, ot pomiar temperatury i załączenie przekaźnika lub kilku

Potem warto byłoby to gdzieś wysłać , a potem jeszcze dobrze byłoby zmienić zdalnie tryb pracy i pętla główna zaczyna puchnąć, czynności mogą zacząć się na siebie nakładać., więc może od razu sztywno przydzielić im przestrzenie czasowe, oczywiście brak wykorzystania mocy procesora

Co do tych diod migajacych regularnie z różną częstotliwością , ale z wspólną osią czasu to takie coś można by załatwić jednym zegarem i jedną pętlą. pod warunkiem że to ma tylko migać a parametry migania mają być niezmienne
Poprostu każde przerwanie zegarowe incrementuje licznik dla poszczególnej diody z inną wagą- mnożnikiem

rozumiem jednak, że wkrótce może dojść jeszcze kilka funkcji czasowo zależnych

Nie pamiętam, żeby Bascom wspierał wprost pracę na osi czasu więc czeka cię droga przez mękę , ale próbuj jeśli dokładność nie jest tu istotna to przy dużej szybkości procesora 10 ms do przodu czy do tyłu nie będzie zauważalne na diodach i innych peryferiach .

AGL napisał:

czy to będzie led czy silnik to czas nie może się zmienić.

Tak naprawde nie da sie na 100% idealnie sterować wiecej jak jednym urzadzeniem, można jedynie przy wielokrotnościach czasu i kiedy czasy te nie pokrywają sie.

W każdym innym przypadku będą wachania zależne od częstotliości przełaczania oraz ilości przełaczanych LED.

No i im szybszy będzie kod (tzn krótszy) to też ten czas rozbierzności będzie mniejszy, bo przecież jakieś warunki musza sie tam posprawdzać

Najprostszym sposobem jest kilka razy już tutaj wymieniana pętla wywoływana z timera. Dokładność czasu sterowania bedzie w przybliżeniu równa okresowi tegoż wywołania. Co przy typowych rzeczach nie ma znaczenia.

Jeżeli proc ma wiele do roboty typu RS, jakieś tam mrugające LEDy to tak jak pisałem już, sprawe w jak najwiekszym stopniu należy powierzyć przerwaniom. No i czas wykonywania tychże przerwań skrócić do minimum.

Widać teraz jakie ludziom siano w głowie bascom robi. 3 diody o zmiennej częstotliwości? Przecież to można zrobić na PWMach, 2 timery mają PWM, do jednego można dorobić programowo, albo wsadzić atmegę88 która ma ich wystarczająco dużo.

Nie trzeba robić żadnych pętli, nic nie puchnie...

Na 89C2051 powstało tyle złożonych projektów, mam analizator stanów logicznych z rs232, lcd na 90S8515, a wy tu piszecie że jest problem z 3 diodami LED? przy ~10MIPSach?

Lepiej zastosuj 5 procesorów, po jednym do każdego leda jeden do rs232 i jeden do temperatury, bo skoro nie potrafisz odpowiedzieć na proste pytania, to nie ma sensu tracić czasu na próbę pomocy.

No, w sumie AGL jakoś nie kwapi sie z większą ilością danych.

Tak naprawde można problem rozwiązać na wiele sposobów. Bo po co np stosować proca z dużą ilością PWM jak mniejszy i tańszy też sobie poradzi.

Ja uważam ze nie ma tutaj jednej gotowej recepty. A fakt faktem zdarza mi sie że stosuje dwa mniejsze procki zamiast jednego dużego. Choćby z tego powodu że moc obliczeniowa rośnie dwukrotnie. Możliwości obsługi urządzeń czasem tez dwukrotnie. Co jest ważne w przypadku dużych ilości prac nad magistralami.

Tak wiec żeby nie zejść z tematu, po póki co my sie produkujemy, a AGL chyba sam nie wie czego do końca czego chce.

McRancor ma racje. Najzwyklejsze ATmegi maja duuzy potencjal tylko kwestia umiejetnosci programowania i logicznego myslenia. W Bascomie tez da sie napisac dosc rozbudowane pogramy, moze nie takie jak w C, ale mimo wszystko. Po to ktos wymyslil timery , przerwania i sprzetowe wspomagacze:) by z nich korzystac.

No tak zgadzam sie, tyle ze ja o przerwaniach już pisałem ze dwa razy w tym wątku. Wiec nie wiem po co klepać to po sto razy.

Nie widze tylko potrzeby kupowania mocniejszego i wiecej zajmujacego miejsca proca po to tylko, żeby korzystać z preryferiów, kiedy to samo można zrealizować na mniejszym procku programowo. Tym bardziej ze nawet małe proce jakieś przydatne timery i inne ciekawe peryferia posiadają. Wiec wcale nie jest tak źle.

Ale nie wiadomo ile i jak te diody mają migać wiec trudno coś doradzić konkretnego. Dla mnie jak pisałem nie ma gotowej recepty na każdy projekt.

programik który był obsługiwał i sterował:
-czujnik temperatury na 1-wire
-czujnik wilgotności za pomocą przetwornika acc
-styk otwarcia drzwi
-sterowanie grzałką która zmieniała temperaturę 2,5stC na 1sekundę
-sterowaniem wentylatorem wyciągowym
-sterował silnikiem nawilżacza powierza
-sterował oświetleniem
-wyświetlanie wszystkiego aktualnie wykonywanego na LCD
i do tego jeszcze była transmisja rs232 do programu inTouch do wizualizacji i sterowania z kompa. Wszystko działało ok, ale zebranie danych z otoczenia i przesłanie do kompa w celu wizualizacji, odczyt zmian użytkownika do wprowadzenia z programu do atmega powodowało że grzałka była za późno wyłączana i jej temperatura nastawy była dawno przekroczona. głównym zadaniem było utrzymywać stałą temperaturę i wilgotność pomieszczenia. jak coś gdzieś się przytkało to zaczynały się problemy do zapętlenia programu i grzałka grzała do oporu. Nie stosowałem flag, i nie bardzo widzę przykłady do rozjaśnienia swoich problemów. Pozdrawiam.

Dodano po 10 [minuty]:

ledy to przenośnia do czegokolwiek wykonywanego przez atmega. Mam do zbudowania sterownik do 3-fazowego silnika DC, problem w tym że będą 4 takie silniki i obsługa żyroskopu i czujników przyspieszenia i obsługa modułu radiowego. to że grzałka grzała na maksa to pikuś ale w tym to każdy silnik pracuje z inną prędkością i na dodatek 2 z nich będą kręciły się w przeciwną stronę. w tym projekcie wiem że jeden procek to za mało, chyba że da rade jeden.

Moze pokombinuj z ARMem, najtanszy za 10 zl. Napewno uzyskasz lepsze rezultaty jezeli chodzi o wydajnosc.
Z drugiej strony AVRy sa juz wszechostronnie przetestowane w wielu zastosowaniach.
Moim zdaniem od strony mikrokontrolera da sie to nadal zrealizowac na jednym ukladzie, wszystko zalezy od stopnia skomplikowania algorytmow regulacji cyfrowej i ukladow wykonawczych ktore chcesz zastosowac.

Dla mnie wiekszym problemem byloby ogarniecie tego wszystkiego od strony analogowej czyli ukladow pomiarowych i wykonawczych.

Sterowanie silników najlepiej oprzeć na układach do tego stworzonych. Pozostanie tylko nadzór i aktualizacja parametrów pracy.
Akcelerometry i żyroskopy najlepiej wybrać z wyjściem analogowym i zatrudnić do obsługi ADC.

Najbardziej zainteresowała mnie grzałka i przyrost temperatury 2.5C/s. W jakiej objętości chcesz uzyskać takie parametry? Jaka grzałka? Sterowanie zwykłe proporcjonalne? Pytań można by mnożyć, ale jedno jest pewne, jest to do upchnięcia w jednym uP.

Projekt z pomiarem temperatury miał być wstępnie wykonany na atmega32 ale zrobiłem na atmega16 i wszystko grało i miałem jeszcze dużo wolnego miejsca. Wiem tylko że problemy jakie miałem to jakiś błąd komunikacji po rs232. Bo jak tam coś nie tak poszło to wisiał. Nie było problemu jak grzałka była wyłączona, ale jak tylko po włączeniu grzania się zawiesił, gdzie żądaną temperaturą było 40st to grzałka miała 250st. Nie było problemu ze względu że to był tylko model symulacji pomieszczenia, ale nie spełniał wymogów wcześniej założonych. transmisja była oparta na protokole modbus.
P.S. czy jest gdzieś dostępny prosty przykład z wykorzystaniem flag w pętli?

A widzisz jednak troszkę zabawek o różnych wymaganiach czasowych:)

Rozumiem że to jakiś modelik czegoś ala inteligentny budynek , lub jakiegoś ciekawego procesu przemysłowego - grzała 2,5°C / 1 sek - niezła

Cytat:

-czujnik temperatury na 1-wire
-czujnik wilgotności za pomocą przetwornika acc
-styk otwarcia drzwi
-sterowanie grzałką która zmieniała temperaturę 2,5stC na 1sekundę
-sterowaniem wentylatorem wyciągowym
-sterował silnikiem nawilżacza powierza
-sterował oświetleniem
-wyświetlanie wszystkiego aktualnie wykonywanego na LCD

jakto już ujął zgrabnie crazy_phisic pozostaw to co się da poszczególnym sterownikom sprzętowym , szczególnie jeśli chodzi o urządzenia indukcyjne bo, mają specyfuczne wymagania dotyczące rozruchu i hamowania silnika - szczególnie wyższej mocy - no chyba że model pozostanie modelem.

Przy tej ilości wzajemnie zależnych parametrów, zastanowiłbym się już nad zamodelowaniem układu za pomocą jakiś funkcji lub chociaż tabel - spójrz na to że temperatura i wilgotność zależy od otwarych drzwi, włączenego oświetlania itd itd.

A regulowanie temperatury możesz uzyskać zarówno za pomocą grzałki jak i wentylatora wyciągowego , a nawet oświetlenia
Napisanie dobrze i optymalnie pracującego układu w obszarze jedynie parametrów krańcowych może powodować zastanawiajace działanie całości . W tej systacji ogólny algorytm będzie naprawde fajowy .

Co do zależności czasowych to musisz kierować się bezwładnością czujników , środowiska oraz elementów wykonawczych, jeśli rzeczywiście masz do czynienia z tak solidną grzałą , no to ona będzie krytycznym punktem algorytmu kontrolnego, bo może się zdarzyć że przyrost rzeczywisty będzie większy niż mozliwości pomiarowe czujnika temperatury , warto to dopasować

Wogóle fajnie byłoby jednak przeanalizować wzajemne relacje pomiędzy urządzeniami, zanim zaczniesz pisać ostateczny kod

Przykład grzała może nie dać sobie rady przy otwartydrzwiach i włączonym wentylatorze wyciągowym, który jest włączony z powodu przekroczenia wilgotności w pomieszczeniu .

Fajne wyzwanie jak na pojedynczy procesorek Moje szczere gratulacje

Dodano po 1 [minuty]:

Cytat:

algorytm będzie naprawde fajowy

W sensie ilości różnych odgałezień i powrotów

Dodano po 2 [minuty]:

Może automat sekwencyjny Malego - na początek dałby radę w końcu trzy zmienne wejściowe i aż cztery wyjściowe jest co analizować

Dodano po 1 [minuty]:

Procesu wyświetlania i wysyłania danych do PC na razie nie biorę pod uwagę bo jest oczywiście pomocniczy

Dodano po 3 [minuty]:

Wydaje mi się jednak , że chyba bezpieczniej będzie rozbić te sterowania na oddzielne zależności - microprocki lub rozbieżne sterowanie w układzie jednego procka i co najwyżej pobawić się sterowaniem w pętlach histerezy temperaturą i wilgotnością.