astpepper 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба эээ приведите код где у вас массив "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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergik_vrn 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба и снова вы правы, но опять не помогло поставил задержку в 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 на полтакта Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба речь не о задержке, а о сдвиге синхронизации. запись-то идет по нарастающему фронту, а чтение - по спадающему (или наоборот). то есть при переходе от записи (команды) к чтению (данных) надо осуществить сдвих фазы 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adc 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 (изменено) · Жалоба там все нормально... это код, который овечает за вывод значений на сигментах... он никак на чтение из 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 - считываю из памяти программ речь не о задержке, а о сдвиге синхронизации. запись-то идет по нарастающему фронту, а чтение - по спадающему (или наоборот). то есть при переходе от записи (команды) к чтению (данных) надо осуществить сдвих фазы CS на полтакта Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS Изменено 21 декабря, 2007 пользователем adc Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergik_vrn 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба согласно даташиту не надо ничего менять... тоесть надо конечно, но у меня там все уже сдвинуто: // Передача адреса закончена, переходим к приему данных 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 да, вроде все правильно. ну тогда остается только попробовать посмотреть соответствие картины обмена на осциллографе Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба да.. должно быть не влияет.. Но только не корректно прибавлять значение только к младшему регистру. если у вас преред массивом не стоит директива ".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: Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. 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 все вроде соответствует даташиту Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergik_vrn 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба Что Вы путаете.. По заднему фронту восьмого такта устанавливается Нулевой бит данных из микросхемы..См. DS я ничего не путаю, просто в исходниках автора не ковырялся - предложил ему самому проверить. потом и сам проверил - с виду все правильно. но с учетом того, что правильное чтение производится не через раз, а именно четных данных, думаю искать ошибку надо именно где-то в районе младшего бита данных Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба да, вроде все правильно. ну тогда остается только попробовать посмотреть соответствие картины обмена на осциллографе к сожалению осцилографа под рукой нет... оглошу еще один маленький факт: то, что я делаю сейчас (подключение RTC к МК) является лишь частью одного более глобального проекта. поэтому сделано все на навесном мантаже. предположения КЗ между ножками отметаются сразу. все проверяно по 100 раз. но в какой-то момент времени (по неизвесным причинам) микросхема нагрелась до такой температуры, что отпаялись все проводки от нее (кроме земли). МК живой, проверял каждую ножку. припоял все проводки на место к RTC. подключил и она заработала... вопрос: могла ли RTC так хитро сгореть, или все же это похоже на баг в коде? я проверял работу алгоритма на AVR Studio в режиме эмуляции ATTiny2313... там никаких глюков не было. что ему на "вход" подовал, то на выходе и получал... поэтому я уже не знаю что думать... может быть действительно RTC битая? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergik_vrn 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба к сожалению осцилографа под рукой нет... я проверял работу алгоритма на AVR Studio в режиме эмуляции ATTiny2313... там никаких глюков не было. что ему на "вход" подовал, то на выходе и получал... поэтому я уже не знаю что думать... может быть действительно RTC битая? плохо, что нет если битая, вряд ли она настолько удачно битая, что именно четные байты не отдает... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба плохо, что нет если битая, вряд ли она настолько удачно битая, что именно четные байты не отдает... тогда я не знаю чё делать... :( мысли закончились :( позвольте один интересный факт рассказать: согласно даташиту ноги RTC подтянуты к земле.... я резистором подтягиваю их на +5 и о чудо... там, где раньше читались нули - щас читаются 0xFF... дальшейшие изыскания привели к тому, что так себя видут ячейки с НЕ инициализированными значениями. т.е. записываю в RAM RTC нечетное значение - читается нормально... а если записать четное или вообще ничего не записывать то получается вот такая вот странная фигура... лично я снова ничего не понимаю... может быть вам это то даст :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergik_vrn 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба тогда я не знаю чё делать... :( мысли закончились :( позвольте один интересный факт рассказать: согласно даташиту ноги RTC подтянуты к земле.... я резистором подтягиваю их на +5 и о чудо... там, где раньше читались нули - щас читаются 0xFF... дальшейшие изыскания привели к тому, что так себя видут ячейки с НЕ инициализированными значениями. т.е. записываю в RAM RTC нечетное значение - читается нормально... а если записать четное или вообще ничего не записывать то получается вот такая вот странная фигура... лично я снова ничего не понимаю... может быть вам это то даст :) сие подтверждает мою мысль - операция чтения четного числа вообще не выполняется. то есть микросхема часов отказывается брать контроль шины на себя и выводить данные - а поскольку контроллер тоже находится в режиме чтения, Вы и наблюдаете указанный эффект. хотя как это может быть связано с СОЖЕРЖИМЫМ регистра - абсолютно непонятно... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 21 декабря, 2007 Опубликовано 21 декабря, 2007 · Жалоба сие подтверждает мою мысль - операция чтения четного числа вообще не выполняется. то есть микросхема часов отказывается брать контроль шины на себя и выводить данные - а поскольку контроллер тоже находится в режиме чтения, Вы и наблюдаете указанный эффект. хотя как это может быть связано с СОЖЕРЖИМЫМ регистра - абсолютно непонятно... мда... ладно, спасибо за помощь. может быть на выходных получится поподробнее разобраца в алгоритмах и даташитах... нужно еще раз все проверить на AVR Studio... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 26 декабря, 2007 Опубликовано 26 декабря, 2007 · Жалоба только что обнаружил еще более странный глюк: при включении питания контроллера на экране ~ полсекунды горят четные числа, а потом нули... что это ???????????? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adc 0 26 декабря, 2007 Опубликовано 26 декабря, 2007 (изменено) · Жалоба только что обнаружил еще более странный глюк: при включении питания контроллера на экране ~ полсекунды горят четные числа, а потом нули... что это ???????????? Выложите проект полностью.. и последнюю версию с исправлениями(в приложенном файле). Или отправьте через личку. А то собирать куски кода по ветке не очень удобно. :07: зы: что то я не вижу в цикле "mainloop" команды "sei" - разрешение прерываний Изменено 26 декабря, 2007 пользователем adc Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
astpepper 0 26 декабря, 2007 Опубликовано 26 декабря, 2007 (изменено) · Жалоба Выложите проект полностью.. и последнюю версию с исправлениями(в приложенном файле). Или отправьте через личку. А то собирать куски кода по ветке не очень удобно. :07: зы: что то я не вижу в цикле "mainloop" команды "sei" - разрешение прерываний вот весь проект 7_s.inc.txt delay.inc.txt main.asm.txt time.inc.txt timer.inc.txt В main`е есть небольшое количесво кода, которое не сипользуется. это эксперементы :) не обращайте внимания :))) Изменено 26 декабря, 2007 пользователем Pepper Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
