SHT11 an ATmega2560 Es funktioniert nicht

[Konrad B. (brutzelnerd)]

Hallo Zusammen!
Ich habe das MyAVR-Board MK3 und will damit einen SHT11 ansteuern umd 
auslesen. Ich bin ein Anfänger in Sachen µCs und habe nun verschiede 
C-codes probiert, doch es funktioniert nicht. Mit dem Oszi habe ich die 
Funktion überprüft, der Sensor gibt auch ein ACK und irgendwas zurück, 
aber es ist halt Blödsinn!
Kann es sein, dass der Atmega2560 zu schnell ist und der Sensor damit 
nicht klarkommt? Der ATmega läuft mit 16 MHz.
Auch habe ich den Sensor an einem relativ langen, ca. 50 cm, Kabel, 
könnte dies Probleme bereiten?
Vielen Dnk schon mal für Eure Hilfe!
MfG
Konrad

[(prx) A. K. (prx)]

Konrad Bethmann schrieb:
> Kann es sein, dass der Atmega2560 zu schnell ist

Nein.

[Georg G. (df2au)]

Pullup an der Datenleitung vergessen?
Ansonsten sagt die Kristallkugel, dass du einen Fehler in Zeile 42 
deines Programms hast.

[Jörg W. (dl8dtl) (Moderator)]

Konrad Bethmann schrieb:
> Kann es sein, dass der Atmega2560 zu schnell ist und der Sensor damit
> nicht klarkommt?

Du musst den I²C halt langsam genug betreiben.  Standard-I²C benutzt
100 kHz Taktrate, “fast” benutzt 400 kHz.  Im Zweifel lieber erstmal
mit 100 kHz rangehen.

Ich habe schon erfolgreich mehr als einen SHT-21 an ATmega128RFA1
betrieben, die ebenfalls mit 16 MHz laufen.

Die Länge des Busses ist bei I²C auch nicht so kritisch.  Das ist ja
keine Hochfrequenz.  Denk dran, den Bus hat Philips so konzipiert,
dass man damit die Bedienelemente innerhalb eines Fernsehgeräts
anschließen kann.  Die liegen auch nicht alle auf 10 cm beieinander.

[(prx) A. K. (prx)]

Es fehlt:
- Bild der Hardware
- Anhang mit Software

[(prx) A. K. (prx)]

Jörg Wunsch schrieb:
> Du musst den I²C halt langsam genug betreiben.  Standard-I²C benutzt
> 100 kHz Taktrate, “fast” benutzt 400 kHz.  Im Zweifel lieber erstmal
> mit 100 kHz rangehen.

Der SHT11 hat kein I2C. Ist aber ähnlich.

[Georg G. (df2au)]

Jörg Wunsch schrieb:
> Die Länge des Busses

Ich betreibe einige SHT11 an 5m abgeschirmter Mikrofonleitung, also 
richtig viel Kapazitätsbelag. Das geht zuverlässig, allerdings nicht mit 
100kHz Takt.
Der Sensor ist recht unkritisch im Handling.

[Jörg W. (dl8dtl) (Moderator)]

A. K. schrieb:
> Der SHT11 hat kein I2C.

Ja, hatte ich so dunkel in Erinnerung.  Daher hat's auch keinen Sinn,
meinen SHT-21-Code zu posten.

> Ist aber ähnlich.

Eben, insofern unterscheiden sie sich elektrisch nicht viel.  Man kann
halt nur nicht das TWI-Modul zur Ansteuerung nehmen, sondern muss es
„zu Fuß“ implementieren.

[Konrad B. (brutzelnerd)]

Danke an Alle für die schnellen Antworten!
Ich werde mal heute Abend ein Bild machen, aber ich habe Den Widerstand 
und den Kondensator richtig angeschlossen!
Ich hänge einfach mal den Quellcode mit an, vielleicht ist der Fehler 
dort versteckt!
Danke schon mal im Voraus!
LG
Konrad
P.s.:
Ich habe eine RAR-Datei angehangen und alle Datein noch mal so, kann 
sein, das einige das RAR nicht öffnen können
Die Haupt datei ist : LCD_BOARD.c, die Unterprogramme liegen in 
SHT_TEST.c, und MK3_2560_LCD.h ist für das Display, nur zur Erklärung!

[(prx) A. K. (prx)]

Meinen Code gibts hier, die Urfassung ohne T-Kompensation:
Beitrag "Sensirion SHT11 Code"

[(prx) A. K. (prx)]

Bei Timing über NOP Befehle könnte der AVR tatsächlich zu schnell sein.

[Konrad B. (brutzelnerd)]

Danke A.K., deine code habe ich mir auch schon angesehen, da ich aber 
absoluter Änfänger bin, konnte ich nicht recht was mit anfangen, wäre 
super, wenn du mir einenen lauffähigen code geben könntest, also mit 
Main. Ich weiss, es klingt doof, doch ich plage mich nun schon recht 
lange damit rum und komme auf keinen Grünen Zweig, dass mir die Lust 
bald vergeht!
LG
Konrad

[(prx) A. K. (prx)]

Konrad Bethmann schrieb:
> wenn du mir einenen lauffähigen code geben könntest, also mit Main.

Sinnlos, da konfigurationabhängig.

PS: Die Messroutine ist in 
Beitrag "Re: Sensirion SHT11 Code"

Wann das auch nicht reicht, dann fang man mit dem üblichen Beispiel 
einer blinkenden LED an.

[Konrad B. (brutzelnerd)]

Hi A. K.!
Alles klar, dann werde ich mich mal mit der Messroutine 
auseinandersetzen.
Die Konfiguration einstellen und auch ne LED blinken lassen, dass klappt 
schon. Soweit bin ich dann doch!
Was mir gerade aufgefallen ist, ich sollte vielleicht die 
Compillerwarnungen nicht ganz ignorieren, das hilft bestimmt!
LG
Konrad

[Jörg W. (dl8dtl) (Moderator)]

Konrad Bethmann schrieb:
> ich sollte vielleicht die Compillerwarnungen nicht ganz ignorieren, das
> hilft bestimmt!

Das ist immer eine gute Idee.

Man kann natürlich gelegentlich auch mal eine Warnung in Kauf nehmen,
aber nur, nachdem man sich gründlich vergewissert hat, dass sie für
eine konkrete Situation tatsächlich bedeutungslos ist.

In der Regel fährt man mit einer “zero warnings policy” immer noch am
besten.

[Konrad B. (brutzelnerd)]

Ich habe bissel was geändert und nun keineWarnungen mehr, aber leider 
auch den Sensor nicht da, um ihn auszuprobieren, werde heute Abend 
berichten!
LG
Konrad

[Konrad B. (brutzelnerd)]

Hi Zusammen!
Auf den Rat von A.K. hin habre ich seinen Code genommen und mir ein 
Programm zum Auslesen des SHT11  gebastelt, aber es passiert immer noch 
nichts. Vielleicht könnte ja der ein oder andere mit Erfahrung mal über 
das Programm schauen und vielleicht findet er ja den Fehler. Ich hänge 
auch mal die Source datei von A.K. mit an, damit ihr wisst von welchen 
Unterfunktionen die rede ist.

Ich denke, dass die Ergebnisse in der Variable "v" gespeichter werden 
und deshalb wollte ich sie mir auf dem Display anzeigen lassen, aber da 
kommt entweder eine 0 oder, wenn ich v vorher initialisiere eben die 
Zahl, mit der ich initialisiert habe, keine Ahnung, wo mein Fehler 
liegt.
Vielen Dank schon mal fürs ansehen!!
VG
Konrad

P.s.: Das Display funktioniert, also da kann es keine Probleme geben!
Hier der Code:

#define F_CPU 16000000UL
#include <avr/io.h>
#include "config.h"
#include "sht11.h"
#include <util/delay.h>
#include <stdint.h>
#include "MK3_2560_LCD.h"
int16_t feuchte_messen(void)
{
  sht11_start_humid();
  while (!sht11_ready());
  return sht11_result_humid();
}
int16_t v;


int main(void)
{
  
  MK3_INIT_LCD();        // init des LCD
  MK3_LCD_CLEAR();        // LCD loeschen
  MK3_LCD_LIGHT(1);      // beleuchtung einschalten
  MK3_LCD_PRINT_STRING("test");

  DDRD =0xFF;
  PORTD =0x00;

    while(1)
    {  
    
    MK3_LCD_PRINT_UINT(v);
    _delay_ms(1000);
    } return 0;
}

[(prx) A. K. (prx)]

Beim Code im Anhang nützt es garantiert nix, den Takt nach <delay.h> zu 
definieren. Und der direkt gepostete Code ruft die Messung nicht auf.

Es fehlt die Hardware-Beschreibung, also Schaltbild und Foto, sowie und 
dein config.h.

[kettenrad (Gast)]

-und wo in der main(while)-Schleife führtst du die Funktion
feuchte_messen(void);
aus?

[Konrad B. (brutzelnerd)]

Sorry, natürlich habe ich in der Main while-schleife das Unterprogramm 
"feuchte_messen()" drin, da ist mir ein Fehler beim kopieren passiert
die config.h hänge ich mit an
Tut mir leid, dass ich nicht gleich alles vollständig hatte!
VG
Konrad

[Konrad B. (brutzelnerd)]

Hi zusammen!
Leider kann ich gerade keinen Schaltplan erstellen und auch kein Foto 
machen. Der SHT11 ist wie im Datenblatt verdrahtet, sprich 100 
nF-Kondensator zwischen GND und Vcc, sowie ein Widerstand, 10 k, 
zwischen DATA und Vcc und dann halt an das MK3-Board, die Leitungen sind 
nun auch kürzer, ca 10 cm, es sollte alles passen, aber es tut sich 
nichts!
Danke für die Hilfe im _Voraus!
VG
Konrad

[Konrad B. (brutzelnerd)]

hi zusammen!
Nun habe ich doch noch ein bild der Sensorbeschaltung machen können, 
aber laut datenblatt dürfte das so passen!
hat jemand zeit gefunden, mal in den code zu schauen, ob es da einen 
fehler gibt?
Danke noch mal!VG
Konrad

[Thomas E. (fuessis)]

Hallo Konrad,

was mir auf die Schnelle aufgefallen ist, dass das toggeln der 
Clock-leitung mit 2u recht kurz ist. Laut Datenblatt ist typisch 0,1 Mhz 
angegeben.
Versuche als mal alle Delays auf 10u hochzusetzen.
Kannst Du Dir die Clock und Data mit einem Ozi oder Logikanalyser 
ansehen?

Gruß
Thomas

[(prx) A. K. (prx)]

Thomas E. schrieb:
> Laut Datenblatt ist typisch 0,1 Mhz angegeben.

In meinem Exemplar des Datasheets sind es bis 10MHz ab 4,5V, bis 1MHz 
darunter.

[Thomas E. (fuessis)]

mein Datenblatt ist schon älter von 2008.
Max ist dort mit 5Mhz angegeben, typisch aber mit 0,1 Mhz bei 5V.
Schaden kann es jedenfalls nicht, die Clock mal zu senken.

Gruß
Thomas

[(prx) A. K. (prx)]

Thomas E. schrieb:
> mein Datenblatt ist schon älter von 2008.

Interessant. Da hat sich wohl nicht nur das Datasheet geändert.

Meine Datasheet war bisher die V3 von 2007. Ein "typ" Wert steht dort 
nicht drin. "Data sheet valid for SHTxx-V4 and SHTxx-V3"

In der aktuellen völlig anders gestalteten V5 des Datasheets steht nun
"Reference to V3 sensors eliminated."

[(prx) A. K. (prx)]

Konrad Bethmann schrieb:
> Nun habe ich doch noch ein bild der Sensorbeschaltung machen können,
> aber laut datenblatt dürfte das so passen!

Dem Bild lässt sich die Beschaltung nicht wirklich entnehmen. 
Beispielsweise wo der Widerstand dran hängt, und mit welchen Pins vom 
Controller der Sensor verdrahtet ist.

[Konrad B. (brutzelnerd)]

Hi!
Ich werde mal versuchen, die Taktrate zu senken, vielleicht hilft es.
Der Widerstand ist an DATA und an Vcc.
Data und CLOCK sind an PORT D, DATA PD7 und CLOCK PD4.
GND und Vcc sind an der Spannungsversorgung des MK3-Boards, mi U = 4,9V
Das sollte also alles passen.
VG Konrad

[(prx) A. K. (prx)]

Konrad Bethmann schrieb:
> Ich werde mal versuchen, die Taktrate zu senken, vielleicht hilft es.

_delay_us(5) statt _delay_us(2) schadet sicher auch nicht.
Und mach ein _delay_ms(11) vor die Initialisierung.

[Konrad B. (brutzelnerd)]

Nun habe ich das Delay raufgesetzt und auch vor der Initialisierung eins 
gemacht, es ändert sich rein gar nichts, was mich echt nervt!!
Vielleicht lege ich das Teil erstmal zur Seite und sehe morgen oder 
übermorgen weiter, heute wird das glaube nichts mehr!
VG
Konrad

[Konrad B. (brutzelnerd)]

Guten Morgen zusammen!
Nun habe ich nochmals bissel am Code gefeilt und es passiert trotzdem 
nichts!!
Leider habe ich auch gerade kein Oszi zur hand, was mich ärgert!

Hier kommt mal der CODE, vielleicht hat ja einer ne Idee
VG
Konrad

p.s.: er wurde problemlos compiliert!

#define F_CPU 16000000
#define sht_port DDRB   // Richtungsregister definieren
#define sht_o PORTB    // Ausgangsport definieren
#define sht_i PINB    // Eingangsport definieren
#define data PB0    // Datenleitung zum Sensor
#define clk  PB1    // Steuerleitung zum Sensor
#include <avr\io.h>
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>
#include "MK3_2560_LCD.h"

//Konstanten
#define status_schreiben  0x06
#define status_lesen    0x07
#define messung_temp    0x03
#define messung_feuchte    0x05
#define Ack          1
#define noAck        0
//-----------------Unterprogramme------------------------------------------------------------

 void  delay(void)      // Delay für Syncronisation
{
  _delay_us(5);
}

void data_hi(void)      // 1 an DATA
{
  sht_o |= (1<<data);
}

void data_lo(void)      // 0 an DATA
{
  sht_o &=~(1<<data);
}

void clk_hi(void)      // 1 an clk
{
  sht_o |= (1<<clk);
}

void clk_lo(void)      // 0 an clk
{
  sht_o &=~(1<<clk);
}

// Startsequenz

void start(void)
{
  sht_port = 0xFF;
  data_hi(); delay();
  clk_lo();  delay();
  clk_hi();  delay();
  data_lo(); delay();
  clk_lo();  delay();
  clk_hi();  delay();
  data_hi(); delay();
  clk_lo();  delay();
}

// Sensorreset
void reset(void)
{
  sht_port = 0xFF;
  char i;
  data_hi(); delay();
  clk_hi();  delay();
  for (i=0;i<9;i++)    // 9 Taktzyklen
  {
    clk_hi(); delay();
    clk_lo(); delay();
  }
  start();        // Startsequenz
}

// Statusregister schreiben

char sht_schreiben(char cWert)
{
  char i;
  char cFehler;

  for(i=0x80;i>0;i/=2)      // Mit einer Schleife jedes einzelne Bit des...
  {
    if (i & cWert) data_hi();      // ...zu uebergebenden Bytes maskieren und das
    else data_lo();          // Ergebnis auf die DATA-Leitung geben
    // Anschliessend einen Taktimpuls erzeugen
    clk_hi();  delay();              // Taktimpuls
    clk_lo();   delay();
  }
  data_hi();     delay();
  clk_hi();    delay();          // steigende Flanke der Takt-Leitung
  sht_port &=~(1<<data);        // DATA-Pin auf Eingang umschalten
  cFehler = PINB;            // DATA einlesen und in fehler sichern
  clk_lo() ;              // fallende Flanke der Takt-Leitung
  sht_port |=(1<<data);        // DATA-Pin auf Ausgang zurueckschalten
  return(cFehler);
}

// Statusregister lesen

char sht_lesen(char cAck)
{
  char i;
  char cWert = 0;

  data_hi(); delay();
  sht_port &=~(1<<data);        // DATA-Pin auf Eingang umschalten
  for(i=0x80;i>0;i/=2)        // Mit einer Schleife das 8-Bit Datenwort
  // bitweise einlesen
  {
    clk_hi(); delay();
    if (PINB) cWert = (cWert | i);
    clk_lo(); delay();
  }
  sht_port |=(1<<data);        // DATA-Pin auf Ausgang zurueckschalten
  data_hi();  delay();      // Bestaetigung (Acknowledge) senden
  clk_hi();   delay();

  clk_lo();   delay();
  data_hi();   delay();
  return (cWert);
}

//Temperaturmessung

char temp(int iTemperatur)
{
  char cFehler = 0;
  unsigned int i;
  char cTemperaturHigh;
  char cTemperaturLow;

  int iTemperaturLin;

  // Schritt 1: Temperaturmessung
  // Schritt 1.1: Startbedingung erzeugen
  start();
  // Schritt 1.2: Anweisung zur Temperaturmessung
  cFehler += sht_schreiben(messung_temp);
  // Schritt 1.3: Auf Messergebnis warten
  sht_port &=~(1<<data);    // DATA-Leitung auf Eingang umschalten
  for (i=0;i<65535;i++) if (PINB == 0){ delay();} 
  if (PINB) cFehler += 1;  // Time-out! -> Fehlerflag setzen
  sht_port |=(1<<data);    // DATA-Leitung auf Ausgang umschalten
  // Schritt 1.4: High-Byte vom Sensor lesen und in cTemperaturHigh sichern
  cTemperaturHigh = sht_lesen(Ack);
  // Schritt 1.5: Low-Byte vom Sensor lesen und in cTemperaturLow sichern
  cTemperaturLow = sht_lesen(noAck);

  // Schritt 3: Temperatur berechnen
  iTemperaturLin = (int)(256 * cTemperaturHigh);
  iTemperaturLin = iTemperaturLin + cTemperaturLow;

  // Schritt 4: Temperatur linearisieren
  iTemperaturLin = (int)(iTemperaturLin / 10);
  iTemperaturLin = iTemperaturLin - 400;

  // Schritt 8: Temperatur- und Feuchtewert dem aufrufenden Programm uebergeben
  iTemperatur = iTemperaturLin;

  // Schritt 9 Rueckgabewert (hier: cFehler)
  return (cFehler);
}

int main (void)
{
  
  int iTemperatur;
  

  
  MK3_INIT_LCD();          // init des LCD

  MK3_LCD_CLEAR();        // LCD loeschen
  MK3_LCD_LIGHT(true);      // beleuchtung einschalten


  while (1)
  {
    iTemperatur =0;
    sht_port = 0xFF;
    temp( iTemperatur);
    _delay_ms(500);
    MK3_LCD_SETCURSOR(0,32);
    MK3_LCD_PRINT_STRING("Temperatur");

    MK3_LCD_SETCURSOR(0,48);
    MK3_LCD_PRINT_STRING("Feuchte");
    //iTemperatur = 12;
    MK3_LCD_SETCURSOR(20,16);
    MK3_LCD_PRINT_UINT(iTemperatur);
    _delay_ms(500);
    
  }
  return 0;
}
//-----------------------------------------------------------------------------

[(prx) A. K. (prx)]

Konrad Bethmann schrieb:
> #define sht_port DDRB   // Richtungsregister definieren
> #define sht_o PORTB    // Ausgangsport definieren
> #define sht_i PINB    // Eingangsport definieren
> #define data PB0    // Datenleitung zum Sensor
> #define clk  PB1    // Steuerleitung zum Sensor

Konrad Bethmann schrieb:
> Data und CLOCK sind an PORT D, DATA PD7 und CLOCK PD4.

Also was nun? Port D/4+7 oder Port B/0+1?

Konrad Bethmann schrieb:
> void data_lo(void)      // 0 an DATA
> {
>   sht_o &=~(1<<data);
> }

Bedenke, dass die DATA Leitung als open drain angesteuert werden sollte. 
Also einmalig PORTx.y=0 setzen und dann nur noch über DDRx.y steuern, 
mit 0=high/input und 1=low.

Beachte, dass der Sensor nach Powerup und Reset-Befehl ein Weilchen 
nicht ansprechbar ist.

[Konrad B. (brutzelnerd)]

Entschuldige A.k., ich hatte einen neuen Code geschrieben und da war die 
Portbelegung anders, also an Port B und nicht D. Danke für deinen 
Hinweis mit der DATALeitung!
VG
Konrad

[(prx) A. K. (prx)]

Wenn du dich am Beispielcode von Sensiron orientieren solltest: Die 
Ports vom dort m.W. verwendeten 8051 sind von Haus aus open drain.

[Konrad B. (brutzelnerd)]

Guten Abend zusammen!
Da ich diese Woche nicht mehr AN EIN VERNÜNFTIGES oSZI KOMME; WERDE ICH 
WOHL ERST mONTAG WIEDER MICH DEM sENSOR WIDMEN1! Zufälligerweise hatte 
ich noch eine NI-Karte da, doch die kann nur 100k S/s damit konnte ich 
nichts richtiges anfangen!
Also, am Mo gehts weiter, muss doch irgendwann mal klappen!
VG
Konrad

[Konrad B. (brutzelnerd)]

Hi zusammen!
Nun habe ich zwei sht11 ausprobiert, nichts rührt sich!
Gibt es irgendeine möglichkeit, mit der ich testen kann, ob die Sensoren 
noch funktionieren?
VG
Konrad

[Karl H. (kbuchegg)]

Das hier

...
  for(i=0x80;i>0;i/=2)        // Mit einer Schleife das 8-Bit Datenwort
  // bitweise einlesen
  {
    clk_hi(); delay();
    if (PINB) cWert = (cWert | i);
...

ist mir in der Lesroutine etwas zu progressiv. Den kompletten PINB zu 
benutzen, dürfte recht sicher nicht zielführend sein.

Ausserdem: Wieso steht da PINB direkt im Code und nicht sht_i?

...
  for(i=0x80;i>0;i/=2)        // Mit einer Schleife das 8-Bit Datenwort
  // bitweise einlesen
  {
    clk_hi(); delay();
    if (sht_i & (1<<data)) cWert = (cWert | i);
...

weiter hab ich dann nicht mehr geschaut. Insbesondere hab ich nicht 
überprüft, ob die Reihenfolge der Pinbewegungen Sinn ergeben und/oder 
mit den Vorgaben vom Sensor übereinstimmen.

[(prx) A. K. (prx)]

Ausserdem wäre drauf hinzuweisen, dass
  char i;
  for(i=0x80;i>0;i/=2)
mit Sicherheit nicht die gewünschte Wirkung hat, wenn man bedenkt, dass 
der char Typ ein Vorzeichen hat und GCC deshalb die Schleife komplett 
entfernt.

[Karl H. (kbuchegg)]

A. K. schrieb:
> Ausserdem wäre drauf hinzuweisen, dass
>   char i;
>   for(i=0x80;i>0;i/=2)
> mit Sicherheit nicht die gewünschte Wirkung hat, wenn man bedenkt, dass
> der char Typ ein Vorzeichen hat und GCC deshalb die Schleife komplett
> entfernt.


Ja, darüber wollte ich schon (fast) schreiben. Aber der Code ist so 
grauslich formatiert, dass ich mir den nicht weiter antun will.

Übrigens kommt das PINB Problem auch noch an anderen Stellen im Code 
vor.

[Konrad B. (brutzelnerd)]

Hallo zusammen!
Dankefür die schnellen Antworten, ich habe nun die Änderungen eingebaut 
und den Code auch (hoffentlich) besser formatiert.
Aber es brachte leider gar nichts. Vielleicht könnt ihr ja nochmal 
drübersehen.
Nun habe ich zwar im Code die ganzen Displaysachen rausgenommen, doch 
ich habe die Funktion des Sensors mit dem Oszi kontrolliert und er gibt 
nichts zurück!

#define F_CPU 16000000
#define sht_o PORTB      // Ausgangsport definieren
#define sht_i PINB      // Eingangsport definieren
#define data PB0      // Datenleitung zum Sensor
#define clk  PB1      // Steuerleitung zum Sensor
#include <avr\io.h>
#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>


//Konstanten
#define status_schreiben  0x06
#define status_lesen    0x07
#define messung_temp    0x03
#define messung_feuchte    0x05
#define Ack          1
#define noAck        0
//-----------------Unterprogramme------------------------------------------------------------

void  delay(void)        // Delay für Syncronisation
{
  _delay_us(5);
}

void data_lo(void)        // 0 an DATA
{
  sht_i |= (1<<data);
}

void data_hi(void)        // 1 an DATA
{
  sht_i &=~(1<<data);
}

void clk_hi(void)        // 1 an clk
{
  sht_o |= (1<<clk);
}

void clk_lo(void)        // 0 an clk
{
  sht_o &=~(1<<clk);
}

// Startsequenz

void start(void)
{
  
  data_hi(); delay();
  clk_lo();  delay();
  clk_hi();  delay();
  data_lo(); delay();
  clk_lo();  delay();
  clk_hi();  delay();
  data_hi(); delay();
  clk_lo();  delay();
}

// Sensorreset
void reset(void)
{
  
  char i;
  data_hi(); delay();
  clk_hi();  delay();
  for (i=0;i<9;i++)      // 9 Taktzyklen
  {
    clk_hi(); delay();
    clk_lo(); delay();
  }
  start();        // Startsequenz
}

// Statusregister schreiben

char sht_schreiben(char cWert)
{
  unsigned int i;
  char cFehler;

  for(i=0x80;i>0;i/=2)        // Mit einer Schleife jedes einzelne Bit des...
  {
    if (i & cWert) data_hi();    // ...zu uebergebenden Bytes maskieren und das
    else data_lo();          // Ergebnis auf die DATA-Leitung geben
                    // Anschliessend einen Taktimpuls erzeugen
    clk_hi();  delay();             // Taktimpuls
    clk_lo();   delay();
  }
  data_hi();     delay();
  clk_hi();    delay();        // steigende Flanke der Takt-Leitung
  sht_i |=(1<<data);          // DATA-Pin auf Eingang umschalten
  cFehler = sht_i;          // DATA einlesen und in fehler sichern
  clk_lo() ;              // fallende Flanke der Takt-Leitung
  sht_i &=~(1<<data);          // DATA-Pin auf Ausgang zurueckschalten
  return(cFehler);
}

// Statusregister lesen

char sht_lesen(char cAck)
{
  unsigned int i;
  char cWert = 0;

  data_hi(); delay();
  sht_i &=~(1<<data);      // DATA-Pin auf Eingang umschalten
  for(i=0x80;i>0;i/=2)        // Mit einer Schleife das 8-Bit Datenwort
                // bitweise einlesen
  {
    clk_hi(); delay();
    if (sht_i & (1<<data)) cWert = (cWert | i);
    clk_lo(); delay();
  }
  sht_i |=(1<<data);      // DATA-Pin auf Ausgang zurueckschalten
  data_hi();  delay();    // Bestaetigung (Acknowledge) senden
  clk_hi();   delay();

  clk_lo();   delay();
  data_hi();   delay();
  return (cWert);
}

//Temperaturmessung

char temp(int iTemperatur)
{
  char cFehler = 0;
  unsigned int i;
  char cTemperaturHigh;
  char cTemperaturLow;

  int iTemperaturLin;

              

  start();
    
  cFehler += sht_schreiben(messung_temp);
  
  sht_i &=~(1<<data);                // DATA-Leitung auf Eingang umschalten
  for (i=0;i<65535;i++) if (sht_i == 0){ delay();}
  if (sht_i) cFehler += 1;            // Time-out! -> Fehlerflag setzen
  sht_i |=(1<<data);              // DATA-Leitung auf Ausgang umschalten
  cTemperaturHigh = sht_lesen(Ack);
  cTemperaturLow = sht_lesen(noAck);
  iTemperaturLin = (int)(256 * cTemperaturHigh);
  iTemperaturLin = iTemperaturLin + cTemperaturLow;
  iTemperaturLin = (int)(iTemperaturLin / 10);
  iTemperaturLin = iTemperaturLin - 400;
  iTemperatur = iTemperaturLin;

  return (cFehler);
}

int main (void)
{
  sht_o =0x00;
  int iTemperatur;  

  while (1)
  {
    iTemperatur =0;
    temp( iTemperatur);
    _delay_ms(500);
  }
  return 0;
}

[Konrad B. (brutzelnerd)]

Die Textformatierung sah in meinem Editor viel besser aus, sorry dafür!
Und auch sorry, wenn ich zusehr damit rumnerve, ich würde den Sensor nur 
gern zum Laufen bringen

[(prx) A. K. (prx)]

Konrad Bethmann schrieb:
> Die Textformatierung sah in meinem Editor viel besser aus, sorry dafür!

Das ist meistens so, wenn man TABs verwendet. Und als Anhang statt 
inline hätte sich das auch nicht schlecht gemacht.

[Karl H. (kbuchegg)]

Der 'char ist beim gcc signed' Fehler ist immer noch drinnen.

Merke: WEnn du mit Bytes hantierst, dann nimmst du nicht den Datentyp 
'char' sondern entweder 'unsigned char' oder 'uint8_t'.

Du fährst am besten, wenn du dir angewöhnst, dass es 3(!) kleine 
Datentypen gibt.

* "signed char" bzw. "int8_t"
Die nimmst du für alles, wofür du nur kleine Zahlen brauchst, die aber 
mit Vorzeichen. Also zb wird eine WOhnraumtemperatur wohl selten größer 
als +127 bzw. kleiner als -128° Celsius sein. Ein int8_t wäre also 
passend, wenn keine Kommastellen gebraucht werden, aber negative Zahlen 
möglich sein sollen.

* "unsigned char" bzw. "uint8_t"
Die nimmst du immer dann, wenn du kleine Zahlen ohne 
Vorzeichenerweiterung brauchst. Genau das ist der Datentyp der Wahl wenn 
man mit Bytes hantiert. Denn hier will man keine Sonderbahandlung eines 
Bits als Vorzeichenbit haben. Ansonsten natürlich für alles, was nicht 
negativ werden kann. Zb die Anzahl an Schweissgeräten im Lager einen 
kleinen Schlosserei wird eher selten negativ sein und wohl auch selten 
größer als 255.

* "char"
Reine 'char' benutzt du nur dann, wenn du Textverarbeitung machst. Da 
kannst du es dem Compiler überlassen, ob er einen char als signed char 
oder als unsigned char implementiert. Aber auch nur da! In allen anderen 
Fällen überlässt du es nicht dem Compilerbauer sondern benutzt explizit 
entweder signed oder unsigned

[Karl H. (kbuchegg)]

Und Programm erst mal abspecken.
Du hast Probleme mit der Kommunikation? Dann interessiert die Auswertung 
erst mal überhaupt nicht. Was dich interssiert ist, dass du 1 Byte zum 
Sensor schickst und vom Sensor 1 Byte (oder mehrere) als Antwort 
kriegst. Alles andere in deinem Programm ist erst mal nur überflüssiger 
Ballast, der selbst wieder Fehler enthalten kann.

[Karl H. (kbuchegg)]

Ich glaube ehrlich gesagt nicht, dass das hier

  for (i=0;i<65535;i++) if (sht_i == 0){ delay();}

in deinem Editor besser aussieht.
Abgesehen davon, dass es immer noch falsch ist. PINB durch sht_i zu 
ersetzen löst nicht das Problem, dass du immer noch den kompletten Port 
einliest und nicht nur den einen interessierenden Pin.

[Karl H. (kbuchegg)]

Ich hab jetzt das Datenblatt des SHT nicht studiert. Darf man eigentlich 
das Timing der Ansteuerung beliebig langsam machen? Wenn ja, dann würde 
ich das mal empfehlen.

[(prx) A. K. (prx)]

Es hat sich eingebürgert, den Namen von Präprozessordefinitionen gross 
zu schreiben. Wenns nicht grad das Äquivalent einer Funktion ist. So ist 
beispielsweise dein "data" für geübte Leser von C Quellcode ziemlich 
irritierend.

[(prx) A. K. (prx)]

Karl Heinz schrieb:
> Darf man eigentlich
> das Timing der Ansteuerung beliebig langsam machen?

Ja.

> Wenn ja, dann würde ich das mal empfehlen.

Und dabei zusehen.

Apropos Timing, zum ca. dritten Mal: Der SHT ist ein Morgenmuffel. Wie 
viele seiner Anwender auch, darf er anfangs erst einmal ein Weilchen 
nicht angesprochen werden.

[(prx) A. K. (prx)]

Karl Heinz schrieb:
> Was dich interssiert ist, dass du 1 Byte zum
> Sensor schickst und vom Sensor 1 Byte (oder mehrere) als Antwort
> kriegst.

Oder zunächst einmal das ACK Bit der grob an I2C orientierten 
Kommunikation.

[Georg G. (df2au)]

Konrad Bethmann schrieb:
> void data_lo(void)        // 0 an DATA
> {
>   sht_i |= (1<<data);
> }
>
> void data_hi(void)        // 1 an DATA
> {
>   sht_i &=~(1<<data);

Um einen Ausgang zu steuern muss man den Eingang verändern?
Wäre nicht sht_o der geeignetere Kandidat?

[(prx) A. K. (prx)]

Georg G. schrieb:
> Um einen Ausgang zu steuern muss man den Eingang verändern?
> Wäre nicht sht_o der geeignetere Kandidat?

Weder noch. 
Beitrag "Re: SHT11 an ATmega2560 Es funktioniert nicht"

[Georg G. (df2au)]

In einigen der gängigen Libs wird entgegen dem Datenblatt nicht Open 
Drain genommen sondern "hart" angesteuert. Wenn man den Takt 
entsprechend steuert, geht das prima. Über den Eingang geht es definitiv 
aber nicht.

[(prx) A. K. (prx)]

Georg G. schrieb:
> In einigen der gängigen Libs wird entgegen dem Datenblatt nicht Open
> Drain genommen sondern "hart" angesteuert.

Bei 8051 Ports ist das auch nicht wirklich "hart". Um den Pullup kommt 
man auch dann nicht herum und falsch bleibt auch dann falsch, wenn es 
funktioniert. Es geht auch nur um die Datenleitung. Die Taktleitung ist 
unidirektional.

[Georg G. (df2au)]

Der TO verwendet einen ATMega. Und auch die Libs, auf die ich mich 
beziehe, sind für ATMega. Glaub mir einfach, es funktioniert 
hervorragend. Der SHT11 wird nur bei passendem Taktpegel niederohmig. Du 
hast alle Zeit der Welt, den Ausgang umzuschalten.

[(prx) A. K. (prx)]

Und wo liegt der Vorteil? Man muss dann Richtungs- und Ausgaberegister 
steuern. In der open drain Version hingegen nur die Richtung.

[Konrad B. (brutzelnerd)]

Hi Zusammen!
Vielen Dank nochmal für die Hinweise!
Ich habe nun den Verdacht, dass der Sensor kaputt ist, da ich den Befehl 
für die Temperaturmessung gesendet habe, Oszi sei dank, konnte ich es 
auch "ansehen".
Aber es fehlt die Bestätigung des Sensors, das der Befehl gültig war.
Es kann sein, dass ich ihn vorhin beim anschliessen verkehrt gepolt 
habe, das nimmt er mir bestimmt übel, schöner Mist!
Einen Sensor habe ich noch, mal sehen, ob es damit klappt!
VG
Konrad

[Konrad B. (brutzelnerd)]

So wie es aussieht ist auch dieser Sensor hin, zumindet kommt keine 
Bestätigung, dass der Befehl gültig ist.
Schade!!

[Konrad B. (brutzelnerd)]

Hi!
Anscheinend ist auch ein weitere Sensor kaputt, er gibt keine 
Bestätigung, wenn ich ihm ein Komando sende!
Ich warte erstmal, bis ich neue Sensoren bekomme und sehe dann weiter!
VG
Konrad

[Dirk K. (dekoepi)]

Wie wahrscheinlich ist es, dass drei Sensoren mit demselben Fehler 
kaputt sind?
Ist da nicht wahrscheinlicher, dass die Ansprache inkorrekt ist?

[Konrad B. (brutzelnerd)]

hi Dirk!
Ja, es ist nicht sehr wahrscheinlich, aber ich denke mal, zwei Sensoren 
sind durch meinen Dummheit kaputt gegangen, da ich sie verkehrt gepolt 
angeschlossen habe, bei einem habe ich es auch gerochen, also eigene 
Dummheit!!
VG
Konrad

[Mike J. (linuxmint_user)]

Es gibt doch diese DHT22 oder auch die DHT11 Sensoren, die sind nicht so 
fummelig.

DHT11: 10 Stück für EUR 9,28 ... oder Preisvorschlag :-)
http://www.ebay.de/itm/10pcs-DHT11-Humidity-Sensor-Temperature-Sensor-Digital-Output-for-Arduino-DE-/231238598923

DHT11 mit Befestigungsplatine: 1,47 Euro
http://www.ebay.de/itm/DHT11-Digitale-Temperatur-Und-Feuchte-Sensor-Modul-Temperatursensor-Kabel-/390794837948

DHT22 (3.3V): 1 Stück für 2,93 Euro, aber dafür genauer.
http://www.ebay.de/itm/DHT22-AM2302-Digital-Temperature-and-Humidity-Sensor-Replace-SHT11-SHT15-/140786274816

[Konrad B. (brutzelnerd)]

Hi zusammen!
Als ich mir noch makl alles angesehen habe, auch meine 
Osziaufzeichnungen, fiel mir auf, dass ein Hight an DATA nur knapp 2V 
sind, der Sensor braucht aber laut Datenblatt min. 80%Vdd was in meinem 
Fall 3,84 V sind, die aber nicht anliegen. Kann es sein, dass dadurch 
nichts passiert, klingt mir sehr logisch!
Ich habe extra noch mal nachgesehen, es ist auch ein 10k Widerstand, der 
zwischen DATA und Vdd hängt, wie im Datenblatt angegeben!
Die meisten hier nehmen auch die 10 K, und es funktioniert, nun verstehe 
ich den Fehler erst recht nicht!
Viele Grüße
Konrad

[Marc V. (Firma: Vescomp) (logarithmus)]

Konrad Bethmann schrieb:
> Als ich mir noch makl alles angesehen habe, auch meine
> Osziaufzeichnungen, fiel mir auf, dass ein Hight an DATA nur knapp 2V
> sind

 Ohne Sensor ?

[Konrad B. (brutzelnerd)]

Doch mit sensor am µC, ich habe das schon vorher mal beobachtet, aber 
nichts dabei gedacht, nun sehe ich das etwas anders!

[(prx) A. K. (prx)]

Wenn keine Kommunikation läuft, dann sollte auf der DATA Leitung über 
den Pullup-Widerstand die volle Versorgungsspannung anliegen. Wenn das 
nicht der Fall ist, dann ist was faul. Egal ob das 10K sind oder 
weniger, die Leitung ist muss offen sein.

Bei einem defekten Sensor ist an dieser Stelle natürlich alles möglich. 
Wenn die 2V aber auch ohne Sensor zu messen sind, dann hast du ein 
gänzlich anderes Problem.

[Konrad B. (brutzelnerd)]

Hi zusammen!
Welch Wunder, nun funktioniert es doch irgendwie, zumindest sieht es so 
aus, dass der Sensor meinen Befehl akzeptiert und was misst. Er legt die 
Datenleitung nach dem Befahl kurz auf Low und dann wieder higth. Nun 
dauert es ne Weile und dann wird die Datenleitung wieder low. Habe ich 
das Datenblatt richtig verstanden, dass ich nach dem Low auf der 
Datenleitung (nach der Messung) Wieder pulse auf die SCL-Leitung geben 
muss und bit für bit die Messwerte auslesen kann?
VG
Konrad

[Mike J. (linuxmint_user)]

Ist die DHT22 Software nicht zu den DHT11 / SHT11 kompatibel ?

http://moretosprojects.blogspot.de/2014/01/dht22-blocking-library-for-avr.html

Sie funktioniert bei mir wunderbar.

Man kann aber nur maximal alle 2 Sekunden einen neuen Wert bekommen, 
steht jedenfalls so im Datenblatt.

Im DHT22 ist ein 4k7 Ohm Widerstand von Vcc nach Data schon integriert.

[Konrad B. (brutzelnerd)]

Anscheinend funktioniert der Sensor wirklich, denn wenn ich den Befehl 
zur Feuchtemessung gebe, ist die Datenleitun viel eher wieder auf low, 
als wenn ich den Temperaturbefehl sende.
Nach dem ich einige Leute bestimmt zur Verzweiflung getrieben habe, 
wofür ich mich entschuldige, ist das Fazit des Ganzen, nicht einfach 
Blind fremden Code zu übernehmen, sonsdern selbst was tun!
Danke trotzdem für die Hilfe und wenn ich auch richtige Daten habe(z.B. 
Temperaturwerte), dann werde ich mich wieder melden!
VG
Konrad

[Mike J. (linuxmint_user)]

In dem DHT22 Code von dem Brasilianer kann man das mit den Zeiten 
wunderschön sehen, der Code ist übersichtlich und hat mir sehr geholfen.

Ich hatte damals auch Probleme damit, zum einen weil mir eine 
Interruptroutine immer während des Lesevorganges reingesprungen ist und 
ein anderes mal weil ich + und Data vertauscht hatte.

[Konrad B. (brutzelnerd)]

Guten morgen zusammen!
Evtl. Können mir die C-Profis noch mal helfen!
Nachdem ich nun Hoffnung habe, dass der Sensor tut, was er tun soll, 
komme ich nicht weiter. Laut datenblatt legt der SHT11 während einer 
Messung DATA auf higth und wenn die Messung beendet ist zurück auf low.
Nun wollte ich mit folgender Schleife warten, bis wieder Low ist und 
dann weitermachen, doch es klappt nicht und ich erkenne den Fehler 
nicht!

for (a=0;a<65035;a++)
{
  if (!(PIND & (1 << data)))
            {break;}
            else {_delay_us(6);}
}
// Byteeinlessen
...

Wie gesagt, nichts passiert!
VG
Konrad
@Mike
Danke für deine Hinweise, bin noch nicht dazugekommen, mir den Code 
richtig anzusehen!

[Georg G. (df2au)]

Warum nimmst du nicht erst einmal eine erprobte Lib und änderst dann 
nach deinen Vorlieben?

Hier eine simple Leseroutine (die den Port nicht Open Drain macht, aber 
dennoch funktioniert).

Die Messung mit Warteschleife:

/*---------------------------------------------------------------------------*/
static uint8_t measure(uint8_t *p_value, uint8_t *p_checksum, uint8_t mode) {

    uint8_t     error   = 0;
    uint8_t     ack     = 1;
    uint16_t    i;
 
    transmission_start();
    error = write_byte(mode);
#ifdef DEBUG
    lcd_puts_P("CMD-Write: ");
    if (error) {
        lcd_puts_P("ERROR ");
        }
    else {
        lcd_puts_P("OK ");
        }
#endif
    _delay_ms(1);
 
  /* wait until sensor has finished measurement or timeout */
    for (i = 0; (i < SHT11_MEASURE_TIMEOUT) && (!error); i++) {
        ack = SHT11_READ_DATA;
        if (!ack) {
            break;
            }
        _delay_ms(1);
        }
 
    error += ack;
#ifdef DEBUG
    if (error) {
    lcd_puts_P("Timeout ");  
        }
    else {
        lcd_puts_P("Execute OK ");
        }
#endif           
  /* read MSB */
    *(p_value + 1) = read_byte(SHT11_ACK);
  /* read LSB */
    *(p_value) = read_byte(SHT11_ACK);
  /* read checksum */
    *p_checksum = read_byte(SHT11_NO_ACK);
 
    return (!error);
    }

Und die Byte-Lese-Routine

/*---------------------------------------------------------------------------*/
static uint8_t read_byte(uint8_t ack) {

    uint8_t i;
    uint8_t value = 0;
 
    SHT11_DATA_IN;
    _delay_us(MINI_DELAY);
 
  /* read value bit by bit */
    for (i = 0; i < 8; i++) {
        value = value << 1;
        SHT11_SCK_HIGH;
        _delay_us(MINI_DELAY);
        if (SHT11_READ_DATA) {
  /* increase data by one when DATA is high */
            value++;
            }
        SHT11_SCK_LOW;
        _delay_us(IF_SPEED);
        }
 
  /* send ack if necessary */
    SHT11_DATA_OUT;
 
    if (ack) {
        SHT11_DATA_LOW;
        _delay_us(IF_SPEED);
        }
    else {
        SHT11_DATA_HIGH;
        _delay_us(IF_SPEED);
        }
 
    clk_signal();
 
  /* release data line */
    SHT11_DATA_IN;
 
    return(value);
    }

[Konrad B. (brutzelnerd)]

Hallo Georg!
Danke dir. Ich habe schon einige Libs probiert und nie hat was 
funktioniert, deshalb habe ich aus den verschiedenen Versionen selbst 
was zusammen gesetzt, ohne viel Gedöns, aber es klappt nicht so wie ich 
das will, ich werde wohl noch mal was tun müssen!
VG
Konrad

[Konrad B. (brutzelnerd)]

Hallo Zusammen!
Nun läuft es wunderbar!!!
Ich habe den Code von A.K. genommen und es klappt!
Ich habe einen ziemlich dummen Fehler gemacht, aber es funktionier und 
hatte nichts mit dem Auslesen des Sensors zu tun!!
Vielen Dank noch mal an alle, aUCH WENN ES VERMEIDBAR GEWESEN WÄRE; SO 
HABE ICH ZUMINDEST VIEL GELERN; DAS IST MIR AUCH WICHTIG!
VG
Konrad