So, ich habe mal den Code aus #18 als Ausgangspunkt genommen. Um das ganze mal durch den Bascom-Simulator zu jagen, habe ich mit bedingter Compilierung(*) die 1wire-Instruktionen überspringen lassen (korrekter: entfernen lassen), wait-Instruktionen verkürzt, und das Scratchpad-Abbild direkt definieren lassen.
Der Code aus #18 belegt offensichtlich ca. 50% des Mega8-FLASHs - meine Simulator-Modifikationen reduzieren das auf ca 44%.
Natürlich bietet der Code noch viele Optimierungsmöglichkeiten - aber darum geht's erstmal nicht.
Die Hauptprogrammschleife besteht (quasi) aus dem Anstoßen der Messung, einer Wartezeit (warum hast Du die 900ms aufgeteilt?) und dem Auslesen der Sensoren nebst Umrechnung und Darstellung.
Auf "Messung anstoßen" hast Du wegen Verwendung der 1wire-Bibliothek keinen Einfluß, wegen der vorgegebenen Timings erst recht nicht. Ich kann es im Simulator auch nicht auswerten - bleibt außen vor.
Die Warte-Instruktion(en) würde ich aus den Routinen rausnehmen, separat in die Hauptprogrammschleife aufnehmen. Man könnte auch statt zu warten timerbasiert wiederholt Messungen starten und Sensoren auslesen/auswerten/darstellen, und den Controller nebenbei was anderes machen lassen.
Von der Reihenfolge her wäre dann in der Schleife folgendes interessanter:
Ruft man das ganze timerunterstützt ... sagen wir mal einmal pro Sekunde .. regelmäßig auf, entfällt das Warten natürlich.
Jedenfalls hab ich mir die Zeiten der eigentlichen Rechnung mal angesehen:
Das Prüfen der CRC kostet (mit dem von mir gewählten Beispiel (erstes Abbild aus dem Log von #15)) 657 Takte (ca 41µs).
Die Berechnung bis Zeile 186 (also wo's noch ganzzahlig abgeht) kostet insgesamt 715 weiter Takte (ca 44,7µs) (im wesentlichen die beiden Integer-Divisionen mit je ca. 280 Takten).
Die Single-Division kostet allein auch 676 Takte (42,25µs) - also etwa die Hälfte der ganzen Rechenzeit.
Überraschend viel kostet die Stringumwandlung: 6489 Takte (405,6µs).
Die Rückkehr ins Hauptprogramm verbraucht - im wesentlichen wegen Print - nochmal ca 200 Takte (12µs) für einen ausgegebenen Wert.
Was mir aufgefallen ist:
(*) Compilerkonstante am Anfang definiert, entsprechende Code-Blöcke in Abhängigkeit dieser Konstante mit
CodeBox BascomAVR
Der Code aus #18 belegt offensichtlich ca. 50% des Mega8-FLASHs - meine Simulator-Modifikationen reduzieren das auf ca 44%.
Natürlich bietet der Code noch viele Optimierungsmöglichkeiten - aber darum geht's erstmal nicht.
Die Hauptprogrammschleife besteht (quasi) aus dem Anstoßen der Messung, einer Wartezeit (warum hast Du die 900ms aufgeteilt?) und dem Auslesen der Sensoren nebst Umrechnung und Darstellung.
Auf "Messung anstoßen" hast Du wegen Verwendung der 1wire-Bibliothek keinen Einfluß, wegen der vorgegebenen Timings erst recht nicht. Ich kann es im Simulator auch nicht auswerten - bleibt außen vor.
Die Warte-Instruktion(en) würde ich aus den Routinen rausnehmen, separat in die Hauptprogrammschleife aufnehmen. Man könnte auch statt zu warten timerbasiert wiederholt Messungen starten und Sensoren auslesen/auswerten/darstellen, und den Controller nebenbei was anderes machen lassen.
Von der Reihenfolge her wäre dann in der Schleife folgendes interessanter:
- Auslesen
- (neue) Messung Triggern
- (ggf.) Warten
Ruft man das ganze timerunterstützt ... sagen wir mal einmal pro Sekunde .. regelmäßig auf, entfällt das Warten natürlich.
Jedenfalls hab ich mir die Zeiten der eigentlichen Rechnung mal angesehen:
Das Prüfen der CRC kostet (mit dem von mir gewählten Beispiel (erstes Abbild aus dem Log von #15)) 657 Takte (ca 41µs).
Die Berechnung bis Zeile 186 (also wo's noch ganzzahlig abgeht) kostet insgesamt 715 weiter Takte (ca 44,7µs) (im wesentlichen die beiden Integer-Divisionen mit je ca. 280 Takten).
Die Single-Division kostet allein auch 676 Takte (42,25µs) - also etwa die Hälfte der ganzen Rechenzeit.
Überraschend viel kostet die Stringumwandlung: 6489 Takte (405,6µs).
Die Rückkehr ins Hauptprogramm verbraucht - im wesentlichen wegen Print - nochmal ca 200 Takte (12µs) für einen ausgegebenen Wert.
Was mir aufgefallen ist:
- zu den WAITs hatte ich schon was gesagt
- die Messung wird doppelt getriggert (einmal in "Con_temp", einmal in "temperature") - wolltest Du sicher noch korrigieren
- 1wreset - hätte ich vor jedem Telegramm genau einmal erwartet, also In Reihenfolge des Programmflusses:
- in Zeile 104 aber nicht in Zeile 108
- vor dem Auslesen eines jeden Sensors (114, 142, 170) aber nicht nach dem Prüfen der CRC (120, 148, 176)
- Die angegebenen Temperaturen im Logfile passen nicht zu den entsprechenden Werten, der Simulator kommt schon eher hin aber..
- Die Integer-Division (durch Count_per_C) kostet etwas Genauigkeit - viel mehr kostet übrigens die erste Division (auch Integer) durch 10. Insgesamt landest Du damit schon recht weit daneben.
- Im Logfile ist Count_per_C auffällig oft 16 (0x10 bzw &b00010000) - ein DS18S20 arbeitet intern mit 12bit, und simuliert extern einen DS1820 (ohne S), indem er aus dem 12bit-Ergebnis den passenden Count_Remain bei festgelegtem Count_per_C=16 berechnet. Ich habs jetzt zwar nicht geprüft, aber wahrscheinlich hast Du bei jedem Eintrag im Log mit Count_per_C≠16 auch'n CRC-Fehler.
(*) Compilerkonstante am Anfang definiert, entsprechende Code-Blöcke in Abhängigkeit dieser Konstante mit
CodeBox BascomAVR
#If Konstante=0 'Codeblock #else 'Codeblock #Endifin das Compilat aufnehmen lassen oder eben nicht.
Zuletzt bearbeitet: