Forum: Compiler & IDEs DS18S20 in C


von Ronny Schulz (Gast)


Angehängte Dateien:

Lesenswert?

Ich versuche den DS18S20 von Maxim jetzt mit C anzusprechen. Aber da
gibts irgendwie Probleme. Ich habe die Zeiten nochmal aus der AppNote
entnommen und Besserung hat sich nicht eingestellt. Es werden bei jedem
Durchlauf immer verschiedene Werte angezeigt, wenn ich das Scratchpad
auslese.

Kann jemand irgdnwie einen Fehler erkennen? Wäre echt super.

von Peter D. (peda)


Lesenswert?

Du hast Dir bestimmt noch nie den erzeugten Assembler angesehen.

if ((1<<bits) & c)

ist nämlich ein äußerst uneffektives Konstrukt und kann schon alleine
eine Menge Zyklen verbraten, die obendrein nicht mal konstant sind.

Besser ist:

if( c & 1 )

und dann am Ende der Schleife schieben:

c >>= 1;


Peter

von Ronny Schulz (Gast)


Lesenswert?

Hmm .. ich habe mir den ASM-Code natürlich nicht angeschaut, deshalb
mache ich das Ganze ja jetzt in C. Das einzige, was ich mache ist den
Debugger von AVR-Studio drüber laufen zu lassen, wobei das auch recht
müssig ist, da der mir ja nur die Registerinhalte usw. anzeigt, aber
nicht wirklich die Variablen. Sonst bilde ich mir ein, das ganze
Konstrukt mal getestet zu haben. (Ausgabe auf die serielle).

Also rein funktionell ist das kein Fehler, nehme ich mal an. Denn die
Zeiten beim DS1820 sind ja eigentlich recht tolerant. Aber Danke für
den Hinweis. Aber läuft immernoch nicht besser. Kann man denn so viele
Fehle machen?

von Peter Fleury (Gast)


Lesenswert?

>wobei das auch recht
>müssig ist, da der mir ja nur die Registerinhalte usw. anzeigt, aber
>nicht wirklich die Variablen

Zum Debuggen AVRStudio 4.08 und make extcoff benutzen

von marco schwalm (Gast)


Lesenswert?

Hallo Ronny.

Ich hatte anfangs auch Probleme mit dem DS18S20 unter C. Meine Routinen
waren prinzipiell richtig, jedoch habe ich ab einer bestimmten
Temperatur (ca. 50°C) nur noch Unsinn ausgelesen. Ursache dafür war das
zu ungenau eingehaltene Timing am DS18S20. Ein paar NOP's bei den
kleinen Zeitkonstanten mehr, und seither funtioniert es.

Gruß Marco

von Ronny Schulz (Gast)


Lesenswert?

@Peter Fleury:
Sicher kann ich dann in AVR-Studio debuggen. Aber der Debugger basiert
ja dennoch nur auf ASM-Ebene, sodass ich mir meine Variablen nicht
anschauen kann oder mache ich was falsch?

@marco schwalm:
Wäre es ein Problem den Code mal zu posten. Da kann ich vielleicht ein
paar Vergleiche ziehen. Denn das Ganze funktioniert noch immer nicht -
auch wenn ich die Timings etwas abändere. Gerade unter 10us ist
ziemlich schwierig einzustellen, wenn man eine timerbasiertes delay
zusammengebastelt hat. Aber die Timingroutinen funktionieren sehr gut.
Ich habe gestern mein VFD-Display mal von 1200 auf 9600 baud umgestellt
- einfach die Baudrate in der Headerdatei geändert und lief auf Anhieb.

von Peter Fleury (Gast)


Lesenswert?

>Aber der Debugger basiert ja dennoch nur auf ASM-Ebene, sodass ich >mir
meine Variablen nicht anschauen kann oder mache ich was falsch?

Ja offenbar machst du etwas falsch.

AVRStudio 4.08 und WinAVR mit extcoff ist ein C Source-level Debugger,
wo man auch Variablen ansehen kann.

von Ronny Schulz (Gast)


Angehängte Dateien:

Lesenswert?

Danke ... das mit den Variablen geht jetzt, wie ich mir das vorstelle.
Also doch ein vollwertiger Debugger. Um jetzt zum Thema
zurückzukommen...

Da gab es doch noch Timingprobleme. Gerade die von peter dannegger
angesprochenen shiftereien haben in der Read-Routine um die 80us
verschlungen. Jetzt geht das so halbwegs. Auch wenn der nicht immer
identische Werte ausliest. Soweit ich verstanden habe sind die
count_remain und cout_per_c immer fest, aber bei mir ist das nicht so.
Einer der beiden Werte verändert sich schon. Die Prüfsumme habe ich
versucht zu berechnen und die stimmt auch nie.

Anbei nochmal der Code.

von marco schwalm (Gast)


Angehängte Dateien:

Lesenswert?

Anbei mein Code.

Dieser ist bestimmt verbesserungsfähig, aber er läuft. Insbesondere die
kurzen Wartezeiten habe ich mit NOP's entsprechend der CPU-Frequenz
realisiert. Hier hatte ich anfangs zu kurze Zeiten, was zu Fehlern
geführt hat (CRC-Error).

Gruß
Marco

von Ronny Schulz (Gast)


Lesenswert?

Danke! Ich werde nachher mal reinschauen.

von Sascha Biedermann (Gast)


Lesenswert?

@marco

Aha! Endlich bestätigt mir das mal einer g
Ab 50°C hat bei mir RomSearch nicht mehr funktioniert ...
freu *aha*

von Divison (Gast)


Lesenswert?

Hallo,

ich habe mal dies ds1820 Paket von marko schwalm getestet, aber bei mir
gibt es da immer nur crc errors.

Hat da jemand eine Idee woran das liegen könnte.

Den Pin für den Sensor, und die Pins fürs Display habe ich angepasst.
Nur leider immer fehler.

Hab den an einem 90s8535.

Danke für Hilfe!!

von Marco Schwalm (Gast)


Angehängte Dateien:

Lesenswert?

@Division:

Sorry, in dem Paket fehlt leider die Datei "crc8_cgen1.bin". Diese
256 Byte große Datei habe ich ohne Offset in das EEPROM kopiert, und
nicht die vom Compiler erzeugte Datei "main_eeprom.srec".

Anbei die Datei. Hoffe das jetzt alles Funtioniert. Würde mich mal
interessieren, ob der Code auf deinem AT90S8535 läuft.

Gruß
Marco

von Divison (Gast)


Lesenswert?

Also laufen tut der Code schon, auch ihne diese crc8. Nur misst der
irgendwie falsch. Müsste schon lange erfrohren sein hier drin!

So bei -128,0 C.

Hmmm aber ich habe wirklich keine Ahnung wo da nu der Fehler liegen
könnte?

Also er reagiert schon auf den Sensor, den wenn ich ihn anpuste wirds
ja laut Display noch kälter und dann auf einmal ganz schön warm! :-)

Er zeigt nur Falsche werte an, und springt auch dolle!

Wüsstest du da noch was?

Liebe Grüsse

von Divison (Gast)


Lesenswert?

Ach ja, ich musste bei mir den Timer anders initialisieren. Deshalb die
CRC-Fehler.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.