Ликбез по программированию PIC
SAK: загрузка счёчика перед завершением прерывания может привести к нестабильности временных интервалов при длительной обработке прерывания.
Ничего подобного...
Возьмем мысленно по шкале времени точки с шагом 20ms. Применим "растяжку" (как вторая развертка в приличном осциллографе) и просмотрим эти точки. Для определенности пусть одной из точек будет время появления флага окончания счета. Прикинем, на сколько по времени от этой точки отстоит время его инициализации. Пусть это будет 20мксек...ну оччень много команд. Пусть счет будет всего пять циклов (это худший у нас случай) И тогда абсолютная ошибка (стабильная,систематическая!) будет составлять 20мксек. от 100ms т.е. 0,02% О нестабильности, речи нет. Ошибка ВСЕГДА будет такой, какой Вы ее сделаете.По поводу нестабильности все вопросы к кварцевому генератору....
По поводу "пройденного материала" . Я лично доволен тем, -что хоть несколько человек в начале этого непростого пути, избежали некоторых типичных ошибок, не пошли по пути усвоения "кривого" программирования. С чтения соседней ветки можно провести сравнение размеров кодов при реализации одинаковых алгоритмов для asm и Cи.
В этом деле есть много забавного и увлекательного...шахматы просто отдыхают перед вывертами программиста на ASM....
Выводы каждый может сделать сам....УДАЧИ! Интересных и хорошо оплачиваемых работ!...
Vlad_Petr: И тогда абсолютная ошибка (стабильная,систематическая!)
Я думаю, что не совсем так. Позволю себе покритиковать гуру. 
В прерываниях программа может развиваться по разным сценариям в зависимости от условий. Поэтому время выполнения команд в прерывании может быть разным. Ошибка небольшая, но она не систематическая!
Zandy: тут http://www.radio.ru/ubb/Forum4/HTML/000769.html
Понял, что это страшно замороченная штука
Почитал ветку. Zandy! Вы на 80% все это уже в подсознание себе заложили.. Это я видел по Вашим предположениям и высказываниям по ходу работы. Еще пока вера в собственные силы не появилась, это наживное, а настойчивости Вам не занимать..все будет ОК!
Zandy: Позволю себе покритиковать гуру.
Спасибо! Мне это приятно!! Значит не зря время потрачено..
В прерываниях программа может развиваться по разным сценариям в зависимости от условий. Поэтому время выполнения команд в прерывании может быть разным. Ошибка небольшая, но она не систематическая!
Уточню. В Вашем изложении она имеет НЕСКОЛЬКО КОНКРЕТНЫХ ВАРИАНТОВ ЗНАЧЕНИЙ. На начальном периоде освоения asm это у Вас, естественно, будет так. Со временем, Вы даже не задумываясь автоматически будете учитывать, если надо, такие ходы и делать все это быстро и правильно. Поверьте опыту...
Вот и ВОПРОС: В каких конкретно приложениях необходимо это учесть...?? Пофантазируем...??
picmaniac, что же все-таки делать дальше? 
Почитал еще раз ликбез №2. Хотел приступить к нему, но... Честно сказать, не особо понравилось. Почему? Ну во-первых переходить от элементарной "зажигалки" светодиодов к сложной программе кодового замка, которую предложил Левон, все-таки сложновато. Во-вторых, как-то все очень сумбурно. Сначала несколько страниц по выбору клавиатуры и индикатора. Такая - сякая клавиатура, такой - сякой индикатор. Надо было "ногой топнуть" и все. Как можно что-либо выбрать не имея представления, какой программный код стоит за всем этим? Учебное задание и есть учебное задание, на то оно и учебное задание. Чем меньше степеней свободы, тем оно "учебнее".
А дальше, сразу, варианты схем и программного кода от участников, которых "чайниками" уже назвать нельзя.
Ну а потом вообще ни с того ни с сего переход на пикбейсик и т. д. Я не против пикбейсика, даже наоборот, очень хотелось бы в нем разобраться, но по-моему момент перехода не совсем удачен. Может попробовать параллельно с ним разбираться. Простенькая задачка на асме, и она же на пикбейсике.
Короче, я как-то призадумался. Как дальше продвигаться? Может присоветуете какую-то оптимальную линию (дорогу) продвижения по хитросплетениям изучения практического написания программ? Хотелось бы побыстрей двигаться, с одной стороны не размениваясь на мелочи, с другой - не заходя в тупики решения непосильных задач.
Опять же висит этот "Дамоклов меч" под названием Граф, на изучении которого вы так настаиваете. Как его изучить? Статейки, которые вы давали, я прочитал, но там эти графы приводятся в основном в качестве иллюстрации к "правильному" подходу написания программ. А вот каковы все законы и тонкости его построения - это наверное очень большая тема, охватить которую можно только при фундаментальном изучении програмирования. По крайней мере все попытки нарисовать его самостоятельно ни к чему не привели. Конечно, было бы хорошо, один раз напрячь голову, нарисовать Граф, а остальная мишура в виде программного кода - дело техники без привлечения "серого вещества". Ведь так должно быть в идеале?
Короче, я не знаю, "куды крестьянину податься". Может в AVRщики переметнуться? 
У-у-у, как всё плохо
"ногой топнуть" Навязывание своего мнения - не мой метод.
переход на бейсик Это здорово упрощает работу. Зная азы асма, освоить бейсик очень просто. Это переходной этап, затем надеюсь перейти на Си.
"Дамоклов меч" под названием Граф Ну ё-моё, прям графофобия какая-то
Составление графа - отнюдь не самоцель. Просто, ещё раз повторяю, грамотно составленный граф прилично облегчает последующую работу. Не настолько, конечно, чтоб совсем мозги в sleep отправить, но всё же ощутимо. Если не получается сразу - ну и ладно, никто ведь не стоит над душой. Забыть на время об этом. Пусть задачка побродит по уголкам подсознания. Глядишь - и всплывёт решение.
Хорошо, простейшая учебная задачка: составить граф для программы мигания одним светодиодом. 1 сек горит и 0,5 сек не горит. И так постоянно пока есть питание. Осилите? Наверняка. Дерзайте. Удачи!
Ув Zandy, AVR от графов не спасет Блин, как СВЧ-девайс посчитать/развести - эт мы запросто, а как пять кружочков со стрелочками нарисовать - эт мы не можем, эт нам тяжело! Ничего, кроме здравого смысла, для рисования графов не требуется.