На няколко пъти ми се приискваше да има софтуерно прекъсване в PIC18. Примерно в high priority прекъсване трябва да свърша известно количество работа. Например да изкарам байт на UART/SPI и да подготвя следващия. Подготвянето на следващия отнема малко повечко време и пропускам друг high priority interrupt - бързо цъкащ таймер. Идеята ми беше когато се получи такова прекъсване да свърша "бързата работа" и да "тригер-на" софтуерно прекъсване с нисък приоритет.
Реших да пробвам като ръчно сет-на INTxIF - на емулация стана, но не знам дали ще работи добре на реално. INTx прекъсванията са на фронт, значи ако вържа пин-а за маса няма да се тригер-ва прекъсването външно. Един пин по-малко, но те никога не стигат и се налага да се избира пик с повечко крачета (особено за случаите когато имаш нужда от прекъсвания с висок и нисък приоритет).

Друг начин е да ползвам прекъсването за промяна на пин на PORTB. Един XOR ще ми каже дали наистина е имало промяна или става въпрос за софтуерно прекъсване. Даже за по-сигурно може да се задели един флаг за да може да се обработват едновременно промяна на порт Б и софтуерно прекъсване.

едит:
Тъй като рядко използвам паралелния порт може да ползвам неговото прекъсване .... ако е възможно да се активира с изключен порт. (не може)

Ами щом можеш да запишеш 0 в xxxIF значи можеш и 1 и това автоматично ще ти генерира въпросното прекъсване ако е сетнат съответния IE. А защо не ползваш приоритети на прекъсвания? Освен това нямаш шанс да изтървеш прекъсване - флага му като е сетнат, след retfie(1) процесора веднага пак влиза в прекъсване, защото флага е вдигант от съответния източник.

Ако пък ползваш приоритетите, там ясно - ако постъпи заявка висок приоритет при изпълняване на ниско такова се прекъсва ниското, изпълнява се високото, и се връща в ниското. Хубаво е да се внимава със запзването работните регистри. Особено ако се ползват SFR регистрите, трябва много да се внимава с тях.

е да де - нали това е идеята. прекъсванията с висок приоритет трябва да се изпълняват бързо. примерно имам таймер. който цъка на 1мс. Имам и второ прекъсване, което ... ами не помня какъв беше случая, но нека да предположим че пуска байт по SPI/I2C/UART за 7 сегментен дисплей. Нека за случая да приемем че по някаква причина взимането на следващата цифра ще отнеме доста цикли (забравили сме да направим двоен буфемр) - пускаме софтуерно прекъсване с нисък приоритет и излизаме от високия. Веднага след това се влиза в прекъсване с нисък приоритет да се смята следващата цифра. по средата на смятането може да се прекъсне с друго "високо" прекъсване - таймера например. Идеята е цифрата да се изпраща точно в определеното време, без да пречим на таймера да си цъка с 1мс.

Не го обясних много добре ама ...
А ако може да не жертвам пин - още по-добре. Не знам защо спират прекъсването ако периферното устройство е спряно - ненужна логика.

Ами защото процесора не работи точно както си го представяш. Значи PIR регистрите са регистри на ядрото, а не на периферията. Периферията пише в тях а логиката свързана към тях генерира прекъсване на ядрото. PIE регистрите пък се AND-ват с PIR-а и така се полуава сигнала за прекъсване. Хардуерния модул няма вземане-даване с ядрото - просто всеки модул има достъп до определени регистри в ядрото.

Ако става въпрос пък конкретно за цифра на динамична индикация - повервай ми ако ще и още 50 други прекъсвания да се изпълнят дори и в момента докато се опресняват регистрите - няма да го забележиш. За цифрите не ти трябва и двойно буфериране. Примерно ако в момента на промяна на байта за дадената цифра ти цъкне прекъсване то ако не е записана новата стойност в клетката ще се изведе старата, след което ще излезе от прекъсването, ще се запише новата стойност и след има-няма няколко милисекунди ще излезе новата . Мислиш ли че ще видиш нещо ? Не - няма да видиш - просто смяната ще стане с едно опресняване по-късно. Ама ти реално няма как да го усетиш със наличните сетива това нещо?

Именно. Аз сетвам PIE бита за паралелния порт. Независимо дали PORTD e в режим PSP (включва се някъде от TRISE) или не вдигането на флага трябва да активира прекъсването. Явно са го AND-нали и със бита който включва/изключва PSP.

За дисплея е така - в момента имам часовник, който си работи и си преобразува bin по таблица - всичко в прекъсването. Не помня за какво ми трябваше. Май беше нещо за генериране на импулси с определена дължина ... CCP-то беше замесено май. Просто реших да го разцъкам защото ми се стори полезно да имаш софтуерно прекъсване. Ако трябва нещо да се смята - умножение/деление ... на C лесно се пише, но колко код генерира ....

Аз в повечето случаи го правя така - високия приоритет - в прекъсване, ниския - в главната програма. Обаче наскоро правих разчитане на дистанционно и имаше режим на мерене на импулсите, и извеждане през UART. на 115к не успяваше да изпише времената през серииния порт и вдигнах на 900 и нещо си. Да ама освен него в главната програма имах една камара сметки и извеждане на дисплей. Понеже има вероятност докато преобразувам в шеснайсетичен код и правя разни други сметки да дойде следващия фронт на импулса просто запазвам измерената стойност, вдигам флаг и главната програма смята и праща през UART. Иначе можех да правя capture в high priority прекъсване, да смятам и извеждам в low, а главната програма да си се занимава с UI-то.

Основно правило е прекъсванията да са максимално кратки - това да се правят сложни сметки в прекъсване принципно е грешно. Трябва да се избягват такива ситуации. Просто програмата така трябва да ти е направена, че да не ти се налага да забавяш нещо или да забързваш друго за да работи.

Защо не ползваш някой свободен таймер да ти генерира прекъсване за тази цел, ще е един вид софтуерно , просто го сложи на повече време, или ако е свързано с дисплей, най добре е да е около 50Хз, хем ще е невидимо трепкането за човешкото око хем е достатъчно бавно
Ако има нещо да смята прати програта да смята, ако са различни сметки правиш ги в някакъв цикъл, първо сметки за първични данни , после смяташ резултата ако е междинен и така.

50 Хз за седем сегментен лед е малко. Ако е за до две цифри е ок, ама за повече не става. А аз съм правил и за 26 цифри. При такава ситуация го правя сканиране по сегменти, а не по цифри, за да имам 1/8 светене (ако се ползват и точките). И там програмата имаше доста други неща да смята и пак не се забелязва ни трепкане ни някакво странно поведение. Всичко е въпрос на структура на програмата и правилно разпределение на ресурсите на процесора.

Ами принципно наистина не е добра идея прекъсванията да са дълги. Ако има по-дълги неща сетваш един флаг, който се poll-ва постоянно в главната програма и там се правят дългите работи. Това решение, разбира се, не позлволява много гъвкавост, затова може да се замислиш или да минеш на PIC24 където има 7 нива на приоритет на прекъсванията или пък да пробваш някакъв "OS" за PIC18.