Delay mit Timer

[lucas (Gast)]

Guten Tag,

Ich habe eine Schaltung 2 Kanal 230V Phasenanschnitt Dimmer die auch 
wunderbar Funktioniert.

Nun sollte noch ein DS1820 dazu kommen.
Für die Delay funktionen wollte ich einen Timer nehmen weil die Delay 
aus der Lib nicht Funktionkeren.

Mein Problem ist wie konfiguriere ich den Timer für ms und ųs
mien Takt ist 16Mhz.

Könnte mir jemand weiterhelfen.

mfg

[Jakob (Gast)]

Hast du schon mal bedacht, dass es zig-1000 verschiedene
Schaltkreise gibt, die mit 16 MHz getaktet werden können?

Handelt es sich um einen µC?

Hat der einen Aufdruck auf dem Gehäuse?

[lucas (Gast)]

Ist ein Atmega8-16

[Mein grosses V. (vorbild)]

lucas schrieb:
> Mein Problem ist wie konfiguriere ich den Timer für ms und ųs

Das ist nicht schwierig.

[Dieter F. (Gast)]

lucas schrieb:
> Für die Delay funktionen wollte ich einen Timer nehmen weil die Delay
> aus der Lib nicht Funktionkeren.

Und wie genau äußert sich das? Kannst Du mal Dein Programm und die 
Einstellungen der Fuses zeigen? Verwendest Du einen Quarz - und hast Du 
den auch korrekt mit Fuses eingestellt? Gibst Du F_CPU korrekt an? Gibt 
der Compiler Warnungen u/o Fehler aus? Wenn ja, welche?

Ich habe es noch nicht erlebt, dass die delay-Funktion nicht korrekt 
ist, außer man hat F_CPU nicht oder nicht korrekt angegeben (bzw. die 
Fuses nicht entsprechend eingestellt).

[Timmo H. (masterfx)]

AVR-GCC-Tutorial/Die Timer und Zähler des AVR

[Dieter F. (Gast)]

Mein grosses V. schrieb:
> Das ist nicht schwierig.

Da sind aber alle froh. Dann kannst Du es ja sicher auch erklären. Warum 
machst Du es dann nicht?

[lucas (Gast)]

Ich wollte gerne den Teiner2 nehmen im CTC modus.

16000000:1024 = 15.625Khz

Wie muss der Timer2 konfiguriert werden

und wie muss den aufrufen im Programm.

Beim Ds1820 muss ich ja bis zu 480ųs warten.

[Mein grosses V. (vorbild)]

Dieter F. schrieb:
> Da sind aber alle froh.

Deswegen hatte ich das auch geschrieben.

[Dieter F. (Gast)]

Mein grosses V. schrieb:
> Deswegen hatte ich das auch geschrieben.

Brav - kriegst ein Wurschti :-)

[Dieter F. (Gast)]

lucas schrieb:
> ie muss der Timer2 konfiguriert werden
>
> und wie muss den aufrufen im Programm.

Timmo H. schrieb:
> AVR-GCC-Tutorial/Die Timer und Zähler des AVR

[Mein grosses V. (vorbild)]

Dieter F. schrieb:
> Brav - kriegst ein Wurschti
Was soll das denn sein?

Hast du irgendwelche Probleme? Immerhin habe ich ihm mit meinem Beitrag 
ein wenig Mut zugesprochen. Das ist schließlich auch etwas wert. Da kann 
er sich das Timer-Tutorial vornehmen und voller Elan die Sache angehen. 
Du dagegen quakst hier nur rum. Naja, du kommst ja auch aus Quakenbusch.

[Dieter F. (Gast)]

Mein grosses V. schrieb:
> Hast du irgendwelche Probleme? Immerhin habe ich ihm mit meinem Beitrag
> ein wenig Mut zugesprochen. Das ist schließlich auch etwas wert. Da kann
> er sich das Timer-Tutorial vornehmen und voller Elan die Sache angehen.
> Du dagegen quakst hier nur rum. Naja, du kommst ja auch aus Quakenbusch.

Ich habe keine Probleme.

Mein grosses V. schrieb:
> Quakenbusch.

Lerne erstmal Lesen.

Mein grosses V. schrieb:
> Immerhin habe ich ihm mit meinem Beitrag
> ein wenig Mut zugesprochen.

Schön, dass zumindest Du das so siehst :-)

Ich vermisse jedoch weiterhin Deine fachkundige Erklärung.

[Mein grosses V. (vorbild)]

Dieter F. schrieb:
> Lerne erstmal Lesen.

Das kann ich sehr gut. Aber Quakenbusch schreibt man mit "sch". Lauf mal 
zum Ortsschild. Dann wirst du es sehen.

Dieter F. schrieb:
> Ich vermisse jedoch weiterhin Deine fachkundige Erklärung.

Ich vermisse den einen Grund, warum mir das nicht vollkommen egal sein 
sollte, ob du etwas vermisst.

[Karl M: (Gast)]

lucas Timer sind eher für länge Laufzeiten gedacht.
Deine µs verzögerst Du schon mit delay direkt im Codeabschnitt.

[Dieter F. (Gast)]

Mein grosses V. schrieb:
> Das kann ich sehr gut. Aber Quakenbusch schreibt man mit "sch". Lauf mal
> zum Ortsschild. Dann wirst du es sehen.

Ich weiß nicht, welches Ortsschild Du meinst. Aber wenn Du meinst ... 
dann meinst Du ja wohl nicht mich.

Mein grosses V. schrieb:
> Ich vermisse den einen Grund, warum mir das nicht vollkommen egal sein
> sollte, ob du etwas vermisst.

Dummlaller fällt mir da gerade so ein - ist aber nicht auf Dich bezogen 
:-) rein historisch.

[Dieter F. (Gast)]

Karl M: schrieb:
> eine µs verzögerst Du schon mit delay direkt im Codeabschnitt.

Aber nicht richtig - und da ist scheinbar das Problem.

Aber ohne Code und Fuses tappen wir da alle (außer denen mit 
auswertbarer Kristallkugel) im Duknel.

[lucas (Gast)]

Karl M: schrieb:
> lucas Timer sind eher für länge Laufzeiten gedacht.
> Deine µs verzögerst Du schon mit delay direkt im Codeabschnitt.

Das mit den internen Delayms und Delayûs funktioniert ja nich

[Dieter F. (Gast)]

lucas schrieb:
> Das mit den internen Delayms und Delayûs funktioniert ja nich

O.K. - "Mein grosses Vorbild (vorbild)"

wird Dir da sicher helfen bzw. Dich sehr ermuntern. Kann es sein, dass 
"lucas" = "Mein grosses Vorbild (vorbild)" ist ? Interessante Hypothese 
...

[Mein grosses V. (vorbild)]

Dieter F. schrieb:
> Ich weiß nicht, welches Ortsschild Du meinst.
Nun tu mal nicht so. Du weißt genau, was gemeint ist.

Dieter F. schrieb:
> wird Dir da sicher helfen bzw. Dich sehr ermuntern.
Sag mal, bist du hier der Dirigent? Teilst du hier ein, wer was zu tun 
hat? Mach das doch selber.

Dieter F. schrieb:
> Interessante Hypothese
Nein, das ist eine uninteressante Halluzination.

[W.A. (Gast)]

lucas schrieb:
> Wie muss der Timer2 konfiguriert werden
>
> und wie muss den aufrufen im Programm.

Den ATmega8 gibt es nun schon sooh lange. Und das Internet auch. Meinst 
du wirklich, dass du der erste bist, der den Timer2 als Taktgeber 
benutzen möchte? Notfalls muss man sich mal ein paar ruhige Minuten mit 
dem Datenblatt gönnen.

Vielleicht solltest du dich erstmal ein bisschen in Internetrecherche 
üben.

[Karl M. (Gast)]

lucas schrieb:
> Karl M: schrieb:
>> lucas Timer sind eher für länge Laufzeiten gedacht.
>> Deine µs verzögerst Du schon mit delay direkt im Codeabschnitt.
>
> Das mit den internen Delayms und Delayûs funktioniert ja nich

Nun bei mir schon, und bei vielen anderen auch.

Das soll somit auch nur ein Hinweis sein, da wir deinen Code und die 
Umgebung nicht kennen, ist es sehr wahrscheinlich dort zu suchen.

Frage ich bitte mal, wie das andere Programmierer machen, um das 1 Wire 
Protokoll zu bedienen.

Ich habe zum bsp. in meiner Entwicklungsumgebung die Delay Macros und 
den dadurch erzeugten Code - und somit die Verzögerung - verifiziert und 
ein zwei Fehler beseitig.

[Karl M. (Gast)]

Hier ist noch etwas Code verlinkt, da lohnt es ich
die Dateien onewire.[ch] an zusehen.

Wie man verwendet _delay_us() ?

[Karl M. (Gast)]

Nachtrag - der Link: 
http://siwawi.bauing.uni-kl.de/avr_projects/tempsensor/

[lucas (Gast)]

Die Delay Routinen die in der Lib vom Gcc  mit dabei sind.
Das haut bei mir irgendwie nicht hin.

das mit dem Timer2 als delay zu Konfigurieren das bekomme ich nicht zum 
laufen.

[Timmo H. (masterfx)]

lucas schrieb:
> Die Delay Routinen die in der Lib vom Gcc  mit dabei sind.
> Das haut bei mir irgendwie nicht hin.
Dann benutzt du sie entweder falsch (z.B. keine Konstante übergeben), du 
hast F_CPU falsch oder gar nicht definiert oder du hast die 
Kompiler-Optimierungen deaktiviert.

lucas schrieb:
> das mit dem Timer2 als delay zu Konfigurieren das bekomme ich nicht zum
> laufen.
Dann zeig doch mal deinen Ansatz.
Es gibt mehrere Möglichkeiten das mit Timer zu realisieren. Du kannst 
entweder den Timer frei laufen lassen (mit der entsprechenden Tickrate) 
und dann in einer While-Schleife warten bis die Zeit abgelaufen ist.

start_wert = TCNT2;
while (TCNT2 - start_wert < 100);

....

Oder du lässt in der ISR bei jedem Überlauf eine volatile Variable 
hochzählen auf die du dann in deiner Routine wartest bis sie einen 
entsprechenden Wert erreicht, siehe 
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR#Overflow_Interrupt

[Dieter F. (Gast)]

lucas schrieb:
> Die Delay Routinen die in der Lib vom Gcc  mit dabei sind.
> Das haut bei mir irgendwie nicht hin.

Dieter F. schrieb:
> Und wie genau äußert sich das? Kannst Du mal Dein Programm und die
> Einstellungen der Fuses zeigen? Verwendest Du einen Quarz - und hast Du
> den auch korrekt mit Fuses eingestellt? Gibst Du F_CPU korrekt an? Gibt
> der Compiler Warnungen u/o Fehler aus? Wenn ja, welche?
>
> Ich habe es noch nicht erlebt, dass die delay-Funktion nicht korrekt
> ist, außer man hat F_CPU nicht oder nicht korrekt angegeben (bzw. die
> Fuses nicht entsprechend eingestellt).

Ohne vorgenannte Details zu kennen kann Dir nicht geholfen werden.

[Lucas (Gast)]

F_CPU = 16000000
160000000/1024 = 15625

So hier is erstma mein Konstruckt.

ich brauch ja nioch eine Funktion die ich Aufrufen muss um zu warten, 
wie geht das mit dem Timer das habe ich gefragt.
Und da komm ich nich weiter.


[c]
//F_CPU 16000000
  //8 Bit Timer2 Einstellungen
  TCCR2A = (1 << WGM21);                //CTC Modus
  TCCR2B |= (1<<CS22)|(1 << CS21)|(1 << CS20); //Prescaler 1024

  OCR2A = 0; //???
  TIMSK2 |= (1<<OCIE2A);                //Enable Compare Interrupt

  sei(); Interrupts freigebn



ISR(TIMER2_COMP_vect) //Interrut Timer2
{


}

[Karl M. (Gast)]

Guten Tag,

Lucas schrieb:
> F_CPU = 16000000
> 160000000/1024 = 15625

Na da staunt der Mathematiker nicht schlecht ein Atmel AVR mit 160MHz !

Mit einem Vorteiler von 1024 kommst Du auf eine Auflösung von 15.625Hz, 
das ist zu wenig.
Beispiel: Wählt man eine Schrittweite von 10µs, so folgt:

10µs = 10*10⁻⁶s ==> f = 1/s = 100*10⁶Hz = 100.000Hz = 100kHz

In dem "hingespukten" Codeauszug sieht man, dass Du keine Ahnung von C 
und von den AVR hast.
Auch fehlt Dir die Vorstellung, wie man mit dem Timer2 ein genaues 
Timing für einen DS1820 umsetzt. Zumindest geht das per Interrupt nicht 
!

Bitte nicht vergessen, auch eine Funktionsaufruf benötigt Zeit und 
dieses Zeitverhalten musst Du auf den Takt genau bestimmen können und 
der muss Konstant sein. Also darf sich nicht durch Compiler Schalter 
ändern.

Ich gehe mal davon aus, dass Du kein AVR Assembler verstehst.

Und wundere mich erneut, warum keine der vielen veröffentlichen Module 
für den OneWire Modus eines DS1820 verwendet wird.

[Falk B. (falk)]

@  lucas (Gast)


>Nun sollte noch ein DS1820 dazu kommen.
>Für die Delay funktionen wollte ich einen Timer nehmen weil die Delay
>aus der Lib nicht Funktionkeren.

Unsinn. Mach es einfach richtig. Für OneWire nimmt man sinnvollerweise 
KEINEN Timer, weil die Zeiten eh nicht sehr lang sind, die man für die 
Bits braucht. Während dieser Zeit muss man die Interrupts sperren, 
danach wieder freigeben. Das bisschen Jitter im Phasenanschnitt sollte 
nicht weh tun. Wenn man ihn per Input Capture/Output COmpare macht 
sowieso nicht.

[lucas (Gast)]

Der eine sagt mann sollte bei dem _delay_us(500); keine grossen werte 
nehmen.

was stimmt denn nun?

zwischen Conwert_t und reset muss ich ja 780ms warten.

[Karl M. (Gast)]

lucas schrieb:
> zwischen Conwert_t und reset muss ich ja 780ms warten.

Nö, da kann man fröhlich weiter Rechnen und lässt nebenbei eine 1ms 
"Uhr" mitlaufen, und generiert nach 800ms einen Event und liest man dann 
das Ergebnis aus.

[lucas (Gast)]

kann es auch daran liegen das ich vom Pin des Atmega ca.1,5m Kabel zum 
DS1820 habe und erst am D1820 den Pullup.

Oder muss der Pullup so nah wie möglich am Atmegs Pin sein.

[Timmo H. (masterfx)]

Bei 1.5m sollte das ziemlich egal sein. Ich tippe auf code oder 
Schaltunhsfehler. Wie groß ist der pullup? Denkst du auch daran das DDR 
umzuschalten? Dein Code scheint ja geheim zu sein..

[Peter II (Gast)]

lucas schrieb:
> Der eine sagt mann sollte bei dem _delay_us(500); keine grossen werte
> nehmen.
>
> was stimmt denn nun?

das stimmte früher einmal. Jetzt darf man das, es wird nur etwas 
ungenauer bei großen werden.

[lucas (Gast)]

Hallo,
Also ich bekomme überhaupt keine Temperratur angezeigt.
Mehrere Sensoren hab ich probiert und es wird immer nur 00,0 angezeigt.
Anbei mal mein Projekt.

[Falk B. (falk)]

Du macht auch alles reichlich kompliziert. Lass en Kram mit dem 
RX-Packet erstmal sein und lies ganz normal in main() die Temperatur und 
lass sie anzeigen. Damit kann man deutlich leichter den Fehler finden. 
Ausserdem, das soll der Unsinn mit den selbstgestrickten delay_ms() uind 
delay_us()? Das funktioniert zumindest bei den delay_us() nicht 
wirklich, denn die Schleife kostet nennenswert Zeit. Nutze die Funktion 
_delay_ms() und _delay_us() aus der libc mit konstanten Argumenten, dann 
passt das. So wie es auch der Verfasser der Lib gemacht hat.

[Karl M. (Gast)]

Hallo,
mir ist immer noch unklar welchen der DS18X20 du verwendest.
Kasst Du das bitte noch aufklären ?

[Dieter F. (Gast)]

Falk B. schrieb:
> delay_us()

Wird beides nicht genutzt - er nutzt die _delay... aus dem "Standard".

Was fehlt sind immer noch die Angaben zu den Fuses. Im Makefile hat er 
zwar 16 MHz bei F_CPU definiert, aber ob das auch so ist?

Auch gibt es keine Aussagen zu Compiler-Warnungen - wäre ggf. auch 
hilfreich.

[lucas (Gast)]

Ich nutze den DS18s20
Der Controller läuft mit 16Mhz das stimmt, die Fuses stimmen.

Aber angezeigt bekomm ich nur 00,0 nicht mal die 85 kommen.

auch wenn ich den Sensor abziehe bleibt es bei der 00,0

[Holger L. (max5v)]

Ich würde dir empfehlen erstmal ein neues Projekt anzulegen in dem nur 
der Temperatursensor ausgelesen wird wodurch ein Hardwarefehler 
ausgeschlossen werden kann.
Den restlichen Code würde ich ehrlich gesagt verwerfen und noch einmal 
neu schreiben, da es darin mehr als einen Schnitzer wie die ISR des 
Timer0 gibt.
Das hört sich im ersten Moment zwar dramatisch an, ist am Ende 
allerdings meißt Zielführender als sich in dem Codegewusel einen Wolf zu 
suchen.

Viel Erfolg !

[lucas (Gast)]

Was ist denn an der Timer0 isr falsch?

[Holger L. (max5v)]

Normalerweise führt man in einer ISR keine Berechnungen durch.
Ich habe es nicht ausgerechnet aber die 50 - 60 Zeilen mit Addition, 
Subtraktion, Multiplikation etc. sehen zu viel aus.
Man kann einfach ein Flag setzen dieses in der Mainloop auswerten und 
dementsprechend darauf reagieren.

[lucas (Gast)]

Holger L. schrieb:
> Normalerweise führt man in einer ISR keine Berechnungen durch.
> Ich habe es nicht ausgerechnet aber die 50 - 60 Zeilen mit Addition,
> Subtraktion, Multiplikation etc. sehen zu viel aus.
> Man kann einfach ein Flag setzen dieses in der Mainloop auswerten und
> dementsprechend darauf reagieren.

gut werde ich ändern

ist denn die Routine für den DS1820 richtig?

[Falk B. (falk)]

@ lucas (Gast)

>ist denn die Routine für den DS1820 richtig?

Das solltest du herausfinden.
In deiner ds1820_read_temp(uint8_t used_pin) sind mehrere Fehler drin.

      while (ds1820_re_byte(used_pin)==0xFF && j<1000){      //4. wait until conversion is finished 
      _delay_us(1);
      j++;
    }

hier ist eher ein _delay_ms(1); angebraucht, denn du musst bis zu 750ms 
(Millisekunden) warten, eher die Umwandlung fertig ist. Nicht 
Mikrosekunden. Kleiner, aber entscheidender Unterschied! Ausserdem ist 
der Vergleich falsch! Eher so

while (ds1820_re_byte(used_pin) != 0xFF && j<1000) { //4. wait until conversion is finished
  _delay_ms(1);
   j++;
}

Deine anschließende Datenverwurstung ist sehr komisch. Kleiner Tipp. Die 
Zahl in den Registern ist schon vorzeichenbehaftet, die muss man nur 
passend zusammenfügen. Der Rest ist Festkommaarithmetik.

int16_t temp;

temp = (int16_t)scratchpad[1]<<8 | scratchpad[0];
temp = temp*5;   // Umrechung 0.5C/LSB auf 0.1C/LSB

[Falk B. (falk)]

Beitrag "Onewire + DS18x20 Library"

[lucas (Gast)]

Hallo,
So anbei nochmal ein neuer Versuch, aber leider bekomme ich nur 127,5 
angezeigt.

  float Temperatur;
  int vorkomma;
  int nachkomma; 

    Temperatur = Temperatur_Messung();
    if ( signbit(Temperatur) ) {
      Temperatur = fabs(Temperatur);
      rf12_txdata_TEST("-",1);
    } 
    vorkomma = (int) Temperatur;
    nachkomma = (int)((Temperatur - vorkomma) * 10);
     sprintf(txbuf,"%d.%d ",vorkomma , nachkomma); //Convert temp. puffer oben to string
  
  Len = strlen (txbuf);
  rf12_txdata_TEST(txbuf,Len);

[Falk B. (falk)]

@ lucas (Gast)

>So anbei nochmal ein neuer Versuch, aber leider bekomme ich nur 127,5
>angezeigt.

Hast du eigentlich ANSATZWEISE verstanden, was ich dir sagen wollte?

Wenn immer 127,5 rauskommt, klingt das danach, als ob deine 
Eingangsbytes immer 0xFF wären. Lass dir mal die Scratchpaddaten als 
HEX-Zahlen ausgeben. Dort geht die Fehlersuche weiter.

Beitrag "Re: DS18s20 Temperatur über 20Grad"

[lucas (Gast)]

Falk B. schrieb:
> @ lucas (Gast)
>

>
> Hast du eigentlich ANSATZWEISE verstanden, was ich dir sagen wollte?
>
> Wenn immer 127,5 rauskommt, klingt das danach, als ob deine
> Eingangsbytes immer 0xFF wären. Lass dir mal die Scratchpaddaten als
> HEX-Zahlen ausgeben. Dort geht die Fehlersuche weiter.
>
> Beitrag "Re: DS18s20 Temperatur über 20Grad"

Ja das habe ich schon alles Versucht entweder die Temperratur geht bis 
20,2Grad oder es wird nur 127 Angezeigt.
Hat denn vielleicht einer ein einfaches Beispiel für ein Atmega8 mit 
16MHz

[Falk B. (falk)]

@ lucas (Gast)

>> Wenn immer 127,5 rauskommt, klingt das danach, als ob deine
>> Eingangsbytes immer 0xFF wären. Lass dir mal die Scratchpaddaten als
>> HEX-Zahlen ausgeben. Dort geht die Fehlersuche weiter.

>Ja das habe ich schon alles Versucht entweder die Temperratur geht bis
>20,2Grad oder es wird nur 127 Angezeigt.

Nein, du hast nicht alles versucht! Lass dir ALLE Scratchpaddaten direkt 
anzeigen!

>Hat denn vielleicht einer ein einfaches Beispiel für ein Atmega8 mit
>16MHz

Beitrag "Re: Delay mit Timer"

[lucas (Gast)]

Die ident kann ich ja richtig auslesen vom sensor.

Ich hatte gefragt ob die Routine für das Auslesen vom sensor richtig 
ist.

[Falk B. (falk)]

@ lucas (Gast)


>Die ident kann ich ja richtig auslesen vom sensor.

Schön, aber das reicht nicht. Lies das Scratchpad KOMPLETT!! Denn das 
ist der nächste logische Schritt einer systematischen Fehlersuche!

Danach kommt die Umrechung von Scratchpad in Temperatur dran!

>Ich hatte gefragt ob die Routine für das Auslesen vom sensor richtig
>ist.

Die hier?

Beitrag "Re: Delay mit Timer"

Ja, das sieht OK aus, aber es kann trotzdem irgendwas klemmen. GIB DIE 
SCRATCHPAD DATEN AUS!

Laufen in deinem Programm noch Interrupts? Dann ist dein OneWire Zugriff 
unsicher! Das Lesen- und Schreiben einzelner Bits muss mit 
Interruptsperre passieren, sonst ist das Timing nicht gesichert!

[lucas (Gast)]

So bitte,

aa,04b,46,ff,ff,c,10,87

[lucas (Gast)]

Falk B. schrieb:

>>Ich hatte gefragt ob die Routine für das Auslesen vom sensor richtig
>>ist.
>
> Die hier?
>
> Beitrag "Re: Delay mit Timer"
Die hier verwende ich im Anhang

[Falk B. (falk)]

@ lucas (Gast)

>aa,04b,46,ff,ff,c,10,87

Was ist das? Die Scratchpad Daten? Beginnend mit Byte 0?
Was ist 04b? 0x4B? Oder 0x04 und das b ein Tippfehler?

Also wenn die Werte stimmen ist die Temperatur 4baa = 19370 = 9685 °C.
Da stimmt was nicht. ;-) Beim DS18S20 ist das gesamt MSB (Byte 1 im 
Scratchpad) nur Vorzeichen, d.h. es ist entweder 0 oder 0xFF. Was 
anderes geht nicht. Also ist ein Fehler im Auslesen deines Scratchpads.

[Falk B. (falk)]

@ lucas (Gast)

>Die hier verwende ich im Anhang

Siehst du bei den Dutzenden Versionen und Änderungen und 
Auskommentierungen eigentlich noch durch?

[Falk B. (falk)]

@ lucas (Gast)

>aa,04b,46,ff,ff,c,10,87

Wenn ich das mal kreativ als 0xaa, 0x00, 0x4b deute, dann könnte es 
passen. Dann stehen aber die Resetwerte 0xAA und 0x00 im Scratchpad. 
D.h. du hast keine neue Temperaturmessung gestartet bzw. der IC hat 
nicht darauf reagiert.

[Falk B. (falk)]

Diese Daten sind korrekt, die CRC passt.

0xaa, 0x00, 0x4b, 0x46, 0xff, 0xff, 0x0c, 0x10, 0x87

Das hätte man aber auch gleich leserlich schreiben können. . . .

[lucas (Gast)]

aber warum bekomm ich als Anzeige immer 127

[Falk B. (falk)]

Weil entweder deine Umrechung nicht stimmt (welche von den vielen 
Versionen ist es denn?) oder die Anzeige es Wertes eine Fehler hat.

[Falk B. (falk)]

Das hier ist FALSCH!

Vorkommastelle = (int16_t)( ( ow_buffer[1] << 8 ) | ow_buffer[0] );

Besser so!

Vorkommastelle = ((int16_t)ow_buffer[1] << 8 ) | ow_buffer[0];

Und wenn man das Scratchpad mit NEUN Bytes lesen will, reicht ein Array 
mit ebenso neun Bytes.

uint8_t ow_buffer[9];

Der Index läuft dann von 0-8! Kleines 1x1 des Programmierens.

[lucas (Gast)]

ist denn die routine zum schreiben lesen und reset richtig?
Beitrag "Re: Delay mit Timer"

Der Angezeigte Wert liegt ja immer bei 127 egal ob ich den Sensor 
erwärme oder nicht.

egal welche Berechnung ich nehme.


Denn die Sensort ID kann ich ja ohne Probleme auslesen.

[Karl M. (Gast)]

Hallo lucas,

ich habe für dich anhand zweier Datenblätter das Timing in kontrolliert 
und angepasst.

ds1820_wr_bit(uint8_t wrbit,uint8_t used_pin)
ds1820_re_bit(uint8_t used_pin)

Warum man da noch die Bitnummer übergibt ist völlig unklar und 
uneffizient !
Sind ja schon Defines
DS1820_DDR
DS1820_PORT

DS1820_DDR |= 1<<used_pin;
DS1820_PORT &= ~(1<<used_pin);

das ist richtig Rechenaufwand und wird voraussichtlich das DS18S20 
Timing zerstören !

Ich würde konsequent nur Defines verwenden
DS1820_BIT für |used_pin| verwenden.

Anbei mein Testprogramm, bzgl. Codeexpansion, und die onwire.[ch] 
Dateien.

Datenblatt
[1] http://mct.de/download/maxim/ds1820.pdf
ds18b20 lib 0x02
[2] http://pdfserv.maximintegrated.com/en/an/AN162.pdf

[ANDREAS (Gast)]

Als Ausgabe bekomme ich 127
Kann mir keiner richtig sagen woran das liegt.
Auch bei Falk seinem Demo bekomme ich dies als Ausgabe

[Falk B. (falk)]

ANDREAS alias lucas hmmmm . . . .

Wir haben festgestellt, dass du zwar den ROM code und das Scratchpad 
korrekt lesen kannst, dort aber die Resetwerte drinstehen.
Ausserdem hantierst du mehreren Versionen von Ausgaberoutine, so daß 
weder wir noch du noch durchsehen, was denn nun aktuell ist. Ganz 
schöner Mist.

Prüfe mal deine Ausgabefunktion, indem du NACH dem Scratchpad einlesen 
die Daten manipulierst. Etwa so.

// scratchpad einlesen, danach das hier

buffer [0] = 2*42+1;
buffer [1] = 0;

Vorkommastelle = ((int16_t)ow_buffer[1] << 8 ) | ow_buffer[0] ); 
sprintf( txbuf, "%+03d.%1d", Vorkommastelle/2, ( Vorkommastelle%2) * 5 ); 
Len = strlen (txbuf);
rf12_txdata_TEST(txbuf,Len);

Dann MUSS dort 42.5 ausgegeben werden.

[Karl M. (Gast)]

Hallo,

Ich weiss ja nicht wer hinter dem letzten Post steckt und was man da 
gemacht hat, aber die Antwort ist dann immer 42.

Ohne Code und Schaltbild und Bilder vom realem Aufbau bleibt es ein 
Raten.

Meine Analyse habe ich ober dargelegt und es ist zu erwarten, dass das 
Timing nicht stimmt.

[Karl M. (Gast)]

Vielleicht stimmt auch der DS18X20 nicht mit dem Code überein.
Auch davon habe wir keine Bilder gesehen.


https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377

[Karl M. (Gast)]

Falk B. schrieb:
> Diese Daten sind korrekt, die CRC passt.
>
> 0xaa, 0x00, 0x4b, 0x46, 0xff, 0xff, 0x0c, 0x10, 0x87
>
> Das hätte man aber auch gleich leserlich schreiben können. . . .


Mit diesen Daten kann man auf einen DS18S20 schließen.

Table 4. Scratchpad Memory Map Comparison
https://www.maximintegrated.com/en/app-notes/index.mvp/id/4377

[Falk B. (falk)]

https://github.com/PaulStoffregen/OneWire

https://github.com/PaulStoffregen/OneWire/archive/master.zip

ZIP ins Arduino-Verzeichnis .../arduino/libraries entpacken
Das Beispiel examples/DS18x20_Temperature/DS18x20_Temperature.pde in der 
Arduino IDE öffnen
OneWire  ds(10); den Pin von deinem Arduino anpassen
Compilieren und hochladen
Seriellen Monitor einschalten

Ging bei mir sofort.

[Karl M. (Gast)]

Hallo Falk,

es ist schon spannend, wie Du dich bei diesem Thema reinhängst.
Dave L. Jones (EEVblog) würde sagen "Thumbs up"!

Es scheint mir, dass der TE gar nicht versteht, was Du und ich ihm 
vorgeschlagen haben.
Er hat wohl nie gelernt "hinter die Dinge" zu sehen oder ihm fehlt der 
Wille Anhand eines Datenblatts - das des DS18S20 - die Richtigkeit einer 
oder auch seiner Software zu verifizieren.

Auch das mantraartige: "Kann mir keiner Helfen" und das 2-4 malige 
wiederholen in immer neuen Threads ist schon sehr auffällig.

[ANDREAS (Gast)]

Falk B. schrieb:
> ANDREAS alias lucas hmmmm . . . .
>
> Wir haben festgestellt, dass du zwar den ROM code und das Scratchpad
> korrekt lesen kannst, dort aber die Resetwerte drinstehen.
> Ausserdem hantierst du mehreren Versionen von Ausgaberoutine, so daß
> weder wir noch du noch durchsehen, was denn nun aktuell ist. Ganz
> schöner Mist.
>
> Prüfe mal deine Ausgabefunktion, indem du NACH dem Scratchpad einlesen
> die Daten manipulierst. Etwa so.
>
> // scratchpad einlesen, danach das hier
>
> buffer [0] = 2*42+1;
> buffer [1] = 0;
>
> Vorkommastelle = ((int16_t)ow_buffer[1] << 8 ) | ow_buffer[0] );
> sprintf( txbuf, "%+03d.%1d", Vorkommastelle/2, ( Vorkommastelle%2) * 5
> );
> Len = strlen (txbuf);
> rf12_txdata_TEST(txbuf,Len);
>
> Dann MUSS dort 42.5 ausgegeben werden.



Als Ausgabe erhalte ich hier 127??

[Falk B. (falk)]

@ANDREAS (Gast)

>> Dann MUSS dort 42.5 ausgegeben werden.

>Als Ausgabe erhalte ich hier 127??

Dann hast du ein grundlegendes Problem mehr. Ich fürchte, das wir das 
hier nicht wirklich lösen können.

[ANDREAS (Gast)]

Im Anhang mal das ganze Projekt.
Vielleicht könnte jemand mal reinschauen.

Wenn ich nur die DS18S20 alleine auf dem Mega8 habe dann gehts 
eingermaßen

mfg

[Andreas (Gast)]

Falk B. schrieb:
> ANDREAS alias lucas hmmmm . . . .
> Wir haben festgestellt, dass du zwar den ROM code und das Scratchpad
> korrekt lesen kannst, dort aber die Resetwerte drinstehen.
> Ausserdem hantierst du mehreren Versionen von Ausgaberoutine, so daß
> weder wir noch du noch durchsehen, was denn nun aktuell ist. Ganz
> schöner Mist.
>
> Prüfe mal deine Ausgabefunktion, indem du NACH dem Scratchpad einlesen
> die Daten manipulierst. Etwa so.
> // scratchpad einlesen, danach das hier
>
> buffer [0] = 2*42+1;
> buffer [1] = 0;
>
> Vorkommastelle = ((int16_t)ow_buffer[1] << 8 ) | ow_buffer[0] );
> sprintf( txbuf, "%+03d.%1d", Vorkommastelle/2, ( Vorkommastelle%2) * 5
> );
> Len = strlen (txbuf);
> rf12_txdata_TEST(txbuf,Len);
>
> Dann MUSS dort 42.5 ausgegeben werden.

Ja als Ausgabe erhalte ich 42,5

Kann mir noch jemand von ihnen sagen warum ich als Ausgabe immer 127 
erhalte.

Denn den Romcode vom Sensor kann ich ja einwandfrei auslesen.

[Falk B. (falk)]

@Andreas (Gast)


>> Dann MUSS dort 42.5 ausgegeben werden.

>Ja als Ausgabe erhalte ich 42,5

Gut. Dann kannst du ja den nächsten Schritt gehen und die echten 
Sensordaten in Temperatur umrechnen lassen. Selbst wenn dort nur die 
Resetwerte drin stehen, sollte nicht 127 rauskommen, sondern 85°C, siehe 
Datenblatt.

>Kann mir noch jemand von ihnen sagen warum ich als Ausgabe immer 127
>erhalte.

Nein, das kann keiner, weil kein Mensch weiß welche Version von Software 
in deinem Chaos bei dir im Controller steckt. Das kann nur jemand, der 
direkt neben dir sitzt.

[Pandur S. (jetztnicht)]

Das normale Vorgehen eines Profis ist :

1) Code fuer alles schreiben, laufenlassen. Geht nicht.
2) Code zum Senden an das Device schreiben. Senden, mit dem Oszilloskop 
die Leitung kontrollieren. Dh die Spannungslevel und das Timung muss 
passen.
3) den vorherigen Code variieren, bis auch etwas aus dem Device 
rauskommt. Spannungslevel mit dem Oszilloskop kontrollieren
4) Code zum Empfangen schreiben, irgendwelche Antworten ueber das UART 
zum PC senden.
5) Den Sende Code variieren bis das kommt was man sich erhofft auf 
binaerem Level, gemaess datenblatt.
6) Den Code zum Verarbeiten der empfangenen Daten schreiben.
7) Falls der nicht geht, den Code mit Konstanten fuettern und auf dem 
Simulator des Compilers/ASM variieren bis er geht. Denn da ist nun ja 
kein Timung mehr noetig.

Alles mit "Hilft mir - es laeuft nicht" sind zu langsam & ..

[ANDREAS (Gast)]

Oder D. schrieb:
> Das normale Vorgehen eines Profis ist :
>
> 1) Code fuer alles schreiben, laufenlassen. Geht nicht.
> 2) Code zum Senden an das Device schreiben. Senden, mit dem Oszilloskop
> die Leitung kontrollieren. Dh die Spannungslevel und das Timung muss
> passen.
> 3) den vorherigen Code variieren, bis auch etwas aus dem Device
> rauskommt. Spannungslevel mit dem Oszilloskop kontrollieren
> 4) Code zum Empfangen schreiben, irgendwelche Antworten ueber das UART
> zum PC senden.
> 5) Den Sende Code variieren bis das kommt was man sich erhofft auf
> binaerem Level, gemaess datenblatt.
> 6) Den Code zum Verarbeiten der empfangenen Daten schreiben.
> 7) Falls der nicht geht, den Code mit Konstanten fuettern und auf dem
> Simulator des Compilers/ASM variieren bis er geht. Denn da ist nun ja
> kein Timung mehr noetig.
>
> Alles mit "Hilft mir - es laeuft nicht" sind zu langsam & ..

Alles schon versucht!
Naja es geht einfach nicht ich erhalte immer 127 als ausgabe.

Ausserdem wenn die Tempmessung stattfindet flackert das Licht.

Auf meinem STM32 hingegen läuft das einwandfrei.

warum nicht auf dem AVR??

[Sascha W. (sascha-w)]

ANDREAS schrieb im Beitrag #443949
> Wenn ich nur die DS18S20 alleine auf dem Mega8 habe dann gehts
> eingermaßen
was soll'n das heisen? Kannst du dann den korrekten Wert auslesen oder 
nicht?

Sascha

[Andreas (Gast)]

Sascha W. schrieb:
> ANDREAS schrieb im Beitrag #443949
> Wenn ich nur die DS18S20 alleine auf dem Mega8 habe dann gehts
> eingermaßen
>
> was soll'n das heisen? Kannst du dann den korrekten Wert auslesen oder
> nicht?
>
> Sascha

Ja dann gehts

[Sascha W. (sascha-w)]

Andreas schrieb:
> Sascha W. schrieb:
>> ANDREAS schrieb im Beitrag #443949
>> Wenn ich nur die DS18S20 alleine auf dem Mega8 habe dann gehts
>> eingermaßen
>>
>> was soll'n das heisen? Kannst du dann den korrekten Wert auslesen oder
>> nicht?
>>
>> Sascha
>
> Ja dann gehts
Dann hast du die Interrups während der 1Wire-Kommunikation nicht 
gesperrt und das versaut dir natürlich das Timing.
Um im Umkehrschluss die PWM nicht zu stören ist es sinnvoll die INTs 
immer nur während der Übertragung eines Bytes zu sperren 
(1Wire_Write_Byte / 1Wire_Read_Byte) das dauert nicht so lang und so 
stört es auch nicht wenn mal ein anderer INT dazwischenkommt.

Sascha

[Andreas (Gast)]

Wie hier zusehen ist

Beitrag "Re: Delay mit Timer"

werden die Interrupts gesperrt.

Sonst könnt ich auch nicht den Rom Code Auslesen.

[Andreas (Gast)]

Von mir aus kann der Thread hier gelöscht werden,
da mir scheinbar keiner weiterhelfen kann.

Ich habe mein Projekt angehangen weiter oben aber anscheinend ist meine 
Frage hier in diesen Forum wohl zu Trivial.

Na jedenfalls gehts mit einen stm32 einwandfrei.

[Walter S. (avatar)]

Andreas schrieb:
> Von mir aus kann der Thread hier gelöscht werden,
> da mir scheinbar keiner weiterhelfen kann.

das liegt aber nicht an den Helfern

[Andreas (Gast)]

Walter S. schrieb:
> Andreas schrieb:
> Von mir aus kann der Thread hier gelöscht werden,
> da mir scheinbar keiner weiterhelfen kann.
>
> das liegt aber nicht an den Helfern

Scheinbar hat sich niemand das Projekt angeschaut.

Denn ich hatte ja geschrieben das ich den Romcode auslesen kann 
einwandfrei aber die Temperratur eben nicht.

Der eine sagt mach die Ausgabe über eine Uart oder Display, hab ich aber 
nicht auf der Platiene eben nur ein RFM12B.

Wenn sich das Projekt jemand angeschaut hätte würde man soetwas nicht 
Schreiben.

Das hab ich gemeint!

[lernen ... (Gast)]

Hier ist das allgemeine Vorgehen beschrieben:

Beitrag "Re: Delay mit Timer"

Du bezahlst niemanden sich Stundenlang mit unnützem Code zu 
beschäftigen. Falk hat Dir seinen Code zur Verfügung gestellt. Den hätte 
man nur einbauen müssen.

[Falk B. (falk)]

@ Andreas (Gast)

>Scheinbar hat sich niemand das Projekt angeschaut.

Doch, ich. Aber es ist groß und chaotisch, das tut sich keiner an, 
nichtmal ich.

>Denn ich hatte ja geschrieben das ich den Romcode auslesen kann
>einwandfrei aber die Temperratur eben nicht.

tja, dort musst du weiter machen. Tips dazu hast du genug.

>Der eine sagt mach die Ausgabe über eine Uart oder Display, hab ich aber
>nicht auf der Platiene eben nur ein RFM12B.

Das ist ein UART.