Recurssive Functions?

[lord loh.]

Has anyone tried recurssive subroutines?

Is it possible with 18F452 assembly?

 

[Nigel Goodwin]

Has anyone tried recurssive subroutines?

Is it possible with 18F452 assembly?

Recurssive sub-routines aren't a good idea, and it's essential to limit the number of possible recurssions.

From a PIC point of view, you would need to be EXTREMELY aware of the small stack size, and also to save all affected registers and GPR's (in different locations) every recurssion.

Do you have some specific requirement for this?, and if so what?.

 

[lord loh.]

So apart from the default stack to store the PC+1, I shall have to write a routine or a macro to implement a software stack...

No...It was just a wild idea I got. I was trying to learn 18F452 and had lot of trouble understanding the banks.

The trouble now is that I am unable to figure out how memory is allocated if the size of the variables exceed a bank... Will I have to do a banksel before every register file operation? This shall add a lot of words to my code. And can variables cross over banks?

:boooh: too much trouble.

 

[Nigel Goodwin]

So apart from the default stack to store the PC+1, I shall have to write a routine or a macro to implement a software stack...

No...It was just a wild idea I got. I was trying to learn 18F452 and had lot of trouble understanding the banks.

The trouble now is that I am unable to figure out how memory is allocated if the size of the variables exceed a bank... Will I have to do a banksel before every register file operation? This shall add a lot of words to my code. And can variables cross over banks?

:boooh: too much trouble.

Is there some specific reason you're playing with banks?, are you writing something large enough to require it? - it needs a LOT of assembler to require it. If you're using C, then the compiler takes care of all the banking problems.

 

[lord loh.]

We are working in a group to develop a micro-robot that in infact using 2 PICs.

It has a lot of routines like PWM for motor Control / IR Range Finder / RF communications (handle contentions etc as there are a number of robots and should be able to communicate with each other as well as to the computer) / Detect Battery temperature and voltage etc.

I shall quit the project after a month but the organization shall continue with their work.

 

[Pommie]

I shall quit the project after a month but the organization shall continue with their work.

So, why are you asking the question when you have no intention to see it to it's conclusion.

Mike.

 

[Jay.slovak]

So apart from the default stack to store the PC+1, I shall have to write a routine or a macro to implement a software stack...

No...It was just a wild idea I got. I was trying to learn 18F452 and had lot of trouble understanding the banks.

The trouble now is that I am unable to figure out how memory is allocated if the size of the variables exceed a bank... Will I have to do a banksel before every register file operation? This shall add a lot of words to my code. And can variables cross over banks?

:boooh: too much trouble.

Please look into the Datasheet, Especially the Access Bank. Shortly, it takes all SFRs and 128 GPRs and put's them into separate address space, so that no Bank switching is necessary (if 128 GPRs is enaugh).

 

[lord loh.]

It is always good to know things isn't it? Moreover, I do not want to leave with projects hanging... People ought to miss me not be glad to see the back of me.

 

[lord loh.]

Yes... I have been thinking and simulating all day...

I am thinking of an extreme case... Where 128 registers are not enough... My PIC is supposed to send packets over an RF link... And a packet means a lot of data with CRC and overheads etc.

What I found was that the linker build fails if a variable or a part of it declared in one udata section overflows from the bank it is currently being defined in into another bank...It is not allowed....

So one has to manage variables in such a way by starting the udata at the begining of the bank so that maximum size of variables can be declared. If I start at FE, I can have only teo bytes.... One at FE and the other at FF. Should I try to define a 3rd byte, there is a build fail.
____________________________
EDIT:
I posted in a hybrid view and expected the replies to be placed below the respective posts.... Looks like the posts are rearranged in linear mode....

 

[Nigel Goodwin]

Yes... I have been thinking and simulating all day...

I am thinking of an extreme case... Where 128 registers are not enough... My PIC is supposed to send packets over an RF link... And a packet means a lot of data with CRC and overheads etc.

What I found was that the linker build fails if a variable or a part of it declared in one udata section overflows from the bank it is currently being defined in into another bank...It is not allowed....

So one has to manage variables in such a way by starting the udata at the begining of the bank so that maximum size of variables can be declared. If I start at FE, I can have only teo bytes.... One at FE and the other at FF. Should I try to define a 3rd byte, there is a build fail.

ALL systems have to manage their variables, either at design time or at run time - if you're using a buffer you should know the size required BEFORE you write the program, and allocate it accordingly. If the buffer is large enough to overrun the size of one bank, then allocate the buffer in it's own bank - this means you only have to bother with bank switching code when dealing with the buffer.

 

[Jay.slovak]

Look and think about this picture.