DS1302 - Sekunden / Minuten von 0 - 90!

[Daniel_HH (Gast)]

Was ist den hier kurioses passiert? Ich hab es endlich geschafft den rtc 
auszulesen, jeodoch: gibt dieser die Zahlen von 0-90 aus, springt von 9 
auf 16, 25 auf 32, 57 auf 64 usw... habt Ihr`ne Idee woran das liegen 
könnte?

vielen Dank füür eure Hilfe!

[Daniel_HH (Gast)]

huii, sorry! Hier der Code.

[avr (Gast)]

Wahrscheinlich gibt er die Zeit BCD-codiert aus.

[Daniel_HH (Gast)]

.include "m32def.inc"

.equ XTAL      = 3686400
.equ LCD_PORT  = PORTD
.equ LCD_Com  = PortB
.equ PIN_RS    = PB0
.equ PIN_RW      = PB1
.equ PIN_E     = PB2
.equ RTCs    = PC5
.equ RTCi    = PC3
.equ RTCr    = PC1
.def temp1    = r16
.def temp2    = r17
.def temp3    = r18
.def dat0    = r19
.def adr0    = r20


.org 0x0000
  rjmp main
.org OVF0addr
  rjmp Overflow0

main:
  ldi r16, LOW(RAMEND)
  out SPL, r16
  ldi r16, HIGH(RAMEND)
  out SPH, r16
  
  ldi r16, (1<<CS02)
  out TCCR0, r16
  ldi r16, (1<<TOIE0)
  out TIMSK, r16
  sei

  ldi r16, 255
  out DDRB, r16
  
  out DDRD, r16

  rcall lcd_init
  rcall rtc_init
  
  
  ldi r19, 0b10000000
  rcall lcd_command
  ldi r19, 0
  rcall lcd_data


loop:

  ldi adr0, 0b10000001
  rcall RtcReadCommand
  rcall akt_uhr
  rjmp loop

akt_uhr:
  mov temp2, dat0
  ldi temp3, '0'-1
check_s10:
  inc temp3
  subi temp2, 10
  brcc check_s10
  subi temp2, -10
  ldi r19, 0b10001011
  rcall lcd_command
  mov r19, temp3
  rcall lcd_data
std_01:
  ldi temp3, '0'
check_s01:
  add temp3, temp2
  mov r19, temp3
  rcall lcd_data
  ret

lcd_init:
   cbi PortB, 1
    ldi   temp3,6
powerupwait:
    rcall delay5ms
    dec   temp3
    brne  powerupwait
    ldi   temp1, 0b00110000
    out   PortD, temp1 
    rcall lcd_enable
    rcall delay5ms
    rcall lcd_enable
    rcall delay5ms
    rcall lcd_enable
    rcall delay5ms
    ldi   temp1, 0b00111000    
    out   PortD, temp1
  rcall lcd_enable
  rcall delay50us
    ldi   temp1, 0b00001100   
    out   PortD, temp1
  rcall lcd_enable
  rcall delay50us
  ldi r19, 0b00000001
  rcall lcd_command
  rcall delay5ms
Charakter:
  ldi r19, 0b01000000
  rcall lcd_command
  
  ldi ZL, LOW(CG00*2)
  ldi ZH, HIGH(CG00*2)
  ldi temp3, 8
cg00loop:
  lpm r19, z+
  rcall lcd_data
  dec temp3
  brne cg00loop
  ldi r19, 0b10000000
  rcall lcd_command
  ret

lcd_data:
  sbi PortB, 0
  out LCD_PORT, r19
  rcall lcd_enable
  cbi PortB, 0
  ret               

lcd_command:
  cbi PortB, 0
  out LCD_Port, r19
  rcall lcd_enable
  sbi PortB, 0
  ret


lcd_enable:
  sbi PortB,2
  rcall delay50us
  cbi PortB, 2
  ret 

delay50us:             
  ldi  temp1, ( XTAL * 50 / 3 ) / 1000000
delay50us_:
  dec  temp1
    brne delay50us_
  ret                         
 
delay5ms:                               
  ldi  temp1, ( XTAL * 5 / 607 ) / 1000
WGLOOP0:   
  ldi  temp2, $C9
WGLOOP1:   
  dec  temp2
    brne WGLOOP1
    dec  temp1
    brne WGLOOP0
    ret        

rtc_init:
  ldi temp2, 255
  out DDRC, temp1
  clr temp2
  out PORTC, temp1
  ldi adr0, 0x8E
  clr dat0
  rcall RtcWriteCommand
  ldi adr0, 0x90
  ldi dat0, 0xA0
  rcall RtcWriteCommand

  ldi adr0, 0x80
  ldi dat0, 45
  rcall RtcWriteCommand

  ldi adr0, 0x8E
  ldi dat0, 0x80
  rcall RtcWriteCommand
  ret

RtcWriteCommand:
  sbi DDRC, 3
  sbi PortC, 1
  push dat0
  mov dat0, adr0
  rcall CeClkSetupTime
  rcall RtcWriteByte
  pop dat0
  rcall RtcWriteByte
  cbi PortC, 1
  ret
  
RtcWriteByte:
  ldi temp1, 8
RtcWriteByte2:
  rcall ClkDataDelayTime
  lsr dat0
  brcs RtcWriteByte3
  cbi PortC, 3
  rjmp RtcWriteByte4
RtcWriteByte3:
  sbi PortC, 3
RtcWriteByte4:
  nop
  sbi PortC, 5
  rcall ClkLoHiTime
  cbi PortC, 5
  rcall ClkLoHiTime
  dec temp1
  brne RtcWriteByte2
  ret

RtcReadCommand:
  cbi DDRC, 3
  cbi PortC, 3
  sbi PortC, 1
  rcall CeClkSetupTime
  mov dat0, adr0
  rcall RtcWriteByte
  ldi temp1, 8
RtcReadCmd1:
  clc
  sbic PinC, 3
  sec
  sbi PortC, 5
  ror dat0
  rcall ClkLoHiTime
  cbi PortC, 5
  rcall ClkLoHiTime
  dec temp1
  brne RtcReadCmd1
  cbi PortC, 1
  ret


ClkLoHiTime:
ClkDataDelayTime:
  ldi temp2, 1
ClkLoHiTime1:
  nop
  dec temp2
  brne ClkLoHiTime1
  ret 

CeClkSetupTime:
  ldi temp2,5
  nop
CeCLKSetupTime1:
  dec temp2
  brne CEClkSetupTime1
  ret

Overflow0:

  reti

CG00:
  .db 0x00, 0x04, 0x0A, 0x0A, 0x0A, 0x1F, 0x04, 0x00

[Daniel_HH (Gast)]

Na Super! Vielen Dank :( Da hock ich hier die halbe Nacht und grübel was 
da falsch gelaufen sein könnte und du zauberst mir innherhalb von 
Sekunden die Antwort schäm

[... (Gast)]

Daniel_HH schrieb:
> .include "m32def.inc"
> .equ XTAL      = 3686400
> ...
Geht soetwas nicht als Anhang???

[Daniel_HH (Gast)]

..geht sicherlich auch als Anhang, war ich grad aber zu doof für -ich 
bite um eine harte und gerechte Bestrafung!

[Odin hilft (Gast)]

selbsternannte Wächter gibts überall

[Daniel_HH (Gast)]

Leute ich hoffe, Ihr habt spontan `ne Idee:

ich verwende die freien Register des DS1302 um andere Daten zu sichern 
und zu lesen, diese werden ständig aktualisiert.
Wenn jedoch Daten geschrieben werden, kann es passieren, dass andere 
Register urplötzlich Ihre Daten verlieren -beim auslesen bekomme ich nur 
noch sinnloses raus... Ich habe das write Protection Bit natürlich nicht 
gesetzt da ich mit gesetzten WPB keine Daten übertragen kann...

Habt Ihr`ne Idee woran`s liegen kann?

[Peter D. (peda)]

Du hast ausversehen das *.hex gepostet. Poste mal das *.c bzw. *.asm.

Peter

[Daniel_HH (Gast)]

Hoppla :/

[Daniel_HH (Gast)]

...jetzt hab ich mal ein wenig rum probiert: Der Fehler tritt nicht auf 
wenn ich den Timer deaktiviere. Ich kann es mir zwar nicht plausibel 
erklären aber ich denke, dass das Carry-Flag aus dem cpi Vergleich wohl 
irgendwie einfluss auf das Hauptprogramm nehmen muß...

[Karl H. (kbuchegg)]

Kleiner Tip

Du machst dir viel zu viel Arbeit. Häng deinen Source Code ganz einfach 
einfach nur an. Die Forensoftware weiß schon, was sie damit machen muss 
und welcher Syntax Highlighter dafür vernünftig ist.

[Karl H. (kbuchegg)]

Daniel_HH schrieb:
> ...jetzt hab ich mal ein wenig rum probiert: Der Fehler tritt nicht auf
> wenn ich den Timer deaktiviere. Ich kann es mir zwar nicht plausibel
> erklären aber ich denke, dass das Carry-Flag aus dem cpi Vergleich wohl
> irgendwie einfluss auf das Hauptprogramm nehmen muß...


Na ja. Wenn du in einer ISR nicht automatisch und im Schlaf sofort erst 
mal das SREG sicherst und als letztes in der ISR wiederherstellst, 
sollte man dir sowieso mit dem nassen Fetzen eine überbraten

Overflow0:
  cpi MenuDelay, 0
  breq Overflow0_Out
  dec MenuDelay

Overflow0_Out:
  reti

Fehler. Schwerer Fehler!

[Daniel_HH (Gast)]

"SREF Sichern" hört sich interessant an :) Für den Spruch: Mit nassen 
Fetzten einen überbraten, bekommst du direkt`nen Oskar von mir :)) 
Genial -den werd ich mir merken lach