AVR ATtiny13 DS18B20/DS18S20 I2C PCF8574 LCD Temperaturanzeige

[Josef F. (tiny_joe)]

Hallo ATtiny 13 Freunde,

folgenden Beitrag Beitrag "AVR ATtiny13 I2C PCF8574 LCD Display Ansteuerung" hatte ich 
2020/06 hier eingestellt. Nun hat mir Manfred Gabriel darauf beziehend 
geantwortet, mit der Bitte seine Dateien und Verbesserungen hier im 
Forum einzustellen.
Sein Programm hat er wesentlich erweitert im Vergleich zu meinem 
Beitrag, sodass der Attiny 13 von einem Temperatursensor DS18B20 oder 
DS18S20 die Daten holt, diese Aufbereitet und über I2C und PCF8574 an 
ein LCD Display sendet.
Dies ist wieder ein gutes Beispiel, was man alles mit den Attiny13 
machen kann.

viel Spass mit Attiny13 wünschen

Manfred und Joe

[Falk B. (falk)]

Josef F. schrieb:
> Dies ist wieder ein gutes Beispiel, was man alles mit den Attiny13
> machen kann.

Aber ein schlechtes zum Thema Netiquette. So viele Dateien packt man 
in ein ZIP-Archiv. Außerdem besser ins Forum Projekte & Code.

[Gerald B. (gerald_b)]

Nur weil man das in einen kleinen Tiny reinbekommt, ist es noch lange 
nicht sinnvoll. Rechne ich zum 8 beinigen Tiny preislich noch den I2C 
Expander dazu, dann kann ich auch gleich einen Atmega, der genügend Pins 
für das Display liefert, kaufen. Auf der Leiterplatte wird es sicherlich 
auf die selbe Platzmenge hinauslaufen, ist aber mehr zu routen.
Wenn es nicht gerade an der momentanen Erhältlichkeit scheitert, sehe 
ich wenig Grund für derlei Handstände.

[Falk B. (falk)]

Pepe T. schrieb im Beitrag #7006846:
> Das ganze 1-wire zeugs in ASM zu machen war wahrscheinlich nicht so
> einfach.

Gähn, das ist doch nur bissel Bitgeklimper. Wo liegt da das Problem?

> Das erzeugt bei mir schon eine gewisse bewunderung und auch
> respekt.

Naja, alles eine Frage der Perspektive.

[MaWin (Gast)]

Falk B. schrieb:
> Aber ein schlechtes zum Thema Netiquette. So viele Dateien packt man in
> ein ZIP-Archiv

Noch irgendwas an Gemecker auf Lager ? Lieber gleich raus damit, bevor 
man erst nach 10 Salamischeiben weiss, wer hier der Kotzbrocken ist.

Geralds Hinweis, dass es Ungeschickt ist, erst einen minderbemittelten 
Attiny13 zu kaufen um dann teuer mit einem Portexpander nachhelfen zu 
müssen, ist natürlich gültig, und ASM ist nicht unbedingt nötig bei so 
einer einfacher Aufgabe, aber so ist es halt ein Beispiel für 
Assemblerprogrammierung.

[Gabriel M. (m_gabriel)]

Hallo Pepe,

die „DS18x20 .asm“ laufen bei mir am Tiny13, Tiny2123, Mega8 und Mege328 
auch bei unterschiedlichen Taktfrequenzen.
Dazu müssen natürlich die Werte im „Write .asm“ angepasst werden.
Die Anzeige am LCD ist der angeschlossen Hardware entsprechend 
anzupassen.
Bei größeren Entfernungen sollte auch der 4,7k input pullup am DS18x20 
eingesetzt werden.
Auch der CRC-Generator ist in dem Programm zu finden.

Vielen Spaß bei der Weiterentwicklung
Manfred Gabriel

[Peter D. (peda)]

Gabriel M. schrieb:
> die „DS18x20 .asm“ laufen bei mir am Tiny13, Tiny2123, Mega8 und Mege328
> auch bei unterschiedlichen Taktfrequenzen.
> Dazu müssen natürlich die Werte im „Write .asm“ angepasst werden.

Ich benutze dann doch lieber meine C-Routinen, da muß ich nur die 
Definition von F_CPU anpassen.

Oft summiert sich aber die Gesamtzeit von 1-wire Routinen, so daß die 
Mainloop merkbar verzögert wird. Daher ist es praktisch, wenn man das 
1-Wire im Hintergrund per Timerinterrupt laufen lassen kann.
Hier ein Codebeispiel:
Beitrag "DS18B20 mit Interrupt, AVR-GCC"

[Falk B. (falk)]

Hmmm. Vielleicht bin ich ja doof, aber das Ding assembliert keine 
Sekunde, hunderte Fehler! Es fehlen die Includes für die Headerdateien. 
Wie hat das der OP assembliert? Irgendwelcher Kommandozeilenmurks mit 
eingefügten Includes?

Naja, von Anfängern für Anfänger, zur Abschreckung?

[Bla bla (Gast)]

Assembler im Jahr 2022?

[Falk B. (falk)]

Egal, wenn's Spaß macht?!

Man muss nur

.include "tn13adef.inc"

Am Anfang von main.asm einfügen, dann assembliert es fehlerfrei.

Naja, trotz des kleinen Fehlers ist die Gesamtstruktur schon mal ganz 
gut, auch wenn das Leute mit mehr Erfahrung an einigen Stellen anders 
machen würden, aber das ist normal. Daumen hoch!

[Falk B. (falk)]

Sooo, ich war mal so frei, das Ganze ein wenig aufzupolieren. Ich habe 
die Struktur weitestgehend so gelassen, nur an wenigen Stellen 
Funktionen zusammengelegt. Siehe Anhang, das Original und die neue 
Version. Ist auch real getestet worden, läuft fehlerfrei ;-)

- Wartefunktionen verallgemeinert, Aufruf mit Parameter über temp2, 20 
Bytes gespart
- Umschaltung des Testpins (TOGGSE) durch einfachen Schreibzugriff auf 
PIN-Register vereinfacht, 12 Bytes gespart
- Wait_RAM_ROM in warte_2s umbenannt und in wait.asm verschoben, Der 
Name einer Funktion sollte klar sagen, WAS sie tut!
- Namen für ID und Temperaturdatenpakete umbenannt
- LCD_Line_1 in PRINT_DS18x20_TYPE umbenannt, etwas komprimiert und 
Kommentare verbessert, 6 Bytes gespart
- In den One Wire Funktionen sind einige Fehler drin.
- 1.) Das Pin ist Open Drain, da darf NIEMALS aktiv HIGH ausgegeben 
werden, das macht nur der externe Pull-Up Widerstand!
- 2.) Beim Auslesen der Temperatur muss man DEUTLICH länger als 480us 
warten, bis man das Ergebnis lesen kann! Je nach Sensor und 
eingestellter Auflösung zwischen 93ms(9 Bit) bis 750ms (12 Bit)!
- Anzeigefunktionen für Temperatur aufgeräumt, Anzeige mit 1 
Nachkommastelle (reicht locker, auch wenn man theoretisch etwas 
Auflösung verschenkt)
- Onewire CRC Berechnung entwirrt und vereinfacht
- Onewire Zeitverhalten verbessert und korrigiert, es fehlt u.a. die 
Wartezeit am Ende eines Bits, das funktionierte nur, wegen der 
illegalen, aktiven Schaltung nach HIGH!
- I2C Routinen aufgeräumt und Fehler korrigiert. Auch hier waren 
illegale, aktive HIGH Pegel für SCL und SDA generiert worden, außerdem 
wurden an eingen Stellen konstante PORT-Register benutzt, anstatt der 
global konfigurierten PORT_DDR etc.

Allgmein:

- Sinnvolle, selbsterklärende Namen für Variablen und Labels bzw. 
Funktionen nutzen! Damit entfallen alle Kommentare! Nomen est Omen!
- Funktionsnamen haben meist eine Aktion, die mit einem Verb beschrieben 
wird, get, set, print, clear, check etc. Dazu ein Subjekt wie data, 
sensor, etc.
- Innerhalb von Funktionen hierarchische Namen für Labes verwenden. In 
Assembler gibt es nur einen Namensraum, da wird es schnell 
unübersichtlich. Z.B. so

- Schreibe_Daten:
- Schreibe_Daten_schleife:
- Schreibe_Daten_fehler:
- Schreibe_Daten_ende:

https://www.mikrocontroller.net/articles/Strukturierte_Programmierung_auf_Mikrocontrollern

Ich habe versucht, das Denglisch einzudämmen, klappt mal mehr mal 
weniger 8-0. Oder man schreibt gleich alles in Englisch. Am Ende sank 
der Flashbedarf von 960 auf zwischenzeitlich 860 Bytes, wobei ich dann 
noch ein paar neue Funktionen eingebaut habe, z.B. die Anzeige der 
Version. Ganz nett, aber das war nicht das wesentliche Ziel der 
Aufräumaktion. Viel mehr ging es darum, den Code deutlich besser lesbar 
zu machen.

Wenn man das Projekt aufbaut, muss man prüfen, ob die I2C Adresse sowie 
die Pinzuordung vom PCF7584 zum LCD stimmt.

Viel Spaß beim Nachbauen

[Falk B. (falk)]

Leute, verschont MICH und DIESE Diskussion mit diesem PWM-Lüfter 
Fetischismus! DANKE!