View previous topic :: View next topic |
Author |
Message |
TSEYFARTH
Joined: 01 Jul 2006 Posts: 1054
|
Posted: Thu Mar 05, 2015 5:42 am Post subject: Memory Question |
|
|
Hello all,
The help has a nice description of the $HWSTACK, $SWSTACK and $FRAMESIZE. Very helpful when trying to understand how these values should be set.
My question is - if these are set per the recommended calculation, but the chip has 1k of memory left, what is the best thing to do with it?
The help shows that the values are relatively small:
Quote: |
Example:
$hwstack = 32 ' default use 32 for the hardware stack
$swstack = 32 ' default use 32 for the SW stack
$framesize = 40 ' default use 40 for the frame space
|
In one of my cases, I am using a M644pa configured as:
Code: |
$regfile = "m644adef.dat" 'register file for MEGA324
$crystal = 20000000 '16MHz crystal
$baud = 9600
$hwstack = 1124 '1248 '1110 '900 '1000 '100 '160 '176 '192 '208 '224 '240 '296 '256 '128
$swstack = 256 '263 '240 '128 '34 'Calculated to 18 + 4= 22 but set at 32 85 '128 '160 '128
$framesize = 256 '132 '128 '263 '240 '128 '40 '80 'calculated BaseFramSize=24 + 9 + 4 = 37 *2 = 74
|
The above leave 5 (dec) bytes of memory unused according to the 'Space left' as shown in the compiler report. As you may see above, the values set are much larger than needed. If the memory is somehow allocated or managed (I think not) when not strictly assigned, then it probably would be best to leave it not allocated.
Replies appreciated!
Thank youl,
Tim
(BASCOM-AVR version : 2.0.7.8 ) |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Thu Mar 05, 2015 5:59 am Post subject: |
|
|
Hi,
Have a look in the samples, there's an example how to use the stackcheck.lib. This lib can be used to record the actual stack used by the program.
The stacks required by an application depends on what the program actually does. Nested calls to subroutines (call to subroutine in a subroutine) will require more stack (saving return address for example).
Bascom does not have a dynamic memory allocation. If ram is reserved for variables or stack it won't be used unless a stack overflows and just happens to start writing to this area (not a good idea as it could well be that the overflowing stack overwrites something important).
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
TSEYFARTH
Joined: 01 Jul 2006 Posts: 1054
|
Posted: Thu Mar 05, 2015 6:09 am Post subject: |
|
|
Hi Ian and thank you for your response.
So if memory is NOT allocated, it is not used. Is that safe to say? I ask that question since the help does not specifically address this question.
In my particular case, there are lots of interrupts generated by a radio. So lots of nesting could occur.
I will have a look at the stackcheck.lib. I did read about it when I was reviewing again, the use of the various compiler settings.
Thanks again Ian,
Tim |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Thu Mar 05, 2015 6:40 am Post subject: |
|
|
Hi,
Exactly, if memory isn't allocated for variables or stack it won't be used (unless the stack grows larger than planned and the unallocated memory just happens to be at the correct location).
As only one interrupt can be processed at a time, you can't have nested interrupts! The interrupt handlers will fire one after the other in very quick succession, but from the hwstack point of view the maximum stack used will be the maximum use by one interrupt handler.
regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
TSEYFARTH
Joined: 01 Jul 2006 Posts: 1054
|
Posted: Thu Mar 05, 2015 6:51 am Post subject: |
|
|
Ian,
Makes sense. I did now incorporate stcheck. I am wondering however, when the variable error is changed from 255, to 1,2 or 3, can that be saved to ERAM so it can be reviewed later? I guess it *may* depend on the situation too.
I have noticed that sometimes I have a problem that *may* be related to memory usage/allocation. However I have them sooo hight that it really should not be. And with your description of interrupts firing in order maybe I am chasing a dead trail.
But - what if the interrupt handling code calls a sub, which calls other subs. Is that considered handling a single interrupt as if all that code was inside the Int? I believe so be am in the forest.
Thanks again Ian,
Tim |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Thu Mar 05, 2015 10:32 am Post subject: |
|
|
Hi,
Just think about how the code runs. A pen and paper might help:-
1) The main code is running in a Loop doing what ever. Stack usage goes up and down depending on whats actually running.
2) An Interrupt fires
a) The Interrupt handler pushes all regsisters onto the Hardware stack (if pushall is used)
b) The Interrupt handler runs whatever code is necessary maybe using some more stack.
c) The Interrupt handler calls a Sub, the variables passed to the Sub are maybe stored on the Frame. If the Sub uses local variables they will be put in the soft stack and the return address is pushed to the hw stack
d) When the Sub called finishes the soft stack and Frame are rolled back to the old size used. The return address is poped from the Hardware stack and the AVR Returns to the Interrupt handler code (the address after the call to the sub)
e) When the Interrupt handler is finished the Registers used in the Interrupt handler are popped from the Hardware stack, then the return address (from main) is popped from the hw stack is popped and the AVR starts running the code from where is was interrupted.
So having nested Subs/functions or Interrupt handlers that call Subs/functions can cause higher stack usage, and can be very hard to debug. Just Think about the case when an Interrupt fires in a Sub that's nested within other Subs. I do not recommend calling Subs in Interrupt handlers, if you do you may end up with almost impossible to solve bugs as if an Interrupt fires in exactly the right/wrong Moment the stack usage could be alot higher than expected.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
TSEYFARTH
Joined: 01 Jul 2006 Posts: 1054
|
Posted: Thu Mar 05, 2015 6:39 pm Post subject: |
|
|
That was really nice Ian.
Great process flow explanation. I think I will remove the subs from the Ints.
Thanks again! I appreciate your time and expertise.
Tim |
|
Back to top |
|
|
|