подскажите пожалуйста алгоритм такой штуки?
Есть n-ое значение в регистре, а в двух других верхний и нижний предел.
Нужно проверить, находится ли значение байта между нижним и верхним пределом. Если находится, то ничего не делать а если нет, то узнать по какому из них не проходит.
вопрос относительно оформления векоров обработчика преываний
я встречал две формы оформления
первая https://dpaste.de/GrXR/raw
вторая https://dpaste.de/rKeZ/raw
по поводу первой формы мне все понятно
вторая говорят более универсальная
в чем заключается ее универсальность ?
когда следует применять первую, когда вторую, а когда только вторую ?
А, ты и тут засветился... я уж было думал меня глючит.
действовать надо по обстоятельствам. Главное, чтобы инструкции перехода на обработчик находились на своих местах, а компилятору до лампочки как ты ему это сообщишь. Остаётся только эстетика для человека-программиста, вот исходя из этого и выбирай.
Если в какой-то микросхеме вектора прерываний идут в именно этом порядке с шагом в ровно одно слово - никто не гарантирует, что в похожей микросхеме и порядок, и шаг останутся точно такими же.
Всегда явно задавай адреса, никаких "авось"!
Приглядись внимательнее к фирменным файлам .inc, посравнивай, проникнись хитрожопостью задумки: условная метка (произвольный набор символов) везде выглядит одинаково, а её "расшифровка" (числовое значение) определяется для конкретной и только конкретной микросхемы.
С точки зрения удобства - по имени вектора сразу понятно от чего он. Единственное неудобство - нужно соблюдать порядок векторов, т.е. UTX после URX и т.д., без этого было бы еще проще.
С точки зрения отладки: если случится косяк, и программа перескочит на незадействованный вектор, то в тех 2-х вариантах, она тупо вернется по RETI, как будто ничего и не было. В варианте выше, на месте незадействованного вектора будет 0xFFFF, реальный МК сбросится (уже признак косяка), а любой эмулятор ругнется на недопустимый опкод, да еще и скажет по какому адресу.
Ну и так короче получается, не нужна длинная таблица.
PS: Я тоже через это прошел, сначала очень долго применял первую форму, потом попробовал вторую, но остановился на приведенной мной выше.
Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
у жирных мег (от 16к флеша) переходы на обработчики делаются по JMP, соответственно сами вектора 4 байтные. Если обработчик состоит из одной команды, например SBI, то можно схитрить и в сам вектор запихать SBI и RETI.
Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
Только не 4кслова, а +2кслова. Т.к. RJMP относительный переход и из начала флеша в 16кбайт на -2кслов перепрыгнуть без грязных хаков не даст компилятор, мы это обсуждали пару страниц назад... С хаками можно из векторов прерываний прыгнуть по RJMP в области 0-2к и "размер флеша"-2к.
Неправильно собранная из неисправных деталей схема нуждается в отладке и сразу не работает... (С)
LDs R16, UCSR0A ;ок, нормально
sbrs R16, RXC0 ;тоже верно
LDS R16,UDR0 ;а вот задержку ожидания приема делают не так, есть же пример в даташите! перед этой строкой должен быть переход на повторное чтение флага
cpi r16,'?' ;ок, приняли, сравнили,
jmp $0 ;почему безусловный переход в 0? сравнивали мы для чего? тут либо BRNE либо BREQ, либо любая другая подходящая BRxx
rjmp $1f10 ;эта строка никогда не выполнится из-за предидущей
WAIT_RX:
LDS R16, UCSR0A
SBRS R16, RXC0
RJMP WAIT_RX
LDS R16,UDR0
CPI r16,'?'
BRNE WAIT_RX ;ну или где вам там ждать надо...
RJMP $1f10
Спасибо! Извините, что не в ту тему влез!
Работает! Но он ожидает байт до посинения, а потом его сравнивает, а как сделать, чтобы время ожидания составляло секунд 8-10 ?
