DS18B20 na delay_ms, wyświetlacz na timerze nie działa

Pozbądź się operacji na przecinku, być może w wyniku błędnego odczytu wychodzą jakieś nieokreślone liczby np. NAN i wtedy ma to się nijak do twojej tablicy.

Cytat:

Pozbądź się operacji na przecinku

nie bardzo rozumiem

nsmarcin napisał:

Znaki są to po prostu jakieś losowo zapalane segmenty na wszystkich wyświetlaczach (oczywiście na pierwszym tylko minus się wyświetla ale to wynika z programu), trwa to bardzo krótko ale jest wyraźnie zauważalne. Na pewno nie są to liczby więc wyglądało by to tak, że po operacjach w switchu na zmiennych temp, temp_ulamek, minus, wartości wychodzą poza zakres tablicy LED_Lookup, ale z kolei jest niby tam blokowanie przerwania przed zapisem do tych zmiennych więc wartości powinny być ok

Na wszystkich wyświetlaczach te same segmenty?

Pokaż schemat.

nsmarcin napisał:

Cytat:

Pozbądź się operacji na przecinku

nie bardzo rozumiem

Link

To schemat, tylko, że rezystory są po drugiej stronie ULNa, a DS18B20 podłączony do PORTD pin 6

Zmodyfikuj maina lekko do takiej treści jak poniżej:




poobserwuj chwilę i sprawdź co się dzieje czy przypadkiem co jakiś czas na wyświetlaczu nie wyskakuje 99.9.

Takie małe sprawdzenie.

Dalej to samo, tzn po zmodyfikowaniu maina dalej są te artefakty a 99.9 wyświetla się tyko na początku, a później to już tak jak było

nsmarcin napisał:

Dalej to samo, tzn po zmodyfikowaniu maina dalej są te artefakty ...

snnaap - zobacz do czego prowadzi, naprowadzanie kogoś na stosowanie myślenia wprost z Bascoma i przenoszenia tego na poziom języka C. Zamiast temperatury - uzyskaliście w końcu całkiem inny wspaniały chyba wynalazek - ARTEFAKTY

Cytat:

Artefakt – wytwór ręki ludzkiej, każdy przedmiot wykonany lub zmodyfikowany przez człowieka, a następnie odkryty w wyniku badań archeologicznych. ...

Proszę bardzo jak płynnie można przejść od elektroniki do archeologii

Może zatem warto w pewnym momencie dojść do wniosku, że taki autor powinien w końcu doczytać sobie z jakiegoś kursu internetowego jak organizować najpierw wyświetlanie multipleksowane zamiast od razu rzucać się na wszystko jak z motyką na słońce. Czyli nie znając ni w ząb multipleksowania jeszcze obsługa 1wire, plus obsługa timerów itd.... Kłania się powiedzenie, że warto zaczynać po kolei, od zwykłego migania diodą LED.

Z tego długaśnego już tematu wynika, że autor ma wstręt do chociażby poszukania czegoś w internecie. Liczy na gotowca. Więc jeśli nawet uda ci się napisać jemu takiego gotowca to i tak będzie miał problem gdy za chwilę będzie trzeba coś drobnego zmienić/dodać/zaktualizować.

Panie autor, po wpisaniu do googla kilku prostych fraz od razu znajdziemy tematy czy kursy omawiające jak to zrobić. Jak zrobić to z czym ty się tu na własne życzenie mordujesz już od kilku dni. Tyle że w necie masz nie tylko gotowce ale także strony bardzo dobrze tłumaczące jak to działa i jak się za to zabrać. np:

http://www.easy-soft.net.pl/artykuly/jezyk-c/...olerow-8051-multipleksowanie-wyswietlaczy-led

http://wortal.majsterkowicza.pl/2011/01/sterowanie-wyswietlaczami-led-multipleksowanie/

http://diycenter.acid19.linuxpl.com/readarticle.php?article_id=19

Tak mi coś więc pachnie tu lenistwem ... i przekonaniem, że ktoś powinien podać na patelni to co mi się należy.

Aha - panie kolego snaap - przyokazji chciałbym nieśmiało poradzić, żeby jak najszybciej przestał kolega stosować w języku C takie tragiczne zapisy:



raz binarnie, raz hexadecymalnie, za to ani razu zgodnie z dobrą sztuką programowania a za to mieszanie jeszcze operatorów, bo raz jest samo = a innym razem wskakuje dwuczłonowy operator |=

Przecież przeczytanie po samym sobie takiego kodu za pół roku może doprowadzić do obłędu, tymczasem w języku C mamy taaaakie duże możliwości, żeby bez nawet dodatkowej dużej ilości komentarzy, zapisać te linijki w sposób tak przejrzysty, że nawet po 10 latach nawet jeśli do takiego kodu sięgnie obca osoba to od razu będzie wiedziała o co chodzi. Czy jest więc sens utrudniania sobie ale też innym życia ?

mirekk36 napisał:

snnaap - zobacz do czego prowadzi, naprowadzanie kogoś na stosowanie myślenia wprost z Bascoma i przenoszenia tego na poziom języka C.

Niech Pan Kolega rozwiń to, bo chyba jestem na niższym poziomie intelektualnym i nie mogę załapać o co chodzi. Czym charakteryzuje się "myślenia wprost z Bascoma"?

mirekk36 napisał:

Aha - panie kolego snaap - przyokazji chciałbym nieśmiało poradzić, żeby jak najszybciej przestał kolega stosować w języku C takie tragiczne zapisy:

Kod: C / C++

Zaloguj się, aby zobaczyć kod

raz binarnie, raz hexadecymalnie, za to ani razu zgodnie z dobrą sztuką programowania a za to mieszanie jeszcze operatorów, bo raz jest samo = a innym razem wskakuje dwuczłonowy operator |=

Przecież przeczytanie po samym sobie takiego kodu za pół roku może doprowadzić do obłędu, tymczasem w języku C mamy taaaakie duże możliwości, żeby bez nawet dodatkowej dużej ilości komentarzy, zapisać te linijki w sposób tak przejrzysty, że nawet po 10 latach nawet jeśli do takiego kodu sięgnie obca osoba to od razu będzie wiedziała o co chodzi. Czy jest więc sens utrudniania sobie ale też innym życia ?

Po pierwsze nie wiem czy Pan Kolega zauważył ale styl "mieszany" nie został narzucony przez mnie tylko już w pierwszym poście przez autora tematu. Najwyraźniej tak było autorowi wygodniej, mi nic do tego.
Nie wiem czy Pan Kolega zauważył ale autor nie piszę "arcydzieła" tylko prosty program który ma za zadanie działać w pewien określony sposób, a jakim sposobem to osiągnie i w jakim stylu to już nie mi to osądzać. Każdy kiedyś zaczynał i każdy w końcu dojdzie do pewnych wniosków jak należy pisać.

snnaap napisał:

Najwyraźniej tak było autorowi wygodniej, mi nic do tego.
Nie wiem czy Pan Kolega zauważył ale autor nie piszę "arcydzieła" tylko prosty program który ma za zadanie działać w pewien określony sposób, a jakim sposobem to osiągnie i w jakim stylu to już nie mi to osądzać. Każdy kiedyś zaczynał i każdy w końcu dojdzie do pewnych wniosków jak należy pisać.

Czym prędzej się wykorzeni złe nawyki tym lepiej. Nie tworzy arcydzieła, ale następny program już będzie pisał pewnie sam, bo będzie wiedział jak zrobić już pewne rzeczy, i będzie pisał też niekonsekwentnie. Niektórzy piszą kod bo piszą. Nie mam zamiaru wskazywać tu palcem autora czy jakichś konkretnych osób, ale szczerze mówiąc w większości przypadków nie chce mi się nawet czytać tego kodu. Ktoś wrzuca jakieś wymiociny i pisze pomóżcie, a Ty się doczytuj w kodzie bez enterów i tabulacji błędu

Firmy zajmujące się certyfikacją oprogramowania, korzystają z kilku norm dotyczących bezpieczeństwa programu itd itp. W tych normach są wyraźne wytyczne o czytelności i przejrzystości kodu o innych rzeczach nie wspomnę.

Albo idziesz do pracy (miałem osobiście kiedyś taką sytuację) i gość mówi "trzeba dokończyć program sprzed 2 lat, WYSTARCZY dopisać prostą rzecz". Tylko, że program był napisany tak, że dopisanie do niego czegokolwiek powodowało rozjechanie wszystkich pomiarów/obliczeń/komunikacji/sterowań. Optymalizacja oczywiście -O0 (bo kompilator "niepotrzebnie wyrzuca kawałki programu i może coś nie działać") i weź się tu człowieku dostosuj. Miałem zrobić durne mignięcie lampą + pomiary + analiza pomiarów napięcia, prądu i jakichś tam pierdół z tego mignięcia i robiłem to ponad tydzień bo program był tak I*O^#DIhjj napisany. Normalnie przecież takie coś jest do napisania w kilka godzin. Dodam tylko, że programu nie pisał jakiś student na praktykach tylko gość który tam już sporo pracował.

gaskoin napisał:

Czym prędzej się wykorzeni złe nawyki tym lepiej. .

snnaap --> chyba kolega wyżej bardzo dobrze wyjaśnił to o co mi chodziło. Ja nie mam nic przeciwko tobie, wręcz z podziwem patrzę, na zatwardziałość z jaką próbujesz odpowiadać i pomóc.

Nie traktuj więc mojej wypowiedzi jako przytyku ale poradę.

Panowie kod działa jak powinien tylko co jakiś czas pojawia się minus, ale myślę, że to kwestia jakiś zakłóceń.

Jednym z dobrodziejstwo jakie daje nam DS18B20 jest CRC.
Proponuje więc zapoznać się z Link i napisać funkię obliczającą CRC co załatwi problem błędnego odczytu danych z czujnika a tym samym możliwych przekłamań.

Kolejna sprawa to nie zdziw się jak będą wyświetlać się bzdury przy ujemnej temperaturze.

To mój plik z obsługą 1Wire


A to main


Niby zastosowałem crc ale i tak co jakiś czas pojawiają się dziwne wyniki tzn np zamiast 20,5 stopnia pojawia się 80 kilka albo coś w ogóle dziwnego, np -127.9 w terminalu wygląda to tak jakby rejestr wypełniały same jedynki

No nie mówcie, że to błąd nie do opanowania...

nsmarcin napisał:

No nie mówcie, że to błąd nie do opanowania...

Masz trochę błędów w obsłudze 1W, głównie złe czasy.
Sprawdź ten kod

nsmarcin napisał:

Niby zastosowałem crc ale i tak co jakiś czas pojawiają się dziwne wyniki tzn np zamiast 20,5 stopnia pojawia się 80 kilka albo coś w ogóle dziwnego, np -127.9 w terminalu wygląda to tak jakby rejestr wypełniały same jedynki

Z plików nagłówkowych można wyczytać, że używasz "jakiejś" biblioteki wyliczania crc 16 bitowej. Z tego co mi wiadomo to DS18B20 wylicza CRC 8-bitową.
Czy zastosowana przez Ciebie funkcja obliczania CRC jest zgodna z tym: Link?

Zdaje mi się również, że CRC z samych 0xFF lub 0 będzie wynosiło 0xFF lub 0 , ale mogę się mylić, jeżeli widzisz, że uK odebrał same FF lub same 00 to znaczy, że wynik jest niepoprawny i należy takie dane zignorować.

Sprawdź czy na pewno masz prawidłową obsługę linii 1wire o czym wspomniał kolega wyżej.

snnaap napisał:

Z plików nagłówkowych można wyczytać, że używasz "jakiejś" biblioteki wyliczania crc 16 bitowej. Z tego co mi wiadomo to DS18B20 wylicza CRC 8-bitową.

_crc_ibutton_update()

Aha czyli albo czasy obsługi 1Wire albo crc niepoprawnie użyta, ok jak sprawdze to dam znać. W sumie bardziej skłaniałbym się do źle użytej funkcji crc bo bez niej efekty są dokładnie takie same

michalko12 napisał:

snnaap napisał:

Z plików nagłówkowych można wyczytać, że używasz "jakiejś" biblioteki wyliczania crc 16 bitowej. Z tego co mi wiadomo to DS18B20 wylicza CRC 8-bitową.

_crc_ibutton_update()

Powiedz mi czemu w podanym przez Ciebie linku crc = (crc >> 1) ^ 0x8C;

a w APPLICATION NOTE 27
Understanding and Using Cyclic Redundancy Checks with Maxim iButton Products
jest

XRL A,#18H ;update the CRC value

Algorytmu asemblerowego nie da się przepisać do C wprost. Odpowiednikiem tego algorytmu w C jest _crc_ibutton_update(), a przepuszczenie liczb od 0 do 255 przez tą funkcję _crc_ibutton_update(0, x) powoduje wygenerowanie tablicy LUT, która służy do szybkiego wyliczania sumy CRC.

Nie wiem już nic, próbuje użyć jakoś tego crc ale jak sobie wyślę na terminal crc z dsa i crc obliczone to z dsa mam np 209 199 itd a obliczone jest to samo jakie jest początkowe, czyli jak dam 0 to będzie 0, jak na początku dam 8 to będzie 8 czyli tak jakby w ogóle nie liczyło

Dodano po 43 [sekundy]:

Nie wiem czy mam liczyc crc dla każdego baju osobno czy dla wszystkich po kolei i je dodawać i na końcu sprawdzać z CRC z dsa

nsmarcin napisał:

Nie wiem czy mam liczyc crc dla każdego baju osobno czy dla wszystkich po kolei i je dodawać i na końcu sprawdzać z CRC z dsa

Mniej więcej tak

Kurcze działa dzięki wielkie ale teraz powiedz mi dlaczego mój kod nie działał jeśli ja miałem tak:

Tzn działało ale róznice były między CRC z DSa a obliczonym CRC, a Twój kod działa, tylko zamiast Sizeof() dałem <8, a DaneDS[i] zastapiłem ds18b20[i], ale mniejsza o to, zastanawia mnie dlaczeo mój kod skoro był praktycznie identyczny nie działał prawidłowo