Serial port kesleltetes

 ( sza2king | 2009. október 20., kedd - 22:25 )

Hi,

Vegulis nem hiszem, hogy C/C++ problema, talan Linux, de meg az is lehet, hogy egyik sem.

Soros porton kell rovid csomagokat kuldenem (~3-5 byte) es fogadnom (1 byte). Peldakent:

while(1) {
write(dev, data, 3);
read(dev, data, 1);
}

Probaltam kulonbozo sorosportokat, de a read es a write kozott mindig van kesleltetes (ha csak write van, a kesleltetes nem eszreveheto). Ugy tunik fuggetlenul a baud rate-tol (115200-tol 921600-ig nezegettem), de fugg az eszkoztol:

FT232BL usb-serial -> ~16ms
NetMOS chippes pci card -> ~3ms
PL2303 usb-serial -> ~1.5ms

Tekintve, hogy 1 byte kuldese vagy fogadasa 921600bps-nel 10us, a kommunikacio igen nagy reszet a felesleges varakozas teszi ki.

Van valakinek otlete, hogy mitol lehet? Netan megoldas ra...

Koszi,

/sza2

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hát szerintem mivel a soros port kezelés it alapú, ezért a kernel a soros porti adatokat elveszi amint a megfelelő it rutin lefut,
de a te alkalmazásod ezekhez adatokhoz csak akkor jut hozzá mikor ütemezve lett, és mivel az ütemező algoritmus csak minden
tick (1 ms PC-nél) esetén nézi meg, hogy kell-e e az aktuális processzust váltani ezért kliens szinten, hacsak nem a te processzusod
van ütemezve akkor kell várni egy kis időt amíg a feldolgozás megtörténik. A változó hozzáférési idő pedig a driver minőségével függ össze.
PC-n preemptív környezetben soha ne írj olyan kódot ami 1ms alatti hardver kommunikációtól függ.
Erre a megoldás egy kis mikrovezérlős áramkör amihez a feladattól függő memóriát illesztesz, hogy tudjon tárolni 500-1000 ms inputot
és azt amikor csak tudod beolvasod a PC programodba.
Ha így csinálod sokkal több sikerélményed lesz, mint elvárni, hogy ~10us késleltetéssel kapj adatot.
Vagy használj valami rtos-t, de x86-on azok csak kvázi real time-ot tudnak, legalábbis nekem az a tapasztalatom.

Most is egy fpga board van a sorosportra kotve, csak nem akartam azzal butykolni, egyszerubbnek latszott a PC oldaon valo megvalositas. Egyebkent onmagaban az adatok tarolasa nem megoldas, mert az, hogy mit kuldok, fugg attol, hogy mi volt a valasz, igy az egesz logikat a kulso eszkozbe kell beleepiteni...

Ezzel egyetértek, az egész adatgyűjtő logikát a külső eszközben kell megvalósítani, az iparban is így csinálják(juk). Az adatfeldolgozás az egyetlen feladata a PC-nek, és a szabályozásba történő beavatkozás, mint a SCADA rendszereknél.
Ha jól akarod megoldani a feladatot akkor egy külső eszközt csinálsz/csináltatsz ehhez a projekthez, az
adatgyűjtő rész megvalósításához.

Szerintem.

És ha nagyobb a távolság mint 5m és esetleg még ipari környezet (nagyfeszültség, nagy áramok és impulzusok) akkor nem RS-232C -vel nyomulsz (minimum RS-422, de inkább ethernet).

* Én egy indián vagyok. Minden indián hazudik.

Bocsásd meg kíváncsiságom, de hol kell ilyen elvetemült sebesség és ilyen szigorú időzítés? Tudsz mondani valami bővebbet a projectről?
Miért zavar, a 10us/3ms "kitöltés"? Hol gondoltad elválasztani a nagy sebességű realtime működést, a hihetetlenül lassú emberi alapú interakciótól? A két követelmény szigorúan ellentmond egymásnak.

* Én egy indián vagyok. Minden indián hazudik.

A "project" egy mikrokontroller programozo. CC2430-as Zigbee IC-ket kell felprogramoznom. A notebookommal - nincs parhuzamos port, nincs soros port - gyakorlatilag csak USB to valami interfesz johet szoba.

"Hol gondoltad elválasztani a nagy sebességű realtime működést, a hihetetlenül lassú emberi alapú interakciótól? A két követelmény szigorúan ellentmond egymásnak." - szerintem nem, talan igy tisztabb kepet kapsz a dologrol:

Jelenleg notebook - fpga board - CC2430-as board a konfiguracio. Az fpga jelenleg egy igen egyszeru feladatot lat el, az RS232 soros adatokat atalakitja egy szinkron soros (I2C - SPI keverekhez hasonlo) formaba. Kb. 10-50kbyte adatot kell beegetni, de a protokoll overheadbol adodoan ez nagyjabol 10x-es adatmennyiseget jelent. Viszont nagyon kicsi csomagokban (mint irtam 3-5 byte kuldes, 1 byte fogadas).

Az extrem nagy sebesseg (921600) nem lenne szukseges, 115200 is eleg lenne, de mivel megy igy, miert gond? A baj, hogy csomagok kozott eltelt ido nagysagrendekkel nagyobb mint maga csomag kuldes (a write es a read kozott miert nincs kesleltetes? - miert csak a read utan van?). Az ethernet es a 485 kizarva, tavolsag kicsi, raadasul az ethernet tipikus agyuval verebre lenne.

Ha nem talalok megoldast, megcsinalom az fpgaval az egeszet, csak az joval nagyobb macera - tekintve, hogy kevesbbe ertek hozza.

A kerdes az, hogy van-e esely a kesleltes csokkentesere. Vegulis haladas, hogy FTDI helyett Prolific-et hasznalok, igy a programozasi ido 10-15 percrol masfelre csokkent. De a fejlesztesnel meg esz is eleg sok - egy adott hiba kijavitasa, ujraforditas neha rovidebb ido mint a letoltes.

teljesen hozzá ne értően, csak kíváncsiságból kérdem:
miért kell a programozásnál ilyen kis adatokban visszaolvasni?
nem arról van szó hogy néhány k(M)byte-t kiírsz és visszaolvasod jó-e? (csak gondolkodtam és nem jutott eszembe semmi olyan amihez így bytonént kellene programozni, csak mondjuk valami gép kalibrációja, de ott meg ilyen kis idők gondolom nem számítanak)

A kontrollernek at kell kuldenem par bajtot (utasitas + parameterek) majd meg kell varnom amig visszakuldi ra a valaszt (egyebkent szinte azonnal (azonnal = nehany mikroszekundum)). Ezt nem tudom megkerulni.

Ha valakit komolyabban erdekel, a CC1110/CC2430/CC2510 Debug and programming Interface Specifications-ben le van irva (http://focus.ti.com/lit/ug/swra124/swra124.pdf).

HŰ, ez amolyan határeset, a türelmetlenséged és az adott lehetőségek között ;)
Ahogy mondtam, a sebesség csak nagyobb távolságok és zavart környezet mellett okozhat gondot - egy laborban általában nem, kivéve ha mondjuk Van Der Graaf generátor mellett kell dolgoznod (de azt a notebook sem bírná).
Szerencsére ezzel a protokollal még nem találkoztam (3-5 bájt küldés és 1 bájt vétel - gondolom nyögta) - kár hogy a jó öreg Intel hex és testvérei kimentek a divatból :(
Szerintem gondold át, ha jól értem ez a töltögetés, csak a fejlesztés során kell és fáj!? Becsüld meg azt az időt mit az fpga piszkálásra fordítasz és addig hányszor tudod letölteni a program módosításokat?

* Én egy indián vagyok. Minden indián hazudik.

A letoltendo alkalmazas itt is hex formatumban van. De mint szinte mindenhol, a (PC-s) programozo dolga, hogy a hex-bol 0-kat es 1-eket csinaljon...

A régi, szép időkben az ilyen hardware -k alap funkciói között volt az Intel vagy Motorola hex ASCII kommunikáció. Nem véletlen, hogy az akkori compilerek outputja hex volt :)

(szerk: én is írtam egy-két ilyet anno. De nem fpga -ra)

* Én egy indián vagyok. Minden indián hazudik.

Bár ez nem segít rajtad: Ha függ az illesztő típusától, akkor a késleltetést vagy az illesztő, vagy a hozzá tartozó driver okozza.

Hát ha ez neked hatékonyabb, akkor írj egy új soros drivert ...
Driver szinten már sokkal "keményebben" megfoghatod a kernelt.

* Én egy indián vagyok. Minden indián hazudik.

hello,

Tavaly egy munka kapcsan vegeztem teszteket, akkor 2.6.26 korul jart a kernel. Azt tapasztaltam, hogy egy atlagos pc-n 5-40mS a kesleltetes a soros portra megerkezo elso karakter es a kiszolgalas megkezdese kozott. Meg mielott tobben felhorkannak, hoy honnan tudom mikor kezdodott a feldolgozas, a soros portra erkezo karaktert lattam szkopon, majd a feldolgozo fuggveny elso dolga volt, hogy a soros port egyik nem hasznalt vezerlo bitjen egy tusket generalt, amit szinten lattam szkopon.

Probalkoztam real-time patch-el is, ettol 20mS korulre csokkent a max ido, de ritkabban voltak 40mS-osok is.
Maradna a real-time os, ami kb. 50uS-ot garantal, de ennek ara van.

Ha csak egy programozo hw-t kell kiszolgalni, tenyleg egyszerubb ha csinalsz egy celhw-t, amiben egy mikrokontroller van. Ennek le tudsz kuldeni egyszerre egy nagyobb puffer-t, majd eljatszik vele.

En is szkoppal mertem. Hat, ha tenyleg nincs mas megoldas, megprobalom atteni az fpga-ra.

Még egyszerűbb, ha leporolod a régi (akár 386 -os, Linus is azzal kezdte) vasadat, felcsapsz rá egy DOS -t (floppyról is ketyeghet) és arra írsz valami gw szerűt - ez a legolcsóbb "celhw" :)

* Én egy indián vagyok. Minden indián hazudik.

Az otlet nem rossz, de a i386-ost nincs kedvem naponta cipelni a munkahelyemre majd haza :-) Meg lehet, hogy nem is engednek, de legalabbis minden nap ketszer papiroznom kellene a portan.

Hát hagyd ott, jól jöhet az még! Ha m,eg nem könnyebb megszabadulni tőla - veszélyes hulladék!

* Én egy indián vagyok. Minden indián hazudik.

Szerezz valahonnan 486-os laptopot. Lehet meg szerezni biztosan...
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azert ezeknel az otleteknel egyszerubb kivarni a masfel percet...

Persze, de egy 486-os laptop jo lehet masra is... a mostani Windowsokon a DOS-os programozok jo resze nem futik. Raadasul, egy akkori laptop meretre nem sokkal nagyobb, mint egy mai (jo, egy picit vastagabb), sulyra talan valamivel tobb, de meg boven a hordozhato kategoria (legalabbis, egy nagy PC-be belegondolva...)
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.