[kaczakat]

Komunikacja po uart trwa określony czas, jak masz ustawione 9600 to w przybliżeniu 1 znak (bajt) leci 100us, a każdy bit, czyli stan na pinie wysoki/5V i niski/0V też trwają ponad 10us. Ale nawet taki wolny uC jak Atmega potrafi cały bajt wziąć z bufora w ciągu 1 cyklu zegara, czyli w UNO 63ns. To się po prostu czasowo rozjeżdża jak bierzesz 1 znak i każesz programowi coś z tym robić i jeszcze wynik tego działania od razu chcesz wysłać na ekran. GPS wysyła linie tekstu i taką trzeba dostarczyć do programu, wybrać moment gdy jest już faktycznie coś do wyświetlenia i wtedy to zrobić. Trzeba też wiedzieć, co z tego "zrobią krasnoludki" w bibliotece, a co trzeba samemu zapewnić.

[oscarX]

Komunikacja po uart trwa określony czas, jak masz ustawione 9600 to w przybliżeniu 1 znak (bajt) leci 100us, a każdy bit, czyli stan na pinie wysoki/5V i niski/0V też trwają ponad 10us. Ale nawet taki wolny uC jak Atmega potrafi cały bajt wziąć z bufora w ciągu 1 cyklu zegara, czyli w UNO 63ns.  To się  po  prostu czasowo rozjeżdża jak bierzesz 1 znak i każesz programowi coś  z tym robić i jeszcze wynik tego działania od razu chcesz wysłać na ekran. GPS wysyła linie tekstu i taką  trzeba dostarczyć do programu, wybrać moment gdy jest już faktycznie coś do wyświetlenia i wtedy to zrobić. Trzeba też wiedzieć, co z tego "zrobią krasnoludki" w bibliotece, a co trzeba samemu zapewnić.

Przecież driver serial właśnie to robi - zapamiętuje nadchodzące dane w buforze, który ma 64 bajty.
Akurat ta (o ile oglądałem tą samą) biblioteka działa napędzana pojedynczymi znakami. Tam jest automat stanów, który rozpoznaje typ sekwencji i numer pola. Zapamiętuje wartośći w zmiennych pomocniczych i jeśli CRC się zgada przepisuje do zmiennych roboczych i ustawia, że valid. Przypuszczam, że problemy są z tego 1Wire - atmegi nie mają specjalizowane sprzętu do obsługi tego protokołu i trzeba bawić się softem z krytycznymi zależnościami czasowymi. Sam wspominałeś, że transmisja po 1wire blokuje na chwilę przerwania, co może spowodować zgubienie znaków, a akurat tego obiekt serial nie sygnalizuje (dziwne bo to nawet sam sprzęt wykrywa). Pytanie co serial zrobi w takiej sytuacji - zignoruje stare (czyli dalej zapisze do bufora, zamazując stare) czy nowe znaki (czyli się zatrzyma do czasu zrobienia miejsca). Lepiej jakby gubił stare.
Najlepiej byłoby użyć inne termometry - nie te 1wire.

[Jarewa0606]

A po co zmieniać termometry? jak ma sprzętowy serial który się nudzi. On nie zgubi znaków w przypadku transmisji 1wire.

Ale nie o to mi chodziło, bo pytał się jak zrobić wyświetlanie/ odświeżanie było na równie z odczytem danych gps. Dlatego mu odpisałem że to można bez millis-a wystarczy synchronizacja ale nie w takim kodzie co miał niech pogłówkuje.

Skoro idę na kibelek to nie mam ustawionego czasu na spłukiwanie lecz zrobię swoje i spłuczkę uruchomię. Takie proste czynności synchronizacyjne, ale nie da się jak widzę "while" coś co blokuje bo przecież siedząc na klopie mogę oglądać forum czyli zrobię coś więcej niż tylko kibelek.

[oscarX]

A po co zmieniać termometry?  jak ma sprzętowy serial który się nudzi. On nie zgubi znaków w przypadku transmisji 1wire.

Ale nie o to mi chodziło, bo pytał się jak zrobić wyświetlanie/ odświeżanie było na równie z odczytem danych gps.  Dlatego mu odpisałem że to można bez millis-a wystarczy synchronizacja ale nie w takim kodzie co miał niech pogłówkuje.

Skoro idę na kibelek to nie mam ustawionego czasu na spłukiwanie lecz zrobię swoje i spłuczkę uruchomię. Takie proste czynności synchronizacyjne, ale nie da się jak widzę "while" coś co blokuje bo przecież siedząc na klopie mogę oglądać forum   czyli zrobię coś więcej niż tylko kibelek.

Problem może być w tym, że 1wire blokuje przerwania, co może powodować gubienie znaków na serialu (GPS).
Zgadzam się że nie potrzeba korzystać z millis - skoro czytamy czas z GPS to można na tym takcie bazować. I czytać
1 termometr co 5 wyników z GPS, po następnych 5 wynikach drugi termometr. Dodatkowa zaleta, że odczyt 1wire będzie synchronizowany z GPS - skoro przyszły dane, następne będą za 1 sekundę, jest sporo czasu. Niektóre odbiorniki GPS można konfigurować, np. wybrać które sekwencje NMEA mają wysyłać. Można zostawić tylko te dwie z których korzysta biblioteka, będzie mniej niepotrzebnego ruchu na serialu, który i tak trzeba przeczytać.

[Prosiak_wej]

W ramach testów mam już GPS przepięty na serial sprzętowy, jest nieco lepiej, bo wskakują trzy... cztery odczyty prędkości co sekundę i kilka sekund wisi ostatnia. A tak sobie czytam Wasze ostatnie posty, próbuję je zrozumieć i wciąż nie wiem jak je wprowadzić w życie. Jest jeszcze masa funkcji, komend, warunków o których istnieniu pojęcia nie mam, więc coś co dla Was jest proste i wystarczy chwilę pogłówkować, dla mnie nadal jest barierą nie do przebicia. Bo nawet, jeśli mógłbym sobie coś teoretycznie wyobrazić, to i tak nie wiem jak to ubrać w kod.

Poza wskazaniem stawu, w którym są ryby, dajcie jeszcze wędkę i trochę przynęty

Też pomyślałem, żeby dołozyć RTC. Zanim z GPS popłynie czas, to byłby pobierany z RTC, a w przypadku rozjazdu z czasem z GPS - aktualizowany w RTC. Może być czas UTC, w samym wyświetlaniu mam korektę na czas polski zimowy i letni za pomocą fizycznego przełącznika.

[oscarX]

Typowy objaw, że gubisz co którąś daną z GPS. Ponieważ są tam sumy kontrolne, co nawet 1 bład powoduje odrzucenie całej linijki (sekwencji NMEA).
Dla próby spróbuj wyłaczyć odczyt termometrów - jeśli to gubienie znaków z seriala z powodu 1wire to GPS powinien działać płynnie. Jak pisałeś, robiłeś już takie próby i było dobrze.
Chyba najlepiej będzie odczyt termometrów zrobić po co którymś (np. co piątym) poprawnym odczycie prędkości. Czas idzie też w tej samej sekwencji czyli jak odczytasz prędkość to i czas. Nawet jak kolejna sekwencja się źle odczyta, to kolejna prędkość przyjdzie za sekundę, już skutki błędu powinny zaniknąć. I czytaj termometry pojedynczo - raz jeden, za następne 5 odczytów prędkości drugi. RTC w sumie dobre, ale chyba dobrze wiedzieć czy GPS działa. Jak startujesz w mieście i są kłopoty ze złapaniem tzw fixa dobrze jest postać chwilkę w odsłoniętym miejscu - w czasie ruchu w mieście warunki widzialności satelitów zmieniają się co chwila (budynki zasłaniają raz z lewej, raz z prawej) i odbiornik nie może ustalić z których satelitów korzystać.

[Prosiak_wej]

Dla wskazywania złapania fixa GPS wyświetla się symbol satelity, wcześniej jest x. Jednak to tez nie do końca działa, bo jak sygnał z satelitów zniknie, to x nie powraca. To jest kolejna rzecz, którą musiałbym wyprostować. Koncepcja z odczytem temperatury co kilka, kilkanaście a nawet kilkadziesiąt odczytów GPS jest słuszny, nawet co minutę będzie okej. RTC dawałby już aktualną godzinę od razu, na prędkość można poczekać.

[oscarX]

Dla wskazywania złapania fixa GPS wyświetla się symbol satelity, wcześniej jest x. Jednak to tez nie do końca działa, bo jak sygnał z satelitów zniknie, to x nie powraca. To jest kolejna rzecz, którą musiałbym wyprostować. Koncepcja z odczytem temperatury co kilka, kilkanaście a nawet kilkadziesiąt odczytów GPS jest słuszny, nawet co minutę będzie okej. RTC dawałby już aktualną godzinę od razu, na prędkość można poczekać.

Z tym fixem to albo timeout - czyli jak dane nie pojawią się kilka sekund, albo odczyt z GPS (bo tam jest info o fixie) tylko chyba akurat ta biblioteka tego nie daje - takiej aktywnie generowanej informacji, że fix został utracony, brakuje jakiejś funkcji, odwrotnej do valid. Przydałaby się także do wybrania RTC jako źródła czasu. Obróbka danych z GPS jest na tyle prosta, że biblioteka do tego nie jest niezbędna, trochę zabawy z tekstem. Ale skoro już jakąś "rozgryzłeś" to wystarczy dopisać jedną funkcję - sygnalizującą, że odczytano właściwą sekwencje NMEA, ale nie było tam czasu/prędkości.

[Prosiak_wej]

Rozgryzłeś to za dużo powiedziane. Wykonałem jakiś przykład prędkościomierza na wyświetlaczu LED, po czym go zaadaptowałem do LCD, więc o jej rozgryzieniu czy pełnym zrozumieniu mowy nie ma. Do mnie musicie jak do przedszkolaka - "idź zrób to, idź zrób tamto". Na razie próbuję rozkminić, jak zrobić naprzemienny odczyt termometrów co 60 sekund, żeby 1Wire nie zajmował za bardzo procesora, aby ten miał czas na zajęcie się prędkością. Ale od 10 godzin jestem w pracy i nawet nie miałem kiedy sobie tego rozmyślić.

[Prosiak_wej]

W jakichś 95% sobie poradziłem. GPS podłączyłem do sprzętowego UART, a odczyt termometrów ograniczyłem do dwóch na minutę dzięki funkcji millis. Jest prawie dobrze. Prawie, bo... chciałbym jeszcze sygnalizować fix lub jego brak (wyświetlenie odpowiedniej ikonki). Obecnie po włączeniu jest krzyżyk i po złapaniu fixa zmienia się on na symbol satelity. Ale, gdy fix się zerwie (np. po wjechaniu w tunel) lub odłączeniu odbiornika GPS, symbol satelity nadal się wyświetla. Nie wiem, jak to ugryźć, aby poprawnie rozpoznać i móc ustawić jakąś zmienną np. fixgps = 1, gdy sygnał jest oraz fixgps = 0, gdy go zabraknie, w jakikolwiek sposób.