DS18B20: Wert 4095 nach einiger Zeit

Jens Gast #6640020
Lesenswert?
• ▲
▼ 
Hallo zusammen,

an einem STM320F103 Bluepill habe ich einen DS18B20 angeschlossen. 
Dieser funktioniert auch für einige Zeit. Irgendwann aber erscheint nur 
noch der Wert 4095 und ich muss den Controller resetten. Ich habe 
mehrere Sensoren ausprobiert, immer mit dem selben Fehler.

Angeschlossen habe ich diesen mit 5 V Versorgungsspannung und 3.3 V 
Portspannung. Ein 4k7-Pullup auf 3V3 ist ebenfalls eingebaut. Die 
eingestellten Zeiten in der tim.c passen ebenfalls.

Die Programmierumgebung ist STM32CubeIDE und als Programmer kommt ein 
ST/Link V2 zum Einsatz.

Als Ausgabe habe ich einen HD44780.

Mein Code ist im Anhang.

Was kann die Ursache für dieses Verhalten sein?

Die Berechnung findet hier statt:

1
float read_temperature(void)

2
{

3
    uint8_t check = 2;

4
    uint8_t temp_l;

5
    uint8_t temp_h;

6
    uint16_t temp;

7
    float temperature;

8


9
    check = sensor_init();

10


11
    sensor_write(SKIP_ROM);

12
    sensor_write(CONVERT);

13
    delay_ms(200);

14


15
    sensor_init();

16
    sensor_write(SKIP_ROM);

17
    sensor_write(READ_SCR);

18


19
    temp_l = sensor_read();

20
    temp_h = sensor_read();

21
    temp = (temp_h<<8)|temp_l;

22
    temperature = (float)temp/16;

23


24
    return temperature;

25
}
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Falk B. #6640126
Lesenswert?
• ▲
▼ 
Jens schrieb:
> an einem STM320F103 Bluepill habe ich einen DS18B20 angeschlossen.
> Dieser funktioniert auch für einige Zeit. Irgendwann aber erscheint nur
> noch der Wert 4095 und ich muss den Controller resetten.

Klingt nach einem Fehler in deiner Software.

> Ich habe
> mehrere Sensoren ausprobiert, immer mit dem selben Fehler.

Was schon mal gut ist. Der Fehler ist reproduzierbar.

> Angeschlossen habe ich diesen mit 5 V Versorgungsspannung und 3.3 V
> Portspannung.

Kann man machen.

> Ein 4k7-Pullup auf 3V3 ist ebenfalls eingebaut. Die
> eingestellten Zeiten in der tim.c passen ebenfalls.

Hast du das Signal mit einem Oszi angeschaut?

Die Wartezeit von 200ms passt nur, wenn dein Sensor auf 8 oder 9 Bit 
Auflösung eingestellt ist. Ist er das?

Wenn du 4095 auf der Anzeige hast, dann reagiert dein Sensor nicht mehr 
und es wird immer 0xFF gelesen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #6640139
Lesenswert?
• ▲
▼ 
Wichtig ist, daß es zu keinen Datenkämpfen kommt. Der Portpin darf immer 
nur Output Low oder High Impedance sein. Aber zu keinem Zeitpunkt Output 
High, auch nicht kurzzeitig zwischen 2 Portbefehlen.

Wenn die CPU keinen echten Open-Drain kann, dann muß folgende 
Reihenfolge eingehalten werden:

Für auf high oder Input setzen:
1. Direction auf Input
2. Port auf High

Für auf low setzen:
1. Port auf Low
2. Direction auf Output

Man kann aber auch den Port einmalig auf low setzen und nie auf high.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jens Gast #6640216
Lesenswert?
• ▲
▼ 
Falk B. schrieb:
> Hast du das Signal mit einem Oszi angeschaut?
>
> Die Wartezeit von 200ms passt nur, wenn dein Sensor auf 8 oder 9 Bit
> Auflösung eingestellt ist. Ist er das?
>
> Wenn du 4095 auf der Anzeige hast, dann reagiert dein Sensor nicht mehr
> und es wird immer 0xFF gelesen.

Auch bei 750 ms zeigt er das Verhalten. Mit dem Oszi habe ich mal 
geschaut, auch das sieht ganz gut aus. Im Fehlerfall sind es dann nur 
noch 3.3 V
Antwort Zitieren Bearbeiten Löschen Beitrag melden
jo mei Gast #6640328
Lesenswert?
• ▲
▼ 
Peter D. schrieb:
> Wenn die CPU keinen echten Open-Drain kann,

Kann sie aber. Der F103 kann das!

Ich mache das bei meinen Soft-I2C-Treibern so. Damit ist man
auf alle Fälle gefeit gegen Bus-Figths. Entscheidend ist aber
dass man bei Lesen eines Ports das Input-Data-Register aus-
wertet (im Gegensatz zum Output-Wert der davon abweichen kann).

Der Open-Drain-Betrieb ist die einzige Methode die sicher
dagegen hilft dass ein Slave und ein Controller gleichzeitig
den Pin-Pegel bestimmen wollen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Beitrag #6640353 wurde von einem Moderator gelöscht.
Beitrag #6640364 wurde von einem Moderator gelöscht.
Beitrag #6640373 wurde von einem Moderator gelöscht.
Beitrag #6640394 wurde von einem Moderator gelöscht.
jo mei Gast #6640619
Lesenswert?
• ▲
▼ 
Peter D. schrieb:
> Ich würde diese Konstante aber als Push-Pull interpretieren

Das wird Jens auch nie gegenteilig behauptet haben.

Er hat es halt so implementiert "weil es funktioniert" (so auf
den ersten Blick zumindest), über gelegentliche Bus-Kämpfe wird
er sich dagegen keine Gedanken gemacht haben.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Beitrag #6640884 wurde von einem Moderator gelöscht.
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren