Здравейте на всички.Опитвам се да направя програмен стек на процесор PIC18f4620 на MicroC pro . Попринцип за да се реализира , трябра да се прочетат регистрите TOSU,TOSH,TOSL.Прочитам ги и ги съхранявам на отделни променливи от тип char , понеже са си осем битови.Проблема е че когато се опитам да освободя повече място как може да се реализира , примерно да съхранявам целия стек в рам паметта и после след извикване на функцията примерно да възстановявам.Споделете как може това да се реализира . Ето с кое започнах :

unsigned char STOSU=0,
STOSH=0,
STOSL=0;
....................................
void Menu(){

STOSU=TOSU;
STOSH=TOSH;
STOSL=TOSL;
..................................
return;
}

А каква е идеята в този стек да вмъкваш регистрите от хардуерния стек на процесора ? При всяко извикване на подпрограма тези регистри се пазят автоматично в хардуерния стек, до който нямаш достъп.

Идеята на този софтуерен стек е , когато кода е много тромав , има много прекъсвания , извикване на подфункции с две думи при препълване на стека . При PIC18 серия има и вариант за реализиране на софтуерен стек , като при прочитането на регистрите TOSU,TOSH,TOSL които сочат TOS да се извлече върха на стека ,демек последното прекъсване .Те са свободни от страна на програмиста и понеже Рам паметта е дооста свободна , да се заделя там

Стек в общото адресно пространство може да потрябва по много много причини.
Скрит хардуерен стек е идея, захвърлена в зората на процесорите.

Все трябва да има вариант да накараш процесора да напъха регистрите в стека
си (някакво прекъсване) и после един по един да ги вадиш и да ги копираш в
стека организиран някъде из паметта. Както и обратното.

Но да се мъчиш да правиш *такова* нещо на език от високо ниво си е не перверзия,
ами чисто губи време.

По тоя въпрос свързан с ПИК18 ни казваха, че има някакъв бърз стек с дълбочина 1,2 адреса. Някой може ли да напише има ли вярно и за какво се използва щото преподавателите дето ни учат на това не са много на ТИ с тая наука.Най- смешното е че щом е бърз, нормалния стек толкова ли е бавен , че да сложат друг бърз стек.

Вземи отвори един "Data Sheet" на 18-ka и намери "FAST REGISTER STACK". Там си е написано какво и как!

Мисля, че ако се опре до там 31 нива на стека да не стигат, значи е сбъркана платформата,
по-добре да се мине на друг микроконтролер, отколкото да се правят такива гимнастики.
Не че не е възможно, напротив, ако се поровиш в AN на Microchip ще намериш такава реализация
за първите 16-ки, които имаха само 2 нива на стека. Обаче процесора става много бавен и тромав,
това на всяко викане на подпрограма започва да харчи от 20 до към 40 инструкции в повече. Ако
е само да запазиш използваните променливи и служебни регистри в подпрограма обработваща
дадено прекъсване, то въобще не нужен стек. Правиш си един масив и си запазваш там всички
променливи, на излизане ги възстановяваш. Но това обикновено се прави на асемблер, за да може
прекъсването да е максимално кратко.

"Бързия" стек на PIC18 се използва при прекъсванията с висок приоритет. Тогава влизайки в прекъсването ядрото си запазва няколко регистъра в този стек, както е при останалите микроконтролери и процесори, при прекъсванията с нисък приоритет това го прави програмиста. И понеже първото се прави автоматично го наричат "бърз" стек. Но този стек имаше доста бъгове по него в първоначалните версии, после май го оправиха. За да нямам главоболия и да следя коя версия са ми продали от магазина, въобще не
го използвам.

Аз досега не съм имал грижи с Fast Register Stack. Само дето съвсем не е достатъчен. FSR-ите например в 95% се налага да се помнят. Пък и други регистри се налага да се пазят. А за стека на преходите - досега не съм имал случай да го напълня. Само ракурсия не съм пробвал да видя как ще стане

Това винаги ми се е струвало голяма глупост - да ограничиш размера на стек-а.
В момента пиша една програма за R8C25 там стек-а се задава при създаване на проекта. След като набутах в кода няколко sprintf-а се оказа че стек-а ми е малко просто го увеличих и толкоз. Дефинира се като област от RAM-a.

Е да де ама то пик-а нали знаеш, че не е като другите. Обаче за сметка на това се връща в рамките на два клока ... На практика софтуера трябва да се грижи само да не надхвърли 32-та прехода.

По скоро да , когато примерно стека достигне 31 ниво тогава автоматично със всяко едно потъване,да се зарежда в Оперативната памет РАМ неговия връх TOS (Top On Stack) . По скоро е добре да бъде реализиран така този софтуерен стек

Мда... Още едно нещо което да го мислиш как ще стане, и после да дебъгваш...

"nikolovs" , защо не четеш стенвестници преди да питаш? Пълно е в нета с инфо!
http://www.freeweb.hu/t-t/elokep/pic/do ... an818a.pdf

Ако наистина ти е много тромав кода и с много писане в стека опитай:
rtos

В real time изпълненията всеки thread (нишка) си има собствен стек. не се грижиш кое след кое се изпълнява. Просто си правиш нишка за всяко нещо което трябва да правиш. Така работата ще се разпредели по нишки. Е, по-тромаво е решението щото май във всички real time OS се копира целия стек преди да се превключи към друга нишка. Все пак ако имаш сложен проект опростява нещата.
Това разбира се ако си в началото на проекта. Ако трябва да го пренаписваш само заради препълване на стека - не е най-доброто решение.

А сигурно ли е че стека се препълва - на 18-ка. Щото ако е така значи нещо не е като хората в програмата. Какво ще рече това много прекъсвания - вектора ти е един (два ако ползваш приоритет) - тука имаш 2 нива. Компилатора да ползва 4-6. Останалите 20 и няколко са за тебе това значи 20 call-а един след друг. Ако и това не ти стига има два варианта - или наистина си сбъркал платформата или нещо си сбъркал програмата. Все пак тия дървета не са направени да търкалят W7.