Portbelegung auf ATMega für LCD1602

[avr_racer]

So, bin schon wieder da

Nichts tragisches ...!

@avr_racer,
ich hab mir deine Zeitenrechnung genauer angesehen und bin zur Ansicht gekommen, dass sie nicht stimmt.
Jetzt gibt es zwei Möglichkeiten:
1. sie stimmt wirklich nicht oder
2. meine Rechnung stimmt nicht!

Dein Beispiel aus text3: (cc = cpu clock cycle = 1µs)
wait25us:
ldi r20,$20 ;1cc
wait25us1:
dec r20 ;1cc
brne wait25us1 ;1/2cc
ret
Nehmen wir brne mit 1cc an (=1µs), dann ergibt das folgende Rechnung:
$20 sind dezimal 32. Also 32 Durchgänge/Schleifen.
32 mal 2 (dec + brne á 1µs) ergibt 64µs und keine 25.

Wo liegt nun der Gedanken-Fehler?
Bei mir oder bei dir?

Bei 1Mhz
;Call = 3 Takte (3µs)
wait25us:
ldi r20,$20 ;1cc ; 1Takt (1µs)
wait25us1:
dec r20 ;1cc ; 1Takt (1µs)
brne wait25us1 ;1/2cc ; 1Takt bei 0 und 2 Takte wenn !=0 also (1µs oder 2µs)
ret ; 4Takte (4µs)

3µs + 1µs + (32*3µs(!=0) - 1µs(bei 0)) + 4µs = 103µs bei 1Mhz

Ich habs mir mal geschrieben und passe es auf die Frequenz an, ja es geht auch anders und manchmal verwirrend

@alle:
Übrigens stehe ich schon länger auf der Leitung und komm nicht weiter.
Ich will/muss einen ADC-Wert (8Bit ADLAR genügt) in Volt umrechnen (Akkuspannung 12V, max. 13,7 Ladeschlussspannung).
Folgende ADC-Beschaltung: 15V-68k-ADC-50kPot-GND.
Bei exakt 15V wird mit einem Spindelpoti der ADC-Maximalwert genau auf 5V eingestellt.
Somit hab ich eine Reserve, sollte die Spannung mal über 13,7V ansteigen.
Zudem dient eine 5V Z-Diode als Schutz.
Bei 15V liegen nun 5V am ADC. Das ergibt einen ADC-Wert von 255 (ADCH).
Das ist Basis für die weiteren Berechnungen.
Nehmen wir nun als zu messende Spannung 10,4V an.
Das ergibt folgende Schlussrechnung:
15V.....255
10,4V....?
10,4*255/15=177 gerundet.
Oder anders rum:
255/15=17*10,4=177 gerundet (was ADC dann tatsächlich bingt? 176/177?)
Jetzt drehen wir die Sache um:
177/17=10,4 gerundet.

Ja ADLAR lässt den ADC auf 8Bit schrumpfen somit ist deine Auflösung 5V (AREF) / 256bits = 0,0195..V also 19,5mV pro Bit
Diesen Wert deklarierst du dir als z.B: 195 in der Init und MULTIPLIZIERST du dir dann mit den im ADCH zu Verfügung stehenden BITS z.B.: mit 256 = 49920.
Dein Widerstandsteilerverhältnis ist 3:1 heißt 49920*3 = 149760 den Punkt richtig setzen und du hast deine 14.976V ohne geschönt zu haben.

1. 10,4*255/15 sind verkehrt denn 8bit ADC hat 256 Stufen die 0 gehört mit dazu
richtig also 10,4*256/15 =177,493bits. Abgeschnitten sinds dann nur 177 wie es auch korrekt ist. Aufgrund das dir jetzt aber im Wandler die Nachkommastellen fehlen wirds halt ungenauer.
Nur mit der Multiplikation ist es einfacher

177bits * 195(bits/V) = 34515(V) * Teiler 3 = 103545(V) jetzt nur den Punkt im LCD richtig setzen und du hast deine 10.3545V auf dem LCD, ohne DIVISION.
Nur über FESTKOMMAARETHMETIK

Nun hab ich nachstehende Divisions-Routine im Netz gefunden.
Allerdings rechnet die (auch) nicht richtig.
Da steht im Rest (=Nachkommastelle) nach obiger Rechnung, statt 4 eine 8!
Wo liegt hier der Fehler, bzw. wie/wo kann man das berichtigen?
Ich möchte bei den Zehntel-Volt schon relativ genau sein.

Sonst schaut bisher alles gut aus ...

; 8Bit Division mit Rest; Laufzeitverhalten im schlechtesten Fall (255/1) 103 Taktzyklen
; Achtung:
; Divison durch 0 wird nicht abgefangen und führt zu einer Endlosschleife
; Dieser Algorithmus funktioniert nur für vorzeichenlose 8Bit-Werte
; Nach Division steht das Ergebnis in r18 und der Rest in r16

.def divident =    r16
.def divisor =    r17
.def ergebnis =    r18
.def zw =    r19
    ldi    divident,177        ; Berechnet 177/17 !
    ldi    divisor,17      
division:
    clr    ergebnis        ; Ergebnis initialisieren
    ldi    zw,1            ; Teilbarkeit durch 1 annehmen
    tst    divisor
loop:
    brmi    div_loop        ; Den Divisor linksbündig ? -> JA
    lsl    zw            ; Zwischenergebnis und
    lsl    divisor            ; Divisor einen Schritt nach links
    rjmp    loop            ; ... und nochmal prüfen
div_loop:
    cp    divident,divisor    ; divident >= divisor
    brlo    division_weiter        ; -> nein
    add    ergebnis,zw        ; Ergebnis vergrößern und
    sub    divident,divisor    ; Dividenten verkleinern
division_weiter:
    lsr    divisor            ; Divisor und Zwischenergebnis
    lsr    zw            ; einen Schritt nach rechts
    brne    div_loop        ; zw!=0 ? ->JA
    nop                ; Ergebnis in ergebnis
                    ; Rest in divident !
end:     rjmp    end

Wo hast denn die Routine her ? Ähm der Rest steht nicht zufällig im DIVIDENT R16 drin mit 7 ??

177/17 = 10, ;10*17 = 170
177 -170 = R 7 ;7/ 17 schwer also 7*10 = 70
70/17 = 4 also 10,4 ;4*17 = 68 somit
70-68 = R 2 ;2/17 schwer also 2*10 = 20
20/17 = 1 also 10,41 ; 1*17 = 17
20-17 = R 3 ; 3/17 schwer also 3*10 = 30
30/17 = 1 also 10,411 usw...

Im AVR-Studio funktionieren aber sehr wohl auch T0 und T1 OVF.
Kann ich davon ausgehen, dass das auch in der Realität so ist?

NEIN das Datenblatt weiß mehr als der Simulator ausser es ist unter der Hilfe angegeben. Grundsätzlich aber das Datenblatt ausschlaggebend.

Man kann aber den Timer laufen lassen oder den Prescaler vor den SLEEP-Befehl zu setzen ist nun nicht wirklich kein Problem oder ?