Ignis Caelum
инфо
инструменты
Xan
alex_zeed
GOGI
Реклама Google — средство выживания форумов :)
-
/af557db03d96.jpg)
Микроконтроллеры AVR - применение и Краткий Курс - часть 10
Теги:
Кто-нибудь оценивал точность внешних кварцов (12 Мгц,18, 24 ) ?
у меня получалось лишние или нехватающие тики в соотношении 1/10000.
у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
I.C.> Кто-нибудь оценивал точность внешних кварцов (12 Мгц,18, 24 ) ?
I.C.> у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Примерно так и есть.
В доках на обычные кварцы несколько десятков миллионных, это и получится 1/10000.
2...5 миллионных — это уже специальные генераторы.
I.C.> у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Примерно так и есть.
В доках на обычные кварцы несколько десятков миллионных, это и получится 1/10000.
2...5 миллионных — это уже специальные генераторы.
I.C.>> Кто-нибудь оценивал точность внешних кварцов (12 Мгц,18, 24 ) ?
I.C.>> у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Xan> Примерно так и есть.
Xan> В доках на обычные кварцы несколько десятков миллионных, это и получится 1/10000.
Xan> 2...5 миллионных — это уже специальные генераторы.
как на этом фоне смотрятся часовые генераторы (32768 Гц) ?
набегающая ошибка у них намного меньше.
I.C.>> у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Xan> Примерно так и есть.
Xan> В доках на обычные кварцы несколько десятков миллионных, это и получится 1/10000.
Xan> 2...5 миллионных — это уже специальные генераторы.
как на этом фоне смотрятся часовые генераторы (32768 Гц) ?
набегающая ошибка у них намного меньше.
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
I.C.> как на этом фоне смотрятся часовые генераторы (32768 Гц) ?
I.C.> набегающая ошибка у них намного меньше.
Ну как намного меньше?
1...2 секунды в сутки — это примерно 20 миллионных, обычная точность.
Более точные встречаются реже.
А в чём проблема случилась?
Обычно кварцевой точности с избытком хватает.
I.C.> набегающая ошибка у них намного меньше.
Ну как намного меньше?
1...2 секунды в сутки — это примерно 20 миллионных, обычная точность.
Более точные встречаются реже.
А в чём проблема случилась?
Обычно кварцевой точности с избытком хватает.
Xan> А в чём проблема случилась?
Xan> Обычно кварцевой точности с избытком хватает.
часы в устройстве на атмеге с кварцем накапливают ошибку размером примерно 1/10000 относительно часов на компьютере.
Xan> Обычно кварцевой точности с избытком хватает.
часы в устройстве на атмеге с кварцем накапливают ошибку размером примерно 1/10000 относительно часов на компьютере.
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
I.C.> Кто-нибудь оценивал точность внешних кварцов (12 Мгц,18, 24 ) ?
I.C.> у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Я как раз сейчас строю приёмник станции РБУ. в инете есть две схемы - Полякова, попроще с умножителем добротности, и Анкудинова, посложнее, с кварцевым фильтром и двойным преобразованием частоты.
Если будет хороший источник опоры, можно подогнать частоту кварца конденсатором.
Вот схема Анкундинова:
Вот схема Полякова:
404
I.C.> у меня получалось лишние или нехватающие тики в соотношении 1/10000.
Я как раз сейчас строю приёмник станции РБУ. в инете есть две схемы - Полякова, попроще с умножителем добротности, и Анкудинова, посложнее, с кварцевым фильтром и двойным преобразованием частоты.
Если будет хороший источник опоры, можно подогнать частоту кварца конденсатором.
Вот схема Анкундинова:
Вот схема Полякова:
404
Это сообщение редактировалось 31.01.2011 в 13:41
А.С.> Если будет хороший источник опоры, можно подогнать частоту кварца конденсатором.
А можно просто коррекцию сделать - условно говоря, раз в какое-то время (минуты) прибавлять-отнимать нужное кол-во миллисекунд к счетчику. Подобного плана коррекцию встречал в советских кварцевых часах.
А можно просто коррекцию сделать - условно говоря, раз в какое-то время (минуты) прибавлять-отнимать нужное кол-во миллисекунд к счетчику. Подобного плана коррекцию встречал в советских кварцевых часах.
Кто тут у нас с помощью МК на жисть зарабатывает? В чём прикол у А.В. Евстифеева в формуле ADC = (Uin*1024)/Uref для перевода значений АЦП Меги в вольты? У Меги АЦП 10bit, значит, результат преобразования лежит в пределах min=0, max=1023. Пусть Uref=5В, Uin=5В, тогда ADC = 1024, а это уже 11bit. Получается, умножать надо на 1023, а не на 1024. ?
Прикреплённые файлы:
Volt-bit_MPX.rar (скачать)
[18,8 кБ]
Простите,-спросили Мартовского Кота,-действительно ли в марте месяце? Какая чушь,- ответил Мартовский Кот,- и март месяц не исключение! http://martkot.embedders.org
MartKot> Пусть Uref=5В, Uin=5В, тогда ADC = 1024
Не, не так. АЦП = 1023
Для напруги примерно от 4.9975 и выше АЦП выдаёт 1023 = 1111111111
А для напруги ниже 0.0025 — 0000000000
0.0025 ... 0.0075 — 0000000001
0.0075 ... 0.0125 — 0000000010
4.9875 ... 4.9925 — 1111111101
4.9925 ... 4.9975 — 1111111110
выше 4.9975 — 1111111111
Вычти из Uin Uref/2048 и формула будет вести себя хорошо!
ADC = ((Uin * 1024) - 0.5) / Uref
Не, не так. АЦП = 1023
Для напруги примерно от 4.9975 и выше АЦП выдаёт 1023 = 1111111111
А для напруги ниже 0.0025 — 0000000000
0.0025 ... 0.0075 — 0000000001
0.0075 ... 0.0125 — 0000000010
4.9875 ... 4.9925 — 1111111101
4.9925 ... 4.9975 — 1111111110
выше 4.9975 — 1111111111
Вычти из Uin Uref/2048 и формула будет вести себя хорошо!
ADC = ((Uin * 1024) - 0.5) / Uref
Xan> Для напруги примерно от 4.9975 и выше АЦП выдаёт 1023 = 1111111111
Xan> выше 4.9975 — 1111111111
Xan> Вычти из Uin Uref/2048 и формула будет вести себя хорошо!
Xan> ADC = ((Uin * 1024) - 0.5) / Uref
Тогда, так что ли получается:
ADC = (4,9975*1024)/5= 1023,488 ->1023 (получается правильно)
ADC = (4,9975*1023)/5= 1022,4885 ->1022
А 2048 откуда? Точность преобразования?
Xan> выше 4.9975 — 1111111111
Xan> Вычти из Uin Uref/2048 и формула будет вести себя хорошо!
Xan> ADC = ((Uin * 1024) - 0.5) / Uref
Тогда, так что ли получается:
ADC = (4,9975*1024)/5= 1023,488 ->1023 (получается правильно)
ADC = (4,9975*1023)/5= 1022,4885 ->1022
А 2048 откуда? Точность преобразования?
Простите,-спросили Мартовского Кота,-действительно ли в марте месяце? Какая чушь,- ответил Мартовский Кот,- и март месяц не исключение! http://martkot.embedders.org
MartKot> А 2048 откуда? Точность преобразования?
Это половинка ступеньки = половина шага квантования.
Ну вот если АЦП однобитный, то он при напруге ниже 2.5 вольт должен выдавать ноль, а выше — единицу.
Или я этим только запутаю?
У реального АЦП ступеньки только в среднем 0.005 вольта.
Если аккуратно померить, то их величина колеблется в пределах 0.001 ... 0.009. Это если фирма гарантирует "no missing code".
А если не гарантирует, то вполне могут быть и меньше нуля, и больше 0.010.
Это половинка ступеньки = половина шага квантования.
Ну вот если АЦП однобитный, то он при напруге ниже 2.5 вольт должен выдавать ноль, а выше — единицу.
Или я этим только запутаю?
У реального АЦП ступеньки только в среднем 0.005 вольта.
Если аккуратно померить, то их величина колеблется в пределах 0.001 ... 0.009. Это если фирма гарантирует "no missing code".
А если не гарантирует, то вполне могут быть и меньше нуля, и больше 0.010.
Xan> Или я этим только запутаю?
Да не, нормально! Теперь всё понял. Я подошёл к формуле АЦП с "аналоговой" точки зрения, не учитывая процесс преобразования, а надо было с "цифровой"
Да не, нормально! Теперь всё понял. Я подошёл к формуле АЦП с "аналоговой" точки зрения, не учитывая процесс преобразования, а надо было с "цифровой"
Простите,-спросили Мартовского Кота,-действительно ли в марте месяце? Какая чушь,- ответил Мартовский Кот,- и март месяц не исключение! http://martkot.embedders.org
Тема: как на МК АТМЕГА задавать красивые временные промежутки.
Несколько раз у участников форума встречал реализации устройств на атмеге с очень странными временными промежутками, используемыми для записи данных. Чаще всего - 61 раз в секунду.
понятно что технике всеравно, но как то не красиво. Плохо переводится в термины старика Герца.
счетчики в МК имеют функционал, позволяющий решить этот вопрос - получение любой заданной частоты.
Для этого надо отказаться от прерывания по переполнению, а использовать прерывание по совпадению с заранее заданным числом.
Расчет этого числа выглядит следующим образом:
Период между прерываниями T = ((1024 * 180) * / 18 432 000) = 0.01 сек ==> для установления частоты срабатывания прерывания 100 Гц следует использовать прескалер 1024 и число сравнения 180.
Бывает что не влазит необходимое число (остаток от деления нацело) в 8-битный счетчик - использую тогда 16битный.
И надо не забыть . что верктор прерывания теперть
Пример.
.cseg
.org 000
rjmp _reset
.org OC2addr
rjmp _interrupt_timer_overcount
//....//
_timer_init: ; устанавливает делитель частоты и запускает таймер
ldi r16, low(cT2top -1 ) ; загружаю (180-1)
mOut OCR2 , r16 ; установлю TOP для TCNT2 при котором он будет обнуляться
mIn r16, TIMSK
ori r16, (1<< OCIE2) ; разрешает прерывание по совпадению Timer2 и OCIE1A
mOut TIMSK, r16
ldi r16, (1<<WGM21) ; устанавливает режим CTC (назначение битов WGM между счетчиками отличаются)
ori r16, (1<<CS22)|(1<<CS21)|(1<<CS20) ; устанавливает делитель частоты 1024
mOut TCCR2,r16
// счетчик запустился
ret
//....//
_interrupt_timer_overcount:
код, выполняемый через заданный промежуток времени.
ret
Несколько раз у участников форума встречал реализации устройств на атмеге с очень странными временными промежутками, используемыми для записи данных. Чаще всего - 61 раз в секунду.
понятно что технике всеравно, но как то не красиво
. Плохо переводится в термины старика Герца.счетчики в МК имеют функционал, позволяющий решить этот вопрос - получение любой заданной частоты.
Для этого надо отказаться от прерывания по переполнению, а использовать прерывание по совпадению с заранее заданным числом.
Расчет этого числа выглядит следующим образом:
Период между прерываниями T = ((1024 * 180) * / 18 432 000) = 0.01 сек ==> для установления частоты срабатывания прерывания 100 Гц следует использовать прескалер 1024 и число сравнения 180.
Бывает что не влазит необходимое число (остаток от деления нацело) в 8-битный счетчик - использую тогда 16битный.
И надо не забыть . что верктор прерывания теперть
Пример.
.cseg
.org 000
rjmp _reset
.org OC2addr
rjmp _interrupt_timer_overcount
//....//
_timer_init: ; устанавливает делитель частоты и запускает таймер
ldi r16, low(cT2top -1 ) ; загружаю (180-1)
mOut OCR2 , r16 ; установлю TOP для TCNT2 при котором он будет обнуляться
mIn r16, TIMSK
ori r16, (1<< OCIE2) ; разрешает прерывание по совпадению Timer2 и OCIE1A
mOut TIMSK, r16
ldi r16, (1<<WGM21) ; устанавливает режим CTC (назначение битов WGM между счетчиками отличаются)
ori r16, (1<<CS22)|(1<<CS21)|(1<<CS20) ; устанавливает делитель частоты 1024
mOut TCCR2,r16
// счетчик запустился
ret
//....//
_interrupt_timer_overcount:
код, выполняемый через заданный промежуток времени.
ret
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
I.C.>...
Ага, принцип понятен.
I.C.>...с очень странными временными промежутками...61 раз в секунду.
Тут всё просто, 4000000/65536=61.035...
Я исходил при измерении частоты из принципа разумной достаточности - при работе ёмкостного датчика частота меняется не более, чем в 2 раза. Сигнал датчика (частота) вешается на прерывание int0 и там просто инкрементируется. А 61 раз в секунду происходит подсчет и сброс.
Ага, принцип понятен.
I.C.>...с очень странными временными промежутками...61 раз в секунду.
Тут всё просто, 4000000/65536=61.035...
Я исходил при измерении частоты из принципа разумной достаточности - при работе ёмкостного датчика частота меняется не более, чем в 2 раза. Сигнал датчика (частота) вешается на прерывание int0 и там просто инкрементируется. А 61 раз в секунду происходит подсчет и сброс.
I.C.> счетчики в МК имеют функционал, позволяющий решить этот вопрос - получение любой заданной частоты.
I.C.> Для этого надо отказаться от прерывания по переполнению, а использовать прерывание по совпадению с заранее заданным числом.
Такой функционал в Меге8 только в одном таймере, а у меня он занят под ШИМ. Поэтому осталось 61, хотя и хотел поменять.
I.C.> Для этого надо отказаться от прерывания по переполнению, а использовать прерывание по совпадению с заранее заданным числом.
Такой функционал в Меге8 только в одном таймере, а у меня он занят под ШИМ. Поэтому осталось 61, хотя и хотел поменять.
I.C.>>...с очень странными временными промежутками...61 раз в секунду.
Massaraksh> Тут всё просто, 4000000/65536=61.035...
Massaraksh> Я исходил при измерении частоты из принципа разумной достаточности - при работе ёмкостного датчика частота меняется не более, чем в 2 раза. Сигнал датчика (частота) вешается на прерывание int0 и там просто инкрементируется. А 61 раз в секунду происходит подсчет и сброс.
Почему такой промежуток - понятно. просто не эстетично.
1. на int0 вешать не надо, можно было сразу завести на TCNT1 - аппаратный 16 битный счетчик.
2. убери из подпрограммы прерывания int0 команды cli и sei. они лишние.
кратко блок схема реализованная у меня в устройстве.
я считаю количество тиков измеряемой частоты за заданный период 0,01. и общее количество тактов процессора прошедшего за во время этик тиков. от фронта до фронта.
Искомая частота это Fизм = CNTизм * Fproc / CNTproc.
Massaraksh> Тут всё просто, 4000000/65536=61.035...
Massaraksh> Я исходил при измерении частоты из принципа разумной достаточности - при работе ёмкостного датчика частота меняется не более, чем в 2 раза. Сигнал датчика (частота) вешается на прерывание int0 и там просто инкрементируется. А 61 раз в секунду происходит подсчет и сброс.
Почему такой промежуток - понятно. просто не эстетично
.1. на int0 вешать не надо, можно было сразу завести на TCNT1 - аппаратный 16 битный счетчик.
2. убери из подпрограммы прерывания int0 команды cli и sei. они лишние.
кратко блок схема реализованная у меня в устройстве.
я считаю количество тиков измеряемой частоты за заданный период 0,01. и общее количество тактов процессора прошедшего за во время этик тиков. от фронта до фронта.
Искомая частота это Fизм = CNTизм * Fproc / CNTproc.
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
Serge77> Такой функционал в Меге8 только в одном таймере, а у меня он занят под ШИМ. Поэтому осталось 61, хотя и хотел поменять.
1. такой функционал во всех трех таймерах.
2. есть идея как отказаться от шима. попробуем - о результатах сообщу.
1. такой функционал во всех трех таймерах.
2. есть идея как отказаться от шима. попробуем - о результатах сообщу.
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
Не вижу какой-то надобности во временных интервалах, кратных десяти.
На конечном этапе постройки графика и скажем вычисления полного импульса абслотно по барабану 60 или 100 раз в секунду выборка. Мы получаем или график или число, никак не связанное с частотой выборки.
На конечном этапе постройки графика и скажем вычисления полного импульса абслотно по барабану 60 или 100 раз в секунду выборка. Мы получаем или график или число, никак не связанное с частотой выборки.
1
GOGI> Не вижу какой-то надобности во временных интервалах, кратных десяти.
конечно нет. но удобней для понимания.
В конечном устройстве на внутренние часы завязаны несколько процессов.
каждый процесс отрабатывает со своей частотой. кто-то 100 Гц, кто-то, 40 Гц, кто-то 10 Гц. Временные промежутки между событиями опять же задаются в секундах.
проще сделать, чем каждый раз помнить коэффициенты пересчета.
P.S.
Данный пост был не вызван не попыткой обращения в свой веру, а желанием поделиться приемом, которым пользуюсь. (я просто разместил объяву... )
конечно нет. но удобней для понимания.
В конечном устройстве на внутренние часы завязаны несколько процессов.
каждый процесс отрабатывает со своей частотой. кто-то 100 Гц, кто-то, 40 Гц, кто-то 10 Гц. Временные промежутки между событиями опять же задаются в секундах.
проще сделать, чем каждый раз помнить коэффициенты пересчета.
P.S.
Данный пост был не вызван не попыткой обращения в свой веру, а желанием поделиться приемом, которым пользуюсь. (я просто разместил объяву... )
Лучше быть оптимистом и ошибаться, чем пессимистом, который всегда прав.
I.C.> Данный пост был не вызван не попыткой обращения в свой веру, а желанием поделиться приемом, которым пользуюсь. (я просто разместил объяву... )
Да понятно, я спросил - ты ответил.
I.C.> убери из подпрограммы прерывания int0 команды cli и sei. они лишние.
Привычка.
Да понятно, я спросил - ты ответил.
I.C.> убери из подпрограммы прерывания int0 команды cli и sei. они лишние.
Привычка.
Это сообщение редактировалось 18.04.2011 в 16:04
В помощь определяющим апогей.
Блок усреднения данных высотомера, работающего по принципу, описанному Serge77, по скользящему среднему на 2,4,8,16,32,64,128 точек и хранение их за последние 5 секунд.
Блок усреднения данных высотомера, работающего по принципу, описанному Serge77, по скользящему среднему на 2,4,8,16,32,64,128 точек и хранение их за последние 5 секунд.
code text
- ;--------------------------регистры
- ;
- ; $060-$15F - кольцевой буфер (рабочий) для вычисления усредненных данных на
- ; (2^N) N=1...7 значений (A)
- ; $160-$28C - кольцевой буфер последних 150 значений (300 байт)
- ; сглаженных данных в SRAM (Б)
- ;
- ; r0 - N
- ; r1 - счетчик начала отсчета скользяшего среднего
- ; r2 - текущее смещение в буфере (A) (Low)
- ; r3 - рабочий
- ; r4 - рабочий
- ; r5 - рабочий
- ; r6 - рабочий
- ; r7 - текущее смещение в буфере Б (High)
- ; r8 - текущее смещение в буфере Б (Low)
- ; r9 -
- ; r10 -
- ; r11 -
- ; r12 -
- ; r13 -
- ; r14 -
- ; r15 -
- ; r16 -
- ; r17 - рабочий
- ; r18 -
- ; r19 -
- ; r20 - Сумма ADC (Low)
- ; r21 - Сумма ADC (High)
- ; r22 -
- ; r23 -
- ; r24 -
- ; r25 -
- ; r26 - регистр X (Low)
- ; r27 - регистр X (High)
- ; r28 -
- ; r29 -
- ; r30 -
- ; r31 -
- ;
- ;--------------------------------Начальные установки
- clr r20
- clr r21
- clr r1
- clr r7
- clr r8
- clr r2
- sei
- idle: rjmp idle ;---Idle
- ................................................
- ;------------------------Сюда приходит суммированное 64 раза значение АЦП (r21:r20)
- inc r2 ;--------увеличиваем указатель в буфере усреднения
- inc r2
- rcall power
- add r6,r6
- cp r2,r6
- brne ac1
- clr r2 ;--------конец буфера? на начало
- ac1: ldi r26,$060
- clr r27
- clr r17
- add r26,r2
- adc r27,r17
- st X+,r20 ;--------запись полученного значения в кольцевой буфер усреднения
- st X+,r21
- inc r1
- rcall power
- cp r1,r6 ;--------пора начинать усреднение?
- brne accno ;--------рано
- ;--------------------------------Подсчет суммы в цикле
- ldi r26,$060
- clr r27
- push r21
- push r20
- clr r20
- clr r21
- clr r4
- clr r3
- clr r17
- ac2: ld r6,X+
- ld r5,X+
- add r20,r6 ;--------сложение 2-ух трёхбайтных чисел
- adc r21,r5
- adc r4,r3
- rcall power
- inc r17
- cp r17,r6
- brne ac2
- ;-----------------------получили сумму, делим 3-х байтовое число на 2^N
- clr r17
- ac3: ror r4
- ror r21
- ror r20
- inc r17
- cp r17,r0
- brne ac3
- ;--------------------------теперь всегда усреднять
- rcall power
- mov r1,r6
- dec r1
- ;--------------------------запись в кольцевой буфер сглаженных значений за последние 5 секунд
- ;--------------------------(это у меня 5 секунд, потому что 30 опросов в секунду)
- ;--------------------------иначе буфер надо расширить
- ldi r26,$60
- ldi r27,1
- add r26,r8
- adc r27,r7
- st X+,r20
- st X+,r21
- ;----------указатель смещаем
- clr r4
- inc r4
- inc r4
- clr r3
- add r8,r4
- adc r7,r3
- ;----------по кольцу
- mov r17,r8
- cpi r17,$2C
- brne accno
- mov r17,r7
- cpi r17,1
- brne accno
- clr r7
- clr r8
- ;-----------------------------запись r20,r21 в EEPROM
- accno: pop r20
- pop r21
- ..........................
- ;-------------------------------п/п возведения в степень
- ;
- ; r0 - N
- ; r6 - 2^^N
- ;
- power: push r17
- ldi r17,2
- mov r6,r17
- clr r5
- pow1: inc r5
- cp r5,r0
- breq powfin
- push r0
- push r1
- push r18
- mov r18,r6
- fmul r18,r17
- ror r1
- ror r0
- mov r6,r0
- pop r18
- pop r1
- pop r0
- rjmp pow1
- powfin: pop r17
- ret
Это сообщение редактировалось 20.05.2011 в 05:38
Massaraksh> Блок усреднения данных высотомера, работающего по принципу, описанному Serge77, по скользящему среднему на 8 точек и хранение их за последние 5 секунд.
Думаю, для определения апогея лучше усреднять не 8-10 точек, а намного больше. Наверно нужно усреднять точки за 0.5-1 секунду полёта. Попробую сегодня на своих полётных данных.
Думаю, для определения апогея лучше усреднять не 8-10 точек, а намного больше. Наверно нужно усреднять точки за 0.5-1 секунду полёта. Попробую сегодня на своих полётных данных.
Serge77> Думаю, для определения апогея лучше усреднять не 8-10 точек, а намного больше. Наверно нужно усреднять точки за 0.5-1 секунду полёта. Попробую сегодня на своих полётных данных.
Тогда будет запаздывание на ту же секунду. А за секунду ракета сколько может пролететь...
Upd: Хотя, изменения в алгоритме для этого будут минимальными - константы поменять.
Тогда будет запаздывание на ту же секунду. А за секунду ракета сколько может пролететь...
Upd: Хотя, изменения в алгоритме для этого будут минимальными - константы поменять.
Это сообщение редактировалось 19.05.2011 в 09:25
Massaraksh> Тогда будет запаздывание на ту же секунду.
Да, будет.
Massaraksh> А за секунду ракета сколько может пролететь...
5 м
Да, будет.
Massaraksh> А за секунду ракета сколько может пролететь...
5 м
Реклама Google — средство выживания форумов :)
Massaraksh> В помощь определяющим апогей.
Я без разрешения немного посоветую
Операция деления
;-----------------------получили сумму, делим на 8
ror r4
ror r21
ror r20
ror r4
ror r21
ror r20
ror r4
ror r21 ;------------------результат (r21:r20)
ror r20
ror - это сдвиг вправо, освободившийся бит берется из флага переноса Система команд микроконтроллера avr Команда ROR Соответственно флаг переноса нужно чистить командой clc перед началом каждого этапа деления либо использовать первой операцией логический сдвиг вправо lsr - в освободившийся бит пишется 0 Система команд микроконтроллера avr Команда LSR. В твоем случае деление выдаст полную абракадабру, т.к. на момент начала деления что с флагом переноса неизвестно и при новом сдвиге ror r4 в 7-й бит будет попадать бит от предыдущей операции.
т.е.
либо
Я без разрешения немного посоветую
Операция деления
;-----------------------получили сумму, делим на 8
ror r4
ror r21
ror r20
ror r4
ror r21
ror r20
ror r4
ror r21 ;------------------результат (r21:r20)
ror r20
ror - это сдвиг вправо, освободившийся бит берется из флага переноса Система команд микроконтроллера avr Команда ROR Соответственно флаг переноса нужно чистить командой clc перед началом каждого этапа деления либо использовать первой операцией логический сдвиг вправо lsr - в освободившийся бит пишется 0 Система команд микроконтроллера avr Команда LSR. В твоем случае деление выдаст полную абракадабру, т.к. на момент начала деления что с флагом переноса неизвестно и при новом сдвиге ror r4 в 7-й бит будет попадать бит от предыдущей операции.
т.е.
code text
- ;-----------------------получили сумму, делим на 8
- clc
- ror r4
- ror r21
- ror r20
- clc
- ror r4
- ror r21
- ror r20
- clc
- ror r4
- ror r21 ;------------------результат (r21:r20)
- ror r20
либо
code text
- ;-----------------------получили сумму, делим на 8
- lsr r4
- ror r21
- ror r20
- lsr r4
- ror r21
- ror r20
- lsr r4
- ror r21 ;------------------результат (r21:r20)
- ror r20
Copyright © Balancer 1997..2018
Создано 06.12.2007
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 06.12.2007
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
