Прикупил RTC DS1302. хочу подключить ее к МК AVR. использую Attiny2313. подключил 4 7-ми сигментных индикатора и хочу отображать время в режиме ЧЧ:ММ
пишу на ASM`е. написал программную реализацию протокола... и вот тут у меня начались приколы: к примеру, записал в регистр секунд значение 0! и в вечном цикле опрашиваю RTC и вывожу значение секунд на индикатор. на индикаторе идут секунды, все хорошо, но!!! если значение секунд четное то на индикаторе появлятются 00!!! если не четные, то все нормально...
проверял - это касается не только секунд, но и всего остального
пробовал даже записывать данные в RAM - та же история: в ячейку RAM пишу 0х55 - читается как 0х55, записываю в эту же ячейку 0хАА - читается как 0х00!
может быть кто нить сталкивался с такой проблемой?
Прощу прощения у модераторов за размещение темы не в нужном месте внимания сразу не обратил, а как перенести не нашел

ну вообще-то неплохо было бы привести хоть какие-то исходники (протокола например). навскидку можно предположить, что Вы где-то напортачили с реализацией протокола (насколько я помню, там операция чтения/записи как раз определяется последним битом адреса, то есть четностью числа)

main.asm
.include "tn2313def.inc"

.equ LED1 = PD2
.equ LED2 = PD6
.equ LED3 = PD4
.equ LED4 = PD5

.cseg
.org 0x00
rjmp main
.org 0x01
rjmp main
.org 0x02
rjmp main
.org 0x03
rjmp main
.org 0x04
rjmp main
.org 0x05
rjmp main
.org 0x06
rjmp main
.org 0x07
rjmp main
.org 0x08
rjmp main
.org 0x09
rjmp main
.org 0x0a
rjmp main
.org 0x0b
rjmp main
.org 0x0c
rjmp main
.org 0x0d
rjmp t0_compa
.org 0x0e
rjmp main
.org 0x0f
rjmp main
.org 0x10
rjmp main
.org 0x11
rjmp main
.org 0x12
rjmp main

t0_compa:
push r16
push r17
push ZH
push ZL
lds r16, LedNum
cpi r16, 0x01
breq t0_l1
cpi r16, 0x02
breq t0_l2
cpi r16, 0x03
breq t0_l3
cpi r16, 0x04
breq t0_l4
rjmp t0_l5
t0_l1:
cbi PORTD, LED1
sbi PORTD, LED2
sbi PORTD, LED3
sbi PORTD, LED4
lds r17, DisplayNum
rjmp t0_l5
t0_l2:
sbi PORTD, LED1
cbi PORTD, LED2
sbi PORTD, LED3
sbi PORTD, LED4
lds r17, DisplayNum + 1
rjmp t0_l5
t0_l3:
sbi PORTD, LED1
sbi PORTD, LED2
cbi PORTD, LED3
sbi PORTD, LED4
lds r17, DisplayNum + 2
rjmp t0_l5
t0_l4:
clr r16
sbi PORTD, LED1
sbi PORTD, LED2
sbi PORTD, LED3
cbi PORTD, LED4
lds r17, DisplayNum + 3
rjmp t0_l5
t0_l5:
ldi ZH, high(Digits << 1)
ldi ZL, low(Digits << 1)
add ZL, r17
lpm r17, Z
cpi r16, 0x02
brne t0_l6
ori r17, 0x80
t0_l6:
com r17
out PORTB, r17
inc r16
sts LedNum, r16
t0_exit:
pop ZL
pop ZH
pop r17
pop r16
reti

main:
ldi r16, RAMEND
out SPL, r16

clr r16
sts LedNum, r16

rcall InitLedPort
rcall InitTimer
rcall InitPort

// Сбросить защиту от записи
ldi r16, 0x8E
ldi r17, 0x00
rcall DataWrite

//Установить часы
ldi r16, 0x84
ldi r17, 0x12
rcall DataWrite

//Установить минуты
ldi r16, 0x82
ldi r17, 0x30
rcall DataWrite

// Установить секунды
ldi r16, 0x80
ldi r17, 0x00
rcall DataWrite

//Установить День
ldi r16, 0x86
ldi r17, 0x21
rcall DataWrite

//Установить месяц
ldi r16, 0x88
ldi r17, 0x12
rcall DataWrite

//Установить год
ldi r16, 0x8C
ldi r17, 0x07
rcall DataWrite

mainloop:
ldi r16, 0x85
rcall DataRead
mov r18, r17
andi r17, 0b00001111
sts DisplayNum + 1, r17
swap r18
andi r18, 0b00001111
sts DisplayNum + 0, r18

ldi r16, 0x83
rcall DataRead
mov r18, r17
andi r17, 0b00001111
sts DisplayNum + 3, r17
swap r18
andi r18, 0b00001111
sts DisplayNum + 2, r18
rjmp mainloop

.include "delay.inc"
.include "7-s.inc"
.include "time.inc"
.include "timer.inc"

.dseg
LedNum: .db '\x00'
DisplayNum: .db '\x00', '\x00', '\x00', '\x00'

и собственно реализация протокола time.inc:
.equ CE = PD3
.equ CLK = PD1
.equ IO = PD0

.cseg
InitPort:
sbi DDRD, CE
sbi DDRD, CLK

cbi PORTD, CE
cbi PORTD, CLK
ret

PortToIn:
cbi DDRD, IO
ret

PortToOut:
sbi DDRD, IO
ret

DataWrite:
// Передаем коммандный байт
// r16 - комманда
cli
push r18
push r19
sbi DDRD, CLK
ldi r18, 8 // Счетчик бит
rcall PortToOut // Переключаем порт на выход данных, что бы передать коммандый байт
cbi PORTD, CLK // Подготавливаем RTC к передачи данных
DelayUs 10 // Временная задержка, что бы CLK успел переключится
sbi PORTD, CE // Включием RTC
DelayUs 10 // Временная задержка, что бы CE успел переключится
dw_l1:
mov r19, r16 // Скопируем адрес во временный регистр
andi r19, 0x01 // извлечем 0й бит
tst r19 // проверим на 0
breq dw_l2 // если 0, то перейти
sbi PORTD, IO // иначе записать в порт данных 1
rjmp dw_l3 // продолжить выполнение
dw_l2:
cbi PORTD, IO // Записать лог. 0
dw_l3:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
lsr r16 // Сдвигаем адрес, что бы получить следующий бит
dec r18 // уменьшить значение переданных бит
brne dw_l1 // если переданы еще не все 8 - перейти

// Передача адреса закончена, переходим к передаче данных
ldi r18, 8 // Снова инициализируем счетчик бит
dw_l4:
mov r19, r17 // Скопируем данные во временный регистр
andi r19, 0x01 // извлечем 0й бит
tst r19 // проверим на 0
breq dw_l5 // если 0, то перейти
sbi PORTD, IO // иначе записать в порт данных 1
rjmp dw_l6 // продолжить выполнение
dw_l5:
cbi PORTD, IO // Записать лог. 0
dw_l6:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
lsr r17 // Сдвигаем данные, что бы получить следующий бит
dec r18 // уменьшить значение переданных бит
brne dw_l4 // если переданы еще не все 8 - перейти
// Адрес и данные переданы, завершаем
DelayUs 10 // Задержка
cbi PORTD, CE // Выключаем RTC
DelayUs 10 // Подержим немного 0
rcall PortToIn // Переключим порт на вход
cbi DDRD, CLK
pop r19
pop r18
sei
ret

DataRead:
// Передаем адрес
cli
push r18
push r19
sbi DDRD, CLK
ldi r18, 8 // Счетчик бит
rcall PortToOut // Переключаем порт на выход данных, что бы передать коммандый байт
cbi PORTD, CLK // Подготавливаем RTC к передачи данных
cbi PORTD, IO // Подготавливаем RTC к передачи данных
DelayUs 10 // Временная задержка, что бы CLK успел переключится
sbi PORTD, CE // Включием RTC
DelayUs 10 // Временная задержка, что бы CE успел переключится
dr_l1:
mov r19, r16 // Скопируем адрес во временный регистр
andi r19, 0x01 // извлечем 0й бит
tst r19 // проверим на 0
breq dr_l2 // если 0, то перейти
sbi PORTD, IO // иначе записать в порт данных 1
rjmp dr_l3 // продолжить выполнение
dr_l2:
cbi PORTD, IO // Записать лог. 0
dr_l3:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
lsr r16 // Сдвигаем адрес, что бы получить следующий бит
dec r18 // уменьшить значение переданных бит
brne dr_l1 // если переданы еще не все 8 - перейти

// Передача адреса закончена, переходим к приему данных
rcall PortToIn // Переводим порт на вход
ldi r18, 8 // Инициализация счетчика бит
clr r17 // Очищаем регистр выходных данных
dr_l4:
lsr r17 // Сдвигаем вправо на 1 бит
sbis PIND, IO // Проверяем бит на входе
rjmp dr_l5 // переход, если = 0
ori r17, 0x80 // Если 1, то устанавливаем 1 в старший разряд выходного регистра
dr_l5:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
dec r18 // уменьшить счетчик бит на 1
brne dr_l4 // Если переданы не все 8, то переход

// Адрес и данные переданы, завершаем сеанс
DelayUs 10 // Задержка
cbi PORTD, CE // Выключаем RTC
rcall PortToIn // Переводим порт на вход
DelayUs 10 // Задержка
cbi DDRD, CLK
pop r19
pop r18
sei
ret


сразу прошу прощения за размещение AVRASM-кода в ветке PIC.
сразу внимания не обратил, а когда уже добавил, не нашел возможности перенести куда надо

Прикупил RTC DS1302. хочу подключить ее к МК AVR. использую Attiny2313. подключил 4 7-ми сигментных индикатора и хочу отображать время в режиме ЧЧ:ММ
пишу на ASM`е. написал программную реализацию протокола... и вот тут у меня начались приколы: к примеру, записал в регистр секунд значение 0! и в вечном цикле опрашиваю RTC и вывожу значение секунд на индикатор. на индикаторе идут секунды, все хорошо, но!!! если значение секунд четное то на индикаторе появлятются 00!!! если не четные, то все нормально...
проверял - это касается не только секунд, но и всего остального
пробовал даже записывать данные в RAM - та же история: в ячейку RAM пишу 0х55 - читается как 0х55, записываю в эту же ячейку 0хАА - читается как 0х00!
может быть кто нить сталкивался с такой проблемой?
функции, реализующие протокол:
.equ CE = PD3
.equ CLK = PD1
.equ IO = PD0

.cseg
InitPort:
sbi DDRD, CE
sbi DDRD, CLK

cbi PORTD, CE
cbi PORTD, CLK
ret

PortToIn:
cbi DDRD, IO
ret

PortToOut:
sbi DDRD, IO
ret

DataWrite:
// Передаем коммандный байт
// r16 - комманда
cli
push r18
push r19
sbi DDRD, CLK
ldi r18, 8 // Счетчик бит
rcall PortToOut // Переключаем порт на выход данных, что бы передать коммандый байт
cbi PORTD, CLK // Подготавливаем RTC к передачи данных
DelayUs 10 // Временная задержка, что бы CLK успел переключится
sbi PORTD, CE // Включием RTC
DelayUs 10 // Временная задержка, что бы CE успел переключится
dw_l1:
mov r19, r16 // Скопируем адрес во временный регистр
andi r19, 0x01 // извлечем 0й бит
tst r19 // проверим на 0
breq dw_l2 // если 0, то перейти
sbi PORTD, IO // иначе записать в порт данных 1
rjmp dw_l3 // продолжить выполнение
dw_l2:
cbi PORTD, IO // Записать лог. 0
dw_l3:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
lsr r16 // Сдвигаем адрес, что бы получить следующий бит
dec r18 // уменьшить значение переданных бит
brne dw_l1 // если переданы еще не все 8 - перейти

// Передача адреса закончена, переходим к передаче данных
ldi r18, 8 // Снова инициализируем счетчик бит
dw_l4:
mov r19, r17 // Скопируем данные во временный регистр
andi r19, 0x01 // извлечем 0й бит
tst r19 // проверим на 0
breq dw_l5 // если 0, то перейти
sbi PORTD, IO // иначе записать в порт данных 1
rjmp dw_l6 // продолжить выполнение
dw_l5:
cbi PORTD, IO // Записать лог. 0
dw_l6:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
lsr r17 // Сдвигаем данные, что бы получить следующий бит
dec r18 // уменьшить значение переданных бит
brne dw_l4 // если переданы еще не все 8 - перейти
// Адрес и данные переданы, завершаем
DelayUs 10 // Задержка
cbi PORTD, CE // Выключаем RTC
DelayUs 10 // Подержим немного 0
rcall PortToIn // Переключим порт на вход
cbi DDRD, CLK
pop r19
pop r18
sei
ret

DataRead:
// Передаем адрес
cli
push r18
push r19
sbi DDRD, CLK
ldi r18, 8 // Счетчик бит
rcall PortToOut // Переключаем порт на выход данных, что бы передать коммандый байт
cbi PORTD, CLK // Подготавливаем RTC к передачи данных
cbi PORTD, IO // Подготавливаем RTC к передачи данных
DelayUs 10 // Временная задержка, что бы CLK успел переключится
sbi PORTD, CE // Включием RTC
DelayUs 10 // Временная задержка, что бы CE успел переключится
dr_l1:
mov r19, r16 // Скопируем адрес во временный регистр
andi r19, 0x01 // извлечем 0й бит
tst r19 // проверим на 0
breq dr_l2 // если 0, то перейти
sbi PORTD, IO // иначе записать в порт данных 1
rjmp dr_l3 // продолжить выполнение
dr_l2:
cbi PORTD, IO // Записать лог. 0
dr_l3:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
lsr r16 // Сдвигаем адрес, что бы получить следующий бит
dec r18 // уменьшить значение переданных бит
brne dr_l1 // если переданы еще не все 8 - перейти

// Передача адреса закончена, переходим к приему данных
rcall PortToIn // Переводим порт на вход
ldi r18, 8 // Инициализация счетчика бит
clr r17 // Очищаем регистр выходных данных
dr_l4:
lsr r17 // Сдвигаем вправо на 1 бит
sbis PIND, IO // Проверяем бит на входе
rjmp dr_l5 // переход, если = 0
ori r17, 0x80 // Если 1, то устанавливаем 1 в старший разряд выходного регистра
dr_l5:
DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
dec r18 // уменьшить счетчик бит на 1
brne dr_l4 // Если переданы не все 8, то переход

// Адрес и данные переданы, завершаем сеанс
DelayUs 10 // Задержка
cbi PORTD, CE // Выключаем RTC
rcall PortToIn // Переводим порт на вход
DelayUs 10 // Задержка
cbi DDRD, CLK
pop r19
pop r18
sei
ret

пожалуйста код в студию.
Обращаю Ваше внимание на то что в интерфейсе записи все байты пишутся по переднему фронту SCLK. А при чтении установка данных из МС осуществляется по заднему фронту SCLK.

Вот на вскидку перед чтением бита из порта после передачи адреса.. сделайте задержку. У вас получается что вы практически после установки заднего фронта (через 10 тактов) читаете первый бит.Это не есть гут ))
вот этот кусок:

Принял на заметку... исправил... не помогло...
вот код основной программы:

.include "tn2313def.inc"

.equ LED1 = PD2
.equ LED2 = PD6
.equ LED3 = PD4
.equ LED4 = PD5

.cseg
.org 0x00
rjmp main
.org 0x01
rjmp main
.org 0x02
rjmp main
.org 0x03
rjmp main
.org 0x04
rjmp main
.org 0x05
rjmp main
.org 0x06
rjmp main
.org 0x07
rjmp main
.org 0x08
rjmp main
.org 0x09
rjmp main
.org 0x0a
rjmp main
.org 0x0b
rjmp main
.org 0x0c
rjmp main
.org 0x0d
rjmp t0_compa
.org 0x0e
rjmp main
.org 0x0f
rjmp main
.org 0x10
rjmp main
.org 0x11
rjmp main
.org 0x12
rjmp main

t0_compa:
push r16
push r17
push ZH
push ZL
lds r16, LedNum
cpi r16, 0x01
breq t0_l1
cpi r16, 0x02
breq t0_l2
cpi r16, 0x03
breq t0_l3
cpi r16, 0x04
breq t0_l4
rjmp t0_l5
t0_l1:
cbi PORTD, LED1
sbi PORTD, LED2
sbi PORTD, LED3
sbi PORTD, LED4
lds r17, DisplayNum
rjmp t0_l5
t0_l2:
sbi PORTD, LED1
cbi PORTD, LED2
sbi PORTD, LED3
sbi PORTD, LED4
lds r17, DisplayNum + 1
rjmp t0_l5
t0_l3:
sbi PORTD, LED1
sbi PORTD, LED2
cbi PORTD, LED3
sbi PORTD, LED4
lds r17, DisplayNum + 2
rjmp t0_l5
t0_l4:
clr r16
sbi PORTD, LED1
sbi PORTD, LED2
sbi PORTD, LED3
cbi PORTD, LED4
lds r17, DisplayNum + 3
rjmp t0_l5
t0_l5:
ldi ZH, high(Digits << 1)
ldi ZL, low(Digits << 1)
add ZL, r17
lpm r17, Z
cpi r16, 0x02
brne t0_l6
ori r17, 0x80
t0_l6:
com r17
out PORTB, r17
inc r16
sts LedNum, r16
t0_exit:
pop ZL
pop ZH
pop r17
pop r16
reti

main:
ldi r16, RAMEND
out SPL, r16

clr r16
sts LedNum, r16

rcall InitLedPort
rcall InitTimer
rcall InitPort

// Сбросить защиту от записи
ldi r16, 0x8E
ldi r17, 0x00
rcall DataWrite

//Установить часы
ldi r16, 0x84
ldi r17, 0x12
rcall DataWrite

//Установить минуты
ldi r16, 0x82
ldi r17, 0x30
rcall DataWrite

// Установить секунды
ldi r16, 0x80
ldi r17, 0x00
rcall DataWrite

//Установить День
ldi r16, 0x86
ldi r17, 0x21
rcall DataWrite

//Установить месяц
ldi r16, 0x88
ldi r17, 0x12
rcall DataWrite

//Установить год
ldi r16, 0x8C
ldi r17, 0x07
rcall DataWrite

// читаем минуты и секунды и выводим их на экран
mainloop:
ldi r16, 0x85
rcall DataRead
mov r18, r17
andi r17, 0b00001111
sts DisplayNum + 1, r17
swap r18
andi r18, 0b00001111
sts DisplayNum + 0, r18

ldi r16, 0x83
rcall DataRead
mov r18, r17
andi r17, 0b00001111
sts DisplayNum + 3, r17
swap r18
andi r18, 0b00001111
sts DisplayNum + 2, r18


rcall maindelay
rjmp mainloop

.include "delay.inc"
.include "7-s.inc"
.include "time.inc"
.include "timer.inc"

maindelay:
push r16
ldi r16, 20
md_l1:
DelayUS 65000
dec r16
brne md_l1
pop r16
ret

.dseg
LedNum: .db '\x00'
DisplayNum: .db '\x00', '\x00', '\x00', '\x00'


четное или нечетное число определяется 0м битом, так же этим 0м битом определяется операция чтения или записи... думал, может это как связано... но, к сожелению, изыскания в этой области ни к чему не привели

сразу скажу, что разбирать асм-код такого размера - удовольствие для людей, обремененных большим количеством свободного времени. скажите, а в 1302 разве не I2C протокол? если да, то я не совсем понял, чем у Вас отличаются команды чтения и записи (насколько я понял Ваш код, адрес передается в r16 в инвертированном порядке?) и там, и там последний бит 1 - то есть режим чтения? а где Вы обеспечиваете I2C Start condotion?

в том то и дело, что это не I2C! это какой то другой протокол, на который в инете мало документации.
адрес действительно передается в регистре r16, но с чего вы взяли что в инвертированном виде?

// Установить секунды
ldi r16, 0x80
ldi r17, 0x00
rcall DataWrite
тут вроде все в норме, никакой инверсии...
Комманды чтения и записи отличаются тем, что для записи я передаю сначала адрес, потом данные. при чтении передается адрес ячейки памяти, а затем информация считывается из RTC.

вот еще.., на "скорость" может не влияет но по даташиту у мс DS1302 CE Inactive Time tCWH =1мкс. У Вас очень "близко"(,без установки интервала) располагаются вызов ПП rcall DataWrite и rcall DataRead. Т.е. работаете почти на пределе скорости. Выключаете CE(ChipEnable) и сразу включаете.

пришлось скачать даташит. насчет инверсии - это просто передача оказывается lsb first. в общем все выглядит нормально, за исключением того, что я не до конца понял, почему Вы читаете секунды по адресу 0x83, а не 0x81. ну если это исключить, то единственную причину проблем с четными значениями можно предполагать в рассинхронизации клоков и битов данных. если, например, предположить, что микросхема младший бит данных(2-го байта) воспринимает как старший бит данных первого байта, тогда 0 будет восприниматься как запрет обмена. кстати, не потому ли у вас как раз 0x83?

и снова вы правы, но опять не помогло
поставил задержку в 10 мкс, думаю более чем достаточно, что бы RTC успел среагировать на перепад уровней...
я в мануале еще нашел вот такую строчку
When reading or writing the time and date registers, secondary (user) buffers are used to prevent errors when the internal registers update. When reading the time and date registers, the user buffers are synchronized to the internal registers the rising edge of CE.

как ее использовать я не пойму... может быть стоит после каждой комманды дергать CE?
может быть это данные не записываются во внутренние регистры?

Все хорошо, а ГДЕ у ВАС задержка после установки заднего фронта CLK? поставте некоторую задержку.. Хоть в DS и написано 200нс.. но всеже.. для отладки не повредит. Потом уберете если все нормально.

1. кто сказал, что я считываю секунды с 83? я считываю оттуда минуты для того, что бы отображать время в формате ЧЧ:ММ... 83 - минуты, 85 - часы...

dr_l4:
lsr r17 // Сдвигаем вправо на 1 бит
sbis PIND, IO // Проверяем бит на входе
rjmp dr_l5 // переход, если = 0
ori r17, 0x80 // Если 1, то устанавливаем 1 в старший разряд выходного регистра
dr_l5:
// DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
DelayUs 10 // подержать 10 мкс
dec r18 // уменьшить счетчик бит на 1
brne dr_l4
не работает!



даже вот так вот
// Передача адреса закончена, переходим к приему данных
rcall PortToIn // Переводим порт на вход
DelayUs 10 // Задержка <<<<<<<<<<<<<<<<<<<<<<<<<<< чтение нулевого бита
ldi r18, 8 // Инициализация счетчика бит
clr r17 // Очищаем регистр выходных данных
dr_l4:
lsr r17 // Сдвигаем вправо на 1 бит
sbis PIND, IO // Проверяем бит на входе
rjmp dr_l5 // переход, если = 0
ori r17, 0x80 // Если 1, то устанавливаем 1 в старший разряд выходного регистра
dr_l5:
// DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
DelayUs 10 // подержать 10 мкс
dec r18 // уменьшить счетчик бит на 1
brne dr_l4

эээ приведите код где у вас массив "Digits"..
что то у вас здесь немудрено.. вы прибавляет без учета старшего регистра ZH:

там все нормально... это код, который овечает за вывод значений на сигментах... он никак на чтение из RTC не влияет:
Digits: .db \
al + bl + cl + dl + el + fl, \
bl + cl, \
al + bl + gl + el + dl, \
al + bl + cl + dl + gl, \
fl + gl + bl + cl, \
al + fl + gl + cl + dl, \
al + fl + el + dl + cl + gl, \
al + bl + cl, \
al + bl + cl + dl + el + fl + gl, \
al + bl + cl + dl + fl + gl, \
al + bl + cl + fl + el + gl, \
el + fl + dl + cl + gl, \
al + dl + el + fl, \
bl + cl + dl + el + gl, \
al + dl + el + fl + gl, \
al + el + fl + gl, \
'\x00', \
gl

речь не о задержке, а о сдвиге синхронизации. запись-то идет по нарастающему фронту, а чтение - по спадающему (или наоборот). то есть при переходе от записи (команды) к чтению (данных) надо осуществить сдвих фазы CS на полтакта

согласно даташиту не надо ничего менять... тоесть надо конечно, но у меня там все уже сдвинуто:

// Передача адреса закончена, переходим к приему данных
rcall PortToIn // Переводим порт на вход
DelayUs 10 // Задержка <<<<<<<<<<<<<<<<<<<<<<<< после этой задержки на шине уже присутствует 0й бит от RTC
ldi r18, 8 // Инициализация счетчика бит
clr r17 // Очищаем регистр выходных данных
dr_l4:
lsr r17 // Сдвигаем вправо на 1 бит
sbis PIND, IO // Проверяем бит на входе
rjmp dr_l5 // переход, если = 0
ori r17, 0x80 // Если 1, то устанавливаем 1 в старший разряд выходного регистра
dr_l5:
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
DelayUs 10 // подержать 10 мкс
dec r18

да.. должно быть не влияет.. Но только не корректно прибавлять значение только к младшему регистру.
если у вас преред массивом не стоит директива ".org" .К воросу это отношение не имеет но на будущее учтите что это грабли! :-) поясняю: Если к примеру у вас значение ZH:ZL = 0x23ff, то прибавив к ZL какоето значение, к примеру "2" вы не получите ожидаемого адреса 2401, а получите 2301.
делай те в следующий раз к примеру так:



Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS

да, вроде все правильно. ну тогда остается только попробовать посмотреть соответствие картины обмена на осциллографе

Это не совсем грабли когда я писал именно этот кусок кода, у меня этот массив был в ОП, были глюки (потом выяснилось, что не из-за этого), из-за которых я переделал этот массив в память программ, а поправить алгоритм забыл...
а когда речь шла о ОП, то ее всего 128 байт (tiny2313). поэтому я и не замарачивался с регистром ZH.
спасибо за уточнение.

что касается RTC:

у меня в влгоритме именно так и происходит:
// Передача адреса закончена, переходим к приему данных
rcall PortToIn // Переводим порт на вход
DelayUs 10 // Задержка <<<<<<<<<<<<<<<<<<, тут 0й бит на шине
ldi r18, 8 // Инициализация счетчика бит
clr r17 // Очищаем регистр выходных данных
dr_l4:
lsr r17 // Сдвигаем вправо на 1 бит
sbis PIND, IO // Проверяем бит на входе <<<<<<<<<<<<<<<<< тут я его читаю и сохраняю
rjmp dr_l5 // переход, если = 0
ori r17, 0x80 // Если 1, то устанавливаем 1 в старший разряд выходного регистра
dr_l5:
// DelayUs 10 // задержка для формирования данных на ноге контроллера
sbi PORTD, CLK // сформировать нарастающий фронт CLK
DelayUs 10 // подержать 10 мкс
cbi PORTD, CLK // сформировать стадающий фронт CLK
DelayUs 10 // подержать 10 мкс
dec r18 // уменьшить счетчик бит на 1
brne dr_l4
все вроде соответствует даташиту

я ничего не путаю, просто в исходниках автора не ковырялся - предложил ему самому проверить. потом и сам проверил - с виду все правильно. но с учетом того, что правильное чтение производится не через раз, а именно четных данных, думаю искать ошибку надо именно где-то в районе младшего бита данных

к сожалению осцилографа под рукой нет...
оглошу еще один маленький факт: то, что я делаю сейчас (подключение RTC к МК) является лишь частью одного более глобального проекта. поэтому сделано все на навесном мантаже. предположения КЗ между ножками отметаются сразу. все проверяно по 100 раз. но в какой-то момент времени (по неизвесным причинам) микросхема нагрелась до такой температуры, что отпаялись все проводки от нее (кроме земли). МК живой, проверял каждую ножку. припоял все проводки на место к RTC. подключил и она заработала... вопрос: могла ли RTC так хитро сгореть, или все же это похоже на баг в коде?

я проверял работу алгоритма на AVR Studio в режиме эмуляции ATTiny2313... там никаких глюков не было. что ему на "вход" подовал, то на выходе и получал... поэтому я уже не знаю что думать... может быть действительно RTC битая?

плохо, что нет
если битая, вряд ли она настолько удачно битая, что именно четные байты не отдает...

тогда я не знаю чё делать...

мысли закончились

позвольте один интересный факт рассказать: согласно даташиту ноги RTC подтянуты к земле....
я резистором подтягиваю их на +5 и о чудо... там, где раньше читались нули - щас читаются 0xFF...
дальшейшие изыскания привели к тому, что так себя видут ячейки с НЕ инициализированными значениями. т.е. записываю в RAM RTC нечетное значение - читается нормально... а если записать четное или вообще ничего не записывать то получается вот такая вот странная фигура... лично я снова ничего не понимаю... может быть вам это то даст

сие подтверждает мою мысль - операция чтения четного числа вообще не выполняется. то есть микросхема часов отказывается брать контроль шины на себя и выводить данные - а поскольку контроллер тоже находится в режиме чтения, Вы и наблюдаете указанный эффект. хотя как это может быть связано с СОЖЕРЖИМЫМ регистра - абсолютно непонятно...

мда... ладно, спасибо за помощь. может быть на выходных получится поподробнее разобраца в алгоритмах и даташитах... нужно еще раз все проверить на AVR Studio...

только что обнаружил еще более странный глюк: при включении питания контроллера на экране ~ полсекунды горят четные числа, а потом нули... что это ????????????

Выложите проект полностью.. и последнюю версию с исправлениями(в приложенном файле). Или отправьте через личку. А то собирать куски кода по ветке не очень удобно.
зы: что то я не вижу в цикле "mainloop" команды "sei" - разрешение прерываний

вот весь проект
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
В main`е есть небольшое количесво кода, которое не сипользуется. это эксперементы не обращайте внимания ))

Я кажется понял где грабли:
у меня моя железка питается от мощьного блока питания. я выдернул щас из нее силовой кабель и напряжение питания начало медленно падать... так вот в какой-то момент времени, перед тем, как экран погаснет, там появлись четные числа...
питание от +5В. завтра буду пробовать подключить RTC через линейный преобразователь напряжения на 3,3 В...
мне почему то кажется, что это решение проблемы

Маленький совет по динамической индикации:Во время отображения, особенно если цифра отсутствует или какойто сегмент отключен, может наблюдаться еле заметная подсветка сегмента. Дело тут в следующем: Ваш код, смотрите сначала в "t0_l4" Вы выключаете "LED4", а при следующем прерывании в"t0_l1"сначало включаете "LED1".. а через несколько команд выключаете "LED4". Это может быть видно на диодах сегментного индикатора:

решение простое:

Спасибо за дельное замечание.
исправил

Скажите, а в схеме у Вас батарейный элемент питания стоит?
зы: я не просто спрашиваю.. уже сам прошелся по этим граблям. http://electronix.ru/forum/index.php?showt...37842&st=30

батарейка стоит. новая CR2032 на 3В.

В начале программы хорошо бы сделать инициализацию ds1303. А именно установку в "0" 7-го бита "CH" (CLOCK HALT FLAG) и "WP"(WRITE-PROTECT BIT)в "0".
Попробуйте изменить кусок кода чтения байта из мс. У Вас получается после прохождения цикла лишний такт (восьмой) а по даташиту их получается семь т.к. установка по по спадающему фронту. ну к примеру так:

у меня стоит начальная инициализация:

и CH сбрасывается при установке секунд


код переписал с учетом ваших рекомендаций - стало еще хуже...
на экране откуда-то взялось число 57, причем оно меняется на 12, и 25. закономерность не пойму.
откоментировал код инициализации, там выставлено время 12:30. записываю его в МК - тот же результат, 57, 12, 25...
попробовал переделать на 3,3 В, не помогло... в общем ясно, что это глюк RTC нужно покупать новую

разобрался в чем дело!!!!!!!!
подключаю основное питание, запскаю контроллер, он инициализирует RTC. на экране чёрти чё...
отключаю основное питание. батарейка на месте, и на экране и четные значения, и идут и все как
положено... в общем это, я так понимаю, все таки RTC бракованная походу

блин, вот гемор... не думал, что могут возникнуть такие проблемы...

Странно?! такое разве может быть?.. т.е. стабильное питание необходимо для мс RTS?
Если после изменения кода произошли изменения в отображении, значит всетаки глюки в программе есть..это факт. Надо копать глубже! 12 это "1100", а 25 -"11001".. очень похоже на интерфейсные дела.. с чтением. Увеличивайте везде задержки, для чистоты эксперимента!
зы: на счет другой мс я использовал DS1307.

забыл уточнить: эти цифры появлялись на 2 версиях кода процедуры чтения. вашем и поем... т.е. дело не в нем...
я решил взять DS3234 - у нее кварц интегрянный, и есть датчик температуры для компенсации ухода часов... стоит 140 рублей... а эту я брал за 90...
в общем спасибо за помощь, думаю тему можно закрывать

закрывайте...
зы:Жаль что не выяснилось в чем дело...