Sziasztok! Köszönöm a válaszokat.
A semmiből születő byte -os problémát az oldotta meg, hogy közvetlenül az utolsó byte kiíródása után kiürítem a bejövő puffert. (tcflush(fd, TCIFLUSH)) A mikor megy ki az utolsó byte -ra a do ioctl(fd, TIOCSERGETLSR, &x); while (!x) lett a jó megoldás. Annyit tettem bele, hogy várok 1ms -t az ioct előtt. A tcdrain() annyira sokat várt, hogy lekéstem a slave -ek adásáról. (Néha a végét még elkaptam. Pedig man szerint tényleg remek lenne.) (A plusz porton csak azt értettem, hogy nem a lapon lévő dsub -ra kivezett, hanem ami a bővítőportra van kötve) Az l-code-l lista tényleg ne túl aktív az archívuma alapján. :( SCHED_FIFO -t bekapcsoltam, ártani nem árthat. A nice ilyenkor változtat még a dolgokon? (Mindenesetre -3 -ra átállítottam.) És az, ha bekapcsolom a kernelkonfigban a nagyon preemptive módot? (System type and features/preemption model: preemptible kernel?) A nanosleep -ről azt olvastam, hogy SCHED_FIFO -val együtt <= 2ms -nél pont busy wait -et csinál, nekem meg pont ez kell. Csak a man oldalán az áll, hogy 2.5.x -ben ezt megszüntették. Mindenesetre többnyire annyit vár, amennyit kell neki, így megfelel. Annyira nem halálos, ha pár csomag elveszik a kommunikációban. (Egy rfid -s beléptetőről van szó, ahol a leolvasók a 485 buszra vannak fűzve. Max. 1 másodperccel későb nyílik az zár. Ez még a mai rohanó világban is belefér. :) ) > A csupa nulla alighanem egy break eredménye. ioctl(fd, TIOCSERGETLSR, &status_register); szerint csak a 0. bit van beállítva. Olvastam már, hogy sok hibát javítottak ennek az atmel sorosportnak a driverében, valsz. van még pár. Az a bufferürítés mindenesetre megteszi. -- Üdv: SA _________________________________________________ linux lista - [email protected] http://mlf2.linux.rulez.org/mailman/listinfo/linux
