xemul я ничего сам не писал.Функция __delay_ms описана в мануале на хайтек,я её просто применил.


Мануалы - рулеззз. Вы только сначала определитесь, какая у Вас версия - pro или std? В любом случае смотрите раздел "Special Type Qualifiers".
Вкратце: версии pro (и picc, и picc18) чихают на пожелания программера о рукопашном распределении переменных по банкам, но на квалификаторы bankN не ругаются для совместимости с версиями std (которые удовлетворяют такие пожелания).


Определился std.Моя версия std видимо очень наглая и не удовлетворяет.
имхо, в большинстве случаев он справится с этой вещью лучше, независимо от Ваших планов.
Щасс.

ЫЖ Евгений Германович, неужели, отвечая кому-нибудь в конфе, Вы не замечали парные конструкции, типа quote .. /quote, code .. /code, color .. /color, ..., заключаемые в []? Такие конструкции называются тэгами и придуманы для облегчения и изложения, и восприятия.
Ваш способ изложения облегчению восприятия совсем не способствует.

Не замечал,каюсь

Появилось несколько вопросов:
1. А как синтаксически правильно выразить "в бит порта (к примеру RC0) вывести битовую переменную (bit my_bit)"? Столкнулся с тем что в switch значение бита порта не равно переменной, при записи RC0 = my_bit.

2. Можно ли на PIC16 организовать вложеные прерывания? Т.е. в системе 3 прерывания - таймер и 2 приоритетных внешних. Необходимо чтоб внешние прерывания могло вызываться при обработке прерывания таймера. Если при возникновении прерывания таймера очищать бит прерывания таймера и устанавливать бит глобального прерывания вручную (а не командой retfie)- будет ли это работать ?
За детские вопросы прошу не бить, с HiT и PIC16 - первый раз.

1. #define my_bit PORTC0 (или RC0, не помню в HI-TECH как было, можно посмотреть в include файле)
2. Работать будет, но надо еще позаботиться о сохранении контекста. Если у вас процедура обработки прерываний такая длинная, это уже само по себе неправильно. В прерываниях нужно поднимать только флаги, а основную обработку совершать вне прерывании. По моему скромному мнению, прерывать прерывание в 16-й серии оправдано только в случае если приходится мониторить о пропаже питания.

добавил: По 2. нужно очень внимательно позаботиться, что бы при повторное прерывание, не попасть в тот же самый обработчик прерываний, который был прерван, получиться reentrance, со всеми вытекающими... Вообще в 16-й серии лучше такое не делать! (хотя у меня было один раз, но по второму прерыванию, сохранял данные и дальше просто усыпал процессор, который из слипа, выходил только по reset)

RC0 = my_bit; - для picc совершенно правильная синтаксическая конструкция, которая раскручивается (т.к. RC0 объявлен volatile bit) во что-нить вроде
btfss 0x.., my_bit_pos
goto $+3
bsf RC0
goto $+2
bcf RC0
Посмотрите внимательно ассемблерный листинг.
Неплохо бы указывать версию компилятора и приводить фрагмент, в котором наблюдаются/предполагаются проблемы, и необходимые объявления.

Можно, но вряд ли оно требуется.
Определитесь, какое прерывание является самым приоритетным для Вашей программы, поставьте его обработчик первым, все остальные обработчики сделайте максимально короткими.
Какие временнЫе параметры у сигналов на "2 приоритетных внешних" прерываниях и чем занимается таймер?

Будет, но Вам придется написать своё сохранение/восстановление регистров и отвести под это соответствующий кусок ОЗУ (с учетом предполагаемой вложенности прерываний). Но сама идея идеологически вредная, учитывая систему прерываний мелких пиков, и самонадеянная, учитывая первый раз.

С прерыванием разобрался - рутиное прерывание (динамическая индикация и скан клавиатуры) и 2 вложенных - прием RC5 и измерение периода сигнала после датчика температуры TMP04 сделал, правда всё прерывание перебил на ассемблере, на С похоже вложенность не сделать из - за авто - кода в заголовке прерывания. Требуется отведение отдельных переменных (удобно в разных банках) под w, status, PCLATH для каждого из 3 прерываний, те по сути маленький диспетчер по org 0x4.

Попутно сделал вывод что PIC16 не айс - сильно устарел, больше в их сторону смотреть не буду.