Lehet, hogy működne a rajzi kapcsolás, de egyrészt tényleg elég ronda, másrészt ugyanaz a baj vele, amit előbb írtam: a PC soros portja nem kifejezetten erre való. Lehet vele kísérletezni, de valószínűleg nem véletlenül mondták már többen is, hogy talán más utat kellene keresni.
Az meg, hogy nem tudsz RS485-öt programozni, lényegtelen, mivel nem is lehet, nem is kell. Az RS485 egy átviteli szabvány, jelszinteket, fizikai réteget ír le. Az átalakítás annyi, hogy soros porton kiküldöd azt az adatot, amit a külső eszköz megért (ez teljes mértékben egyezik a COM port megszokott használatával, a programozást tekintve), viszont a gép a külvilághoz egy kis hardveren keresztül csatlakozik, aminek a feladata az RS232 jelszintjeinek RS485-re való illesztése, és fordítva.

Ami abban volt, az ugyanolyan illesztő mint az rs485 illesztő, csak 1wire-re, csak annyit csináltam a rajzzal, hogy mivel a hőmérőt nem kell programozni, ezért letöröltem a programozó feszültség előállítását végző részt...
I2C-nél miért kell kis bitidő?
A master rángatja a busz órajelét, az résztvevők meg annak megfelelően figyelik az infót rajta nem? És akkor lényegtelen a bitidő, csak az kell, hogy az órajel magas szintjénél már a szükséges adat legyen kint...
De mondjuk ennek megvalósítása semmivel nem egyszerűbb programozás terén, mint az rs485-é, de ezzel akkor elvileg használhatná a meglévő lpt-s kapcsolását, csak több elemet fűzne fel a buszra, és vannak hozzá mondjuk ilyen kifejtő ic-k, hogy i2c-n kiküldesz rá egy bájtot, és megjelenik a kimenetein...
Én személy szerint tutira nem állnék neki ilyennek, de ha valaki érez lelki erőt, hogy megírja az i2c kommunikácót lpt-re, annak szerintem jó megoldás, csak mondjuk tudni kell, hogy mi a többi eszköz, hogy van-e hozzájuk megfelelő cucc, amit fel lehet fűzni a buszra...

A programozási részéről annyit,hogy eddig leginkább grafikai programokat irtam,irtam egyszerű soros file linkert, meg elkezdtem
lpt-n is a linkert,de csak annyit haladtam benne ,hogy látta egymást a 2 gép.meg a soros részébe ugy hogy egy file-t át birtam vele küldeni ,de azt teljes egészében én irtam,mondjuk akkor csak a txd-t használtam meg az rxd-t de most már kapcsolgatom a dtr lábat is ki ,bemenet a többi tűn ok azt letudom progizni.De mondjuk most már kompit használok az alacsony szintű hozzáféréshez.

Tehát a kommunkáció tudásom programozást tekintően nem a legjobb ,ugyhogy azért tartok attól, hogy hogy fogom megvalósítani az i2c-t .De ha valahol le van írva rendesen ,tehát nem hiányosan meg egyértelműen le van irva angolul vagy németül vagy magyarul akkor azt meg tudom érteni és le tudom progizni.
Viszont lehet hogy van benne olyan idegen elektronikai szakkifejezés több is amiről még magyarul sem halottam vagy csak ritkán hallottam róla nagy vonalakban.
Ugyanigy vélekedek az 1wire-ről és a 2 wire -ről is.

a 2wire szerintem az i2c... nekem mondhatod, hogy hogy programozol pc-n, nekem a soros port kezelés annyi volt eddig életemben, hogy visual basicban behúztam egy soros port objektumot, és karaktereket fogadtam rajta...
LPT-ben meg annyit csináltam, hogy dos alatt borland c-ben állítgattam a biteket, nem tudom, hogy a win xp engedi e, hogy te azt mondd az lpt-nek, hogy akkor most legyen a lábakon 0xFF vagy valami...
Ha a többiek alátámasztják azt amit írtam, hogy nem szükséges a bitidő miatt aggódni, és tutira nem fordulhat elő xp alatt, hogy egy utasítás amit később adtál ki, az előbb hajtódik végre, akkor szerintem megoldható azzal a módszerrel amit írtam a problémád...
I2C-vel kapcsolatban olvasd el a szabványt, abban meg tudod, hogy hogy megy az információ küldés, és fogadás, kapcsolásnak jó az amit elsőnek küldtél, csak perifériákat kell illeszteni hozzá, és az egyes eszközök kommunikációjáról pedig az eszközök manualjában olvashatsz, az elektronikai résztől nem kell félni, mivel vannak cél ic-k, végtelenül egyszerű megcsinálni.
Csak annyi a fenntartásom, hogy szerintem bonyolult neked megírni a kommunikáció kezelését. Igaz, hogy csak biteket kell állítgatni, meg időzíteni, csak a sorrend... a szabványban a téged érintő résznél nem fogsz találni semmilyen elektronikai kifejezést, amit ne lehetne megérteni...
Elvileg a cím mező 8 bites, ami azt jelenti ugye, hogy 256 eszköz csatolható, az ilyen ic-knél az szokott lenni, hogy a lábszámok miatt csak 3 bitet módosíthatsz, de szerintem ezzel is meg lehet oldani a problémád bőven...

De ha nem haragszol, akkor most ebbe nagyon nem folyok bele, mert nemsokára államvizsgázok, és baromira le vagyok maradva a tanulással...

jamég a szabvány:
http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf

Fú pedig kéne még a segitséged,akkor nem tom ,hogy lesz este még biztos írok ,csak a vinyómat takaritom egy kicsit addig mer má nagyon brekeg.

Akkor nekem ilyen fázishasított szinuszokat is kell generálnom
a com porton bit szinten? Az i2c-vel kapcsolatban?

Pl a 37.oldalon az utolsó pdf-ben amit az előbb belinkeltél?

Nem nézted meg rendesen a képet: ott vannak alatta a magyarázó ábrák, miszerint a lineáris változást valamelyik eszköz, a görbét pedig a felhúzó ellenállások okozzák. Érdekes gondolat egyébként egy tisztán digitális portnál fázishasított szinuszkimenetről beszélni...
Az említett doksi 42. oldalán leírja, hogy 10 cm fölötti vezetékhosszak esetén hogyan kell a vonalakat egymás mellé helyezni. Ez azért van, mert az I2C többnyire olyan eszközöket köt össze, amik térben egymás körül, gyakorlatilag egy panelon vannak. Nem próbáltam még sosem mondjuk 1-2 méterre átvinni, lehet, hogy megfelelő vezetékkel működne, bár egy kicsit ezt kétlem, több ilyen alkalmazásban is extender IC-ket láttam (pl. P82B96) jelerősítésre, a sima összekötés helyett.
1-Wire hőszenzort már láttam hosszabb vezetéken egy kernel-módban futó programmal, ott az időzítések azok, amik megnehezítik a megoldást (emiatt nyúltak le a kernelig). Amit korábban írtam a PC bitszintű portvezérlésének időzítési gondjairól, az igazából erre vonatkozik. Meg lehetne csinálni azt is, hogy megfelelő driver-en át (io.dll, és hasonlók) hozzányúlunk az alaplapi interrupt-vezérlőhöz és rendszer-időzítőhöz, bár nagyon észnél kell lenni eközben, és így próbálunk korrekt, bitszintű átvitelt megvalósítani. Ebben az a legnagyobb hátulütő, hogy elég nagy overhead-et jelent a CPU számára, fagyogatós jellegű lesz tőle a gép az átvitel közben.

Egy olyan megoldási lehetőség, amit valószínűleg pár év múlva is tudsz majd használni, az LPT és COM portok (sajnos) törvényszerű kihalása után: USB-s virtuális soros port létrehozása (pl. FT232-vel), ebből RS232-RS485 konverteren át csatlakozás a "külvilág" felé. Az átviteli közeg sodort érpár (akár az egész lakáson is körbevihető), a külső eszközökön pedig egy-egy apró kontroller, melyekhez a vonali jeleket több módon is illeszteni lehet, periféria-készlettől és programozási kedvtől függően. A kontrollerek feladatai: a PC felé címezhető modulként mutatkozni, kapott parancs alapján a hozzájuk csatolt elemek (amik már lehetnek I2C vagy 1-Wire eszközök, relék, motorok, szinte bármi) vezérlése, lekérdezése, illetve válaszadás a PC felé.
Mindezek után, a számítógép programja egyszerű soros küldést-fogadást fog jelenteni, a vonalak egyenkénti macerálása helyett, ehhez pl. az FT232 esetén szabadon letölthető driver-ek állnak rendelkezésre. A külső eszközök kontrollereit olyan programmal kell ellátni, ami képes fogadni, kiértékelni, vezérelni / lekérdezni, illetve válaszolni, és tartalmazzák azt a protokollt is, ami a hozzájuk kapcsolt eszköznek megfelelő. Igaz, hogy ez az eszközök oldalán megnöveli a munkaigényt, viszont ha azonos kontrollereket használsz, egyszer megírod a kódot pár protokollra, aztán már majdnem csak másolgatni kell. Így mind a fejlesztés, mind a későbbi bővítés elég rugalmasan megoldható.
Lehet persze, hogy ez egy elfogult és kevés hozzáértést tükröző vélemény, de én így csinálnám, ha annyira kellene.

Köszönöm!
Csak azt nem értem, hogy a com port mér halhat ki ,ha pci os com
port kártya a vista alatt is megy.
?

Azért jutott el idáig ez a topic, mert dobpista2 nem tud kontrolert programozni, és nem is mozgatja a fantáziáját.

Senki se mondta hogy tudok,fura lenne ha mindent tudnánk

Főleg az alaplapi portok megszűnését láthatod, már nálunk (a cégnél) is láttam pl. olyan asztali gépet, amin két USB aljzaton kívül semmi kapcsolat nem maradt a külvilág felé. Természetesen a PCI-os eszközök egy darabig még megmaradnak, de az is lehet, hogy (ha már Win) egy következő verziójú oprendszerhez már nem lesznek ilyen célú driver-ek.
PCI-os portról mellesleg végképp nem próbálgatnék időkritikus bit-manipulációkat, kizárólag saját (külön ehhez írt) driver támogatásával, és még akkor sem garantált a siker.

Esetleg, ha dos-ban írnám meg a com portos progit,akkor az real time szempontjából jobb lenne-e?(Az időzítésekre gondolok itt)

Mert azt elfelejtettem mondani ,hogy dosban is tudok programozni.