www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 1-Wire Slave auf AVR


Autor: martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde gerne eine 1-Wire Slave Application auf einem Atmel Avr
realisieren. Der uC soll dabei als Slave im Bus zur verfügung stehen.
Das ganze sollte mit dem 1-Wire Protokoll von Dallas kompatibel sein da
noch andere 1-Wire Devices am Bus hängen.

Leider gibts von Atmel nur eine Application Note für die
Implementierung des Masters.

Ich würde ungern das Rad neu erfinden. Das hat sicher schonmal jemand
gemacht.

Hat jemand erfahrung damit und weiss wo ich entsprechenden SOurce COde
finden kann?

Autor: gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo martin,

du willst dir also soweit ich das verstehe mit einem mc ein
1-wire-device erstellen.

im prinzip ist das doch nicht schwerer, als den mc als master zu
programmieren. brauchst doch die selben routinen nur das du halt den
portpin nun abtasten musst, ob ein reset ansteht und das ganze zeug.

selbermachen ist doch am schönsten!

Autor: Aleksej Kiselev (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist fast hoffnungslos. Wenn es nur ein Slave waere, dann koennte man
das realisieren, aber wenn da andere Slaves dran haengen, dann hat man
mit AVR kaum eine Chance. Timing ist sehr wichtig fuer 1-wire, AVR
schafft es nicht. Und es gibt keine vernuenftige Beschreibung, weil es
von DS lizensiert ist. Alles was man finden kann ist nur ein Paar
Tests.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht m.E. nur mit etwas Nachilfe in Form externer Hardware, die ggf. den
1µs-Impuls vom Master latched. Ansonsten müsste der AVR garantiert
binnen 1µs reagieren können, was sich schwer garantieren lässt, wenn
der noch was anderes tun soll.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. Vielleicht mit Hilfe vom USI, so vorhanden. Der start condition
detector könnte sich missbrauchen lassen um den Impuls zu latchen, und
ein timer mit input capture kriegt raus, wie lange das schon her ist.
Damit könnte es gehen. Trotzdem haarig.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre denn der ordinäre externe Interrupt nicht für den 1µs-Impuls
geeignet?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Lesen zieht der Master für 1µs auf 0. Der Slave muss dann binnen
dieser 1µs den Pin selber auf 0 ziehen, wenn er eine 0 zurückgeben
will, oder er lässt den Pin in Ruhe bei einer 1.

In Software ist diese Reaktionszeit schlecht zu gewährleisten.

Autor: gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

wo habt ihr die 1us her. schau ich mir die timmingbeschreibung von
maxim an, finde ich diese bedingung nicht. ich gehe davon aus, das man
die devices nicht im overdrive modus betreibt.

z.b. um auf den presence puls zu reagieren, hat man genügent zeit. Die
erst phase ist ca. 600us und detektiert wird bei 610us.

avr kenn ich perönlich nicht. aber der takt wird doch sicher auch bei
20mhz liegen.

schwirig ist eher, das das timing zwischen min und max werten läuft.
hier würde ich auf masterseite den ds2482-100 empfehlen, der sich ums
timing kümmert und nicht die onewire schnittstelle sleber realisieren.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe das seit ein paar Wochen am laufen für einen Tiny13 und Mega8. Hat
allerdings noch einen kleinen Bug (gelegentlich antwortet der nur mit
FFs, gibt dann aber CRC Error, kann aber auch am Netzwerk liegen), aber
funktioniert prinzipiell in einem Netzwerk mit mehreren DS1820.

Kann ich heute abend mal reinstellen. Ist aber noch Alpha status.

Gruss
Axel

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"wo habt ihr die 1us her."


Die stehen doch im Datenblatt.

Der Master muß für mindestens 1µs Low anlegen, um dem Slave zu sagen,
daß er ein Bit lesen will.
Und der Slave muß dann dieses Low für min 15µs strecken, wenn er ein
0-Bit ausgeben will.

Der Master gibt also für 1µs low und irgendwann innerhalb 14µs liest er
den Pin zurück.

Nur mit dem USI der ATTinys kann man das realisieren.


Ist kein Original-Slave mit dran, könnte man sich darauf einigen, daß
der Slave innerhalb von 10µs auf low ziehen muß und der Master erst
nach 10µs ausliest. Dadurch reduziert sich natürlich auch die maximal
mögliche Leitungslänge.


Peter

Autor: gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo peter,

das timing lässt sich gut aus dem datenblatt zum DS2482-100 ablesen.
dort steht, das der master nach ca. 14us (typischer wert), den zustand
auswertet. also muss ich nach feststellen der negativen flanke bis
dahin meinen zustand stabil haben. bei den devices, z.b. dem ds2433
wird das fenster für die detektierung mit trvd - tlowr  angeben. wie
man daraus sieht, stellt der ds2482-100 den zustand zimlich am ende
erst fest. so schlägt maxim das ja auch vor, wenn man sich den master
mit einem portpin selber schustert.

Man muss sich also nicht einigen, da ja das von maxim geklärt ist und
wann dein mc das zurück liest, kannst ja du selber festlegen.

ich nutzte den ds2482-100 und hab damit keine probleme.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das One-Wire Timing laesst sich prima mit einem UART erzeugen. Bei Maxim
oder Atmel gab eine Applikationsnote dazu.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist doch, was ich für einen Master verwende. Digiterm z. B.
verwendet den PC UART, das Timing dort kann ich beeinflussen. Das
Gleiche gilt, wenn man einen AVR als Master nimmt.

Somit sind die 1 us zwar in der Theorie vorhanden, kommen aber
praktisch kaum vor. Eigentlich muss man nur die Flanke detektieren und
dann das Signal auf den Pin bekommen. Das kann man aber schon
vorbereiten, d. h. der Flankeninterrupt kann das direkt nach Aufruf
machen.

Entscheidend ist, dass man rechtzeitig aktiv wird, bevor der Master das
Signal abtastet.

Gruss
Axel

Autor: Joachim Börke (joachimb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den Dallas-Bausteinen ist das Protokoll in Hardware realisiert. Bei
einem Read-Data-Time-Slot zieht der Slave das Signal so nach spätestens
einer us auf Masse.
Ein integrierter Master (z.B. DS2480) hält das Signal dagegen zu Beginn
des Time-Slots 8 us auf Masse.
Bei der Masterschnittstelle mittels UART nutzt Dallas für den
Read-Data-Time-Slot das Startbit eines 115200 bd Signals, das ungefähr
8,6 us dauert.
Da es nicht erforderlich ist, den 1-wire-Bus gleichzeitig vom Master
und vom Slave auf Masse legen zu lassen, sollte man für das mit dem
"1us-Signal" ohne übertriebene Eile handhaben.
Bei einer Dauer von 7 us entsteht auch keine Lücke, in der der Pullup
die Leitung auf 1 ziehen könnte.

Gruß
Joachim

Autor: Joachim Börke (joachimb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@martin
Es gibt zum one-wire-slave einige Quellen im Netz:
http://lcd.strony.pl/d-109v2.htm
http://embeddeddatasystems.com/page/EDS/PROD/IO/DSP7X4
http://www.louisswart.co.za/1-Wire_Overview.html
http://home.hetnet.nl/~thomas_7/1Wire/1-WireIOPort.html
http://www.alpov.net/elektronika/owslave.html
evtl. kannst Du davon etwas brauchen.

@axel
Du hattest angeboten, deinen Quelltext zu veröffentlichen. Ich bin
daran interessiert.

Gruß
Joachim

Autor: Bjoern M. (salival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zitat http://www.mikrocontroller.net/articles/Hausbus :
"in Software realisierte Peripherie verstößt gegen US-Patente"

Also nicht verklagen lassen bei Veroeffentlichung...

gruss, bjoern.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Joachim,

hmm, das mit den Patenten könnte tatsächlich ein Problem sein, wenn ich
das hier veröffentliche. Ist vielleicht auch schlicht der Grund, warum
ich nirgends ein Programm für so einen Slave finden konnte.

Hast Du eine E-Mail Adresse, wo ich das hinschicken kann ?

Gruss
Axel

Autor: Joachim Börke (joachimb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Axel,

meine email-Adresse ist:
joachim.boerke(at)gmx.de

Gruß
Joachim

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joachim,

ich schicke es Dir heute abend, will den Code erst noch ein bischen
aufräumen.

Gruss
Axel

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Axel,

ich hätte auch interesse an dem Code. Wäre super wenn du ihn mir auch
schicken könntest.

Email:  einer.meiner@lycos.de

Danke und Grüße,

Joachim

Autor: Stephan Bauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Axel,

ich hätte auch interesse an Deinem Code.

Könntest Du ihm mir bitte auf diese Adresse schicken:
stephan_bauer@gmx.de

Danke

Grüße

Stephan

Autor: ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun Das mit den Patenten geht so: US-Patente gelten nur in USA! Wenn Du
kein Geld damit machst, kannst Du das benutzen. Patente sind keine
Geheimnisse... eher das Gegenteil! Was nicht geht: Patent nutzen für
eine Sache die verkauft oder vermietet wird.

Autor: Henning Schreiber (xtsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Axel,

so einen Code suche ich doch schon seit Ewigkeiten...

Wenn es geht, bitte auch an mich:

xtsi@gmx.de

Gruss,

Henning

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorschlag:
Ab in die Codesammlung damit.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich schieb ihn heute Abend hoch.

Ist aber, wie bereits geschrieben, noch Alpha Stadium (funktioniert
aber).

Gruss
Axel

Autor: Axel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier also der Code. Läuft auf einem Tiny13 und einem Mega8. Das kann im
Makefile eingestellt werden.Im Tiny13 wird es aber schon sehr knapp und
es ist der Timer und der externe interrupt belegt. Ich habe im Haus
einen 1-Wire Bus hängen, an dem viele 18B20 hängen, die Tiny13 Variante
nutze ich um z. B. Reedkontakte abzufragen.

Der Baustein verhält sich im Prinzip wie ein 1820 Temperatur Sensor
wobei natürlich keine Temperaturen, sondern die 8 Datenbytes ausgegeben
werden, die in "transdata" stehen.

Dazu gibt es noch eine adaptierte Digitemp 3.3.2 Source, die
zusätzliche Aufrufparameter zum Schreiben der zwei EEPROM Zellen
bietet.

Gruss
Axel

Autor: hand sieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann sind patente nur schutz dieser speziellen sache. die idee selbst
ist nicht geschützt. wenn du nicht unbedingt die genauen zeiten
brauchst dann fahr das ding auf einer anderen (nicht in den
datenblättern spezifizierten) taktrate und schon ist das nicht mehr
1wire konform - aber kompatibel.
wenn die z.b. nur zwischen zwei µC aus layout-gründen nur eine leitung
ziehen kannst, dann bist du doch nicht an 1wire gebunden.
abgesehen davon sind 1µS bei 8MHz takt eines avrs immer noch 8 takte...
assembler lässt grüssen.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Axel

Wie hast du den Tiny13 beschaltet?
Data I/O auf welchem Port, mit externem Transistor?
Interner RC-Oszi oder extern?

Gruss Mike

Autor: JoachimB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mike,

lies doch einmal in "onewire.c" nach.
Data I/O liegt an INT0.
Die Taktfrequenz sollte 9,6 MHz sein.
Ein Transistor ist sicher nicht erforderlich. Bei einem bidirektonalen 
Anschluß wüsste ich nicht wie das Schaltungstechnisch aussehen sollte?

Gruß
Joachim

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JoachimB schrieb:
> Die Taktfrequenz sollte 9,6 MHz sein.

Hä? Im Code steht
#define F_CPU                 8000000
Interner RC funktioniert (zumindest bei mir auf einem ATtiny85).

Autor: JoachimB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

Du hast recht.
Ich hatte mich auf diesen Teil der Datei bezogen:
#define ONEWIREPIN 1         // Pin, an dem der 1-Wire angeschlossen ist, MUSS INT0 sein
#define PRESENCEZEIT 15      // Timingdeclarationen für 9,6 MHz
#define PRESENCEWAITZEIT 2
#define ABTASTZEIT 3           // Abtastzeitpunkt beim empfangen 
#define SENDEZEIT 5           //  Dauer des 0-Sendeimpulses
Die 17% Abweichung sind dann offensichtlich nicht kritisch.

Gruß
Joachim

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JoachimB schrieb:
> Die 17% Abweichung sind dann offensichtlich nicht kritisch.

Nein, die funktionieren einwandfrei. Ich meine sogar, dass die DS18B20 
viel kürzere Zeiten als Presencepulse benutzen.

Autor: erwind (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hab mir eine ATTiny13 besorgt, scheint aber nicht zu funktionieren.
Kann es sein das "SKIP_ROM" nicht richtig unterstütz wird ?

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht ganz richtig. Korrekt ist es wenn man das Wort "richtig" streicht.

Es werden nur folgende Kommandos unterstützt:

MATCHROM
READ SCRATCHPAD
WRITE SCRATCHPAD

Autor: erwind (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn ich per SKIP_ROM alle DS18B20 abfrage, reagiert der ATiny aber und 
verstümmelt die Daten bzw. der Bus bricht ab.

Der 1-Wire Master schickt auch noch ein "SEARCH ROM [F0h]" Kommando beim
einlesen der DS18B20, evtl. reagiert der ATiny darauf.

Im Code ist "SEARCHROM" ist zwar definiert, aber nicht benutzt.

Autor: JoachimB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erwind schrieb:
> wenn ich per SKIP_ROM alle DS18B20 abfrage, reagiert der ATiny aber und
> verstümmelt die Daten bzw. der Bus bricht ab.

Mit SKIP-ROM darf man nur einen Dallas-Baustein am Bus haben. Dieser 
fühlt sich dann ohne Seriennummern-Check angesprochen.

Autor: erwind (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab im Master nachgeschaut - CONVERT T [44h] wird mit SKIP ROM [CCh] 
angefordert.
Nach etwa 1s wird mit SEARCH ROM [F0h] nach den IDs der DS18(S,B)20 
Sensoren gesucht, diese werden dann gezielt mit READ SCRATCHPAD [BEh] + 
ID aus dem vorhergehenden SEARCH ROM [F0h] Commando ausgelesen.

Das Tut alles seit Jahren, ich brauche aber ein paar Eingänge, so bin 
ich auf die ATiny Geschichte hier gestossen.

Läuft das tatsächlich bei jemandem am Bus zusammnen mit anderen Dallas 
Bausteinen ?

Welche Komando-Reihenfolge führt zum Ziel ?

Autor: Axel Laufenberg (axel_5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, so viel Aktivität bei einem 4 Jahre alten Beitrag :-)

Ich hatte SKIP ROM nie verwendet, allerdings sollte es trotzdem keine 
Störungen machen.

Allerdings hatte ich mal Probleme mit dem RESET nach 
Übertragsungsfehlern, die aber nur alle paar Wochen bei mir Probleme 
gemacht hatten. Ich könnte mir aber vorstellen, dass das genau diese 
Symptome zeigt, weil Übertragunsfehler und unbekannte Opcodes aus Sicht 
der Software ja im Prinzip das Gleiche sind.

Ich werde das die Tage mal raussuchen, vorher schaffe ich es leider 
nicht.

Gruss
Axel

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ide aktuelle Variante. Habe da einiges angepasst, um die 
Störungen wegzukriegen, bin aber nicht sicher, ob das auf einem ATTINY 
noch läuft, da ich das nur noch auf einem ATMEGA laufen lasse.

So läuft das aber seit drei Jahren ohne Fehler.

// Timer interrupt routine
#ifdef _AVR_ATtiny13_
ISR (TIM0_OVF_vect)
#elif defined (_AVR_ATmega8_)
ISR (TIMER0_OVF_vect)
#endif    // Port als Ausgang
{
    unsigned char tim0_i, status;
    signed int temperaturwert, temperaturwert_bruch;
    TIMSK0 &= ~(1 << TOIE0);       // Timer Interrupt aus
    status = status_global;
#ifdef _AVR_ATtiny13_
          DDRB &= ~(1 << ONEWIREPIN);    // Pin auf Eingang
#elif defined (_AVR_ATmega8_)
          DDRD &= ~(1 << ONEWIREPIN);    // Pin auf Eingang
#endif
    if (status == RESET){
#ifdef _AVR_ATtiny13_
          DDRB |= (1 << ONEWIREPIN);    // Pin auf Ausgang
#elif defined (_AVR_ATmega8_)
          DDRD |= (1 << ONEWIREPIN);    // Pin auf Ausgang
#endif
          status = PRESENCEPULSE;
          bitcount = 0;
          TCNT0 = ~PRESENCEZEIT;     // Neu Starten zum bestimmen der 
Presencepulselaenge
          TIFR0 |= (1 << TOV0);
          TIMSK0 |= (1 << TOIE0);       // Timer Interrupt an
    }
    else if (status == PRESENCEPULSE){    // Presence Puls zu ende, 
Timer INT aus, Pin auf Eingang, warten auf Opcode
          status = RECEIVE_OPCODE;
          bitcount = 0;     // TINT wird oben ausgeschaltet
    }

   else if (status & (RECEIVE_OPCODE | MATCHROM | WRITEMEM)){
            bitcount++;
            if (bitcount == 1) {
                transbyte = 0;
            }
            transbyte = transbyte >> 1;
            if (PIND & (1 << ONEWIREPIN)){
                transbyte |= 0x080;
            }
            if (bitcount == 8){
                if (status == RECEIVE_OPCODE) {
                        if (transbyte == 0x55){   // 0x55 -> Matchrom
                              status = MATCHROM;
                              transbyte = 0;    // New
                        }
                        else if (transbyte == 0x4E){
                              status = WRITEMEM;
                              transbyte = 0;
                        }
                        else if (transbyte == 0x48){  // Write data to 
EEPROM
                              status = WRITEMEM;
                              transbyte = 0;
                        }
                        else if (transbyte == 0x48){  // Write data to 
EEPROM
                            for (tim0_i = 2; tim0_i < 4; tim0_i++){
                                while(EECR & (1<<EEPE)) ;
                                /* Set Programming mode */
                                //EECR = (0<<EEPM1)|(0>>EEPM0);
                                /* Set up address and data registers */
                                EEARL = tim0_i;            // EEPROM 
Address
                                EEDR = transdata[tim0_i];
                                /* Write logical one to EEMPE */
                                EECR |= (1<<EEMPE);
                                /* Start eeprom write by setting EEPE */
                                EECR |= (1<<EEPE);
                            }
                              status = IDLE;
                              transbyte = 0;
                        }
                        else if (transbyte == 0xBE){    // Daten lesen
                              status = READMEM;
                              shift_reg = 0;     // Schiebergister für 
CRC loeschen
                             transbyte = transdata[0];
                        }
                        else {
                                status = IDLE;
                        }
                        bitcount = 0;
                        bytecount = 0;
                }
                else if (status == MATCHROM){
                        if (bytecount == 0){
                                if (transbyte == FAMILYCODE);
                                else status = IDLE;
                        }
                      else if (bytecount < 7){
                                if (transbyte ==  DEVICEID) ;
                                else  status = IDLE;
                        }
                        else {                  // Byte 8
                                status = RECEIVE_OPCODE; // Eigentlich 
CRC checken, aber wozu ?
                        }
                        if (status == IDLE){
                                bytecount = 0;
                        }
                        bytecount++;
                        bitcount = 0;
                }
                else if (status == WRITEMEM){
                        if (bytecount == 0){
                                onewire_cmd1 = transbyte;
                                transdata[2] = transbyte;
                        }
                        else {
                                onewire_cmd2 = transbyte;
                                transdata[3] = transbyte;
                                status = RECEIVE_OPCODE;
                                bytecount = 0;
                        }
                        bytecount++;
                        bitcount = 0;
                }
          }
    }
    else {                 // status == READMEM oder rest
#ifdef _AVR_ATtiny13_
          DDRB &= ~(1 << ONEWIREPIN);    // Pin auf Eingang
#elif defined (_AVR_ATmega8_)
          DDRD &= ~(1 << ONEWIREPIN);    // Pin auf Eingang
#endif
    }
    status_global = status;
}

// Flankenerkennung am 1-Wire pin, entsprechend wird dann dei Aktion 
ausgewählt
ISR (INT0_vect)
{
    unsigned char tim0_i, status;
    status = status_global;
#ifdef _AVR_ATtiny13_
          DDRB &= ~(1 << ONEWIREPIN);    // Pin auf Eingang
#elif defined (_AVR_ATmega8_)
          DDRD &= ~(1 << ONEWIREPIN);    // Pin auf Eingang
#endif

#ifdef _AVR_ATtiny13_
      if (PINB & (1 << ONEWIREPIN)){     // Steigende Flanke am One Wire
#elif defined (_AVR_ATmega8_)
    if (PIND & (1 << ONEWIREPIN)){     // Steigende Flanke am One Wire
#endif
            if ((TCNT0 < 0xE0) && (TCNT0 > 35)) {    // Reset pulse wenn 
Puls >30 und < F0 geaendert auf 35
                  TIFR0 |= (1 << TOV0);                   // Timer 
Overflow loeschen
                  TCNT0 = ~PRESENCEWAITZEIT;                  // Timer 
Neu Starten Fuer Presencepulse
                  TIMSK0 |= (1 << TOIE0);       // Timer Interrupt an
                  status = RESET;
            }
      }
      else {                                      // Fallende Flanke am 
One Wire
          if (status == READMEM){
                if ((transbyte & 0x01) == 0){
#ifdef _AVR_ATtiny13_
                      DDRB |= (1 << ONEWIREPIN);    // Pin auf Ausgang
#elif defined (_AVR_ATmega8_)
                      DDRD |= (1 << ONEWIREPIN);    // Pin auf Ausgang
#endif
                  }
                TIFR0 |= (1 << TOV0);         // TimerOverflow loeschen
                TCNT0  = ~SENDEZEIT;
                TIMSK0 |= (1 << TOIE0);       // Timer Interrupt an
                fb_bit = (transbyte ^ shift_reg) & 0x01;   // CRC 
berechnen
                shift_reg = shift_reg >> 1;
                if (fb_bit)
                        shift_reg = shift_reg ^ 0x8c;
                bitcount++;
                transbyte = transbyte >> 1;
                if (bitcount == 8){
                        bitcount = 0;
                        bytecount++;
                        if (bytecount == 8){
                                 transbyte = shift_reg;  // CRC senden
                        }
                        else if (bytecount == 9) status = IDLE;  // CRC 
senden
                        else transbyte = transdata[bytecount];
                }
          }
          else if (status == IDLE) {           // Erste fallende Flanke
              TIFR0 |= (1 << TOV0);         // TimerOverflow loeschen
              TIMSK0 &= ~(1 << TOIE0);       // Timer Interrupt aus
              TCNT0 = 0;
             // status = RESET;                // Erste fallende Flanke 
nach Idle, Timer nutzen um Länge des Pulses zu messen
          }
          else if (status & (RECEIVE_OPCODE | MATCHROM | WRITEMEM)){
                TCNT0 = ~ABTASTZEIT;          // Zeichen abtasten in 
ABTASTZEIT
                TIFR0 |= (1 << TOV0);         // TimerOverflow loeschen
                TIMSK0 |= (1 << TOIE0);       // Timer Interrupt an
          }
          else if (status == RESET) {           // Da hat ein anderer 
einen Presence Pulse gesendet, da haengen wir uns dran
//              DDRD |= (1 << ONEWIREPIN);    // Pin auf Ausgang
                status = PRESENCEPULSE;
                bitcount = 0;
                TCNT0 = ~PRESENCEZEIT;     // Neu Starten zum bestimmen 
der Presencepulselaenge
                TIFR0 |= (1 << TOV0);       // Timer OVF loeschen
                TIMSK0 |= (1 << TOIE0);       // Timer Interrupt an
          }
          else if (status == PRESENCEPULSE);   // Gar nichts tun, 
Pegeländerung kommt vom eigenen Timer beim Senden oder anderen
          else {
               status = IDLE;
                TCNT0 = 0;
                TIFR0 |= (1 << TOV0);         // TimerOverflow loeschen
                TIMSK0 &= ~(1 << TOIE0);       // Timer Interrupt aus
          }
     }
    status_global = status;
}

Autor: erwind (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hab das mal in den Ur-Code eingepflegt, komme aber erst Morgen zum 
testen.

Danke schon mal

AVR Memory Usage
----------------
Device: attiny13

Program:     958 bytes (93.6% Full)
(.text + .data + .bootloader)
Data:         15 bytes (23.4% Full)
(.data + .bss + .noinit)

Build succeeded with 6 Warnings...

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich an dem Code mal ausgelassen. Jetzt läuft er bei mir 
(Boarduino, d.h. atmega168) stabil, kann SEARCH_ROM, lässt sich debuggen 
(via interruptgesteuertem UART-Output), passt dafür aber nicht mehr in 
den attiny13 rein (nichtmal wenn man die neuen Features weglässt). 
Dagegen werde ich noch was tun müssen. :-/

Bei Interesse: Mail an mich. Sobald einigermaßen fertig, veröffentliche 
ich's auf github, damit Andere sich auch daran auslassen können.

Ach ja: Axel: Ich hoffe, du hast nichts dagegen; dein Code hatte kein 
Copyright und stand nicht unter GPL oder Ähnlichem ...

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ach ja: Axel: Ich hoffe, du hast nichts dagegen; dein Code hatte kein
>Copyright und stand nicht unter GPL oder Ähnlichem ..

Is scho recht :-)

Gruss
Axel

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Code ist hier:

http://github.com/smurfix/owslave

SEARCH_ROM funktioniert, die Grundfunktion eines DS2408 und eines DS2423 
sind als Proof-of-concept implementiert, wenn auch noch ohne externe 
Anschlüsse.

Passt momentan leider nur in AVRs ab 4k Flash; den Code wieder auf 2k 
runterzubringen dürfte möglich sein, 1k ist nicht besonders realistisch 
(u.A. wegen der CRC-Berechnung).

Ich freue mich auf Mitarbeit.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bjoern M. schrieb:
>> http://www.mikrocontroller.net/articles/Hausbus :
>> "in Software realisierte Peripherie verstößt gegen US-Patente"
>
> Also nicht verklagen lassen bei Veroeffentlichung...
>
> gruss, bjoern.

Hallo, kann diesen Abschnitt jemand mit einer Quelle belegen?

Gruß,
Alexander

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn ich versuche den Code von smurfix im AVR Studion für einen ATmega8 
zu kompilieren, bekomme ich folgende Fehlermeldung(en):

Build started 22.7.2010 at 11:14:02
avr-gcc  -mmcu=atmega8 -Wall -gdwarf-2 -std=gnu99 
-DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct 
-fshort-enums -MD -MP -MT onewire.o -MF dep/onewire.o.d  -c 
../onewire.c
../onewire.c: In function 'setup':
../onewire.c:170: error: 'EIFR' undeclared (first use in this function)
../onewire.c:170: error: (Each undeclared identifier is reported only 
once
../onewire.c:170: error: for each function it appears in.)
../onewire.c: In function 'set_idle':
../onewire.c:428: error: 'EIFR' undeclared (first use in this function)
../onewire.c: In function '__vector_9':
../onewire.c:455: error: 'EIFR' undeclared (first use in this function)
../onewire.c: In function '__vector_1':
../onewire.c:677: warning: overflow in implicit constant conversion
make: *** [onewire.o] Error 1
Build failed with 5 errors and 1 warnings...

Leider kann ich damit nichts anfangen, da in den betreffenden Zeilen 
immer nur   IFR |= (1 << INTF0);    steht.

Für jede Art von Hilfe bin ich dankbar.
Gruß, Dieter

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:

> Hallo, kann diesen Abschnitt jemand mit einer Quelle belegen?

Irgendwo hier wirst du bestimmt fündig, auch wenn sich das eher als 
Belegungsplan eines Krankenhauses liest: 
http://www.1wire.org/Files/Patents/Dallas.htm

Autor: Hamza (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit WinAVR ist das EIFR Problem gelöst.

Ja das ist aber jetzt nicht so super.

Ich habe einen ziemlich langen Beitrag über die Verwendung der Arbeit 
von smurf geschrieben und vor dem Abschicken noch auf das Lesen der 
Nutzungsbedingungen geklickt, womit mein Beitrag weg war.

Klar, ich bin schon ein ..., wenn ich Nutzungsbedingungen lese, aber das 
weiss ich.

Mein Beitrag zusammengefasst:

Smurfs Arbeit, aufbauend auf der Arbeit von Axel, erachte ich als 
professionelle Basis für weitere Arbeiten.

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
> Smurfs Arbeit, aufbauend auf der Arbeit von Axel, erachte ich als
> professionelle Basis für weitere Arbeiten.

Danke für die Blumen.

Ich muss dringend die Änderungen von taliesin in meine Version 
einpflegen (siehe github, http://github.com/smurfix/owslave/network).

Hoffentlich komme ich demnächst dazu. :-/

Autor: Michael Buchholz (m_i_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
( ... in den Raum ruf ... )

Ist dieser Fred noch aktuell resp. wird an dem Projekt noch gewerkelt?

Egal ob oder ob nicht:
http://www.brain4home.eu scheint mit Dallas keine Probleme zu haben / zu 
befürchten. Denn was die da cooles machen, ist ja im Grunde 
vergleichbar, nur halt fertig (zumindest der BAE0910).
Sowas wie die derzeit als BAE0911 stricken auf einem AVR gepackt wäre 
echt eine supercoole Sache und sicherlich ein lohnendes Projekt; oder 
gibts das schon? Dann ist es mir entgangen...

Autor: MC9S08SH32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheint dieser oder ein PIN kompatibler FreeScale "MC9S08SH32" zu sein, 
der da verwendet wird (großes Board).

Autor: MC9S08SH32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stimmt sogar, ich hatte PINs verglichen um den Typ zu finden ...

Ich habs eben gerade in der Doku gefunden:
MC9S08SH8 im SOIC-8 für das kleine Modul.
MC9S08SH16/MC9S08SH32 im SOIC and TSSOP 28 für das große Modul.

Na dann kann das Reverse Engineering ja losgehen ...
(ich hab von FreeScale Null Ahnung)

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das scheint ein 1-Wire Master zu sein. Da gibt es keine Probleme mit. 
Dallas verfolgt meines Wissens nur Slave Implementierungen.

Wobei Patente sowieso nur die kommerzielle Verwertung verbieten, so dass 
einem Einsatz im eigenen Haus wohl nichts entgegensteht.

Gruss
Axel

Autor: Michael Buchholz (m_i_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... hmmm? Definitionssache? ;)

Ich halte das für einen Slave. So ist es ja auch konzipiert. Ok, wenn 
ich das richtig verstanden habe, könnte der auch als Master tätig 
werden, da ja auch eigene Routinen im System abgelegt werden können 
(wohl in Zukunft in einer Art Basic), aber das ist ja nicht der Zustand 
"out of the box" ...

Aber ist ja eh alles Banane, da hier ja niemand sowas für kommerzielle 
Zwecke einsetzen wird ;)

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, man muss ja nur das Datenblatt öffnen, da steht auf der ersten 
Seite, dass das ein Slave ist.

Gruss
Axel

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
>
> Ist dieser Fred noch aktuell resp. wird an dem Projekt noch gewerkelt?
>
Aktuell werkle ich an diesem Projekt nicht, weil keine Zeit dafür. 
Irgendwann ändert sich das aber wieder …

Hauptproblem ist übrigens, dass der aktuelle Code stark CPU- und 
taktabhängige Timingparameter hat, die man ohne gutes 
Zweikanal-Oszilloskop nicht debuggen bzw. korrigieren kann. :-/

NB, dieses BAE0910-Projekt klingt interessant, aber wenn die nackte CPU 
15€ kostet, fängt es schon wieder an schwierig zu werden. Da kriege ich 
fünf Atmel für, zumal es die auch im DIL-Gehäuse gibt -- zum Basteln 
doch etwas einfacher als SOIC und Konsorten.

Autor: Michael Buchholz (m_i_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Urlichs schrieb:
> die man ohne gutes Zweikanal-Oszilloskop nicht debuggen bzw. korrigieren kann.

... hmmm, so teuer sind die nicht mehr, je nach dem, was du unter "gut" 
verstehst; wo kommst du denn weg?
BTW: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=...

>  aber wenn die nackte CPU 15€ kostet

Ebend, nicht nackend. Daher ja meine Idee, sowas oder sowas ähnliches in 
einen AVR zu packen; was braucht man denn meisst? Einen Knecht, der 
schalten und Sensorik erkennen kann, der autark ein oder mehrere PWM 
generiert, wobei der Master ihm halt z.B. sagt "mach ma 25%DC" und ggf. 
autark noch nebenher kleinen Code ausführen kann.

Dann das ganze in einen Tiny45, einen Tiny44 und ggf. in einen "Dicken" 
und feddich ist ein universelles Werkzeugs für uns Frickler ;)

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Buchholz schrieb:
> Matthias Urlichs schrieb:
>> die man ohne gutes Zweikanal-Oszilloskop nicht debuggen bzw. korrigieren kann.
>
> ... hmmm, so teuer sind die nicht mehr, je nach dem, was du unter "gut"
> verstehst; wo kommst du denn weg?

Das Problem sind nicht die 300€ (nebenbei bemerkt gibt es vernünftige 
schnelle USB-Messwandler mit brauchbarer Oszilloskop-Software für die 
Hälfte, und die können mehr. PS: das Zeug, was Conrad als PC-Oszi 
anbietet, ist alles Andere als brauchbar.)

Das Problem ist, dass ich mich als Bastler bei diesen Teilen auf was 
Anderes konzentrieren mag als darauf, das 1wire-Bustiming hinzufrickeln 
-- zumal ich zum Prüfen sämtlicher Funktionen, die das Teil eigentlich 
übernehmen können muss, keinen Oszi brauche, sondern mit einem simplen 
Multimeter auskomme.

Ich gebe gerne zu, dass meine Lösung genau das noch nicht leistet.

Andererseits: wenn's erstmal läuft, ist das Anbinden von eigenem Code 
(Funktion X => empfange Y und sende Z, und so) ziemlich einfach. Um 
Einiges einfacher, als dem OWFS-Code dessen Ansteuerung beizubringen ...

Autor: G. S. (varda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bin vor ein paar Wochen zufällig auf diesen Thread gestossen. Eigentlich 
suchte ich ja Beiträge zum DS 2423.

Herausgekommen ist folgende Platine mit einem Attiny44. Als Software 
Basis wurden die Versionen von smurfix und taliesin verwendet. 
Hinzugefügt wurde der ATtiny44 und einige Änderungen im SourceCode.

Auslesen mit Digitemp .. total easy (1Wire Adapter USB9097)


win2000@AMDX2:~/digitemp-3.6.0$ ./digitemp_DS9097U -i -s /dev/ttyUSB0
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
Turning off all DS2409 Couplers
.
Searching the 1-Wire LAN
1D89E1C34CBE42B7 : DS2423 4Kbit RAM + Counter
ROM #0 : 1D89E1C34CBE42B7
Wrote .digitemprc

win2000@AMDX2:~/digitemp-3.6.0$ ./digitemp_DS9097U -a -s /dev/ttyUSB0
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
Oct 10 08:27:10 Sensor 0 #0 31
Oct 10 08:27:10 Sensor 0 #1 51
win2000@AMDX2:~/digitemp-3.6.0$

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das freut mich. Kannst du mir deine Änderungen schicken?
(Direkt auf github wäre noch besser. ;-)

Autor: G. S. (varda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Urlichs schrieb:
> Das freut mich. Kannst du mir deine Änderungen schicken?
> (Direkt auf github wäre noch besser. ;-)

Natürlich, kein Problem.

als Diff Vergleich zur taliesin-Basis (Datei aenderungen)

und als kompl. Directory (tiny44.zip)

Folgende Datein wurden geändert:
- avr.h
- ds2423.c
- features.h
- Makefile
- onewire.c
- onewire.h

Falls Interesse besteht. Die Platine wurde unter Kicad entwickelt. Kann 
auch diesen Teil hier noch posten.

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kicad ist super, das verwende ich auch, immer nur her damit. freu

Ich hoffe, ich komme dieses Jahr noch dazu, die ganzen Änderungen 
diverser Leute in das öffentliche Archiv einzupflegen. :-/

NB: Ich finde es faszinierend, dass das Timing offenbar auf Anhieb 
passt; da hatten Andere schon schlechtere Erfahrungen.

Autor: G. S. (varda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
als Anlage die KICAD - Dateien als zip

..

Autor: G. S. (varda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timing war kein Problem.

Habe es mit mehreren 1 Wire Adaptern mit 8 und 16 MHz ausprobiert.
Keine Probleme aufgetreten.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wer kann mir helfen damit ich die Dateien auf einem WinXP mit WinAVR und 
AVRStudio zu kompilieren.

Es kommt z.B diese Fehlermeldung:
../ow_slave.c:170: error: 'EIFR' undeclared (first use in this function)

Wie muss ich das Makefile umschreiben damit es auf WinAVR läuft?

Wie funzt das mit dem gen_eeprom

Danke und Gruß
Mario

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario schrieb:
> Hallo,
>
> wer kann mir helfen damit ich die Dateien auf einem WinXP mit WinAVR und
> AVRStudio zu kompiliere

Deine Frage ist eher eine fürs GCC-Forum.Bitte mach dort einen neuen 
Thread auf und beziehe dich dann auf diesen Code hier.
Sonst wird dieser Thread zugemüllt mit Dingen die hier keiner sucht und 
wissen möchte.

Autor: G. S. (varda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier mal die Dateien für den Tiny44

Flash:  ds2423.hex
eeprom: ds2423.eeprom

Fuse-Bytes: Highbyte = 0xDD, Lowbyte = 0XE2, Extended = 0xFF

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,

vielen Dank, hast du mir auch Hex-Files und EEProm für einen atmega8, 
den hab grad zur Hand und will eigentlich nur mal das ganze one-wire 
ausprobieren.

Danke und Gruß
Mario

Autor: G. S. (varda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario schrieb:
> Hallo Günter,
>
> vielen Dank, hast du mir auch Hex-Files und EEProm für einen atmega8,
> den hab grad zur Hand und will eigentlich nur mal das ganze one-wire
> ausprobieren.
>
> Danke und Gruß
> Mario

Hallo Mario,

nein für den atmega8 nicht. Pin-Interrupt geht so mit dem atmega8 nicht.
Da dürften weitere Änderungen im Source-Code notwendig werden.

Besser würde da ein atmega88 passen.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,

ich hab mal beim C geschaut, den Attiny44 und atmega88 gibts nicht im 
DIL.
Im File avr.h sind doch viele Typen definiert unter anderem auch der 
Atmega 8.

Gruß
Mario

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario schrieb:
> ich hab mal beim C geschaut, den Attiny44 und atmega88 gibts nicht im
> DIL.

Dann kauf woanders.

Selbstverfreilich gibt's beide ICs im DIL-Gehäuse.

Autor: G. S. (varda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mario schrieb:
> Hallo Günter,
>
> ich hab mal beim C geschaut, den Attiny44 und atmega88 gibts nicht im
> DIL.
> Im File avr.h sind doch viele Typen definiert unter anderem auch der
> Atmega 8.
>
> Gruß
> Mario

bei CSD gibt es den attiny44 für 2,39 Euro im DIL Gehäuse

Autor: G. S. (varda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe noch ein paar leere Platinen.

Bitte Boardmail an mich falls Interesse besteht. Gehen zum 
Selbstkostenpreis von 5 Euro + Versand raus.

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nun muss ich diesen Beitrag doch noch einmal rauskramen :-) Ich habe 
obigen Code von Axel auf meinem ATtiny85 erfolgreich zum Laufen gebracht 
und gebe derzeit (Dummy)-Messwerte an meinen Haupt-Controller aus.

Wenn ich nun zusätzlich den Timer1 starte und den entsprechenden 
Timer-Overflow aktiviere, so treten Aussetzer in der One-Wire 
Kommunikation auf. Je kleiner der Prescaler (also je öfter ein solcher 
Overflow) desto frequentierter diese Aussetzer. Das Problem tritt auch 
dann auf, wenn die Interruptroutine nur ein ";" enthält, also 
vernachläsigbar kurz sein sollte.

Mein derzeitiges Hauptprogramm besteht derzeit nur aus einer leeren 
Schleife, macht also nichts. Mit dem Timer1 möchte ich später eine 
kleine LED für eine gewisse Zeit nach einer erfolgreichen Übertragung 
leuchten lassen. Ich bin mit meinem Latein wirklich am Ende und habe 
keine Ahnung, wo ich den Fehler suchen soll... Für einen kleinen 
Denkanstoß wäre ich sehr dankbar :-)

Hier noch die Initialisierung:
int main(void)
{    
   TCCR0B |= (1<<CS00)|(1<<CS01);
   TCCR1  |= (1<<CS10)|(1<<CS11);
   GTCCR = 0;
  
   TIMSK  |= (1<<TOIE0)|(1<<TOIE1);
   GIMSK |= (1<<PCIE);

   DDRB |= (1<<PB3)|(1<<PB4);        // LED's

   status_global = IDLE;

//   USI_TWI_Master_Initialise();

   sei();

   while(1) {}
}

Vielen Dank schonmal !!
Gruß
Christoph

Autor: Anon Ymous (anonymous)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Christoph,

ich habe zufälligerweise genau das selbe letzte Woche gemacht. Bin aber 
leider noch nicht zum testen gekommen.

Wo sind deine Interrupt Routinen? Verwendest du ISR_NOBLOCK?

Autor: Matthias Urlichs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem: der Interrupt-Wrapper (also der Maschinencode vor- und 
nachher) ist ziemlich lang; er sicher so gut wie alle Register, egal ob 
sie gebraucht werden oder nicht.

Das bringt das Timing im Zweifelsfall zu sehr durcheinander. (1wire ist 
diesbezüglich leider ziemlich kritisch.)

Evtl. reicht es, gleich am Anfang der Routine Interrupts wieder zu 
ermöglichen (entsprechendes Bit setzen …), anstatt darauf zu warten, 
dass das der Maschinencode am Ende der ISR tut.

Wenn das auch nicht reicht, muss wohl ein wenig Assemblerprogrammierung 
her, zusammen mit anderen Compiler-Optionen (-mcallee-saves und 
Konsorten). Die darf man aber nur für die ISR verwenden, für sonst nix.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Urlichs schrieb:
> Das Problem: der Interrupt-Wrapper (also der Maschinencode vor- und
> nachher) ist ziemlich lang; er sicher so gut wie alle Register, egal ob
> sie gebraucht werden oder nicht.

Bei einer leeren ISR tut er das nicht.  Das von dir beschriebene
Verhalten tritt nur auf, wenn man eine Funktion aus der ISR heraus
aufruft (die der Compiler nicht inlinen kann), weil er dann davon
ausgehen muss, dass die Funktion alle ihr nach ABI zustehenden
Register auch modifizieren könnte.  Bei ISR_NOBLOCK wäre dieser
Vorgang übrigens bereits wieder unterbrechbar (muss man aber mit
Vorsicht genießen, bei manchen Interrupts kann das tödlich sein).

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zunächst mal vielen Dank für Eure Antworten / Tips! Die 
"ISR_NOBLOCK"-Option war mir bis dato völlig unbekannt... (man lernt 
eben nie aus!). Das Ganze scheint tatsächlich mein "Problem" zu lösen. 
Seit ich die timer1-OVF Routine auf diese Weise unterbrechbar gemacht 
habe, treten die Übermittlungs-Aussetzer nicht mehr aus.

Ich werde mich jetzt mal mit Hilfe der Forensuche näher in die 
Problematik einlesen, um meinen Horizont diesbezüglich zu erweitern. 
Wenn ich das richtig verstanden habe, dann kann ich durch die 
"ISR_NOBLOCK"-Option die Priorität bestimmter ISR-Routinen 
herabstufen...

Vielen Dank auf jeden Fall für Eure Hilfe, da wär ich wohl selber nicht 
drauf gekommen !!!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:

> Ich werde mich jetzt mal mit Hilfe der Forensuche näher in die
> Problematik einlesen, um meinen Horizont diesbezüglich zu erweitern.

Lies doch lieber gleich das Original. ;-)

http://www.nongnu.org/avr-libc/user-manual/group__...

(Könnte sich gut und gern sogar auf deiner Festplatte befinden.)

> Wenn ich das richtig verstanden habe, dann kann ich durch die
> "ISR_NOBLOCK"-Option die Priorität bestimmter ISR-Routinen
> herabstufen...

Nein, es gibt keine echten Interruptprioritäten beim Standard-AVR.
Stattdessen werden normalerweise beim Eintritt in die ISR die
Interrupts geblockt und mit RETI wieder freigegeben.  Die Option
ISR_NOBLOCK veranlasst (über ein attribute) den Compiler, ein
sei() in die Präambel der ISR einzubauen, sodass die Interrupts
sofort wieder (global!) freigeben werden.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo


Ein Beispiel eines SLAVES, allerdings in ASSEMBLER:

http://www.mikrocontroller.net/topic/241934



Bernhard

Autor: Tobias M. (mio)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
als alter 1wire-Fan habe ich ein bisschen gebastelt und mit etwas 
Ehrgeiz den DS18B20 auf den Attiny13 bekommen auch mit CRC.

Als Temperatur werden die Messungen des AD-Wandlers am Pin 7 (PB2) 
ausgegeben. Die Flags lassen sich zwar setzten aber haben keine Wirkung. 
EEProm wurde nicht mit integriert. Befehle für nur ein OW-Device (0xCC, 
ReadRom) auch nicht.

Als 1 Wire Port dient PB3, dass hat den Vorteil (gegenüber INT0/PB1), 
dass man nicht immer umstecken muss um zu Flaschen.

Mit meinen C-Programmen funktioniert alles bestens, aber die 1-Wire 
–Viewer haben manchmal Probleme:

OneWireViewer.exe (Das Java Teil)  erkennt den Chip kurz aber schmeißt 
ihn aus der Liste wenn man nicht schnell genug „Stoppt“ aber die 
Grafenanzeige funktioniert gut. Irgendwie schiebt das Programm beim 
Searchrom-Prozess zwischen den 0xF0 immer mal ein 0xC0 dazwischen. 
Dachte erst an einen Lesefehler aber mein Oszi zeigt das auch an.

iButten Viewer32 (iButton-TMEX (32-Bit) V3.22)  Erkennt alles richtig 
aber gibt keinen Befehl (0x44) zum Messen.

Naja nun mach ich mich dran den Counter DS2423 mal zu implementieren 
(ohne EEPROM), den gibt es nicht mehr und dann kommt noch der DS2413 
dran. Der ist ziemlich teuer (im Vergleich zum attiny13)
Aber zuletzt kann ich ja jetzt auch mein ganz eigenens Device erstellen 
mit unbegrenzten Möglichkeiten :-)

Für Anregungen bin ich dankbar. Habe noch nicht soviel Ahnung von den 
AVRs.

Folgende Optimierungen habe ich noch versucht eber recht schnell 
verworfen:
 - Die einzelnen Switch/Case Gruppen in Funktionen und der Sprunng über 
ein Array.
 - Der Zugriff auf die Felder owid und scratchpad über einen Zeiger 
direkt ((*ptr)=...) dadurch entsteht zwar gleicher Code, denn man 
zusammenfassen kann, aber der Code ist trotzdem größer.

Das beste wäre natürlich ASM aber da habe ich irgendiwe keine Lust :-)

Viele Grüße
Mio

Autor: Tobias M. (mio)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So da bin ich noch einmal,
Habe im Code noch ein paar Änderungen vorgenommen.

Das Problem mit OneWireViewer.exe bestand darin, dass zwei Reset-Signale 
nacheinander gesendet wurden. Das verträgt jetzt der neue Code.

Der iButten Viewer32 sendet nachweislich ein den Befehl 64h ich vermute 
mal zum Temperaturmessen. Habe ich einfach mit eingefügt und nun geht’s 
ohne Probleme.

Für den Counter muss wohl ein Attiny25 herhalten. CRC16 und die 80 Bit 
die zur Abfrage getauscht werden müssen... das geht einfach nicht in 1k.

Aber ein alternativer Counter der nicht Kompatibel zu Dallas ist geht 
bestimmt. Vielleicht mit CRC8 und nur 5 Byte bei der Abfrage.

Viele Grüße
Mio

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
habe gerade mal meinen alten DS9490R rausgekramt. Normalerweise habe ich 
jetzt alles auf LinkUSB von iButtonLink umgestellt. Die Master-impulse 
des DS9490 sind so kurz, dass am Eingang schon wieder ein High-Pegel 
anliegt. Ich arbeite gerade an einer Verbesserung.

Vieleicht lohnt sich dann doch eine Idee umzusetzen einfach die Abstände 
zwischen den Pegelwechseln zu messen und auszuwerten.

Viele Grüße
Mio

Autor: Tobias M. (mio)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

So nun habe ich noch ein bischen gebastelt und eine Variante 
programmiert die mit allen Verfügbaren 1-Wire Mastern und Programmen 
funktioniert. In meiner Testumgebung mit 12 1-Wire Geräten lief sie auch 
problemlos.

Das schöne an der Sache: Das Programm ist nur 982 Bytes groß.

Der 1-Wire Eingang ist wieder auf Pin6 PB1 Int0 verlget und wird nur bei 
fallender Flanke aktiviert. Ausnahme ist die steigende Flanke eines 
Resetimpulses.

Viele Grüße
Mio

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Versuch den Clock Prescaler im ATiny13 zu ändern (für den Fall dass 
die CKDIV8-Fuse gesetzt ist), ist in dieser Form wirkungslos:
CLKPR=0; //9.6Mhz
Dafür braucht's eine getimte Sequenz, also:
CLKPR=(1<<CLKPCE);
CLKPR=0; //9.6Mhz

Autor: Tobias M. (mio)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wer hätte es jemals gedacht, aber jetzt passt der DS2423 wirklich auf 
einen attiny13. Wobei man aber sagen muss, es ist ein DS2423 
kompatibler 32 Bit Zähler. Für meine Zwecke vollkommen ausreichend. 
Vielen Dank an MWS für den Hinweis.  Habe ich eingearbeitet.

Es funktioniert:

- Zählerabfrage mit crc16 Generation
- 32 Bit Zähler zählt bei LOW an PIN 2 (PB3)
- Befehl zur Zählerabfrage (0xA5)
- 1-Wire Bus Management  (ohne SKIP_ROM)

Es funktioniert nicht:
- NVRAM
- Adressierung
- Alle anderen Befehle außer  Bus Management und 0xA5

0xA5  + 2 Byte Adresse die nicht ausgewertet werden liefert:

X C0 C1 C2 C3 0 0 0 0 CRC0 CRC1

X: letztes (eigentlich adressiertes) Byte
C0  C1 C2 C3: 4 Byte Counter LSB first
0 0 0 0: 4 mal 0 nach Spezifikation
CRC0 CRC1: 2 Byte CRC LSB first

Weis jemand ob dass das SRAM des attiny13 nach Power On mit 0 gefüllt 
ist. Ich habe dazu nichts gefunden in der Dokumentation. Habe sie aber 
auch nicht ganz durchgelesen.  Bei meinen Versuchen war es jedenfalls 
immer so.  Da noch ein paar Bytes übrig waren, konnte ich die 
Initialisierung noch mit reinbringen.

Für alle weiteren Funktionen wie z.B. 2 Counter und so ist der attiny13 
nun wirklich zu klein :-)

Wichtig wenn in der 1-Wire Bibliothek die Adressierung mit angegeben 
werden kann:
Immer das Letzte Byte einer Page adressieren also z.B. 0x1ff.
Die Software die ich von Dallas/Maxim gesehen habe macht das 
automatisch.

Viele Grüße
Mio

Autor: Tobias M. (mio)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
nur noch der vollstänigkeit halber:

Der DS2423 mit 2 Zählern (PB3 und PB4).
Die Start Adresse in den Pages ist jetzt auch egal.
Sie kann jetzt also für Counterpage 14 0x1C0 bis 0x1df und
für die Counterpage 15 0x1E0 bis 0x1FF beragen. Es werden entsprechend 
mehr Bytes vor dem Zählerwert übertragen.

Zur Implementierung eines Speichers fehlt mir die Motivation.

Als nächstes werde ich wohl eher eigene 1-Wire Devices entwickeln.

Der attiny25 hat auch ein Thermomenter man könnte damit sicher einen 
DS18B20 real nachbauen. Aber die Genauigkeit von +/-0.5 K erreicht man 
sicher nur mit Eichung und bei einen Preis von 1 EUR für den DS18B20 
lohnt es sich auch nicht.

Ich denke, mit den vorgestellen Code hat jeder einen Baukasten um 
beliebige 1-Wire Geräte zu modellieren.

Viele Grüße
Mio

Autor: Johan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

sorry for breaking in with english here, but I'm interested in this 
discussion :)
I've experimented with the OW-slave code from smurfix 
(https://github.com/smurfix/owslave/) and the fork taliesin 
(https://github.com/taliesin/owslave/), with mixed results. I've been 
using an ATMega8 running at 8Mhz, and in a simple basic setup (DS2480B 
master, cables < 1m) it works. But as soon as I introduce longer cables 
(10-20m) it doesn't work very reliable, if at all.

My question is, have you had any success with longer cables in your 
experiments? Also, what clock frequency do you run it at?

Thank you
Johan

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dear John,
sorry for my late answer an my bad english...
Today I've checked my Attiny counter in my large 1-Wire network:
50m in one direction of LinkUSB 20m in other direction and 54 devices.
All with Cat5e and soldered contacts.
I'm suprised ... It works verry fine, without any errors.
I used a attiny25 with 8MHz and the above program.

Mio

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
ich habe jetzt eine Homepage zu meinen Projekten eingerichtet. Weitere 
Informationen und Details zum 1-Wire-Slave sind nach und nach unter 
http://www.tm3d.de/index.php/1-wire-device-mit-avr zu finden.

Mio

Autor: Anon Ymous (avion23)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

ich bekomme nach einiger Zeit die Fehlermeldung "bus short circuit". An 
dem bus ist ein und 5 DS18B20 Sensoren. Der 1wire-rs232-Wandler ist 
selbst gebastelt mit zwei n-fets als Pegelwandler, funktioniert aber 
stabil.
Als Hardware verwende ich einen attiny85 mit 8MHz internem Oszillator, 
Vcc ~= 4,5V. Der 1wire-bus ist dort direkt an den Port-pin 
angeschlossen.

Nach ein-ausschalten des attinys funktioniert es wieder.

Die Software ist von der Homepage, Datum 07.07.2012. Der simulierte 
1wire-Baustein ist ein DS2423. Geändert habe ich:
- Pin-change interrupt für PB3 und PB4 entfernt. Statt dessen läuft ein 
busy loop in der main, dem Unterbrechungen durch ISRs nicht ausmachen. 
Sonst sind keine Interrupts aktiv.
- Im Code selbst habe ich die Zeiten hochgeschraubt. Danach wurde das 
Verhalten etwas besser:
#define OWT_READLINE 4 //for fast master, 4 for slow master and long lines
#define OWT_LOWTIME 4 //for fast master, 4 for slow master and long lines

Mit digitemp ändert sich nichts an dem Verhalten. Ein "screen 
/dev/ttyUSB0 115200" als Funktionstest liefert kein echo zurück. Hier 
noch ein log von owfs:
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.18
flags=0x0000047b
max_readahead=0x00020000
   INIT: 7.18
   flags=0x00000011
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40
unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2051
getattr /
   CALL: ow_fstat.c:(22) path=/
   CALL: ow_parsename.c:(98) path=[/]
   CALL: ow_fstat.c:(39) ATTRIBUTES path=/
  DEBUG: ow_parsename.c:(62) /
   unique: 2, success, outsize: 120
unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2055
getattr /
   CALL: ow_fstat.c:(22) path=/
   CALL: ow_parsename.c:(98) path=[/]
   CALL: ow_fstat.c:(39) ATTRIBUTES path=/
  DEBUG: ow_parsename.c:(62) /
   unique: 3, success, outsize: 120
unique: 4, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 2055
   unique: 4, success, outsize: 32
unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80, pid: 2055
getdir[0]
   CALL: ow_parsename.c:(98) path=[/]
   CALL: owfs_callback.c:(177) GETDIR path=/
  DEBUG: ow_dir.c:(65) path=/
   CALL: ow_dir.c:(100) path=/
  DEBUG: ow_cache.c:(868) Looking for directory 00 00 00 00 00 00 00 00
  DEBUG: ow_cache.c:(881) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0xb6f87094 extension=0
  DEBUG: ow_cache.c:(910) Dir not found in cache
  DEBUG: ow_search.c:(32) Start of directory path=/ device=00 00 00 00 00 00 00 00
  DEBUG: ow_select.c:(66) Selecting a path (and device) path=/ SN=00 00 00 00 00 00 00 00 last path=00 00 00 00 00 00 00 00
  DEBUG: ow_select.c:(79) Continuing root branch
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
  DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
CONNECT: ow_reset.c:(36) 1-wire bus short circuit.
  DEBUG: ow_bus_data.c:(120) Splitting byte 0 of 1 = F0
  DEBUG: ow_tcp_read.c:(64) attempt 8 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_select.c:(66) Selecting a path (and device) path=/ SN=00 00 00 00 00 00 00 00 last path=00 00 00 00 00 00 00 00
  DEBUG: ow_select.c:(79) Continuing root branch
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
  DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
CONNECT: ow_reset.c:(36) 1-wire bus short circuit.
  DEBUG: ow_bus_data.c:(120) Splitting byte 0 of 1 = F0
  DEBUG: ow_tcp_read.c:(64) attempt 8 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_select.c:(66) Selecting a path (and device) path=/ SN=00 00 00 00 00 00 00 00 last path=00 00 00 00 00 00 00 00
  DEBUG: ow_select.c:(79) Continuing root branch
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
  DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1
CONNECT: ow_reset.c:(36) 1-wire bus short circuit.
  DEBUG: ow_bus_data.c:(120) Splitting byte 0 of 1 = F0
  DEBUG: ow_tcp_read.c:(64) attempt 8 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes

Kannst du mir weiterhelfen? Was kann ich tun, um das vernünftig zu 
debuggen?

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo avion23,

ich hatte das Problem an meinem Rechner auf Arbeit auch vor kurzem.
Versuch mal folgendes:
 setze mal OWT_MIN_RESET von 55 auf 45 oder so was.

Bitte schreibe mir mal ob es funktionier hat!


Viele Grüße
Mio

Autor: Anon Ymous (avion23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke,

ich habe jetzt folgendes eingestellt:
#define OWT_MIN_RESET 45
#define OWT_RESET_PRESENCE 4
#define OWT_PRESENCE 20
#define OWT_READLINE 3 //for fast master, 4 for slow master and long lines
#define OWT_LOWTIME 3 //for fast master, 4 for slow master and long lines
Im ersten Test funktioniert es (so wie bisher auch). Ich lasse das ein 
paar Tage laufen.

Autor: RoBue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias / Mio

die 1-Wire-Slaves interessieren mich sehr und ich finde es super, was 
hier in diesem Thread bisher versucht wird. Ich selbst programmiere z.Z. 
mehr mit BASCOM und versuche 1-Wire- und andere Sensoren über AVR 
anzusprechen und in PC-Systeme einzubinden.

(Schleichwerbung: http://home.arcor.de/RoBue/AVR-PC-Ctrl/index.html)

Nun konkret:
Hat schon jemand Erfahrung mit der ATtiny13-DS2423-Version?
Ich habe das hex-File auf einen ATtiny13 geflasht.
Der Baustein wird auch erkannt,
aber beim Auslesen erhalte ich lauter 0xFF,
egal, was ich sende.

Aufbau: Pin 1 mit 10k an VCC, Pin 2 ebenfalls (=Countereingang), Pin 6 
als 1-Wire, Pin 4 an GND, Pin 8 an VCC

Fuses: Spien, ckdiv8, sut0, cksel0

Hat vielleicht einer eine Idee, woran das liegen könnte?

RoBue

Autor: RoBue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

habe nun einige Mails mit Tobias gewechselt und habe keine 
ATtiny13-1-Wire-Emulation (DS18B20 und DS2423) an einem AVR mit 
BASCOM-Programm zum Laufen gebracht.

Interessanterweise wird die ID problemlos erkannt,
auch "Match Rom" funktioniert ohne Fehlermeldung,
aber dann kommen beim Auslesen immer nur 0xFFs.

Bei "echten" 1-Wire-Devices gibts überhaupt keine Probleme.
Die werden erkannt und ausgelesen, auch wenn man die Befehle einzeln 
über den Draht schickt.

Ein ähnliches Phänomen hatte ich bei echten 1-Wire-Devices,
wenn man sie ohne VCC an den Bus anschließt (weder echte 5V noch 
parasitär).
Dann wird die ID ebenfalls ausgelesen, aber keine Werte.

Okay - soweit der Stand der Dinge.

Meine Frage:
Haben andere BASCOM-User ähnliche Probleme mit den AVR-1-Wire-Slaves?
Kann jemand das vielleicht auch mal testen?
Falls Ihr ein Programm sucht, werdet Ihr sicher im bascom-forum 
(www.bascom-forum.de) fündig.
Da habe ich auch eines eingestellt.

Ich vermute einmal ganz freche
- wenn ich nicht völlig auf dem Schlauch stehe -,
dass das Problem am BASCOM liegt.

Liebe Grüße,
RoBue

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
für alle, die das Problem haben, das der 1-Wire-Bus nach einiger Zeit 
immer auf Low bleibt, bietet sich folgende Lösung an:

in der Funktion PIN_INT die Zeile:

if ((lwmode==OWW_WRITE_0)) {SET_LOW;}

ersezen durch

if ((lwmode==OWW_WRITE_0)) {SET_LOW;lwmode=OWW_NO_WRITE;}


die restlichen lwmode=OWW_NO_WRITE; in dieser Funktion können dann 
entfallen.

Vor allem bei dem 1-Wire Master DS9490 kam es zu diesen Problem.

Ich werde diese Änderung nach abschließenden Tests auch in kürze auf 
meiner Homepage (http://www.tm3d.de/index.php/1-wire-device-mit-avr) 
einpflegen.

Mio

Autor: Anon Ymous (avion23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

die Änderungen funktionieren seit ungefähr einem Tag. Normalerweise wäre 
der 1wire slave jetzt schon abgestürzt. Meine PIN_INT-Routine sieht 
jetzt so aus:
PIN_INT
{
  uint8_t lwmode = wmode; //let this variables in registers
  uint8_t lmode = mode;
  if ((lwmode == OWW_WRITE_0)) {
    SET_LOW;
    lwmode = OWW_NO_WRITE;    // Tip from Tobias M. (mio) @25.07.2012
  } //if necessary set 0-Bit
  DIS_OWINT; //disable interrupt, only in OWM_SLEEP mode it is active
  switch (lmode) {
  case OWM_SLEEP:
    TCNT_REG = ~(OWT_MIN_RESET);
    EN_OWINT
    ; //other edges ?
    break;
    //start of reading with falling edge from master, reading closed in timer isr
  case OWM_MATCH_ROM: //falling edge wait for receive
  case OWM_GET_ADRESS:
  case OWM_READ_COMMAND:
    TCNT_REG = ~(OWT_READLINE); //wait a time for reading
    break;
  case OWM_SEARCH_ROM: //Search algorithm waiting for receive or send
    if (srcount < 2) { //this means bit or complement is writing,
      TCNT_REG = ~(OWT_LOWTIME);
    } else
      TCNT_REG = ~(OWT_READLINE); //init for read answer of master
    break;
#ifdef _ONE_DEVICE_CMDS_
    case OWM_READ_ROM:
#endif
  case OWM_READ_MEMORY_COUNTER: //a bit is sending
    TCNT_REG = ~(OWT_LOWTIME);
    break;
  case OWM_CHK_RESET: //rising edge of reset pulse
    SET_FALLING
    ;
    TCNT_REG = ~(OWT_RESET_PRESENCE); //waiting for sending presence pulse
    lmode = OWM_RESET;
    break;
  }
  EN_TIMER;
  mode = lmode;
  wmode = lwmode;
}
Danke!

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

So nun ist es soweit. Ich habe ein völlig neues 1-Wire Gerät entwickelt. 
Es ist ein Barometer. Die genaue Beschreibung, Schaltung, Code usw. gibt 
es auf

http://www.tm3d.de/index.php/1-wire-barometer

Viel Spaß beim Stöbern.

Mio

Autor: Anon Ymous (avion23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anon Ymous schrieb:
> die Änderungen funktionieren seit ungefähr einem Tag.

Und funktionieren bis heute. Ich bin sehr zufrieden :)

Autor: RoBue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
wenn wir hier schon beim Sammeln von 1-Wire-Slaves sind,
möchte ich (nochmal) auf folgende Seite hinweisen:

Beitrag "Re: 1-WIRE SLAVE DEVICE BEISPIELE AVR ASSEMBLER ATmega8"

Dort kann man nun einen Slave für SHT11 mit LCD downloaden.

Habs auch noch im Bascom-Forum eingestellt:

http://bascom-forum.de/showthread.php?4481-Emulati...

Liebe Grüße,
RoBue

Autor: Markus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
leider muss ich diesen alten Beitrag wieder hoch holen.
Ich lese seit einiger zeit diesen Artikel und habe
nun mich auch mal ran gemacht einen 1-Wire Slave zu
Programmieren.

Nun habe ich folgendes Problem. Ich habe es auf einen Atmega16 mit 8Mhz 
mit Erfolg ausprobiert. Nun habe ich ein Atmega 644 Board auf dem der 
1-Wire fest auf einen Pin Change Pin verdrahtet ist.
Das Board läuft mit 20Mhz. Die Software ist abgespeckt, aber Ich kann 
den Slave über die Suchfunktion nur mit dem Atmega16 finden. Beim 644 
hängt der Master sich in der Suchfunktion auf.

Zum Testen habe ich zwei DS18S20 die werden immer gefunden. Wenn der 
AT16 dran ist wird dieser auch gefunden. Nur beim AT644 werden nur die 
DS18S20 gefunden und danach hängt er in der Suchfunktion.

Ich denke das ich in der ISR vom PinChange das Problem ist.
Dort habe ich verschiedene Routinen zum aus werten der Flanken 
verwendet. Allerdings ohne Erfolg.

Nun Hoffe ich das einer von euch das Problem eingrenzen kann.

Schöne Weihnachten

Autor: Tobias M. (mio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,
ich kann jetzt nicht direkt einen Fehler erkennen. Du musst allerdings 
bedenken, das die Interruptroutine bis zu EN_TIMER jetzt ein bischen 
länger dauert, versuche es mal mit kleineren Werten für
#define OWT_MIN_RESET 113    //360
#define OWT_RESET_PRESENCE 10  //32
#define OWT_PRESENCE 50    //160
#define OWT_READLINE 8 //for fast master, 10 for slow master and long lines 24-32
#define OWT_LOWTIME 8 //for fast master, 10 for slow master and long lines 24-32

Schöne Weihnachten

Autor: Hamid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Tobias Muller
thanks for your code's 1wire.
I test it over tiny13 and very good work.I change micro to mega8 and 
mega32, after start we have 1/2 good send & recive data after than I 
have many fault recive data.
after change this code from you, I have not any code & detect.please 
help me.

thanks

Beitrag #3816222 wurde von einem Moderator gelöscht.
Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich habe jetzt Tobias' Code mit meinem integriert. Ein DS2423-Verschnitt 
passt gerade so in 2k rein. CRC-Berechnung oder ähnlicher aufwändiger 
Kram passieren außerhalb des Interrupts, was fürs Implementieren 
komplizierterer Ideen mehr Spaß macht. Die 1wire-Adresse wird (optional) 
aus dem EEPROM gelesen.

Getestet mit einem atmega88 bei 8Mhz; ich sehe keinen Grund, wieso ein 
passender attiny nicht auch tun sollte.

https://github.com/smurfix/owslave

Was ich damit vorhabe: unter Anderem Lichtschalter, Fensterkontakte und 
Co. Mit Conditional Search kann man an einem 1wire-Bus 100 Taster 
anschließen, ohne sich wegen der Latenzzeit Gedanken machen zu müssen.

Und: Semi-autonomes Heizungsthermostat. Thermometer via I2C anschließen, 
via 1wire die Zieltemperatur setzen, einen thermischen 24V-Stellantrieb 
an den PWM-Ausgang des atmega anschließen, PID-Regelalgorithmus 
dahinter, fertig.

Nicht zuletzt wäre ein Firmware-Update über 1wire sehr angenehm … aber 
das geht dann nicht mehr mit dem attiny. ;-)

Autor: Matthias Urlichs (smurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Code findet sich jetzt auf https://github.com/m-o-a-t
OWFS-Unterstützung ist noch sehr rudimentär, wird die nächsten Tage aber 
besser.

Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal danke an Tobias für den tollen Code :-).

Ich hab den ds18b20-Beispielcode genommen und daraus mit einem attiny25 
ein Gateway für DHT22 Sensoren gemacht. Die Datenleitung vom DHT22 muss 
mit dem PIN B4 verbunden werden, der wird nach den START_CONVERSION 
Befehl in das Scratchpad ausgelesen, einfach die 5 Bytes der Reihe nach 
wie sie auch vom DHT22 kommen.
Zusätzlich wird auch noch der ADC3 an pin PB3 ausgelesen und in die 
Bytes 6 und 7 geschrieben.

Läuft bei mir bisher ziemlich zuverlässig.

Viele Grüße,

Martin

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.