Dodaj po operacji

wpisanie zera na ostatniej pozycji ciągu.

--
Pozdrawiam,
Robert

Jeżeli działa Ci z warunkiem z breakiem a z założenia ciąg ma nie mieć więcej niż 4 znaki, to znaczy że w takim wypadku nie masz poprawnego ciągu kończącego się zerem.
Dlaczego tak się dzieje, to ciężko jest ustalić z tych fragmentów (może nawet mając całość też nie będzie łatwe) .
Jeżeli dodanie zera na czwartej pozycji spowoduje, że będzie Ci działać, to trzeba będzie szukać dlaczego konwersja itoa daje taki efekt.
Najlepiej podpiąć PC i do niego wysyłać dane z informacją o stanie zmiennych, przy wystąpieniu warunku, gdzie i będzie większe od 4.

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 2 minutach ]


Powinien być, ale coś się dzieje u Ciebie nie tak

A przy ujemnych temperaturach poprawnie Ci pokazuje? Masz wtedy tmp->cel > 0x80:

Nie powinieneś przy spełnieniu warunku dodać usuwania znacznika ujemnej temperatury?


--
Pozdrawiam,
Robert

Ale jak wynika z Twojego kodu, to jak masz ujemną temperaturę, to masz wartość tmp->cel > 0x80. Potem taką liczbę poddajesz itoa(), więc albo masz wartość > 128, albo jak masz zmienną signed, to dostajesz drugi znak -.
Proponuję sprawdzić poprzez zapoznanie układu z lodówką (zamrażalnikiem). Tylko uważaj by czegoś nie wyjadł

--
Pozdrawiam,
Robert

A czytałeś:http://atnel.pl/mkuart-error.html?

W AVR nie ma priorytetów przerwań. Podczas wykonywania funkcji przerwania reszta oczekuje w kolejce na zakończenie, chyba że dodasz atrybut ISR_NOBLOCK.

Wysłane z mojego LG-E460 przy użyciu Tapatalka

To widać jak nieuważnie czytałeś ten artykuł, bo tak jak pisze kolega wyżej, w AVR nie ma priorytetów przerwań, więc proszę nie szerz jakichś dziwnych i niesprawdzonych wiadomości na dodatek pisząc na potwierdzenie - że gdzieś coś tam czytałeś ... a nie potrafisz nawet zacytować jakiegoś fragmentu czy powołać się na konkretne informacje z artykułu. Gdybyś to zechciał zrobić to pewnie sam byś doszedł do wniosku jak to jest naprawdę z priorytetami przerwań w AVR.

_________________
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 ]

Witam

To chyba o ten artykuł chodziło, ale tu jest zaznaczone że jeśli jest wykonywane jakieś przerwanie a w kolejce czekają następne to tym "następnym wykonywanym" będzie to o najwyższym priorytecie.
Nie ma timera który pokazuje kolejność nadejścia żądań przerwań a jakoś należy rozstrzygnąć "kto następny" - ja to tak rozumiem, nigdy nie miałem natłoku przerwań więc nie wiem czy mam rację.

Pozdr.

A ja się z tobą Mirku nie zgodzę . Priorytety są.
Twierdzę tak z lekką przekorą do słów Mirka, bo nie takie jak myśli kolega. I dla początkujących słowa Mirka powinny wystarczyć.
Priorytety są tylko uwzględniane przy wybieraniu do obsługi przerwania w przypadku jeżeli w danym momencie są zgłoszone dwa lub więcej przerwania. Wykona się przerwanie to z wyższym priorytetem (niższy adres wektora przerwania). Tak ustalonego priorytetu nie można zmienić. Oraz ten priorytet nie obowiązuje w czasie obsługi innego przerwania (nie ma systemu przerywania przerwania przez inne z wyższym priorytetem).
To coś jak na skrzyżowaniu z drogami równorzędnymi. Żadna droga nie ma pierwszeństwa (nie ma priorytetu), ale jak pojawią się dwa samochody w tym samym czasie, to musi być jakoś rozsądzone kto ma pierwszy przejechać (czyli jest priorytet ). Lecz jak już ktoś wjechał na skrzyżowanie, to on ma pierwszeństwo przed tym dojeżdżającym do skrzyżowania, niezależnie od jego strony. I w procesorze tak samo - w momencie sprawdzania flag przerwań "przelatywane" są one w zadanej kolejności (to są te priorytety), ale jak już któryś został wyzwolony, to już on dostał priorytet i inni czekają.

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 2 minutach ]

O kicajek szybciej napisał o tym samym

------------------------ [ Dodano po: 15 minutach ]

Wracając do problemu kolegi, to przerwanie z wyższym priorytetem (niższy wektor przerwania) może skanibalizować cały czas procesora i inne przerwanie o niższym priorytecie się może wykonywać bardzo rzadko, albo wcale.
Dlatego, jak masz zaburzony timing przerwania timera, to należy popatrzeć się co się dzieje w innych przerwaniach a szczególnie w przerwaniach o wyższym priorytecie, bo może ono się zapętla - trwa tak długo, że jak się kończy, to już czeka ustawiona ponownie flaga i następuje kolejne jego wyzwolenie.

Jak masz kilka wolnych wyprowadzeń, to zrób prosty debuger. Jak wchodzisz do danej procedury przerwania lub danego eventa, to wystawiasz sygnał na wyprowadzenia a jak kończysz, to kasujesz. Dla różnych przerwań i eventów dajesz sygnał na inne wyprowadzenia. Dzięki temu jak masz stan zawieszenia, wiesz kiedy i jak długo jesteś w danym przerwaniu / evencie. Może uda się coś zobaczyć dając diody świecące, ale najlepiej jakbyś miał jakiś analizator by na nim poogladać wygenerowane tak przebiegi.

Co do przyczyn problemu, to sprawdź w kodzie czy nie masz gdzieś procedury, która może trwać w nieskończoność jak nie zostanie spełniony jakiś warunek, który nie zależy od samego procesora. Chodzi o to, że może przez zasilanie lub inne czynniki zewnętrzne układ wychodzi z danego stanu i nie odpowie w oczekiwany sposób. A ty czekasz na coś konkretnego, bo tak według Ciebie w tym stanie musi wyglądać odpowiedź a ona nie nadchodzi.

Przetestuj też jak zachowuje się układ jak w trakcie działania nagle podpinasz i po pewnym czasie podepniesz zewnętrzne układy (DSa, WiFi, OLEDa, itd).

Możesz też mieć jakiś problem z przepełnieniami buforów lub co gorsze przepełnieniem stosu

--
Pozdrawiam,
Robert

Witam,

Kolego MrNew, według mnie, jeśli dioda Led faktycznie się nie świeci i nigdzie w programie głównym nie masz wyłączanych przerwań, to jedynym rozsądnym wytłumaczeniem tego zjawiska jest to, że program "grzęźnie" w którymś z pozostałych przerwań - innego logicznego wytłumaczenia nie ma. Tylko dokładnie sprawdź, czy czy nie masz gdzieś ATOMIC_BLOCK... czy jak to się tam pisze, alb cli().
Jeśli dysponujesz oscyloskopem, to daj to LED_TOG bez tego licznika (cnt) i zobacz oscyloskopem, czy na tej diodzie masz przebieg i jaki ( z tego co widzę, powinno być 50Hz i normalnie dość powtarzalny ). Jeśli w momencie "zawieszenia" się programu zaobserwujesz na oscyloskopie stabilny stan niski lub wysoki - sprawa będzie oczywista. Mam pewne podejrzenia, ale sprawdź najpierw to z tym LED_TOG bez licznika. I napisz proszę, jaką masz ustawioną szybkość transmisji UART-a i jakiej długości stringi wysyłasz/odbierasz.

Pozdrawiam, QuadMan.

więc widzisz razem wiemy o co chodzi - a udajemy, że się nie zgadzamy ... i po co?

Zwykle każdy kto pisze o priorytetach przerwań to ma na myśli takie jakie są np w 8051 i nie mów że nie. A to, że w AVR są poukładane w kolejności .... ale to już pewnie sam wiesz że bezsensowna dyskusja. Bo i tak jak się mówi "priorytety przerwań" to chodzi o taki mechanizm jak w 8051.... Więc nie czarujmy młodzieży

_________________
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 ]

Witam,

Kolego MrNew, Spróbuj może opisać to wszystko w jednym poście od początku: jakie elementy masz podłączone, jaki procek (ATMEGA328, tak ), jakiś szkielet programu - jakie eventy, jakie przerwania, czy do i2c i Uarta libsy Mirka itd, bo już się w tym wszystkim gubię - podejrzewam, że nie tylko ja. Na razie strzał na ślepo, zastąp:

tym:


I czy aby na pewno masz INT0 na zbocze - nie czasem na poziom? A może dodatkowo używasz jeszcze INT1? Ja w celach testowych dałbym w kodzie puste wektory od tych dwóch przerwań, bo może gdzieś czasem przypadkiem masz jednak ustawione bity w rejestrze EIMSK, weź może wyzeruj go na wszelki wypadek w rtc_init.

Pozdrawiam, QuadMan.

Może pomoże:)
Ja kiedyś miałem podobną sytuację z M328P i RTC, że procek zawieszał się niby "bez powodu", a program był banalnie prosty. Winną okazała się zbyt prosta obsługa transmisji I2C.
W funkcjach bibliotecznych są pętle while podczas transmisji danych (oczekiwanie na koniec transmisji) i jak transmisja nie pójdzie zgodnie z planem, to mamy zawieszenie procka.

Wystarczy w tych funkcjach dać prymitywny drugi warunek w zależności od czasu (taki pseudo watchdog), np.:

Czas oczekiwania najlepiej dobrać doświadczalnie w zależności od złożoności danej funkcji i szybkości jej wykonania (oczekiwania na koniec transmisji). Jak robiłem testy, to poprawna transmisja TWI_write/TWI_read nie trwała dłużej niż 120us przy czestotliwości magistrali 50kHz oraz 15us@400kHz. TWI_start/TWI_stop oczywiście trwały kilka razy krócej.

Może nie jest to zbyt eleganckie rozwiązanie (trochę wydłuża wykonanie funkcji), ale u mnie działa i procek się nie wiesza, a to chyba najważniejsze.

Jeszcze sugeruję ustawić przerwanie INT od RTC na zbocze opadające a nie poziom niski.

Pozdrawiam