Delay mit Timer

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?

Ist ein Atmega8-16

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).

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?

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. schrieb:
> Deswegen hatte ich das auch geschrieben.

Brav - kriegst ein Wurschti :-)

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. 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.

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

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.

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.

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

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 
...

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.

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.

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

Wie man verwendet _delay_us() ?

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

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.

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.

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
{


}

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:

1

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.

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.

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.

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.

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.

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.

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

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.

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

Was ist denn an der Timer0 isr falsch?

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?

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

1

  float Temperatur;

2

  int vorkomma;

3

  int nachkomma; 

4

5

    Temperatur = Temperatur_Messung();

6

    if ( signbit(Temperatur) ) {

7

      Temperatur = fabs(Temperatur);

8

      rf12_txdata_TEST("-",1);

9

    } 

10

    vorkomma = (int) Temperatur;

11

    nachkomma = (int)((Temperatur - vorkomma) * 10);

12

     sprintf(txbuf,"%d.%d ",vorkomma , nachkomma); //Convert temp. puffer oben to string

13

14

  Len = strlen (txbuf);

15

  rf12_txdata_TEST(txbuf,Len);

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

Die ident kann ich ja richtig auslesen vom sensor.

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

So bitte,

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

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

aber warum bekomm ich als Anzeige immer 127

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.

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

1

DS1820_DDR |= 1<<used_pin;

2

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

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

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.

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

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

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.

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??

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

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.

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. 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

Wie hier zusehen ist

Beitrag "Re: Delay mit Timer"

werden die Interrupts gesperrt.

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

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. 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!

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.