- LiFePO4 Speicher Test         
Seite 11 von 18 ErsteErste ... 910111213 ... LetzteLetzte
Ergebnis 101 bis 110 von 173

Thema: Portbelegung auf ATMega für LCD1602

  1. #101
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Anzeige

    E-Bike
    Sie bleibt unverändert, egal wie oft E gegen + getippt wird.
    E liegt über einen Widerstand an Plus,
    Du musst E dann 3 mal nach Masse ziehen.

  2. #102
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    Zitat Zitat von Siro Beitrag anzeigen
    E liegt über einen Widerstand an Plus,
    Du musst E dann 3 mal nach Masse ziehen.
    Lieber Siro,
    es steht doch "egal wie oft" gegen Masse gezogen ...
    Aber dein Testaufbau hat mir geholfen!

    Hab mir ein neues 1602 LDC besorgt (€ 13,-)

    Und ....
    BINGO !!!!!!!!!!!!

    @ avr_racer,
    hab daraufhin gleich dein text3-progrämmchen adaptiert (statt portD > portA).
    Und alles funktioniert!

    Danke euch allen!

    Jetzt kann ich mal beruhigt weiter machen ... bis ich auf das nächste Problem stoße ...
    Dann rühr ich mich wieder (bin mir sicher!).
    Spätestens jedoch, wenn ich fertig bin - und das wird noch lange dauern ..................

  3. #103
    Erfahrener Benutzer Fleißiges Mitglied Avatar von avr_racer
    Registriert seit
    01.04.2014
    Ort
    MecklenburgVorpommern
    Beiträge
    174
    Schön zu hören das es funktioniert, weniger schön das ein nicht benutztes und nagelneues einfach defekt war/ist. So kann man sich eben nen Wolf suchen warum das Programm nicht funktioniert obwohl es das tut vllt auch nur in Ansätzen.... Seuftz

  4. #104
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    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?

    @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.
    Umgekehrt:
    255.....15V
    177......?
    15/255=0,0558 Und da haperts schon! Wie rechne ich mit 0,0588?
    177*0,0588=10,4

    Auch hab ich nachstehende Divisions-Routine im Netz gefunden.
    Allerdings rechnet die nicht richtig.
    Da steht im Rest (=Nachkommastelle) bei einer Rechnung 177/17, 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 ...

    Code:
    ; 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
    Geändert von HeSt (11.01.2019 um 13:52 Uhr)

  5. #105
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.703
    Blog-Einträge
    133
    Zitat Zitat von HeSt Beitrag anzeigen
    Da steht im Rest (=Nachkommastelle) bei einer Rechnung 177/17, 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.
    Hallo HeSt,
    Rest ist nicht gleich Nachkommastelle. Ich habe den Code mal durch meinen Bascom Simulator laufen lassen und bekomme als Rest nicht 8 sondern eine 7. 177/17 ist ja gleich 10 Rest 7. Um auf die erste Nachkommastelle von 4 zu kommen, könnte man nun den Rest von 7 wieder durch 17 teilen. Um den gleichen Code zu nutzen erst den Rest von 7 mit 10 multiplizieren und dann den Code mit 70 und 17 füttern.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  6. #106
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    Servus Searcher,
    danke für die Antwort!
    Werde es dann gleich probieren ....

    Eine andere Frage noch an alle:
    Im Datenblatt des Mega16 steht auf Seite 32 in Tabelle 14, dass der µC von den Timern nur durch Timer 2 geweckt werden kann.
    Oder lese ich das falsch!?
    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?
    Klicke auf die Grafik für eine größere Ansicht

Name:	Mega16.png
Hits:	6
Größe:	41,7 KB
ID:	33926

  7. #107
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Es kommt drauf an, welchen Sleep Mode Du möchtest, dann kannst Du sehen, was man nutzen kann, zum Aufwecken (im Datenblatt steht es dann ja). Oder Du entscheidest Dich für eine bestimmte Art und Weise, den aufzuwecken (weil es keine andere Möglichkeit gibt), dann muss geschaut werden, welcher Sleep-Mode dazu möglich ist. Je tiefer der Schlaf, desto weniger Möglichkeiten gibt es zurück zu kehren.

    Beim ATmega328P steht auch nur Timer2. Ich verwende aber Timer1, der dann bei Überlauf einen Interrupt auslöst und auch zum Aufwachen führt.
    Allerdings muss ich darauf achten, dass im jeweiligen Sleep-Mode dann der Timer1 auch aktiv ist. In manchen Modi sind bestimmte Dinge abgeschaltet, dann kann man die nicht nutzen.

    MfG
    Geändert von Moppi (11.01.2019 um 15:23 Uhr)

  8. #108
    Erfahrener Benutzer Fleißiges Mitglied Avatar von avr_racer
    Registriert seit
    01.04.2014
    Ort
    MecklenburgVorpommern
    Beiträge
    174
    Zitat Zitat von HeSt Beitrag anzeigen
    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

    Zitat Zitat von HeSt Beitrag anzeigen
    @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

    Zitat Zitat von HeSt Beitrag anzeigen
    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 ...

    Code:
    ; 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...

    Zitat Zitat von HeSt Beitrag anzeigen
    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 ?
    Geändert von avr_racer (11.01.2019 um 16:07 Uhr)

  9. #109
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    20.09.2008
    Ort
    Linz A
    Beiträge
    126
    Danke für die Antworten!
    Zitat Zitat von Moppi Beitrag anzeigen
    Es kommt drauf an, welchen Sleep Mode Du möchtest, ...
    In diesem Fall ist nur Timer2 angegeben, egal welcher Modus.
    Zitat Zitat von Moppi Beitrag anzeigen
    Beim ATmega328P steht auch nur Timer2. Ich verwende aber Timer1, der dann bei Überlauf einen Interrupt auslöst und auch zum Aufwachen führt.
    Allerdings muss ich darauf achten, dass im jeweiligen Sleep-Mode dann der Timer1 auch aktiv ist.
    Das gibt mir Hoffnung. Im Datenblatt des ATmega328P ist auch nur Timer2 angegeben.
    Zitat Zitat von avr_racer Beitrag anzeigen
    25µs versus 103µs bei 1Mhz
    Mir gings nur darum, ob mein Gedankengang richtig ist.
    Ob da noch vorne und hinten ein paar µs dazu kommen, darum gings nicht.
    Aber danke für die exakte Erklärung!
    Zitat Zitat von avr_racer Beitrag anzeigen
    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
    2 Hundertstel Volt an Genauigkeit genügen mir. Wenn die Zehntel stimmen passt es schon.
    Zitat Zitat von avr_racer Beitrag anzeigen
    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.
    Die Multiplikationen hatte ich ja auch schon im Kopf.
    NUR: ein 16Bit Register (word) fasst nur bis 65535.
    Laut Datenblatt wird das Ergebnis einer Multipikation in R1-R0 geschrieben = 16Bit.
    Wie aber funktioniert diese Multiplikation: 49920*3 = 149760?
    Wo soll 149760 gespeichert werden?
    Oder hier:
    177bits * 195(bits/V) = 34515(V) * Teiler 3 = 103545(V)
    Da fehlt mir noch einiges an Wissen ...
    Zitat Zitat von avr_racer Beitrag anzeigen
    Wo hast denn die Routine her ?
    Irgendwo aus dem Netz. Woher weiß ich nicht mehr.

  10. #110
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Der Timer2 ist glaub ich ein besonderer. Zumindest beim ATmega328P kann man den auch unabhängig takten, selbst, wenn sonst alles schläft und auch der übliche Taktgenerator abgeschaltet ist.
    Das man auch Timer1 verwenden kann oder einen andern, liegt beim 328P daran, dass der auch durch so ziemlich jeden Interrupt geweckt werden kann. So löst auch der Timer1 bei Überlauf einen Interrupt aus und weckt also den µC. Auch wenn der Timer1 jetzt namentlich nicht direkt in der Tabelle steht. Auch Signalwechsel an den I/O-Ports können einen Interrupt auslösen und so zum Wecken führen. So könnte man auch eine Real Time Clock extern anschließen.


    MfG

Seite 11 von 18 ErsteErste ... 910111213 ... LetzteLetzte

Ähnliche Themen

  1. [ERLEDIGT] Atmega 644 & atmega8 parallel am ISP ... Reset beider atmega notwendig ..
    Von Ritchie im Forum AVR Hardwarethemen
    Antworten: 2
    Letzter Beitrag: 29.03.2013, 12:18
  2. CCPRO M128: Portbelegung
    Von Dirk im Forum Robby RP6
    Antworten: 0
    Letzter Beitrag: 22.05.2009, 23:26
  3. Portbelegung bei diesem Display [erledigt]
    Von Rob.Anfänger im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 18.11.2006, 19:12
  4. Portbelegung ATmega32
    Von Rob.Anfänger im Forum Elektronik
    Antworten: 7
    Letzter Beitrag: 15.11.2006, 20:59
  5. Antworten: 4
    Letzter Beitrag: 12.11.2006, 17:40

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test