Zainspirowany tym projektem http://www.elektroda.pl/rtvforum/viewto ... 1b06eaa0ef

Zacząłem myśleć w jaki sposób zrobić "tendencje"...

Czy przez określony czas zbierać próbki i zapisywać min-max, potem porównywać?, czy wymaga to bardziej skomplikowanego algorytmu.

Po drugie, jest jakiś "prosty" sposób na działanie RFM12 w "sieci" czyli jeden obiera reszta nadaje?.

Czy trzeba zastosować coś na kształt "rozgłaszania" czyli odbiornik wysyła "beacon" z ID nadajnika (czujnika), który dopiero wtedy odpowiada.
Wychodziło by na to, że wtedy odbiornik cały czas musi być zasilany, albo w równych odstępach czasu, ale będzie problem z synchronizacją tej sieci.
Co prawda są "gotowe" rozwiązania pomiarów rozproszonych na RFM12, ale tam jest to za bardzo skomplikowane, bo dochodzi niezależność poszczególnych węzłów sieci, oraz zaimplementowano routing itp.

Moja zdolność programistycznego myślenia jest nadal na poziomie depresji , elektronicznie praktycznie mam cały układ zaprojektowany...., nawet bym sobie poradził z zwiększonym poborem prądu, rzędu kilkunastu mA, bo urządzenia pomiarowe nie muszą być małe.

PS. Nie jest to projekt komercyjny! więc wszystkie źródła będą publikowane na forum.

"tendencje" hmm "trendy" raczej są prosto robione na zasadzie uśredniania próbek z jakiegoś okresu czasu i porównywania ...

po drugie - z tym działaniem RFM12 w sieci, to proponuję nie rzucaj się na przygotowaniu koncepcji sieci wielu czujników typu "multi Master" z rozgłaszaniem/broadcastingiem i bóg wie jeszcze czym - bo wyjdzie ci z tego kobyła programistyczna, która pochłonie 90% mocy projektu i prądu a nadal będzie działała o wiele mniej wydajniej niż dedykowane do takich celów chociażby ZigBee czy XBee i podobne , które sporo rzeczy załatwiają sprzętowo bez konieczności udziału programisty. No chyba że po prostu zależy ci sprawdzić się w czymś takim i lubisz się bawić, mając dużo wolnego czasu to jak najbardziej.

Jeśli już to proponuję ci zacząć jednak od prostszego podejścia i potraktowania sieci czujników z transciverami RFM12 jak sieci RS485 z jednym Masterem na dobry początek. A potem ew wchodź w wodę dalej i głębiej, bawiąc się w multimaster, arbitraż itp. Ale warto byłoby wtedy coś więcej poczytać o istniejących już rozwiązaniach w tym zakresie niż wyważać głową drzwi i tworzyć od nowa własny rozbudowany koncept....

Bo zawsze trzeba się dobrze zastanowić, czy:

1. zależy ci na opracowaniu np następcy ZigBee i opracowujesz nowy typ takiej komunikacji i to jest twoim celem
2. czy robisz jakiś konkretny projekt którego celem jest praca wielu czujników i zbieranie danych

zwykle udaje się to zrobić zawsze jakimś najprostszym sposobem, a najczęściej jeszcze jak dochodzą kłopoty z poborem prądu to nawet okazuje się na końcu że wystarczą zwykłe komplety nadajnik/odbiornik np Telecontrolli zamiast transcieverów.

Piszę o tym, ponieważ piszesz o rzekomej "depresji swoich zdolności" bez sensu zresztą ... po prostu - tak mi się wydaje, że może cię dobrze rozumiem (jeśli nie to mnie popraw) .... bo gdy już się ma pod ręką "aż" transcievery zamiast zwykłych kompletów nad/odb - to zaczynają chodzić po głowie coraz bardziej dalekosiężne pomysły. I dobrze zresztą - ale myślę, że nie warto czasem wyważać głową drzwi. Bo jak mówię - spróbuj zapoznać się z tymi XBee jeśli RZECZYWIŚCIE i w 100% masz na tym etapie takie potrzeby komunikacji "bardzo sieciowej" że tak powiem.

... a tymczasem trzymając się jakby zasad RS485 z jednym Masterem na takich radiówkach też można bardzo dużo zrobić, a przy okazji nie tracić tyle prądu ....

ale jak mówię wyżej - może kompletnie źle mówię - bo przecież nie przybliżyłeś założeń swojego projektu.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jak zwykle masz rację , ale dosyć tego słodzenia . Zigbee i Xbee są niestety odrobinę za drogie , bo max na czujnik 50zł mogę przeznaczyć, nie będzie tego dużo. Raptem 5-8czujników maksymalnie, może mniej na początek.
Można by to faktycznie zrobić na nadajnik-odbiornik, ale docelowo możliwe że trzeba będzie czymś zasterować zdalnie.

Chodzi mi wyłącznie o prostą "sieć" zbierającą temperaturę bezprzewodowo. Niestety z racji niekomercyjności z założenia koszta muszą być jak najniższe .

Nawet nie musi być 1czujnik-1 RFM12, bo one będą w pomieszczeniach gospodarczych, czyli będzie przypadać jeden, lub kilka czujników na jeden RFM12.

Docelowo faktycznie wirtualna sieć 485 była by bardzo fajna. Musze oblookać z czym się to je .
Danych będzie niewiele.

No więc pomyśl zasady z RS485 można wręcz wprost wprowadzić w życie.

Jakiś centralny master będzie co jakiś czas odpytywał czujniki i w razie czego jeszcze czymś tam może przez nie - zdalnie - sterować. Tak mi się wydaje.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Fakt, pomiar będzie od tyłu, czyli to master inicjuje "wykonaj pomiar" rozwiązuje to problem po pierwsze z ilością czujników, po drugie z ich wykrywaniem i wiele innych problemów.

Dwa paluszkowe akumulatory AA eneloop powinny załatwić problem zasilania. Raz na jakiś czas będą po prostu wymagały naładowania i tyle.

Zresztą w moim przypadku nie muszę sprawdzać non stop temperatury raz na 15minut wystarczy, mogę wybudzać raz na 10-15minut moduły... coś pomyślę jeszcze.
Zamówię jeszcze kilka RFM12 i zobaczę jak się będą sprawdzać .

nie znam się na tym, ale...
może zastanów się nad rfm22b, gdzie termometr jest chyba w nim gratis i moc większa,
http://www.hoperf.com/rf/fsk/

Też już o tym myślałem, ale DS18B20 jest wygodniejszy w użyciu, no i zakres ma do 125C, a potrzebuje mierzyć temperaturę na piecu CO.
Mocy mi dużo nie trzeba, pomieszczenia gospodarcze nie są od siebie oddalone o więcej niż kilkanaście metrów.

Chwilowo coś takiego wymodziłem tj. koncept z tablicą struktur i zapisywaniem do niech wyników pomiarów..... dobrze kombinuje, czy mam wrócić do czytania książki .


Wyświetlanie na wyświetlaczu podobnie, tyle że lcd_int(Tsens(i).cel itd.

No na razie lecisz po przypadkowo wykrytych czujnikach - ale dobrze do tablicy struktur temperatury zapisujesz przecież

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Prośba, czy ktoś może mi podpowiedzieć, jak wyłuskać ID układu DS18B20? za pomocą bibliotek mirka

stworzyłem sobie strukturę


I potrzebuję wrzucić do id_temp ID wykrytego czujnika. Tyle, że to jest iluś tam bajtowy "ID", po pierwsze nie bardzo wiem, jak go wyłuskać z bibliotek Mirka (próbowałem już za pomocą gSensorIDs[i] ale nie do końca to jest to.

UP!

Słuchaj a co byś powiedział na to aby na dobry początek wyświetlić numer id czujnika?

Poniżej kod funkcji która jest napisana prawie żywcem z pierwotnej wersji biblioteki od Mirka



A tutaj jest sposób wykorzystania samej funkcji:



Jak widać powyżej przekazujesz adres tablicy z numerami id(tablica dwuwymiarowa) a następnie podajesz jak długi numer seryjny chcesz wyświetlić(ja mam wpisany 4 i dostaje 8 cyfrową wersję numeru id czyli wystarczającą do wyświetlenia np na lcd)

Mam nadzieję że troszkę cię to naprowadzi(chodzi o sam mechanizm) na to co chcesz osiągnąć .

Pozdrawiam!

Dziękuję pięknie, spróbuje to ogarnąć swym ciasnym rozumem

To znowu ja

Słuchaj być może to ultra szarlatański sposób ale w twojej strukturze sens zadeklaruj wskaźnik id1 który będzie przechowywać numer seryjny czujnika.



a tutaj masz jak przez tą naszą funkcję show_id wyświetlasz numer seryjny



Jak zapewne wiesz że zmienna sens1 jest typu sens(instrukcja typedef tworzy nowy typ danych tak dla uściślenia zeznań ). Żeby nie było to przed chwilą sprawdzałem ten powyższy sposób i działa.

I według mnie to jest rozwiązanie twojego problemu .

Pozdrawiam!

Działa, ale dziwnie .



Wyświetla oczywiście pierwszą temperaturę, czyli np. 24.0C 284a1af4 (gdzie 4a1af jest częścią ID czujnika) po zmianie czujnika na inny zmienia się id między liczbami 28____f4, nie bardzo rozumiem skąd się wzieły te 28 i f4, skoro funkcja show_id wyświetla tylko teoretycznie znaki z 4miejsc, czyżby te 28 i f4 były jakimiś stałymi które definiują typ czujnika???. Sprawdzałem na 3sztukach 2 kupionych od kolegi z forum, jedna oryginalna z zestawu.


OK, już wiem, 28 to FAMILY CODE i chyba muszę odwrotnie wyświetlać, bo 1 od lewej jest kod, a na wyświetlaczu mam pierwszy od prawej. Nadal tylko nie rozumiem, dlaczego wyświetla się więcej bajtów....te f4 mi nie daje spokoju, dziwnie bo jak jest jeden czujnik to się nie pojawia dopiero jak podepniemy dwa albo więcej to zaczyna się pojawiać.

Cały numer układu 1-Wire to 8-bajtów wliczając family code i crc. Wyświetlasz tylko połowę. 4 to liczba bajtów a bajt hexadecymalnie to 2 znaki. Jak chcesz sam numer to wyświetl 6 bajtów pomijając zerowy( i od 1 do 6)

_________________
Dragonus Cracovus: Biomagia

No wiem , zajrzałem do datasheeta, ale dlaczego za pierwszym razem wyświetla więcej znaków?



Moje czujniki wyświetlają po 6bajtów, ten oryginalny w zestawie ATB po 4bajty, a wszystkie są 18B20, bądź tu mądry.
Teraz znowu z jednego czujnika pokazuje 5 bajtów drugiego 6 bajtów, po wyciągnięciu jednego z moich czujników pokazują się pierwsze 4bajty czujnika ATB, ale 2bajty zostają na końcu z starego czujnika.

Dlatego masz różne ilości znaków, bo widać zero nieznaczące nie jest wyświetlane np. 0x01 -> na LCD 1.

_________________
Dragonus Cracovus: Biomagia

Dzięki, o tym nie wiedziałem
Wystarczyło dodać tą linijkę

if(Tsens[nr_czujnika].id_room[i] < 0x10) lcd_str("0");

To teraz mogę walczyć z wrzucaniem seriali do EEPROMA, bo docelowo, będzie można edytować reprezentacje ID czujnika i np. wpisać jakąś własną nazwę, nie wiem jeszcze czy zrobić to np. za pomocą dwuwymiarowej tablicy, czy da się jakoś inaczej, ale będę myślał .

Chyba, że zrobić to prościej za pomocą trybu wyliczeniowego, na stałe przypisać do poszczególnych miejsc w tablicy nazwy (które można ewentualnie edytować), a zmieniać tylko przypisanie czujników do miejsc, czyli np. dostajemy pierwszy czujnik na szyne i przypisujemy go np. do miejsca nr3

Z racji iż istnieje już kilka podobnych tematów tj. topic1725.html oraz topic1784.html no i post17932.html?hilit=zapis%20eeprom#p17932

Po zapoznaniu się z w/w tematami doszedłem metodą wykluczeń (tj. wykluczania co wiem czego nie ) do tego iż najlepiej będzie stworzyć dwie struktury, a w zasadzie trzy.



w przypadku struktury czujników sens, bedzie stworzona tablica

gdzie będą lądować ID czujnika, aktualny pomiar temperatury itd. wszystko w RAM, do tego
w eeprom będzie tablica eem_sens_id EEMEM;, czyli tablica samych ID, z paroma dodatkowymi zmiennymi, bo po co mi aktualny pomiar w eepromie.

Czyli na początku robię funkcję (jeszcze przed main), która za pomocą bibliotek Mirka wykrywa czujniki na szynie 1wire, ich ID wrzuca do eeproma, następnie używając już tylko ID z eeprom wykonuję pomiary podobnie jak w temacie topic1725.html?hilit=zapis%20eeprom#p18348
Dzięki wykorzystaniu struktury struktur mogę przypisać dowolną nazwę do danego ID czujnika, nie tracąc przy okazji ID czujnika .
Dodatkowo (jeszcze nie wiem jak, ale w topic1591.html#p15892 SunRiver opisał dosyć dobrze odwoływanie się do eeproma struktury itp), będę mógł pobierać i zmieniać poszczególne parametry tablicy struktur w eepromie (tak mi się przynajmniej wydaje).

Docelowo będę miał 6 pomieszczeń do obczujnikowania, do tego jakieś alarmy max, min, temperatura na piecu z jakimś prostym sterowaniem, ale by było śmieszniej 2-3czujniki będą w bazie reszta po RFM12, albo nRF24L01, ale to później.

Mirek tak fajnie opowiadał o swoim 4kanałowym sterowniku, czuję się jak "krasnoludki" z kingsize, cyt. "bo z was dupy nie prowokatorzy..." koniec cytatu.

do tej pory miałem zrobione tak




Chyba będę musiał wywalić to wszystko i pisać od początku, bo już sam nie wiem jak do tego podejść ...

Zgodnie z tym postem topic1591.html#p15892 stworzyłem takiego potworka


mając zadeklarowane struktury



Tylko że
Zapisuje tylko strukturę do EEPROM, czy zamiast sens czujnik, dać sens *czujnik i przekazywać wskaźnik do tablicy, czy coś nie do końca zrozumiałem, bo chcę eeprom_update_block.... załatwić przepisywanie całej tablicy Tsense do eeprom, dzięki temu po pierwsze mam wszystkie dane potrzebne w eeprom, które niepotrzebnie nie są za każdym razem zapisywane na nowo, bo eeprom_update_block najpierw sprawdzi czy dane już istnieją w eeprom, ewentualnie zmieni tylko to co się zmieniło .

Czy to jest prawidłowe wywołanie?

by całą tablicę struktur Tsens[] wrzucić do Tablicy struktur w eeprom?, w zasadzie potrzebuję mieć tylko tablicę struktry sens_id by była zachowana nazwa i ID czujnika, ale zaczyna mi wychodzić masło maślane.....

to jest potworek



już tłumaczę dlaczego,

1. pozbądź się tego rzutowania - ono jest tu ZUPEŁNIE niepotrzebnie ponieważ argumenty funkcji są już void* i zresztą po to są void*, żebyś nie musiał rzutować nawet innych typów. To już jest wbudowana zaleta a ty próbujesz ją jeszcze dodatkowo niepotrzebnie obejść. Oczywiście to niczemu nie zaszkodzi w tym przypadku ale niestety robi się potworek i po tym rozpoznałem że tu jeszcze nie wiesz o co chodzi - dlatego tłumaczę



2. jak już będziesz robił rzutowanie to UWAŻAJ! rzutowanie na typ wskaźnikowy (void*) może być dla ciebie dosyć niebezpieczne, dokąd ostatecznie i dobrze nie zrozumiesz zasad rzutowania a widać, że jeszcze troszkę kiepsko. Nawet jak się rozumie rzutowanie dobrze to - rzutowanie na typ void* robi się w ostateczności, gdy już INACZEJ (normalnie) się nie da

3. patrz korzystasz ze struktury czujnik, korzystasz ze struktury eem_sens_id, tymczasem sizeof bierzesz z ??? sens ... a co to jest sens ... nawet dla oka ciężko później to analizować. nie lepiej dla oka jeśli byłoby tak?



albo nawet jeśli struktury są równe i lecimy po całości to także



teraz to ja od razu widzę o jaki rozmiar chodzi do skopiowania/updejtowania

to tyle tak na gorąco

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

OK, już wczoraj to czytałem, ale byłem zbyt zmęczony by cokolwiek przetrawić . Dziękuję po pierwsze za pomoc.

Po drugie mogłem faktycznie namieszać z tymi danymi przekazywanymi do sizeof, bo zmieniałem to tyle razy, że mogło mi umknąć, po za tym po napisaniu posta wprowadziłem kilka zmian, bo po co mi cała tablica struktur Tsens, jak w eepromie potrzebuje mieć tylko ID czujnika, nazwę pomieszczenia, ewentualnie max, min, i średnią temperaturę z całej doby.

Po trzecie, sugerowałem się postem SurRivera (który chyba za bardzo jest skrzywiony C++, albo robi to z rozmysłem ), bo w książkach do C było właśnie opisane bez void* i już potem zgłupiałem kogo mam słuchać ;).
Zaraz będę walczył dalej ....(luz w pracy czasem się przydaje )

Tylko, nie wiem, jak to ugryźć (w tej chwili), bo tak, mając strukturę sens_id, która wchodzi w skład struktury sens z której to tworzona jest tablica Tsens[9], czyli dziesięć elementów typu struct sens.... i teraz wrzucając strukturę sens_id do eeprom, przecież będzie wrzucona tylko dla jednego czujnika, wrzucając zaś tablicę Tsens niepotrzebnie zajmuję w eeprom pamięć. Robić kolejną tablicę 10elementówą struktur sens_id która będzie wrzucona do EEPROM, czy jest na to jakiś inny sposób, bo nie bardzo wiem, jak zmusić eeprom by przyjmował 10 struktur sens_id, bez stworzenia tablicy by łatwo było na tym operować.

A wiem wiem - ja już z SunRiverem kiedyś rozmawiałem o tym (void*) ... rzeczywiście - on miał na to jakieś uzasadnienie chyba z kompilatorów dla PIC (nie wiem czy dobrze pamiętam) ... no ale to człowiek omnibus jak wiesz i pisze w dziesiątkach różnych kompilatorów

dlatego tak jak ci mówiłem - stosowanie tego (void*) nie jest jakimś błędem okropnym bo jak widzisz działa poprawnie i nie ma warninga. Ale ja ze swojej strony to uzasadniłem podpowiadając o zagrożeniach szczególnie jak ktoś stawia pierwsze kroki - to pod tym kątem piszę. Sun to wiesz - sobie poradzi - jak on pisze (void*) przy tych argumentach to ja wiem że on sobie bardzo dobrze zdaje z tego sprawę.

A z drugiej strony ja zawsze jestem zwolennikiem ułatwiania sobie życia podczas pisania kodu, zatem jeśli teraz już dokładnie rozumiesz o co chodzi z tym (void*) w tym konkretnym przykładzie to też sam sobie wybierzesz sposób

ale dodam że - moim zdaniem akurat w konstrukcji AVR GCC, która jest na prawdę fajnie przemyślana jeśli chodzi o kompilator - to stosowanie rzutowania na typ wskaźnikowy void* zostawiłbym na tzw czarną godzinę, jeśli można w innych przypadkach się tego pozbyć i poprawić nawet czytelność kodu. Tak chyba też zakończyła się nawet może w tamtym temacie czy w mailu nasza konkluzja z Sunem

------------------------ [ Dodano po: 7 minutach ]

co do pytania twojego o te struktury, eeprom itp - to tak jak widzisz trzeba dobrze przemyśleć. Ale widzę, że piszesz i obawiasz się jakby że niepotrzebnie coś tam będziesz trzymał w eeprom. Z drugiej strony - czy planujesz wykorzystać cały eeprom po brzegi ? jeśli nie to w czym może przeszkadzać te parę bajtów nadmiaru ?

Innym rozwiązaniem problemu może być przygotowanie wskaźników na poszczególne miejsca w strukturze i to je zapakować do struktury w eepromie ... eeeh wiem że jak się tak o tym pisze z marszu to wygląda jak masło maślane z potrójnym saltem ... no ale postaraj się jeszcze pokombinować i ew pokazać efekty - w kodzie to może coś się uda podpowiedzieć dalej - naprowadzić

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Masz rację, zresztą sam fakt rzutowania na typ pusty, niby jest zrozumiały, ale nie do końca i potem człowiek coś stosuje, a sam nie wie po co .
Chwilowo próbuję przetrawić te struktury bo to faktycznie fajna rzecz . Ale przykładów z tym biednie, a nic tak nie uczy jak "życiowy" przykład, a nie opisy samego zagadnienia. Dlatego męczę te zapisywania do eeprom by w końcu zatrybić o co w tym chodzi.
Tablice, wskaźniki fajna rzecz, ale struktury to jest to co tyrgryski lubią najbardziej, załatwiają wiele rzeczy, podobnie jak klasa vector, czyli kontenery itd.

Faktycznie, może nie będzie aż takiej nadmiarowości, bo nie wiem, czy znam na tyle wskaźniki by to wrzucić tym sposobem do eeproma, szczerze mówiąc nawet nie bardzo wiem jak to od tej strony ugryźć.

Hmmm co by tu dużo mówić, pierwszy krok za mną, działa, co prawda nie sprawdzałem jeszcze samego odczytu z eeprom, ale same "zarządzanie" czujnikami do struktur i z struktur działa bez zarzutu



PS. Faktycznie 10elementowa tablica Tsens nie zajmuje aż tak wiele miejsca w eepromie, wrzucę ją całą do eeproma, uaktualniane będą ewentualnie tylko ID czujników w przypadku ich zmiany no i same id_room celem zadeklarowania własnych nazw pomieszczeń, na początku będą wrzucane standardowe napisy z flash, a potem można będzie ewentualnie edytować nazwy w eepromie.

PS. Teraz czas na kolejny etap, czyli stworzenie jakiegoś menu pod to , potem dalsze przygody .

Po kilku dniach walki, udało mi się w końcu stworzyć strukturę menu







Teraz czeka mnie oprogramowanie poruszania się po menu, następnie wykonywanie działań właściwych w poszczególnych funkcjach menu . Ależ te struktury dają popalić .

Masz to juz wyswietlone na lcd ?

_________________
pozdrawiam
Jachu

Jeszcze nie, bo została mi obsługa klawiszy do przerobienia pod to, ale obsługę menu już wrzuciłem. Po wrzuceniu debounce od Mirka, będę powoli uruchamiał to .

PS. Mam nadzieje, że ruszy bez większych problemów, menu może być trochę chaotyczne, ale mam nadzieje, że będzie działać zgodnie z założeniami..... Jeszcze muszę pomyśleć o spowolnieniu przeskakiwania między menu, by nie było na _delayach. Zapewne wykorzystam ten sam mechanizm co Mirek przy debouncigu z softwerowym timerem.

PS2. Debouncig wrzucony, ale coś namieszałem w samych strukturach bo wyświetla się od razu menu RS232, można przejść do przodu do RFM12, odpalić program ale przypisany pod funkcję RS232, ale przy cofaniu menu idzie w maliny , program chyba też .
Chwilowo nic nowego nie wrzucam, przeanalizuję jeszcze raz struktury menu i jak będzie działać do dopiero wrzucę źródełka.

Jak obiecałem tak zrobiłem, chwilowo to tylko menu i pomiar, oraz wyświetlanie danych z trzech czujników, cała reszta dopiero w fazie pisania (czyt. wymyślania jak to napisać). Zresztą całe to menu to jak to ładnie Mirek określa Koci program .
Na razie to mam problem, że po wywołaniu funkcji start pomiaru wyświetla się na chwile jeszcze menu, potem kawałek zostaje , oj szkoda gadać, głupi z tego jestem......
nie wiem, jak połączyć pseudo-wielowątkowość z obsługa menu i głównego programu.....

Zresztą oceńcie sami..... program w załączniku, oczywiście biblioteki 1wire i LCD w własnym zakresie należy sobie skopiować.

Ja bym umieścił pomiar w pętli głównej poza warunkiem menu_show:



A z tego kawałka wywalił warunek z timerem, niech temperatura wyświetla się w każdym obiegu o ile nie jest wyświetlane menu