W dniu 2014-11-12 17:21, Jakub Rakus pisze:

> Prawdę powie Ci kod w assemblerze, zajrzyj tam i policz ile to
> instrukcji wymaga. Takie liczenie bywa upierdliwe, szczególnie gdy
> fragment kodu zawiera jakieś pętle i odwołania do funkcji, ale wynik
> bywa zaskakujący i dobrze uświadamia gdzie spędzamy za dużo czasu.

Hmm... To ja głupio zapytam - w jaki sposób dostać się do tego kodu?
Istnieje jakiś sposób na ustalenie która część kodu odpowiada danemu
fragmentowi w C? Bo niestety nie znam asemblera AVR-ów, a z jako takim
miałem do czynienia przed laty, robiąc proste "wprawki" pod x86...

Generalnie istnieje jeszcze jakaś inna możliwa przyczyna takiego
zachowania programu? Najbardziej dziwi mnie to, że opóźnienie wynosi
kilka sekund tuż po ostatniej synchronizacji, a sprowadzenie go do 0-1s
wymaga wielokrotnych, wymuszanych synchronizacji, jedna po drugiej.

Generalnie układ nie był projektowany z myślą o liczeniu czasu. Gdybym
wiedział o tym na początku, zastosowałbym inny mikrokontroler, dający
możliwość podłączenia zewnętrznego kwarcu zegarkowego i generowania
przerwań z częstotliwością dokładnie 1Hz. To już trochę ułatwiłoby
sprawę, gdyż nie musiałbym zliczać milisekund w przerwaniu.

do góry

On 12.11.2014 17:43, Atlantis wrote:

> Hmm... To ja głupio zapytam - w jaki sposób dostać się do tego kodu?

Nie wiem jakiego tam kompilatora używasz, ale jeśli GCC to wystarczy
dodać flagę -S i masz kod asemblera w pliku z rozszerzeniem .s

> Istnieje jakiś sposób na ustalenie która część kodu odpowiada danemu
> fragmentowi w C? Bo niestety nie znam asemblera AVR-ów, a z jako takim
> miałem do czynienia przed laty, robiąc proste "wprawki" pod x86...

Jak potrzebujesz bardziej zaawansowanych opcji (np. przeplatanie kodu
C/ASM):
http://www.delorie.com/djgpp/v2faq/faq8_20.html

> Generalnie istnieje jeszcze jakaś inna możliwa przyczyna takiego
> zachowania programu? Najbardziej dziwi mnie to, że opóźnienie wynosi
> kilka sekund tuż po ostatniej synchronizacji, a sprowadzenie go do 0-1s
> wymaga wielokrotnych, wymuszanych synchronizacji, jedna po drugiej.

Nie wiem co tam się dzieje w pozostałej części programu, być może masz
tam kilka przerwań, które przerywają się nawzajem zbyt często.
Generalnie wiele przerwań a atmegach to śliska sprawa, trzeba dobrze
rozplanować ich wykonywanie, bo te procki nie mają jako takich "jawnych"
priorytetów przerwań. Może dobrze by było odebrane dane z pakietu
wyrzucać na jakiś uart, niestety dla atmegi to jest chyba najszybszy
sposób na debugowanie.

--
Pozdrawiam
Jakub Rakus

do góry

On Wed, 12 Nov 2014 15:45:05 +0100, Atlantis <m...@w...pl>
wrote:
> Jeśli to tu leży przyczyna, to w jaki sposób powinienem wprowadzić
> poprawkę? Jak ustalić czas potrzebny do wykonania tych operacji?

Kod wygląda ok, myślałem, że w przerwaniu robisz te obliczenia. Nie
znam się na avr ale domyślam się z kodu, że przerwanie generowane
jest przez komparator tmera, przy czym timer biegnie dalej w trakcie
obsługi przerwania, tak? Ja bym na razie w funkcji main () obserwował
tylko wartość uptime (np. wyświetlając ja przez uart przy każdej jej
zmianie, taki stoper) . Chodzi o to by się upewnić czy lokalne
odliczanie sekund jest ok. Na pickach bez kwarcu odliczanie sekund
(uptime) taką metodą jak Ty zastosowałeś (przerw. co 10ms) na dobę
rozjezdżało mi się max kilka - kilkanaście sekund względem dobrego
zegarka.

--
Marek

do góry

Hmm... Nie wydaje mi się, żeby tu chodziło tylko o zajmowanie cykli
procesora przez operacje na zmiennych 32bitowych w przerwaniu.
Trochę przerobiłem program:

1) Zwiększyłem czas pomiędzy kolejnymi przerwaniami do 20 ms.
2) Przeniosłem obsługę niekrytycznych timerów do pętli głównej. Nic
złego się nie stanie, jeśli od czasu do czasu odczyt jakiegoś czujnika
opóźni się o sekundę albo uptime będzie pokazywał wartość zafałszowaną o
kilka sekund.

W tej chwili procedura obsługi przerwania wygląda następująco:

ISR(TIMER0_COMPA_vect) {
twenty_millis++;

if (twenty_millis > 50) {
geiger_pulses[seconds] = TCNT1;
TCNT1 = 0;
seconds = (seconds + 1) % 60;

one_second_tick = 1;

if (rtc) rtc++;

twenty_millis = 0;
}
}

Normalnie jest to tylko inkrementacja jednej zmiennej ośmiobitowej. Raz
na sekundę dochodzi do tego jeszcze kilka operacji na zmiennych
szesnastobitowych oraz inkrementacja zegara (zmienna 32bit), jeśli czas
został już pobrany. Trochę trudno mi uwierzyć, że zajmuje to więcej niż
20ms...

Poza tym jest jeszcze jedna dziwna sprawa - parę razy tuż po wymuszonej
synchronizacji czasu zauważyłem opóźnienie wynoszące np. 3 albo i 10
sekund. Przecież niemożliwe, żeby taka wartość nabiła się w kilka sekund!

do góry

On Wed, 12 Nov 2014 17:43:38 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... To ja głupio zapytam - w jaki sposób dostać się do tego kodu?
> Istnieje jakiś sposób na ustalenie która część kodu odpowiada danemu
> fragmentowi w C? Bo niestety nie znam asemblera AVR-ów, a z jako
takim

Ale poczekaj, sprawdż najpierw czy lokalnie czas (bez ntp) w miarę
precyzyjnie odliczasz (max rozjazd kilkanascie sek. na dobę).
Twoje przerwanie wygląda ok, nie powinno wprowadzać błędu o ile nie
ma innych przerwań blokujące to od timera. No i oczywiście timer musi
biegać podczas obsługi przerwania, aby czas jego obsługi nie dodawał
się do biegu timera. Przerwanie jest krótkie, a 10ms interwał
spokojnie powinien dać czas na jego obsługę. Atmega odkłada flagę
przerwania gdy ono nastąpi po cli() aby je wywoływać zaraz po sei()?
Jeśli czas lokalny będzie liczony ok to wtedy weryfikuj kod
synchronizujący czas ntp.

--
Marek

do góry

W dniu 2014-11-12 20:07, Marek pisze:

> Ale poczekaj, sprawdż najpierw czy lokalnie czas (bez ntp) w miarę
> precyzyjnie odliczasz (max rozjazd kilkanascie sek. na dobę).

To już wiem. Domyślnie synchronizacje zegara są wykonywane co godzinę. W
tej chwili mam 26 sekund opóźnienia po 18 minutach od uruchomienia układu...


> Twoje przerwanie wygląda ok, nie powinno wprowadzać błędu o ile nie
> ma innych przerwań blokujące to od timera.

W tym programie nie występują żadne inne przerwania. Drugi,
szesnastobitowy timer pracuje w trybie licznika, nie wywołując żadnych
przerwań.


> No i oczywiście timer musi biegać podczas obsługi przerwania, aby
> czas jego obsługi nie dodawał się do biegu timera. Przerwanie jest
> krótkie, a 10ms interwał spokojnie powinien dać czas na jego
> obsługę.

W tej chwili dałem 20ms i wyrzuciłem mniej krytyczne instrukcje do pętli
głównej. Problem ciągle występuje.


> Atmega odkłada flagę przerwania gdy ono nastąpi po cli() aby je
> wywoływać zaraz po sei()?

Tego nie jestem pewien, ale z ciekawości zrezygnowałem ze stosowania
cli() i sei() przy odczycie/zapisie zmiennej rtc. Chciałem zobaczyć czy
dryf będzie nadal występował. Występuje...


> Jeśli czas lokalny będzie liczony ok to wtedy weryfikuj kod
> synchronizujący czas ntp.

Nie jest liczony ok, jednak tej synchronizacji też nie jestem pewien.
Kilka razy zauważyłem, że skrypt pokazywał nawet kilkanaście sekund
opóźnienia (albo i więcej) tuż po starcie urządzenia albo wymuszonej
synchronizacji.

do góry

On Wed, 12 Nov 2014 20:48:31 +0100, Atlantis <m...@w...pl>
wrote:
> To już wiem. Domyślnie synchronizacje zegara są wykonywane co
godzinę. W
> tej chwili mam 26 sekund opóźnienia po 18 minutach od uruchomienia
układu...

To za dużo. Takie rozbieżności wskazują na źle dobrane wartości do
wygenerowania przerwania timera (pre/post scaler itp) albo timer
jest wstrzymywany gdy przerwanie jest obsługiwane.

--
Marek

do góry

Dnia Wed, 12 Nov 2014 12:43:21 +0100, Atlantis napisał(a):
> W dniu 2014-11-12 12:17, J.F. pisze:
>> Porownujesz z jakims innym urzadzeniem ... ale jakim ?
>
> Porównałem z webowymi wzorcami (np. currenttimestamp.com). Pokazują
> dokładnie to samo, co Raspberry Pi. Czas na Atmedze prawie zawsze różni
> się o pewną liczbę sekund...

Czekaj, zaczynam rozumiec.
Atmel wysyla pakiet NTP, przychodzi odpowiedz, atmega ustawia swoj
zegar na podstawie tego co przyszlo.
Potem sobie powieksza wlasny zegar w przerwaniach, a gdzies obok RasPi
odczytuje zegar z atmegi, odczytuje z ntp, porownuje i wychodzi mu
roznica znaczna ?
Mimo ze niedawno atmega ustawila czas w/g pakietu NTP?

Ja bym zrezygnowal z tego RasPi, wyrzucal wszystko tekstowo, i
porownywal naocznie.

Ale co mi sie nasuwa:
-czy oba korzystsja z tego samego serwera - ale mysle ze nawet jak z
innych to czas powinien byc zgodny,
-o ile kojarze, to NTP jest bardziej skomplikowany, wysyla sie w dwie
strony pakiety - moze cos nie/zle ustawiles ?
-czy przerwania tam dobrze wspoldzialaja ? Bo jak rozumiem -
przychodzi pakiet, w przerwaniu ustawiasz timer, w przerwaniu go
powiekszasz - to sie moze cos zle dziac. Ale rzadko.

-jaki masz czas odpowiedzi ? Moze cos tam sie w sieci blokuje i
pakiety gdzies czekaja

-typowo na unixach NTP nie przestawia zegara, tylko go zwalnia lub
przyspiesza i zmiana jest rozciagnieta w czasie. Unix nie lubi skokow
czasu. Ale to by dotyczylo RP, bo na ATmega jak rozumiem sam
programujesz.

Ale najbardziej podejrzewam:
-czy dobrze odczytujesz tego ENC i przerwania dobrze przychodza ?
Bo jakby tak pakiet przychodzil, ale atmega nic o tym nie wiedziala,
tylko czekala, a odczytywala pakiet przy calkiem innej okazji, ktora
nadejdzie nie wiadomo kiedy - to by tak moglo byc jak opisujesz.

J.

do góry

On Wed, 12 Nov 2014 21:29:38 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Ale najbardziej podejrzewam:
> -czy dobrze odczytujesz tego ENC i przerwania dobrze przychodza ?
> Bo jakby tak pakiet przychodzil, ale atmega nic o tym nie
wiedziala,
> tylko czekala, a odczytywala pakiet przy calkiem innej okazji,
ktora
> nadejdzie nie wiadomo kiedy - to by tak moglo byc jak opisujesz.

Przecież mu się czas już źle liczy lokalnie z timera a co dopiero z
ntp.

--
Marek

do góry

W dniu 2014-11-12 21:26, Marek pisze:

> To za dużo. Takie rozbieżności wskazują na źle dobrane wartości do
> wygenerowania przerwania timera (pre/post scaler itp)

Hmm... Faktycznie coś jest nie tak z timerem.
Wyłączyłem synchronizację przez NTP i kazałem po starcie programu
inkrementować zmienną rtc od 1 w górę. Po trochę ponad godzinie
nazbierało się 81 sekund opóźnienia...


> albo timer jest wstrzymywany gdy przerwanie jest obsługiwane.

Jak to sprawdzić?

do góry