| |
|
  |
 Странное поведение DS1302 |
|
|
|
|
 Dec 21 2007, 12:40
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(adc @ Dec 21 2007, 15:35)  эээ приведите код где у вас массив "Digits".. что то у вас здесь немудрено..: Код ldi ZH, high(Digits << 1) - загружается 0й элемент массива
ldi ZL, low(Digits << 1)
add ZL, r17 - прибавляю к адресу 0ого элемента цифру, которую необходимо показать
lpm r17, Z - считываю из памяти программ
cpi r16, 0x02 - если в данный момент отображается 2й (из 4х) цифр, то зажечь точку (получается формат XY.IJ)
brne t0_l6
ori r17, 0x80
t0_l6:
com r17 там все нормально... это код, который овечает за вывод значений на сигментах... он никак на чтение из 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
|
|
|
|
|
|
|
|
Dec 21 2007, 12:51
|
Частый гость
Группа: Свой
Сообщений: 152
Регистрация: 11-10-05
Из: Воронеж
Пользователь №: 9 491
|
Цитата(Pepper @ Dec 21 2007, 15:14) и снова вы правы, но опять не помогло
поставил задержку в 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?
может быть это данные не записываются во внутренние регистры? речь не о задержке, а о сдвиге синхронизации. запись-то идет по нарастающему фронту, а чтение - по спадающему (или наоборот). то есть при переходе от записи (команды) к чтению (данных) надо осуществить сдвих фазы CS на полтакта
|
|
|
|
|
|
|
|
Dec 21 2007, 12:57
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(sergik_vrn @ Dec 21 2007, 15:51) речь не о задержке, а о сдвиге синхронизации. запись-то идет по нарастающему фронту, а чтение - по спадающему (или наоборот). то есть при переходе от записи (команды) к чтению (данных) надо осуществить сдвих фазы 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
|
|
|
|
|
|
|
|
Dec 21 2007, 13:02
|
Местный
Группа: Свой
Сообщений: 409
Регистрация: 29-10-07
Пользователь №: 31 836
|
Цитата(Pepper @ Dec 21 2007, 15:40) там все нормально... это код, который овечает за вывод значений на сигментах... он никак на чтение из RTC не влияет:
Digits: .db \ да.. должно быть не влияет.. Но только не корректно прибавлять значение только к младшему регистру. если у вас преред массивом не стоит директива ".org" .К воросу это отношение не имеет но на будущее учтите что это грабли! :-) поясняю: Если к примеру у вас значение ZH:ZL = 0x23ff, то прибавив к ZL какоето значение, к примеру "2" вы не получите ожидаемого адреса 2401, а получите 2301. делай те в следующий раз к примеру так: Код ldi ZH, high(Digits << 1) - загружается 0й элемент массива
ldi ZL, low(Digits << 1)
clr r20//любой свободный регистр
add ZL, r17 - прибавляю к адресу 0ого элемента цифру, которую необходимо показать
adc ZH, r20 // с учетом переноса
lpm r17, Z - считываю из памяти программ Цитата(sergik_vrn @ Dec 21 2007, 15:51) речь не о задержке, а о сдвиге синхронизации. запись-то идет по нарастающему фронту, а чтение - по спадающему (или наоборот). то есть при переходе от записи (команды) к чтению (данных) надо осуществить сдвих фазы CS на полтакта Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS
Сообщение отредактировал adc - Dec 21 2007, 13:05
--------------------
Умный программист пишет тупым кодом гениальные вещи, а не наоборот...
|
|
|
|
|
|
|
|
Dec 21 2007, 13:12
|
Частый гость
Группа: Свой
Сообщений: 152
Регистрация: 11-10-05
Из: Воронеж
Пользователь №: 9 491
|
Цитата(Pepper @ Dec 21 2007, 15:57) согласно даташиту не надо ничего менять... тоесть надо конечно, но у меня там все уже сдвинуто:
// Передача адреса закончена, переходим к приему данных
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 да, вроде все правильно. ну тогда остается только попробовать посмотреть соответствие картины обмена на осциллографе
|
|
|
|
|
|
|
|
Dec 21 2007, 13:13
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(adc @ Dec 21 2007, 16:02) да.. должно быть не влияет.. Но только не корректно прибавлять значение только к младшему регистру. если у вас преред массивом не стоит директива ".org" .К воросу это отношение не имеет но на будущее учтите что это грабли! :-) поясняю: Если к примеру у вас значение ZH:ZL = 0x23ff, то прибавив к ZL какоето значение, к примеру "2" вы не получите ожидаемого адреса 2401, а получите 2301. делай те в следующий раз к примеру так: Код ldi ZH, high(Digits << 1) - загружается 0й элемент массива
ldi ZL, low(Digits << 1)
clr r20//любой свободный регистр
add ZL, r17 - прибавляю к адресу 0ого элемента цифру, которую необходимо показать
adc ZH, r20 // с учетом переноса
lpm r17, Z - считываю из памяти программ Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS Это не совсем грабли  когда я писал именно этот кусок кода, у меня этот массив был в ОП, были глюки (потом выяснилось, что не из-за этого), из-за которых я переделал этот массив в память программ, а поправить алгоритм забыл... а когда речь шла о ОП, то ее всего 128 байт (tiny2313). поэтому я и не замарачивался с регистром ZH. спасибо за уточнение. что касается RTC: Цитата(adc @ Dec 21 2007, 16:02) Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS у меня в влгоритме именно так и происходит: // Передача адреса закончена, переходим к приему данных 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 все вроде соответствует даташиту
|
|
|
|
|
|
|
|
Dec 21 2007, 13:15
|
Частый гость
Группа: Свой
Сообщений: 152
Регистрация: 11-10-05
Из: Воронеж
Пользователь №: 9 491
|
Цитата(adc @ Dec 21 2007, 16:02) Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS я ничего не путаю, просто в исходниках автора не ковырялся - предложил ему самому проверить. потом и сам проверил - с виду все правильно. но с учетом того, что правильное чтение производится не через раз, а именно четных данных, думаю искать ошибку надо именно где-то в районе младшего бита данных
|
|
|
|
|
|
|
|
Dec 21 2007, 13:21
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(sergik_vrn @ Dec 21 2007, 16:12) да, вроде все правильно. ну тогда остается только попробовать посмотреть соответствие картины обмена на осциллографе к сожалению осцилографа под рукой нет... оглошу еще один маленький факт: то, что я делаю сейчас (подключение RTC к МК) является лишь частью одного более глобального проекта. поэтому сделано все на навесном мантаже. предположения КЗ между ножками отметаются сразу. все проверяно по 100 раз. но в какой-то момент времени (по неизвесным причинам) микросхема нагрелась до такой температуры, что отпаялись все проводки от нее (кроме земли). МК живой, проверял каждую ножку. припоял все проводки на место к RTC. подключил и она заработала... вопрос: могла ли RTC так хитро сгореть, или все же это похоже на баг в коде? я проверял работу алгоритма на AVR Studio в режиме эмуляции ATTiny2313... там никаких глюков не было. что ему на "вход" подовал, то на выходе и получал... поэтому я уже не знаю что думать... может быть действительно RTC битая?
|
|
|
|
|
|
|
|
Dec 21 2007, 13:27
|
Частый гость
Группа: Свой
Сообщений: 152
Регистрация: 11-10-05
Из: Воронеж
Пользователь №: 9 491
|
Цитата(Pepper @ Dec 21 2007, 16:21) к сожалению осцилографа под рукой нет...
я проверял работу алгоритма на AVR Studio в режиме эмуляции ATTiny2313... там никаких глюков не было. что ему на "вход" подовал, то на выходе и получал... поэтому я уже не знаю что думать... может быть действительно RTC битая? плохо, что нет если битая, вряд ли она настолько удачно битая, что именно четные байты не отдает...
|
|
|
|
|
|
|
|
Dec 21 2007, 14:12
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(sergik_vrn @ Dec 21 2007, 16:27) плохо, что нет
если битая, вряд ли она настолько удачно битая, что именно четные байты не отдает... тогда я не знаю чё делать...  мысли закончились позвольте один интересный факт рассказать: согласно даташиту ноги RTC подтянуты к земле.... я резистором подтягиваю их на +5 и о чудо... там, где раньше читались нули - щас читаются 0xFF... дальшейшие изыскания привели к тому, что так себя видут ячейки с НЕ инициализированными значениями. т.е. записываю в RAM RTC нечетное значение - читается нормально... а если записать четное или вообще ничего не записывать то получается вот такая вот странная фигура... лично я снова ничего не понимаю... может быть вам это то даст
|
|
|
|
|
|
|
|
Dec 21 2007, 14:24
|
Частый гость
Группа: Свой
Сообщений: 152
Регистрация: 11-10-05
Из: Воронеж
Пользователь №: 9 491
|
Цитата(Pepper @ Dec 21 2007, 17:12) тогда я не знаю чё делать... мысли закончились позвольте один интересный факт рассказать: согласно даташиту ноги RTC подтянуты к земле.... я резистором подтягиваю их на +5 и о чудо... там, где раньше читались нули - щас читаются 0xFF... дальшейшие изыскания привели к тому, что так себя видут ячейки с НЕ инициализированными значениями. т.е. записываю в RAM RTC нечетное значение - читается нормально... а если записать четное или вообще ничего не записывать то получается вот такая вот странная фигура... лично я снова ничего не понимаю... может быть вам это то даст сие подтверждает мою мысль - операция чтения четного числа вообще не выполняется. то есть микросхема часов отказывается брать контроль шины на себя и выводить данные - а поскольку контроллер тоже находится в режиме чтения, Вы и наблюдаете указанный эффект. хотя как это может быть связано с СОЖЕРЖИМЫМ регистра - абсолютно непонятно...
|
|
|
|
|
|
|
|
Dec 21 2007, 14:30
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(sergik_vrn @ Dec 21 2007, 17:24) сие подтверждает мою мысль - операция чтения четного числа вообще не выполняется. то есть микросхема часов отказывается брать контроль шины на себя и выводить данные - а поскольку контроллер тоже находится в режиме чтения, Вы и наблюдаете указанный эффект. хотя как это может быть связано с СОЖЕРЖИМЫМ регистра - абсолютно непонятно... мда... ладно, спасибо за помощь. может быть на выходных получится поподробнее разобраца в алгоритмах и даташитах... нужно еще раз все проверить на AVR Studio...
|
|
|
|
|
|
|
|
Dec 26 2007, 11:53
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
только что обнаружил еще более странный глюк: при включении питания контроллера на экране ~ полсекунды горят четные числа, а потом нули... что это ????????????
|
|
|
|
|
|
|
|
Dec 26 2007, 12:20
|
Местный
Группа: Свой
Сообщений: 409
Регистрация: 29-10-07
Пользователь №: 31 836
|
Цитата(Pepper @ Dec 26 2007, 14:53) только что обнаружил еще более странный глюк: при включении питания контроллера на экране ~ полсекунды горят четные числа, а потом нули... что это ???????????? Выложите проект полностью.. и последнюю версию с исправлениями(в приложенном файле). Или отправьте через личку. А то собирать куски кода по ветке не очень удобно.  зы: что то я не вижу в цикле "mainloop" команды "sei" - разрешение прерываний
Сообщение отредактировал adc - Dec 26 2007, 12:25
--------------------
Умный программист пишет тупым кодом гениальные вещи, а не наоборот...
|
|
|
|
|
|
|
|
Dec 26 2007, 12:36
|
Участник
Группа: Новичок
Сообщений: 22
Регистрация: 21-12-07
Из: г.Астрахань
Пользователь №: 33 511
|
Цитата(adc @ Dec 26 2007, 15:20) Выложите проект полностью.. и последнюю версию с исправлениями(в приложенном файле). Или отправьте через личку. А то собирать куски кода по ветке не очень удобно. зы: что то я не вижу в цикле "mainloop" команды "sei" - разрешение прерываний вот весь проект 
7_s.inc.txt ( 893 байт )
Кол-во скачиваний: 226
delay.inc.txt ( 176 байт )
Кол-во скачиваний: 206
main.asm.txt ( 3.9 килобайт )
Кол-во скачиваний: 232
time.inc.txt ( 4.6 килобайт )
Кол-во скачиваний: 198
timer.inc.txt ( 447 байт )
Кол-во скачиваний: 174В main`е есть небольшое количесво кода, которое не сипользуется. это эксперементы не обращайте внимания ))
Сообщение отредактировал Pepper - Dec 26 2007, 12:40
|
|
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
