Und zwar geht es mir um die Zeiten B und D (H-Zustand am Bus):
formatting link
Wenn ich das richtig sehe können die auch länger als die dort angebenen Zeiten sein ohne dass die Slaves ein Problem bekommen?
D.h. letztendlich wichtig wären (ausser dem Bus-Reset und der Pause danach) das einhalten der Zeit für den kurzen L-Puls A, den langen L-Puls C und das abtasten des Buszustandes nach der Zeit E?
Mir geht es um eine Anwendung in der der Master nicht allzu fix ist, das kritische Timing würde dann durch ein wenig Hardware realisiert, der Master gibt nur vor dass wieder ein neuss Bit (kurz oder lang) generiert wird oder liest den zuletzt bei E gespeicherten Zustand wenn er dazu Zeit hat.
Danke für eure Tips.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Was für nen Master/Clock hast Du denn? Ich kann mir kaum vorstellen, dass der zu langsam für 1wire ist.
Ich hab hier irgendwo noch einen kompletten 1wire Developer Kit von Dallas rumliegen. Wenn Du nicht weiter kommst, dann such ich mal. Habs damals mit 8031 in FORTH geschrieben, ging ganz ordentlich. War auch HW dabei, die am PC am UART hing und dann die 1wire ansteuerte. Das war garantiert langsam, ging aber auch.
Hauptproblem am 1 wire ist, das der Code - der den 1 Wire-Bus per Software realisiert - für ne knappe Millisekunde (oder war es gar noch länger?) nicht durch Interrupts unterbrochen werden darf. Hatte da auch schon mal damit rumgekämpft - und seitdem immer versucht, 1wire Chips zu vermeiden. Ist aber ne Weile her, so dass ich da nicht mehr soviel dazu sagen kann; der OP sollte mal in nem echten Datenblatt nachschauen, die Zeit zwischen den Bit's war nicht so kritisch, es gab da aber auch nen Timeout.
Ich hab gerade eine Application von mir wiedergefunden und pappe sie hier dran
-----------8x--------------
\ DOW31d.txt editiert und uebersetzt aus: ALL20080416 \ DOW31.SCR Dallas One Wire words 8031 ALL 10:08 12JAN95 \ Last changed screen # 010 ALL 21:21 14APR96
\ (c) 1995, 2008 by Wolfgang Allinger \ c/o Ingenieurbuero Allinger \ Villa Elisa, Paraguay \ mailto: snipped-for-privacy@gmx.de
\ Das Programm darf frei benutzt werden, solange damit \ kein Geld verdient wird UND mein (c) Eintrag erhalten \ bleibt.
\ Falls jemand es komerziell nutzen moechte, dann bitte \ wg. Genehmigung anfragen.
\ 123h ist hexadecimal, 456. ist decimal # in Kommentaren
\ Uebersicht: \ Das DALLAS One Wire (DOW) Protokoll wird hier benutzt \ um eine eindeutige Seriennummer aus dem DS2401 zu lesen. \ Es gibt weiter DOW Bausteine, u.a. fuer Temperaturmessung, \ I/O Signale, RAM, Uhr, ADC und DAC...
\ Where is the beef? Warum der Aufstand? \ Es sollte in meinem Fall Nachbauer/Kopierer abhalten :-) \ Der DS2401 wird in einem TO92 geliefert und sieht wie ein \ normaler Transistor (EBC) aus, aber nur 2 Anschluesse \ 'Basis' und 'Emitter' sind aktiv, der 'Kollektor' ist n/u.
\ Wenn man die 'Basis' an einen 8031 bidirektionalen Port \ Pin, den 'Emitter' an GND und den 'Kollektor' an irgend- \ einen anderen Pin verdrahtet kann man die meisten Hacker \ schoen zum Narren halten.
\ Entsprechende Abfragen beim Start mit viel dummy ROT PICK \ TUCK SWAP DROP TUCK n ROLL, Plutimaktion, M/MOD... garniert, \ irgendwo dabei tiefer im Stack die Nummer ueber n PICK \ abfragen und dann nach Start der Anwendung und einer \ Zufallszeit gegen eine Codierte Kopie im EPROM vergleichen \ und dann lapidar mit EPROM Daten-Fehler-Meldung anhalten. \ Hat prima funktioniert, zumal ich die Beschriftung vom \ DS2401 abgeschliffen habe und der in der Stueckliste und \ Schaltplan als NPN Transistor aufgeführt war :-)
\ Ich bin nicht boese, nur der Umgang mit Geiz is geil \ Kunden hat mich das erfolgreich gelehrt. Man musste \ allerdings zum 1. Start noch eine Routine ins RAM \ kompilieren die dann die aktuelle Nummer im Target \ auslas und dann in das Prom Image schrieb.
\ Geht heutzutage mit geflashten Programmen sehr leicht.
\ DOW Bus Prinzip: \ Der DOW Bus ist als Open Collector Leitung zu sehen, die \ von einem pullup hochgezogen wird. Alle Teilnehmer sind \ an dieser einzigen (neben GND) Leitung (Daher der Name \ Hase) angeschlossen. Die Teilnehmer werden durch high \ Pulse und einem damit geladenen internen Kondensator \ gespeist.
\ Nach einem high Puls vom DOW Master, zieht der aktivierte \ Slave für eine gewisse Zeit den Bus auf Masse oder auch \ nicht. Je nachdem wird die Antwort als 0 oder 1 \ interpretiert.
\ Ein 8031 port im bidirektional Mode ist ideal als BUS \ Master. Man braucht keinen externen pullup, da der 8031 \ einen weak-pullup (ca. 20kOhm) hat, der beim Wechsel von \ L nach H fuer 2 Tcyclen niederohmig kraeftig nach \ high gezogen wird. Den schlappen high Pegel können die \ Slaves dann leicht runterziehen.
\ Der DS2401 schickt seine Seriennummer, die 'unique' ist, \ als 8 byte incl. einer CRC8 zurueck.
\ In dieser Applikation schicke ich immer entweder das \ RD Kommando (33h) oder eine Dummy Date (FFh) zum Bus \ aus dem unteren Bit und kopiere dann die Antwort ins \ untere Bit und rotiere das, bis alle 8bit ausgetauscht \ sind. Also ein spezielles Software UART. Beim 8031 kann \ man sehr geschickt das Cy bit auch komplementaer mit \ einem Portpin verwursten, was ich auch ausnutze.
\ Das exacte Timing und die sonstigen Eigenheiten dieses \ DOW bitte im Dallas Handbuch nachlesen. Das einzige \ Uebel ist, das DALLAS vor laengerem von MAXIM geschluckt \ wurde :-(
\ Diese Datei ist aus einer Anwendung von 1995 herauskopiert \ und editiert worden. Ich hab alles spezielle dieser \ Anwendung rausgeschmissen, kann und habe es aber nicht \ getestet. So ist es einfach eine Info, aber ich hoffe, \ dass diese Info nuetzlich ist.
\ Die Applikation war ursprünglich fuer den LMI metacompiler \ geschrieben, aber ich habe die urspruenglichen screens \ aka blocks umeditiert.
\ Ein Bericht von Joerg Paysan: "Dallas 1-Wire mit Forth \ ansprechen" aus der VD 1/2008 hat mich veranlasst, mal \ meine sehr Hardwarenahe Sicht zu zeigen. Ich brauche \ etwa 40 Zeilen für den eigentlichen Code. Der Rest ist \ Anwendung und Gesabbel :-)
\ NOTAM: \ Die timing Schleifen laufen alle für einen alten 8031 \ mit 12MHz clock. Mit modernen optimierten und sehr \ schnellen 8031 Derivaten geht das latuernich nicht so \ einfach :-)
\ Villa Elisa, Paraguay \ snipped-for-privacy@gmx.de ALL20080416
\ -------------------------------------------------------------- \ history: last revision first ALL 14:07 28AUG95
\ ALL950828 V0.06 first release \ .... \ ALL950112 V0.01 first try
\ -------------------------------------------------------------- \ TMEM? DALLAS TOUCHMEMORY ALL 11:53 28AUG95 DECIMAL
ASSEMBLER P1.5 EQU $PTM \ define TOUCH-MEM DATA port pin FORTH
HEX 33 EQU cTMRD DECIMAL \ 0F or 33 are read commands
\ -------------------------------------------------------------- \ TMEM? DALLAS TOUCHMEMORY present? ALL 21:13 14APR96
CODE TMEM? ( -- t=PRESENT ) \ TM present? A,# 4 MOV $PTM CLR \ start of RESET pulse LOW B ,# 250 MOV 1$: B , 1$ DJNZ \ 480..960uSEC->500Tcycles $PTM SETB \ end of RESET pulse HIGH B ,# 6 MOV C CLR \ clear CY = NO_presence
2$: $PTM , 3$ JB \ B: HIGH, leave loop B , 2$ DJNZ \ LOOP for 3360uSEC ACC , 2$ DJNZ \ if DATA stays LOW 9$ SJMP \ STUCK LOW
3$: B ,# 40 MOV \ 60..240uSEC-> 160Tcycles
4$: C,/ $PTM ORL B , 4$ DJNZ \ delay CY=1=PRESENCE detect
9$: A CLR A,# 0 SUBB R1,A MOV APUSH LJMP END-CODE
\ -------------------------------------------------------------- \ TM>=1uS ..6T, send CY B ,# 05 MOV 1$: B , 1$ DJNZ \ ..6+2+10=18Tcycles C, $PTM MOV \ read DS_DATA ..20Tcycles B ,# 18 MOV 1$: B , 1$ DJNZ \ 20+2+36=78Tcycles B POP \ =60..120uSEC =tSLOT $PTM SETB \ terminate time slot RET END-PROC
CODE TM>SP LJMP END-CODE
\ -------------------------------------------------------------- \ .tm# TML show DOW/DS2401 data ALL 12:43 31JAN95 \ L. shows low byte as 2 HEX chars
Hmm, ich hatte keine Probleme mit IR (8031), aber ich bin ein alter ASM Haudegen, der mit IR eh keine Probleme hat :) Die 1wire Zeiten sind alles Mindestzeiten, langsamer darf man (durch IR) durchaus werden. Die Timeouts waren bei mir nie kritisch, da relativ lang. Man muss sich latürnch gut mit den Ports und IR auskennen, sonst wird dat nix!
NACK, jedenfalls wenn man keine (schwülstigen) Treiber hat/nehmen kann, oder keine vollständigen I2C Ports hat.
Nee, beim OneWire gibt es auch Maximalzeiten; Was passiert denn da in Deinen Timingschleifen, wenn die durch nen Interrupt einfach mal 500us länger werden? In kleinen übersichtlichen Programmen kann man das in Einzelfällen bestimmt sicherstellen. Wenn man ne Hardware hat, bestimmt auch (nen 8051 hatte da aber nix); aber nicht, wenn man noch 3 Timer laufen hat und 2 serielle Schnittstellen - die da immer mal mit reinfunken ;-).
Hmm? I2C-Master läuft per Software bestens; da braucht man keine HardwareUART oder sonstiges. Der Software-Code ist genauso klitzeklein, wie Dein 1-Wire Beispeil. Auch wenn da mal ein Takt etwas länger (bis auf wenige Ausnahmen - egal wie lang) ausfällt, ist das bei I2C kein Problem. M.
Am 06 Dec 2010 08:59:00 -0300 schrieb Wolfgang Allinger:
USB am PC, aber nicht mit den Umsetzern von Dallas.
Ich versuche zu umgehen dass der Anwender erst einen Treiber installieren muss (einfacher Start des Programmes soll reichen), das wäre dann z.B. über ein HID-Device am USB machbar. Einzelne Pins damit wackeln lassen geht, aber nicht in dem Timing.
Deshalb die Frage ob da nicht bestimmte Teile des Protokolls zeitunkritisch sind, etwas mehr H am Bus sollte den Slaves doch wegen der Speisung eher gut bekommen.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Am Mon, 6 Dec 2010 15:34:47 +0100 schrieb Lutz Schulze:
Habe jetzt hier noch ein Diagramm gefunden, in dem für diese Recovery Time angedeutet wird dass sie auch länger sein kann:
formatting link
Aber sicher gibt es auch noch ein Datenblatt in dem das exakt drin steht ob es da auch Begrenzungen nach oben gibt.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
ACK, hab gerade nochmal nachgesehen, mein Beispiel wird während PWRup ausgeführt, wenn noch alle IR off sind. Wenn man also IR zulassen (muss), gehts nicht. Irgendwo steht was von max 120us Slottimes... (oder
Mit USB dürftest Du das Timing nicht hinbekommen. IIRC geht mit USB nix schneller, als 1ms :(
IMHO egal, wenn der C im Slave voll ist, ist er voll :)
Es geht dann nur noch um die Länge der Low-Pulse aus dem Slave, der den C leernascht... Und diese Pulslänge bestimmt der Slave, je nachdem was er zu knüttern hat. Und wenn der Master nicht flott genug ist, haste mit Korinthen gehandelt. USB ist eben kein Echtzeit sondern ein echt-Zeit Protokoll :(
Aber das Problem wolltest Du ja eh mit etwas externer HW abfangen. Das sollte dann doch wieder gehen.
Du musst nur aufpassen, ein L-Puls von 120..480us wird vom Slave als Reset interpretiert, das kann üble Schwulitäten verursachen. Der H-Pegel am Ende eines Slot muss >1us bis unendlich lang sein (tREC)! Das ist wohl weniger das Problem. Wenn Du lustig bist, kannste so 1 bit alle
10min übertragen :)
D.h. mit 3 Monos (15us, 60us, 480us) und einem FF sollte die HW funzen. Dann kommt per USB halt 1bit/ms durch...
Am 06 Dec 2010 12:37:00 -0300 schrieb Wolfgang Allinger:
Das denke ich so weit is das Protokoll verstanden habe.
Das war die Frage die sich mir stellte.
Ein wenig schneller sollte es dann auch mit HID am USB gehen ;-)
Das war der erste Gedanke, mittlerweile sehe ich da statt der drei Monoflops z.B.einen attiny45 der die richtigen Pulse erzeugt.
Das wäre nicht das grosse Problem, so viele Daten sind das ja nicht. Wichtig ist dass Laien das anstecken können, die Software auf dem PC starten und fertig.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Und dann noch andre Sachen machen kann... :-). Naja es gibt ja auch fertige RS232 zu 1wire chips (steht ja sogar auf der Seite die Du gepostet hast). Da muss man jetzt nicht unbedingt etwas neues erfinden. Pro ms ein bit kann aber schon ganz schön langsam sein. Hat nicht FTDI nen intelligenten Chip, der USB zu z.B. SPI und I2C umsetzen kann? (Vielleicht war da ja auch 1- Wire mit dabei?) Damit hast Du dann nur den USB zu 1Wire-Chip im Design und brauchst nix zusätzliches zu entwickeln. (Der Tiny will ja auch mit ner Software geflasht werden).
Am Mon, 6 Dec 2010 15:54:59 +0000 (UTC) schrieb Matthias Weingart:
Ziel ist dass der Anwender am PC keinen Treiber installieren muss. Das wird mit USB zu RS232 nicht gehen, oder?
Wie gesagt, ohne Installation von Treibern (sonst könnte ich den fertigen Wandler von Dallas nehmen). Die Bedienung wird im Fall der Fälle von ziemlichen Laien erfolgen.
Das wäre für diese recht einfache Sache nicht das grosse Problem, auf der PC-Seite sieht es da schon etwas aufwendiger aus wenn man nicht viel fertiges verwenden kann.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Wenn Du in der externen HW einen uC hast, dann kannste das wesentlich schneller erledigen. Per USB kompletten Datensatz raus, was Du wollen, der uC daddelt das schnell mit dem 1wire Slave aus und schickt einen kompletten Block per USB zurück.
Und ne Variante, wo der USB Stick als Plattenersatz funzt und die 1wire Daten in einer/mehreren Dateien stehen?
Man kann auch so nen "USB zu RS232"-Wandler als HID-Device anmelden. Da muss nur die USB-Kennung (der Descriptor, wo VID, PID usw. drin festgelegt sind) im Chip geändert werden, was in der Regel möglich ist. Hab das aber selber noch nicht gemacht. Und ob der FTDI das dann mit den speziellen Busschnittstellen kann - k.A. müsste man sich mal die Datenblätter anschauen. Du willst ja keine DLL's installieren - aber wenigstens ne eigene Exe (oder VBA)? Da hat man schon noch einige Möglichkeiten. M.
Am Mon, 6 Dec 2010 16:22:05 +0000 (UTC) schrieb Matthias Weingart:
Braucht der aber dann nicht trotzdem die Treiber des Herstellers für den virtuellen Com-Port?
Exe auf jeden Fall, auch Zugriff auf lokale DLLs ist kein Problem. Das wichtige ist die Transparenz für den Anwender, aber vielleicht hat da jemand noch eine ganz andere Idee.
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Am 06 Dec 2010 13:08:00 -0300 schrieb Wolfgang Allinger:
Ja, das geht wohl wenn man da etwas mehr Aufwand reinsteckt.
Die externe Hardware soll möglichst transparent sein, Updates der Funktion dann möglichst nur in der PC-Hardware erfolgen.
Der Datendurchsatz ist in der Anwendung wahrscheinlich nicht das Problem.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Am Mon, 6 Dec 2010 17:38:47 +0100 schrieb Lutz Schulze:
soll natürlich Software heissen
Lutz
-- Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin auch für Nagios - Nachricht per e-mail,SMS und SNMP:
Stimmt, das ist der Grund warum 1Wire Mist ist. Ich hab das Problem aber geloesst indem ich die gesamte 1-Wire-Uebertragung als Statemachine in den Interrupt verlagert habe. Die jeweils unterschiedlich langen WArtezeiten bei den einzelnen States werden ueber Timereinstellungen geloesst. Ausserdem muss der 1Wire-Timer mit einem hohen IRQ-Level arbeiten, aber das ist ja kein Problem weil der IRQ immer nur sehr kurz laeuft. So laeuft dieser @#$@$@@#$ Bus unauffaellig im Hintergrund.
1Wire waere genauso unproblematisch wenn er sich verbreitet haette und er in die Controller eingebaut waere. Das Problem mit dem Bus ist aber das ihn ausser Dallas keiner benutzt und es ausser dem DS1820 keinen Grund gibt ihn zu nutzen weil es Alternativen gibt.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.