FIX TV - az agyam megall

[Vomberg István]

2003-11-26, sze keltezéssel 16:09-kor Füzesi Arnold ezt írta:
> Javaval az a fo gond, hogy  a szemetgyujtes -aaaaaaaaaaaaajjjajajjajaj egy
> alkatreszeszacsko raesett a pakara az asztalrooool, debudoooooos- szoval a
> szemetgyujtes nem determinisztikus, es a prioritasa is magas. Ez okozza a fo
> bajt.

Oda kell figyelni a kódolásnál és nem slendriánkodni, akkor nincs gond a
szemétygűjtéssel.

Természetesen van helye ennek a technikának is, ha segfaultol a progi,
főleg fejlesztésnél.

> Erdekesseg:
> Csinaltam egy hw-t, egy FPGA 115.2k-n nyomta fel az adatokat sorosporton.
> Ugy, hogy 1 bitido volt a frame-ek kozott. A 200MHz PC-n NT4 alatt egy java
> alkalmazas fogadta adatvesztes nelkul.
> Ez azert nem olyan rossz... Nagyon meglepett legalabb is...

Miután a serial driver intézi a dolgot és nem a Java..... hát engem
speciel nem lep meg.
A folyamat a következő:
- Jön föl soroson a bájt
- Megérkezik, a 16C450 (550, stb) pufferolja majd kiad egy interruptot
- Valamikor a soros driver lenyúl a 16C550 pufferébe és kitakarítja azt
- Felpakolja a saját pufferébe, a kernel területen
- Állítja a számlálókat belül
- A Java alkalmazás által indított read() rendszerhívás észreveszi, hogy
van adat a driver pufferében
- Kiolvassa

Magyarul a feljövő bájtnak és a Java read() utasításának max.
köszönőviszonyban van köze egymáshoz. Több kilobájtnyi puffer és kernel
szintű meghajtók vannak köztük.

Abban az esetben, ha a feljövő bájtokra azonnal kéne reagálnod egy
kiadott bájttal a soros porton, meglepődnél a késleltetéseken. Kövesd
szkóppal az eseményeket és látsz csodát.
Küldjél fel 1000 darab akármilyen bájtot (legyen A5), majd egy egyedit
(legyen 5A). És erre az 5A-ra válaszolj egy write()-al a sorosra és
figyeld digit-szkópon. De legalább 20msec-et adjál a képernyő
szélességre.....

I.

-- 
Vomberg István <vomberg at chemotron.hu>
Chemotron Inc.   www.chemotron.hu