А здесь все гораздо хуже.
80+ 79=159
если складывать эти числа на pic16f452
то все нормально-80н +79н дальше DAW в регистре WREG число 59 и флаг С в статусе =1
но если складывать числа больше 79 то получается следующее
80н + 80н далее DAW регистре WREG число 60 и флаг С в статусе =0 !!!!
ХОТЯ В МПЛАБЕ С=1
Это похоже на глюк контроллера.

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

Да нет не правильно.И в даташите по этому поводу полная тишина.
Если хотите текст,то пожалуйста ;пп перевода HEX в DEC
;вход BBNDEC-число в HEX формате
;выход CHBD-старший,CLBD-младший байты десятичного числа
BINDEC:
GLOBAL BINDEC
MOVLB 0
CLRF CHBD,BANKED
CLRF CLBD,BANKED
MOVLW 08H
MOVWF RBINDEC,BANKED ;счетчик
;
MET: RLCF BBNDEC,F,BANKED
MOVF CLBD,W,BANKED
ADDWFC CLBD,W,BANKED
DAW ;здесь сбросится флаг переноса.
MOVWF CLBD,BANKED
MOVF CHBD,W,BANKED
ADDWFC CHBD,W,BANKED
; DAW
MOVWF CHBD,BANKED
;
DECFSZ RBINDEC,F,BANKED
GOTO MET
RETURN

При прогоне в мплабе все хорошо и прекрасно,на реальном железе начиная со 160 и заканчивая 199 будет не совсем хорошо,вместо 1 в сотнях будет 0.

Я тоже ни разу не сталкивался с подобными проблемами в Пиках: не на 16-й серии, не на 18-й таких проблем с арифметикой не было. Тем более с целочисленной. Так что ищите грабли у себя.
P.S. Я предпочитаю всегда вести отладку на живом железе, а не в программных симуляторах и иже с ними.

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

Это не глючок,а глючара
Все не так просто.Если при сложении чисел в старшем полубайте образуется число <9 (и С устанавливается в 1)то при десятичной коррекции флаг сбрасывается -а это иначе как бл......м не назовеш.
А если там более 9 то все нормально.

Я тоже ни разу не сталкивался с подобными проблемами в Пиках: не на 16-й серии, не на 18-й таких проблем с арифметикой не было. Тем более с целочисленной. sad.gif Так что ищите грабли у себя.
Проверьте- просуммируйте 80 и 80 и произведите десятичную коррекцию.
Дб 60 и С=1 ,а для вышеупомянутого пика будет 60 и С=0
Если складывать 80 и 79 то р-тат будет 59 и С=1.
Но мплаб всегда показывает С=1 для всех примеров.

М-да, похоже что это действительно косяк кристалла. Я был не прав, прошу прощения.


А вот тут вы совершенно не правы. Небольшой поиск - и результат на лицо. Смотрите любую из еррат по ссылке. Там их пять штук (не считая ерраты по Таймеру_1). И во всех пяти упоминается этот косяк и как его победить. Удачи.

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

79h+80h = 255d -> при дополнении полубайтов(+6 для daw) просиходит переполнение обоих полубайтов, С=1
80h+80h = 256d = 0 -> при дополнении переполнения нет для обоих полубайтов, С=0

кажется это вполне корректное поведение для флага С - показвывать переполнение (т.е. при >9 в полубайте и добавлении 6 в соответсвии с командой происходит переполнение)

и еще раз повторюсь, если уж в тектсе смешиваете числа в разных форматах, ПОДПИСЫВАЙТЕ ФОРМАТ, имейте уважение к людям

ЗЫ: Микродип собственно написал все, эрраты читать надо, их для того и пишут

Согласен,как говориться, факт на лице Однако ,всё равно ,создатели этого кристалла-нехорошие люди( и это ещё мягко сказано).




79h+80h = 255d -> при дополнении полубайтов(+6 для daw) просиходит переполнение обоих полубайтов, С=1
80h+80h = 256d = 0 -> при дополнении переполнения нет для обоих полубайтов, С=0
Неправда ваша 0х79 + 0х80 =0хF9 DAW 0х59 С=1
а 0х80 +0х80=0х100 DAW 0х60 С=0!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

вообще то процессор 8-битный, поэтому числа 0х100 для него не существует (в регистре остается 0х00 + 1 в С) и логика о которой я писал есть, другое дело, что это мешает использованию команды, за что разработчиков можно попинать ногами по голове

Лучше в другое место

может не совсем в тему, но почему древность 452?
есть уже поновее - 4520 - гораздо удобнее, встр. генератор - до 32мгц с плл, и другие вкусности, ECCP опять же
или например 4523 - с 12 битным АЦП...

Причин несколько:
1 на него есть русский текст
2 у меня он есть
3 он есть в продаже
4 у 4520 ошибок не меньше
5 мне не надо АЦП
6 частота нужна кварцованная

Установил тут версию MPLab 8.90 заместо 8.40.
Теперь, в старых проектах, невозможно отобразить регистр WREG?
Это как-то можно побороть?

Попробуйте установить версию 8.91 отсюда.