Der DS2408 kann nicht nur Daten ausgeben (Output-Funktion) sondern auch lesen (Input-Funktion). Insbesondere erlaubt das Channel-Access Write-Timing ein Rücklesen der ausgegeben Daten. Mit Hilfe des STRB-Impulses und wegen der Openkollektorausgänge ist ein Datenaustausch mit einem 8-Bit Parallelport eines Mikrocontrollerschaltung möglich.
Damit könnte ein Interface zu I2C, RS232, usw. realisiert werden.
Meine Frage:
Ist die Bereitstellung einer TMEX_F29_ReadBytes-Funktion angedacht?
Softwaretechnisch entspräche dies weitgehend der TMEX_F29_WriteBytes-Funktion mit hexadezimal x-mal „FF“ (8xHIGH) als rezessive Output-Daten und Rückgabe der x-Inputbytes! Die Stringlänge könnte durch die Länge der Schreibdaten festgelegt werden. Alternativ wäre auch möglich, dass die TMEX_F29_WriteBytes-Funktion die beim Schreibvorgang gesampelten Daten zurückgibt.
Die Implementation aller vorhanden Funktionen des TMEX-Treibers ist sicherlich möglich, aber was meinst Du mit Interface zu I2C und RS232. Eine Kopplung PC<->IPS<->1-Wire<->RS232/I2C ? Wer kann schon 8 Ports für eine µC-Anbindung opfern?
Das geht wohl einfacher und mit den vorhandenen Methoden:
PC<->(IPS)<->RS232<->µC mit den bekannten ComPort-Funktionen und
PC<->(IPS)<->RS232/ParallelPort<->I2C <->µC mit der I2C-PHP-Library.
Um ehrlich zu sein, hatten wir 1Wire nicht dazu gedacht, ganze MircoController Applikationen zu erstellen. Ich lasse mich von steiner gerne des besseren belehren, dass so eine Funktion wirklich gebraucht wird, ohne dass später jemand sagt, meine 1Wire Temperatur wird nicht gelesen, weil da irgendwer per ReadBytes auf dem Bus rummarmelt… (Mit der WriteBytes Funktion sollte man schon sorgsam umgehen… Solche Ideen wir Laufschrift auf dem Display per 1Wire zu realisieren ist ganz sicher Möglich… technisch gesehen aber übernicht sinnvoll ist)
Wie tommi schon sagte… es gibt dafür wahrscheinlich bessere Alternativen…
Um Missverständnisse auszuräumen:
Die WriteBytes-Funktion verwendet (höchstwahrscheinlich) die 1-Wire Channel-Access-Write Funktion (s. Datenblatt zu DS2408). Diese liest automatisch beim Schreiben jedes Bytes das tatsächlich anstehende Ausgangsbyte zurück. Zu überlegen wäre, ob diese Daten einfach von der WriteBytes-Funktion an IPS zurückgegeben werden und bei Bedarf zur Verfügung stehen.
[QUOTE=tommi]Die Implementation aller vorhanden Funktionen des TMEX-Treibers ist sicherlich möglich, aber was meinst Du mit Interface zu I2C und RS232. Eine Kopplung PC<->IPS<->1-Wire<->RS232/I2C ? Wer kann schon 8 Ports für eine µC-Anbindung opfern?
Das geht wohl einfacher und mit den vorhandenen Methoden:
PC<->(IPS)<->RS232<->µC mit den bekannten ComPort-Funktionen und
PC<->(IPS)<->RS232/ParallelPort<->I2C <->µC mit der I2C-PHP-Library.
Hallo Tommi,
vielfach stehen noch Sensorbaugruppen oder Geräte mit serieller Schnittstelle zur Verfügung. RS232 und I2C erlauben nur vergleichsweise kurze Verbindungslängen. Bei niedrigen Datenmengen ist es durchaus denkbar, vor Ort (remote) 1-Wire Busknoten mit den genannten Interfaces zu realisieren.
vielfach stehen noch Sensorbaugruppen oder Geräte mit serieller Schnittstelle zur Verfügung. RS232 und I2C erlauben nur vergleichsweise kurze Verbindungslängen. Bei niedrigen Datenmengen ist es durchaus denkbar, vor Ort (remote) 1-Wire Busknoten mit den genannten Interfaces zu realisieren.
Ich denke, auch 1-Wire ist nicht primär dazu gedacht, größere Leitungslängen zu überbrücken. Dafür bieten sich auch wieder etabliertere Technologien an, wie z.B. LAN oder RS485. So läßt sich eine Kopplung PC<->LAN<->XPort<->1-Wire oder PC<->RS485<->µC<->1-Wire realisieren, freilich nicht mehr mit dem TMEX-Treiber. Das ist vieleicht auch von Vorteil, weil dadurch der IPS-PC vom Polling entlastet wird.