🚀 go-pugleaf

Lembit wrote:

> Aga s�ndmuse reaalne aeg l�heb nihkesse.

Koera saba tuleb ka jupikaupa l�igata. Et nii valus poleks :)

> kui buffris on 11 paketti ja  nt. esimeses  muutus mingi tingimus t�eseks
> ning 11-ndas muutus �ra, siis reaalselt oli t�ese aeg 6*10 mS,
> need korraga mahalugedes aga on nullil�hedane.

Siis kui sa m��rad aega PC lugemise j�rgi.
Aga kui m��raks aja mikros, saatmise j�rgi?


Mahalugemise aeg on ja null, aga saadeti nad ju iga�ks oma ajaaugus.
Kui saadetisst vahe on 6 ms, siis esimene on toimunud ajahetkel null. 
teine 6 ms
kolmas 12 ms
neljas  (4-1)*6
jne


> Asi ongi selles, et on vaja teada s�ndmuste algust ja l�ppu(vahet)
> Vajalikud s�ndmused on 50mS... 1min vahemikus
> Ekraanile ja kirja l�heb �le 10 sekundi olevad
> Aga t�psus peab olema mitte �le pluss-miinus 10mS.
> Ei p��se kuhugi, peab s�nkroonis olema
> Niisiis kuidas teha nii, et iga kella peale lasen
> 4 k�lalist sisse, aga eelmisest kellast ei tohi
> keegi olla uksetaha j��nud, kes seltskonda ei sobi?

Sea sisse kord et iga neliku esimesele mehele antakse k�tte punane lipp.
(�ks bait algusse lisaks) Selle j�rgi tunned �ra kust jada algab.
Ja j�rjekorranumber. Et keegi vahele ei tr�giks v�i ei j��ks. (veel �ks 
bait lisaks) Baiti mahub k�ll 256 tegelast, aga kui 255 j�rgi tuleb 
null, siis liida j�rjele �ks juurde. Matikud �tlevad vist et loendaja on 
v�etud moodul 256ga.
Seega �ks blokk on 6, mitte 4 elementi.

N��d kui sul buffer algab "punase lipuga" ja "j�rjega" 34, siis
6000. grupi algus on 6*6000+34 ja tema "j�rg" on 194.
(kontrolli �le).

T�psuse garanteerib mikromasina kvarts.
Aga seeeest ei pea PC pingutama nagu hull.
V�id vahepeal netis kirju lugeda. :)

Ja t�pselt sama programm saab hakkama ka selle salvestatud faili t��tlusega.
Vahet pole, kas lugesid log failist v�i com pordist.

Nii tundub mulle.
Mis on valesti?

A.R.