Dataloggaus ikäkriisissä, millä jatkossa?

[mk]

Ymmärsit väärin.
Pääasia on miten sitä käytetään.
Eikä siis käyttämisen käyttäminen vaan asentamisen käyttäminen.

Suurin ongelma on, että ketjusta puuttuu usein ainakin yksi lenkki.
Olen vuosien saatossa useamman kerran yrittänyt saada jalkeille vapaehtoista työryhmää, joka toteuttaisi tällaisen avaimet-käteen-projektin käsikirjan, milloin mistäkin tarkkaan rajatusta aiheesta.
Viimeistään siinä vaiheessa kun täytyy ruveta sijoittamaan asiaan tunteja niin tulee kato.

Toteutus täytyy siis onnistua niillä mitä on, oli se sitten tietoa tai taitoa.
Jos sattuu olemaan naapurissa täydentävä kaveri niin hyvä, jos se kaveri on naapurikylässä niin huono.

Tässä tiedonkeruuasiassa Wikipedian Southbridge-artikkelista näkee tilanteen.
Periaatteessa kaikki vanha voisi toimia jo nyt varsin yksinkertaisilla emulaattoreilla.
Esim. vanhan I/O-väylän osan voisi rekisteröidä kuten minkä tahansa muunkin, ei uudet prosessorit muutenkaan tiedä mitä niiden osoittamassa osoitteessa tosiasiallisesti on.
Tällainen emulointi ei vaan ole kennellekään mitenkään tuottavaa toimintaa.

Edellä mainitusta huonosta ketjusta seuraa sitten helposti huono toteutus.
Tästä malliesimerkki on reaaliaikaisuuden vaatimus Windows-ympäristössä.

 

[jahonen]

Ei tiedä ei, mutta käytännössä on kuitenkin niin että prosessorin matalan tason IO-jaksot (out- ja in-käskyt) ovat huomattavan nopeita verrattuna USB:n käyttöön.

USB on ennemminkin ajateltu että sinne työnnetään tai sieltä vastaanotetaan iso määrä dataa jonka se laite/PC prosessoi omaa tahtiaan, kuten normaalin printterin kanssa tapahtuu. USB on todella huono jos halutaan pientä edestakaista latenssia. Edes PCIe ei ole kovin pienilatenssinen tuommoisessa käytössä, vaikkakin useita kertaluokkaa USBia parempi. Tässä on tärkeä erottaa throughput ja latenssi jotka eivät välttämättä mitenkään korreloi samaan suuntaan.

Eli ehdotetussa emulaatiossa täysin optimaalisessa tapauksessa kun havaitaan että ollaan lukemassa LPT-porttia sopivasta trapatusta IO-osoitteesta, pitäisi ensin lähettää USB-laitteelle jotain endpointtia pitkin tieto että "lue portti". Vastaus tähän voidaan saada aikaisintaan USB-kehyksen ajan kuluttua joka on normaalissa USB:ssä 1 ms ja highspeedissä 125 µs, joten vasteaika lukuoperaatioon voisi emulaatiota käyttävän softan kannalta olla pahimmillaan 2 ms tai 250 µs, joka on painajaismaisen pitkä verrattuna normaaliin IO-porttiin.

Mikäli rinnakkaisporttiin liitetty laite vaatii tarkkaa ajastusta niin pieleen menee. Ja koko tämän operaation ajan prosessori olisi siis haltissa kun tuota emulaatiota tehdään. Koodiahan ei voi ajaa yhtään käskyä eteenpäin ennen kuin lukuoperatio on valmis ja data voidaan palauttaa. En tiedä miten se sopii siihen että pitäisi samaan aikaan ajaa USB-pinoa yms. Ehkei se ole ongelma jos odotusaikana voisi tehdä jotain muuta, epäilen vaan tuon toimivuutta. En niinkään sitä että tässä olisi takana mitään erikoista salaliittoa. Enkä jaksa uskoa sitäkään että joku USB-tulostinportti kävisi tähän emulaatioon mitenkään vaan pitäisi tehdä ihan spesiaali-USB-laite joka on tähän suunniteltu.

En tunne x86:sta niin tarkkaan että saisiko tuota toimimaan, ehkäpä, mutta nopeudessa se ottaa varmasti 1000x turpiin tavalliselle IO-portille.

t. Janne

 

[mk]

Ymmärrän ettet tunne x86-ympäristöä n. 286n jälkeen juuri ollenkaan.
En väitä itsekään mokomaa tuntevani merkittävästi enempää.

Muistan pari vuosikymmentä taaksepäin ihmetelleeni kun cli/sti lakkasi toimimasta.
Tein vielä ihan testinkin ja sain reilusti alle tuhat kierrosta sekunnissa laitteella jonka suoritin oli jotain aivan toista luokkaa.
Manuaalista sitten luin, että turvaluokitukset on uudistettu ja tästä eteenpäin moiset käskyt ns. emuloidaan.
En muista hyytyikö kone, mutta emulointi tuli selväksi.

I/O-käskyjen osalta tilanne on paljon helpompi, käskyllä ja fyysisellä I/Olla ei ole mitään yhteyttä.
Suorituksen kannalta sitä voi siis suorittaa niin kuin huvittaa.
Windows käyttää hommassa I/O-manageria, joka juontaa juurensa 70-luvun alkuun ja RSXään.
Varsinainen hallinoitava on sitten IRP (I/O request packet), joka voi esim. jäädä jonoon ja viestiä ajurien välillä.
USBn ja LPTn kohdalla latenssi on siten väärä ajatuksen suunta.
Oikeampi suunta on suoritusteho, UGreenin palikka lupaa 12Mb, suuntaan katsomatta, väittää ilman erillisiä ajureitakin pärjäävänsä.
Kyseessähän ei ole kenen tahansa I/O, aivan kuten varattu muistiosoitekaan ei ole kenen tahansa käytössä.

Mitä tarkkaan ajoitukseen tulee niin LPT-portin tyypillinen nopeus oli 10kb, maksimi 150kb ja USB2.0 on maksimissaan 480Mb.
Hyvinkin on siten aikaa tarkkaan ajoitukseen, LPT-portin toleransseista en osaa sanoa, enkä yhtään käytönaikaista signalointia muista nähneeni, vanhempaa tai uudempaa.

Ongelma tulee siitä, että vaikka alemman tason ajuri voi suoratoistaa koko liitännän niin seuraavan tason ja vanhan ajurin välinen yhteys puuttuu, johon voi auttaa ainoastaan suorittimen valmistaja, tai erilliskomponentin tapauksessa northbridgen valmistaja.

Alla 386n out-käskyn suorituksen testaus.
Suoritus ei siis ole aikoihin ollut jotain mitä se oli sitä ennen.

IF (PE = 1) AND ((VM = 1) OR (CPL > IOPL))
THEN (* Virtual 8086 mode, or protected mode with CPL > IOPL *)
IF NOT I-O-Permission (DEST, width(DEST))
THEN #GP(0);
FI;
FI;
[DEST] := SRC; (* I/O address space used *)

Linkissä läppärin päivitystä.

TechnologyGuide

Thank you for visiting the TechnologyGuide network. Unfortunately, these forums are no longer active. We extend a heartfelt thank you to the entire community for their steadfast support—it is really you, our readers, that drove

www.notebookreview.com

 

[jmaja]

Mitä tarkkaan ajoitukseen tulee niin LPT-portin tyypillinen nopeus oli 10kb, maksimi 150kb ja USB2.0 on maksimissaan 480Mb.
Hyvinkin on siten aikaa tarkkaan ajoitukseen, LPT-portin toleransseista en osaa sanoa, enkä yhtään käytönaikaista signalointia muista nähneeni, vanhempaa tai uudempaa.

Mitä tarkoitat tuolla? Kyllähän LPT-portista pystyy lukemaan tai kirjoittamaan MHz nopeudella. Kerralla saa kaikki 8 bittiä, joten on nopeus ainakin 10 Mbs. Ennen kaikkea tuolla voi tehdä ohjelman, joka lukee bitin ja sen mukaisesti kirjoittaa bitin ja koko homma menee mikrosekunneissa. USB:llä vastaava kestää millisekunteja. USB:llä voi toki lukea ja kirjoittaa samaan aikaankin varsin nopeasti, mutta ei niin, että välissä olisi jotain logiikkaa, joka vaikuttaisi johonkin.

Mikä on "käytönaikainen signalointi".

Itse aloitin mikrokontrollereiden kanssa keskustelun ja niiden ohjelmoinnin rinnakkaisportilla. USB:ssä olen käyttänyt pääosin FTDI:n piirejä, joilla nykyään keskustelen mikrokontrollereille tai vaikkapa luen suoraan AD-muunninta. FTDI:llä on rajapinta, jolla voi vätkyttää pinnejä LPT-tyyliin. Sinne voi lähettää jonon, jonka mukaisesti joitain pinnejä vätkytetään ja samalla toisia luetaan. Tuolla voi tehdä paljon, mutta ei yhdistää ohjelmaan, jossa yksittäinen luettu bitti vaikuttaa toimintaaan. Tai siis voi, mutta silloin jokainen bitti on oma USB-komentonsa ms viiveineen ja ei päästä edes 1 kbs nopeuteen. Tuollaisenkin toiminnallisuuden saa helpohkosti tehtyä FTDI:llä tai varsinkin mikrokontrollerilla, mutta silloin se äly siirtyy sinne USB:n toiselle puolelle ja se vaatii eri ohjelman PC-puolelle.

 

[kotte]

Lpt-portissahan on HW-kättely jokaiselle siirrettävälle tavulle (mutta alun perin tuo oli tarkoitettu vain yksisuuntaiseksi., mutta toki myöhemmät variaatiot mahdollistavat myös kaksisuuntaisuuden moodista riippuvin rajoituksin). Kykenihän tuon kautta käyttämään mm. 10Mbit/s Thinnet-internet-adapteria jo x86-aikaan (x=0,2,3) tai suorittamaan vastaavaa tiedonsiirtoa kahden koneen välillä kaapelin kautta. Kaapelit ja vaatimus jokaisen rinnakkaisen tavun jälkeen suoritettavaan kättelyyn vain tekevät nykyisessä mielessä suurten tiedonsiirtonopeuksien käytön mahdottomaksi, vaikka juuri nopean kättelyn ja rinnakkaisuuden takia lpt-portti periaatteessa olisi käyttökelpoinen nykyisinkin, vaikkakin kokonaissuorituskykyynsä nähden suhteettoman kallis toteuttaa.

 

[jahonen]

Nimenomaan ajallinen latenssi on se oleellinen juttu näissä, kun dataa siirrellään pikku pala kerrallaan, siitä ei pääse mihinkään. Megabittimäärät toteutuu vain jos kirjoitetaan kerralla about niin paljon kuin USB-paketti sallii. Jos siirretään 1 tavu kerrallaan niin nopeus on 1000 tai 8000 tavua/s, riippuen USB:n toimintamoodista.

Olenhan perinteisen rinnakkaisportin latenssia ja nopeutta joskus mitannutkin, LinuxCNC:n rinnakkaisportti-askelmoottoriajurihan nojaa nimenomaan pienilatenssiseen rinnakkaisporttiin ja siitä on mahdollista parhaimmillaan saada kymmenen-kymmenien kilohertsien step-nopeuksia jolloin rinnakkaisportin kirjoitus pitää mennä kyllä mieluusti alle 1 µs. Aletaan tosin lähestyä x86-raudan latensseja muussakin mielessä. Samaa vaivaa on kyllä muissakin mutkikkaammissa prossuissa, ne ovat kyllä nopeita tekemään suuria määriä suoraviivaista laskutoimitusta tai ajamaan tavanomaista ojelmakoodia mutta kompastuvat nenilleen kun aletaan hyppyyttämään jatkuvasti eri paikkaan. Tätä joskus töissä mitattiinkin ARM Cortex a9-linuxin kanssa kun piti testata päästäänkö minkälaiseen taattuun keskeytyslatenssiin. Vastaus oli että vaikka hyvin suurella todennäköisyydellä reaaliaikapatcheilla keskeytyslatenssi oli alle 1 µs, siellä silloin tällöin tuli suuria "venähdyksiä" (tyyliin >50 µs) ja reaaliaikaosa piti siirtää FPGA:lle koska esim. 10 µs vasteaikaa ei voinut taata ja muu systeemi suunniteltiin niin ettei prossun ja linuxin tarvinnut pystyä muuhun kuin kohtuulliseen datavirtaan mikä olikin ihan hyvä järjestely.

Olen tulkitsevani tuota 386-juttua niin että IO-operaatio estetään ja suoritetaan poikkeuskäsittelijä mikäli CPL ei ole tarpeeksi korkea, mikä onkin loogista. Tuo ei vielä kerro sitä miten USBista mitään ymmärtämätön softa voitaisiin ohjata käyttämään prossun matalimmalta tasolta USB:tä. Tietysti seuranneesta poikkeustilanteen käsittelijässä voisi sitten käynnistää jatkotoimenpiteen. Voisihan binaarikoodia tietty myös muokata mutta sitten kysymys ei enää ole ihan samasta asiasta. Kyllähän nykyäänkin oheislaitteita käsitellään laiteajureista ihan suoralla muistiin- tai IO:hon kirjoituksella. IO-avaruus tosin taitaa olla enempi x86-juttuja, armissa sitä ei taas ole olemassa.

t. Janne

 

[VesA]

USB:llä voi toki lukea ja kirjoittaa samaan aikaankin varsin nopeasti,

Eikös se perinnemalli nyt kuitennii ole half-duplex noin luonnostaan.. eihän siinä ole kuin kaksi piuhaa. Nämä uudemmat keksinnöt 3.x ovat sitten jotain muuta vaikka niitä samalla nimellä kutsutaankin.

 

[jmaja]

Eikös se perinnemalli nyt kuitennii ole half-duplex noin luonnostaan.. eihän siinä ole kuin kaksi piuhaa. Nämä uudemmat keksinnöt 3.x ovat sitten jotain muuta vaikka niitä samalla nimellä kutsutaankin.

USB on mitä on, mutta sen läpi saa suuren määrän dataa, jolla voi tehdä mitä tekee. Eihän kukaan kai ole puhunut itse USB kaapelin käyttämisestä sellaisenaan. USB:n toisessa päässä on joku USB-piiri, joka voi ohjata joitain pinnejä. Itse esimerkiksi käytän FTDI:tä niin, että lähetän jonon sinne ja takaisin tulee "vaste". Ko. tapauksessa tuo on SPI:tä eli siinä on data ulos, kello ja data sisään. Tuo siis lukee ja kirjoittaa yhtäaikaa, mutta USB:ssä liikkuu ensin se lähetettävä jono ja sitten takaisin vastaus.

 

[jahonen]

Jep, streaming-tyyppisissä jutuissa USB on ihan hyvä kun ei tarvita pientä latenssia. Käytännössähän data tosiaan kulkee USB-hostin tahtiin siten että host lähettää paketin jossa joko lähetetään dataa laitteeseen (endpoint kerrallaan) tai sitten kysytään että "onko dataa lähetettäväksi?" hostin suuntaan, johon laite sitten vastaa että joko ei ole dataa tai sitten lähettää datan vastauksena. Laite ei kuitenkaan koskaan voi lähettää dataa hostille ilman että host aloittaa liikenteen. Mikäli data myöhästyy tästä niin seuraava lähetystilaisuus tulee vasta seuraavassa hostin kyselyssä, joten latenssi on aika suuri.

t. Janne

 

[mk]

Mitä tarkoitat tuolla?

Väärä b, tai piti olla 10k tai 150k merkkiä/s.

LPT-portti on vanha LinePrinTer-portti, eli SPP.
EPP ja ECP ovat taysin eri asioita.
Kaikki ne ovat rinnakkaisportteja.

ISA-standardi sanoo, että maksimi kello on 8MHz.
Tiedonsiirto voi siis teoriassa olla 16 megatavua sekunnissa.
Kahdeksan bittisen rinnakkaisportin tapauksessa maksimi putoaa tietysti puoleen.

USBllä bittien tai tavujen käsittely on periaatteellista väärinkäyttöä.

Tehdään ajuri, joka rekisteröi kaksi muistiosoitetta.
Olkoon ensimmäinen I ja toinen O.
Suoratoistetaan tällä ajurilla jostain väylästä tietoa osoitteeseen I ja samaan väylään tietoa osoitteesta O.

Tehdään toinen ajuri, joka rekisteröi kolme muistiosoitetta.
Olkoon niiden nimet 378, 379 ja 37A.
Siirretään tällä ajurilla tietoa edellisen kanssa.

Jälkimmäisen ajurin on pakko olla pollaava, mutta se voi silti toki liputtaa tuloksistansa.
Voi se tietysti itsekin sisältää vaikka rengaspuskurin enemmän tiedon keräystä varten ja vaikka minkälaisia ajoituksia omiin tietoihinsa perustuen.

Aukotonhan tuo ei tietenkään ole, aivan kuten edellä on todettu, aukottomaksi sen voi saada ainoastaan reaaliaikaisella käyttöjärjestelmällä.

Sellainen nyanssi vielä, että ymmärtääkseni kernel-ajurien tekijän täytyy olla hyväksytty ja ajurinsa sertifioitu.

Ja jos minulta kysytään niin I/O-avaruus oli suuri virhe sillä hetkellä kun ainoa helppo ja koneesta ulos tuleva yleiskäyttöinen liitäntä oli rinnakkaisportti.
Toinen vaihtoehto olisi ollut MMIO(Memory Mapped I/O) ja se oli käytössäkin valtavirran ulkopuolella, tai valtavirrassa mutta toisella tasolla ja nythän se on x86-ympäristössäkin suositeltu toimintamalli.
Kaiken maailman suunnittelutöppäyksistä tämä on toki sieltä pienemmästä päästä.

Mikä on "käytönaikainen signalointi".

Se on se mitä liityntäkaapelissa tapahtuu käytön aikana.
Kyse oli toleranssista, eli kuinka paljon signaalien ajoitukset todellisuudessa poikkeavat määrityksistä.

FTDI on hyvä valmistaja.
Ainakin siinä mielessä, että sen tuki on oikeasti tuettu.
Joissain toisissa tapauksissa tuki on lähinnä silmän lumetta.
Itse törmäsin vastottain NUC140 kontrolleriin, varsin monipuolinen palikka.

 

[mk]

Kyllähän nykyäänkin oheislaitteita käsitellään laiteajureista ihan suoralla muistiin- tai IO:hon kirjoituksella.

Tottakai, ei se laite sieltä alta ole mihinkään kadonnut.
Sen toteutus on vaan siirretty matalammalle tasolle.

Ketjun aiheeseen liittyen.
On siis laite USB-portti kytketty laitteeseen rinnakkaisportti.
Lisäksi on sovellus tiedonkerääjä ja laite tiedonkerääjä.
Alunperin tiedonkerääjien välissä oli ajuri, joka suoritti I/O-käskyt, aivan normaalisti niin kuin kuuluu.
Sittemmin laiteelta tiedonkerääjä katosi laite rinnakkaisportti.
Tilalle tuli uusi, mutta se olikin toiselta puolelta laite USB-portti.
Vanha välissä ollut ajuri ei enää saanut yhteyttä.
Uusi ajuri voidaan tehdä vastaamaan vanhaa ympäristöä, mutta sitä ei voi enää osoittaa vanhan ajurin käskyillä.