Представим, что МК участвует в обмене данными через UART. Обмен
производится пакетами, состоящими из заголовка, «тела» пакета, где заключена
собственно передаваемая информация, и трейлера, содержащего контрольную
сумму. Логика работы такова, что сначала принимается весь пакет, а затем управ-
ление получает процесс, ожидающий пакет и обрабатывающий заключенную в
нем информацию. Совершенно очевидно, что при приеме заголовка и «тела» па-
кета нет никакой необходимости в передаче управления процессу, т.е. никакого
перепланирования реально происходить не будет – перепланирование с после-
дующей передачей управления процессу, ожидающему пакет, будет иметь место
только после приема трейлера, проверки контрольной суммы и в случае отсутст-
вия ошибок. Таким образом, реально полное сохранение контекста требуется
только один раз на весь пакет, но при рассматриваемом подходе будет происхо-
дить каждый раз при приеме очередного символа приемником UART. Т.е. налицо
очень значительный оверхед, который весьма снижает производительность сис-
темы и очень ограничивает скорость передачи по UART’у.
Еще одним недостатком является то, что каждый ISR включает в себя код
по полному сохранению и восстановлению контекста, что влечет за собой на-
кладные расходы по размеру кода программы.

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

Можно ли всё-таки использовать прямую передачу управления

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

Можно, если программа будет успевать и вам не жалко потребляемого тока на лишние действия. Поэтому вариант с прерыванием лучше.

Сам не понял чё сваял, но главное работает

P1IFG можно устанавливать только однажды, в процессе инициализации

Введение классов как-нибудь сказывается на размере кода?
Преобразовал модуль вывода на экранчик в класс TIndicator, и чё-то такое ощущение, что размер на килобайт увеличился.

Вызов метода OS::WakeUpProcess вызывает немедленную перепланировку процессов или только по системному таймеру?
Можно ли его применять внутри прерываний
Можно ли сбрасывать WDT c целью немедленной перепланировки, чем это может быть чревато или как сделать по-другому
Чем отличается WakeUpProcess от ForceWakeUpProcess

• WakeUpProcess(TBaseProcess& p); Выводит процесс из состояния «спячки». Процесс переводится в состояние готового к выполнению, только если он находился в состоянии ожидания с таймаутом события; при этом, если этот процесс имеет приоритет выше текущего, то он сразу получает управление;

• ForceWakeUpProcess(TBaseProcess& p); Выводит процесс из со-стояния «спячки». Процесс переводится в состояние готового к выполне-нию всегда. при этом, если этот процесс имеет приоритет выше текуще-го, то он сразу получает управление; Этой функцией нужно пользоваться с особой осторожностью, т.к. некорректное использование может привес-ти к неправильной (непредсказуемой) работе программы;

Может есть какой аналог Sleep(), но который не системные тики считает, а к примеру, микросекунды (загнул конечно, ну хоть десятки).
В смысле не в штатных средствах операционки, а у кого-нибудь из сообщества.
Какой-нибудь класс виртуального таймера
Самому лень писать, а Pause(mks){while(mks--)_NOP();} как-то уже не катит...

И ещё:
OS::TISRW ISRW;
вот эту штуку обязательно писать в прерывании?
Что будет, если её не поставить?