rinnakkaisportti ja 24kpl io:ta

höpö höpö. USB ei voi korvata rinnakkaisporttia jitterin takia. HDMI:llä puolestaan ohjataan lähinnä näyttöjä. WLAN on nettiliikenneratkaisu. Kyllä varmasti noihinkin saa kytkettyä 8bittistä io:ta tuottavia laitteita, mutta se vaiva on todennäköisesti niin järkyttävä, että 99% ihmisistä joutuu jättämään leikin kesken.
Siispä käytän edelleen rinnakkaisporttia, koska siihen pääsee jo käsiksi assembler-tasolta yhdellä out-komennolla. Teepä sama noilla muilla tekniikoilla! :)
Oma arvaukseni on, että nuo yo. on esitelty, jotta saadaan tehtyä "yhteensopivuusongelmia" laitteiden välille, jolloin ihmisten on pakko päivittää aina jotain laitetta, koska homma ei enää muuten toimi. Toinen vaihtoehto on pitäytyä laitekannassa, eikä päivittää sitä. Menee sitten kaikki kerralla vaihtoon ja ei aiheuta päivitysrumbaa eikä muutenkaan ongelmia, kun ostaa avaimet käteen periaatteella.
Yksinkertainen homma saada tuolla 8255-piirillä io-nastoja käyttöön nopeudella n. 500kbit/s nastaa kohti. Piirin sain ennen laitettua suoraan ISA-väylään, mutta tämä parport ratkaisu poistaa osoite-dekoodauksen tarpeen ja on siten yksinkertaisempi.
Toki yhtä hyvin voi em. väylään tehdä monia muita expandereita, kuten SPI/I2C ja ilman väliin tulevia piirejä, mutta joskus tarvitaan io:ta ja tuon piirin löytää helposti vielä nykyäänkin, koska se on lähes kaikissa PC-laitteissa ollut aikanaan.
USB ei taivu, kun se on softa-ratkaisu..

softa_haitakkeet kirjoitti:

höpö höpö. USB ei voi korvata rinnakkaisporttia jitterin takia. HDMI:llä puolestaan ohjataan lähinnä näyttöjä. WLAN on nettiliikenneratkaisu. Kyllä varmasti noihinkin saa kytkettyä 8bittistä io:ta tuottavia laitteita, mutta se vaiva on todennäköisesti niin järkyttävä, että 99% ihmisistä joutuu jättämään leikin kesken.
Siispä käytän edelleen rinnakkaisporttia, koska siihen pääsee jo käsiksi assembler-tasolta yhdellä out-komennolla. Teepä sama noilla muilla tekniikoilla! :)
Oma arvaukseni on, että nuo yo. on esitelty, jotta saadaan tehtyä "yhteensopivuusongelmia" laitteiden välille, jolloin ihmisten on pakko päivittää aina jotain laitetta, koska homma ei enää muuten toimi. Toinen vaihtoehto on pitäytyä laitekannassa, eikä päivittää sitä. Menee sitten kaikki kerralla vaihtoon ja ei aiheuta päivitysrumbaa eikä muutenkaan ongelmia, kun ostaa avaimet käteen periaatteella.
Yksinkertainen homma saada tuolla 8255-piirillä io-nastoja käyttöön nopeudella n. 500kbit/s nastaa kohti. Piirin sain ennen laitettua suoraan ISA-väylään, mutta tämä parport ratkaisu poistaa osoite-dekoodauksen tarpeen ja on siten yksinkertaisempi.
Toki yhtä hyvin voi em. väylään tehdä monia muita expandereita, kuten SPI/I2C ja ilman väliin tulevia piirejä, mutta joskus tarvitaan io:ta ja tuon piirin löytää helposti vielä nykyäänkin, koska se on lähes kaikissa PC-laitteissa ollut aikanaan.
USB ei taivu, kun se on softa-ratkaisu..

Lue lisää

Eikös sulla PC:ssä ole joku käyttöjärjestelmä, jonka alla sitä ohjelmaa pyörität. Kyllä siihenkin tulee jitteriä, kun käyttis tekee muutakin kuin sinun ohjelmaasi ja sitä rinnakkaisportin ohjaamista.

Saahan USB:n kauttakin ohjattua lukuisia I/O portteja suurella nopeudella. Ei tietysti niin, että jokaista porttimuutosta kohti tehdään uusi USB-komento, jolloin homma menee hyvin hitaaksi. On myös USB-palikoita, joissa voi pyörittää omaa ohjelmaa siinä USB-piirissä.

Yhteensopivuudeltaan USB on loistava. Ainakin minulla kaikki ikinä olleet USB-laitteet saa toimimaan edelleenkin uusimmassa tietokoneessa. Itse myös teen USB-pohjaisia laitteita. 2007 suunniteltu USB-laitteeni on edelleen täysin identtinen kuin silloin ja toimii uusimmissa koneissa uusimmilla käyttiksillä. Ei rinnakkaisportti koskaan ollut noin yhteensopiva kaikkine eri moodeineen.

Lähinnä tuo jitteri on kuitenkin ennustettavampaa rinnakkaisportilla, kun missään ei suoriteta bufferointia(jos sitä ei halua). Tottunut kytkemään piirejä suoraan PC:hen. Tämä vaatii, että pystyy yksittäisiä bittejä vääntelemään mielin määrin. Tuo usb vaatii väliin kuitenkin kontrolleria. En oikein tiedä, onko järkeä tehdä usb-liitäntäinen, kun sitten se vaatii, että isäntäkoneessa on usb. Nyt voi periaatteessa kehitystyön jälkeen hyllyttää pc:n ja laittaa laitetta ohjaamaan _minkä tahansa_ 8bittistä io:ta käyttävän kontrollerin, jossa n 10 nastaa vapaana. Se on rinnakkaismuodossa nopeampaa kuitenkin, kuin mitä SPI-expanderilla. Toki löytyy sellainenkin, mutta haluttuun nopeusluokkaan pitää sitten pystyä syöttämään dataa 24MHz taajuudella, mikä taas vaatii isompaa kontrolleria. Nyt pärjää 4MHz vehkeellä. Lisäksi tuon värkkääminen esim ATMega128:n muistiväylään on älyttömän helppoa, eli jos laite käyttää jo valmiiksi ulkoista muistia, laitetaan yhteen muistikantaan adapteri ja ladotaan io suoraan liittimen lay-outille. Yksi piuha pitää vetää erilleen, eli se, jolla valitaan normitoiminnan asemesta käyttöön oma io eikä muisti, cs-nasta johdotetaan siis uusiksi muistipiiriltä ja expanderilta.
Eli eiköhän tehdä hommat niillä laitteilla joilla ne on opittu tekemään ja siinä sivussa opitaan sitten vähän uutta - eikä vaihdeta toimivasta epävarmaan toimintaan - tai ainakaan toimintaan, josta ollaan epävarmoja. Siitä seuraa vain hammasten kiristelyä. Omalla kohdalla usb ei oikein ole koskaan menestynyt ja ainoa, mitä siihen laitan kiinni on muistitikku. Ongelmia on aika liuta: PCI-enumeraatio sekoittaa kortit keskenään. USB-enumerointi vaihtaa laitteiden paikkaa käyttöjärjestelmien välillä. Toimimaton kontrolleripiiri saa aikaan sen, että välillä enumerointi on väärin päin saman koneen käynnistyskertojen välillä. Ei missään tapauksessa laitteisiin, joiden käytöllä voi olla seurauksia.

vanhalla_tavalla kirjoitti:

Lähinnä tuo jitteri on kuitenkin ennustettavampaa rinnakkaisportilla, kun missään ei suoriteta bufferointia(jos sitä ei halua). Tottunut kytkemään piirejä suoraan PC:hen. Tämä vaatii, että pystyy yksittäisiä bittejä vääntelemään mielin määrin. Tuo usb vaatii väliin kuitenkin kontrolleria. En oikein tiedä, onko järkeä tehdä usb-liitäntäinen, kun sitten se vaatii, että isäntäkoneessa on usb. Nyt voi periaatteessa kehitystyön jälkeen hyllyttää pc:n ja laittaa laitetta ohjaamaan _minkä tahansa_ 8bittistä io:ta käyttävän kontrollerin, jossa n 10 nastaa vapaana. Se on rinnakkaismuodossa nopeampaa kuitenkin, kuin mitä SPI-expanderilla. Toki löytyy sellainenkin, mutta haluttuun nopeusluokkaan pitää sitten pystyä syöttämään dataa 24MHz taajuudella, mikä taas vaatii isompaa kontrolleria. Nyt pärjää 4MHz vehkeellä. Lisäksi tuon värkkääminen esim ATMega128:n muistiväylään on älyttömän helppoa, eli jos laite käyttää jo valmiiksi ulkoista muistia, laitetaan yhteen muistikantaan adapteri ja ladotaan io suoraan liittimen lay-outille. Yksi piuha pitää vetää erilleen, eli se, jolla valitaan normitoiminnan asemesta käyttöön oma io eikä muisti, cs-nasta johdotetaan siis uusiksi muistipiiriltä ja expanderilta.
Eli eiköhän tehdä hommat niillä laitteilla joilla ne on opittu tekemään ja siinä sivussa opitaan sitten vähän uutta - eikä vaihdeta toimivasta epävarmaan toimintaan - tai ainakaan toimintaan, josta ollaan epävarmoja. Siitä seuraa vain hammasten kiristelyä. Omalla kohdalla usb ei oikein ole koskaan menestynyt ja ainoa, mitä siihen laitan kiinni on muistitikku. Ongelmia on aika liuta: PCI-enumeraatio sekoittaa kortit keskenään. USB-enumerointi vaihtaa laitteiden paikkaa käyttöjärjestelmien välillä. Toimimaton kontrolleripiiri saa aikaan sen, että välillä enumerointi on väärin päin saman koneen käynnistyskertojen välillä. Ei missään tapauksessa laitteisiin, joiden käytöllä voi olla seurauksia.

Lue lisää

kaikki riippuu myös käyttöjärjestelmästä!

MS-DOS: toimii hyvin, jos on tarpeen tehdä bittitason I/O:ta omasta ohjelmasta

Vanhat windowsit (95, 98, 98SE, ME): toimii myös, koska antavat ohjata I/O -portteja sovellusohjelmista, toisin kuin NT-pohjaiset windowsit (2000, XP, Vista, 7, 8, 8.1, 10).

Uusissa windowseissa tulee ongelmia! Ei tukea rinnakkaisportin epästandardille käytölle !
Toisaalta, JOS saat laitteesi suunniteltua niin, että standardinmukainen sarjaliikenne sarjaportin kautta riittää, niin silloin toimii ok.

Linux: toimii, mutta vaatii ohjelmalle root -oikeudet (muuten ei lupaa I/O -toimintoihin).

MUTTA:

pelkkä I/O -oikeus ei välttämättä riitä!

Vaikka I/O sinänsä toimisikin, niin kun käyttöjärjestelmä tekee kaikkea muutakin, niin bittitason ohjailussa tulee helposti ajastusongelmia (eli kun käyttöjärjestelmä tekee jotain muuta, sillä aikaa ohjelma ei saa suoritusaikaa, ja portin ohjailu viivästyy tai jos kyse on lukemisesta, dataa voidaan menettää, jos ohjelma ei saa suoritusaikaa, kun pitäisi lukea).

Suositus: joko Atmel AVR tai Raspberry Pi siihen väliin, ja aikakriittiset osat tuon Atmel AVR tai Raspberry Pi:n hoidettaviksi, ja standardinmukainen sarjaliikenne PC:n kanssa. Jos PC:ssä ei ole sarjaporttia, niin esim. ftdichip:in muunnoskaapeli USB --- 5V tai 3,3V sarjaliikenne.

elektr_harrastaja kirjoitti:

kaikki riippuu myös käyttöjärjestelmästä!

MS-DOS: toimii hyvin, jos on tarpeen tehdä bittitason I/O:ta omasta ohjelmasta

Vanhat windowsit (95, 98, 98SE, ME): toimii myös, koska antavat ohjata I/O -portteja sovellusohjelmista, toisin kuin NT-pohjaiset windowsit (2000, XP, Vista, 7, 8, 8.1, 10).

Uusissa windowseissa tulee ongelmia! Ei tukea rinnakkaisportin epästandardille käytölle !
Toisaalta, JOS saat laitteesi suunniteltua niin, että standardinmukainen sarjaliikenne sarjaportin kautta riittää, niin silloin toimii ok.

Linux: toimii, mutta vaatii ohjelmalle root -oikeudet (muuten ei lupaa I/O -toimintoihin).

MUTTA:

pelkkä I/O -oikeus ei välttämättä riitä!

Vaikka I/O sinänsä toimisikin, niin kun käyttöjärjestelmä tekee kaikkea muutakin, niin bittitason ohjailussa tulee helposti ajastusongelmia (eli kun käyttöjärjestelmä tekee jotain muuta, sillä aikaa ohjelma ei saa suoritusaikaa, ja portin ohjailu viivästyy tai jos kyse on lukemisesta, dataa voidaan menettää, jos ohjelma ei saa suoritusaikaa, kun pitäisi lukea).

Suositus: joko Atmel AVR tai Raspberry Pi siihen väliin, ja aikakriittiset osat tuon Atmel AVR tai Raspberry Pi:n hoidettaviksi, ja standardinmukainen sarjaliikenne PC:n kanssa. Jos PC:ssä ei ole sarjaporttia, niin esim. ftdichip:in muunnoskaapeli USB --- 5V tai 3,3V sarjaliikenne.

Lue lisää

Muistathan aina että ripulikin on kakkaa?

elektr_harrastaja kirjoitti:

kaikki riippuu myös käyttöjärjestelmästä!

MS-DOS: toimii hyvin, jos on tarpeen tehdä bittitason I/O:ta omasta ohjelmasta

Vanhat windowsit (95, 98, 98SE, ME): toimii myös, koska antavat ohjata I/O -portteja sovellusohjelmista, toisin kuin NT-pohjaiset windowsit (2000, XP, Vista, 7, 8, 8.1, 10).

Uusissa windowseissa tulee ongelmia! Ei tukea rinnakkaisportin epästandardille käytölle !
Toisaalta, JOS saat laitteesi suunniteltua niin, että standardinmukainen sarjaliikenne sarjaportin kautta riittää, niin silloin toimii ok.

Linux: toimii, mutta vaatii ohjelmalle root -oikeudet (muuten ei lupaa I/O -toimintoihin).

MUTTA:

pelkkä I/O -oikeus ei välttämättä riitä!

Vaikka I/O sinänsä toimisikin, niin kun käyttöjärjestelmä tekee kaikkea muutakin, niin bittitason ohjailussa tulee helposti ajastusongelmia (eli kun käyttöjärjestelmä tekee jotain muuta, sillä aikaa ohjelma ei saa suoritusaikaa, ja portin ohjailu viivästyy tai jos kyse on lukemisesta, dataa voidaan menettää, jos ohjelma ei saa suoritusaikaa, kun pitäisi lukea).

Suositus: joko Atmel AVR tai Raspberry Pi siihen väliin, ja aikakriittiset osat tuon Atmel AVR tai Raspberry Pi:n hoidettaviksi, ja standardinmukainen sarjaliikenne PC:n kanssa. Jos PC:ssä ei ole sarjaporttia, niin esim. ftdichip:in muunnoskaapeli USB --- 5V tai 3,3V sarjaliikenne.

Lue lisää

Nimenomaan ongelmaksi tulee ajoitukset - jos yrittää tehdä ilman kättelyitä juttuja. Kättelyjen kanssa homma taas menee heti hitaaksi (helposti n. 200kt/s std portilla, suurella vaivallakin <700kt/s). Tuo EPP bufferoinnilla on siitä hyvä, että jos kirjoittaa 32-bittisiä lukuja, niin 16 tavun bufferin saa täyteen 4x i/o:ta. Ja rinnakkaisporttiajuri käytännössä takaa tuon kirjoituksen hw-bufferiin(fifoon..) onnistumisen. Siispä device-päähän on mahdollista tehdä laite, joka lukee perättäisiä tavuja tuon verran ilman kättelyä eli kytkemällä kättelyn oikotietä suoraan takaisin invertterillä. Tällöin saa n. 2Mt/s nopeutisen purskeen ja driver-overhead putoaa samalla 1/4:aan. Ja IRQ-nastan avulla pystyy pyytämään lisää datasiirtoa, kun purskeen on saanut käsiteltyä.
Tässä on siis paljon mahdollisuuksia selvitä 1-2 ylimääräisellä logiikkapiirillä kytkennässä ja silti saavuttaa nopeushyöty. Tai sitten käyttää se n. 5-6 mikropiiriä ja olla standardin mukainen - vaihtoehto tietysti ottaa n. 64 nastainen EPP-hw chip, mutta se ei ole mielestäni enää tarkoituksenmukaista, jos ohjain-chip on tehokkaampi, kuin vastaanottava mikrokontrolleri ja maksaa n. 10 kertaa enemmän..
Kannattaa tutustua myös ECP-moodiin, se voi olla mukavampi kuin EPP, ainakin jos vastapäät ovat ohjelmallisesti toteutettuja. EPP on kuitenkin yliveto monessakin asiassa juuri sen yksinkertaisuuden vuoksi. Sarjaliikenne ei tällaisessa oikein toimi, kun siinä ensin pitää siirtä 10-bittinen kehys ja tämän jälkeen prosessorilla vasta voi reagoida/tuottaa signaalin. Konfiguroinnit ja debug-tulosteet saa tietysti kehitysvaiheessa hyvin tuon kautta hoidettua.
Joskus muisti-skoopilla katsonut minkä verran saa kerralla dataa rinnakkaisportista taottua ohjelmalla, joka ei tee muuta kuin looppaa xor:n avulla 101010.. io:ta ulos ja siinä on tosiaan muusta prosessoinnista riippumatta aina välillä kernelin schedulerin ajosta aiheutuvia taukoja. Ja ihan missä välissä tahansa - tämä voi mm. vääristää bittien kestoaikoja linjalla, jos ohjelma poistuu ajosta vaikka jonkin bitin päälle asetuksen ja nollauksen välillä hetkeksi.