Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-03

AVR HeapSize and StackSize

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Dimitrios Chr. Ioannidis

Hi,

  I'm using the heapmgr unit and, for the atmega328p, AFAIU the default heap size is 80 bytes. Cause it's too small for my needs, I changed to 512 bytes ( -Ch512 ). But now I'm worrying for the stack and heap collision.

  Can anybody know any resources, docs regarding FPC stack and heap management for the AVR platform ? Any hints, tools ?

regards,

Dimitrios Chr. Ioannidis

Reply by email

Florian Klämpfl
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 6 lines
Hi,   I'm using the heapmgr unit and, for the atmega328p, AFAIU the default heap size is 80 bytes. Cause it's too small for my needs, I changed to 512 bytes ( -Ch512 ). But now I'm worrying for the stack and heap collision.   Can anybody know any resources, docs regarding FPC stack and heap management for the AVR platform ? Any hints, tools ?

The sources ;) For the embedded targets, the stack grows downward from the highest ram address. So set a suitable stack size so you do not exceed total memory, test with stack checking on, then you should be fine.

Reply by email

Christo Crause
to Florian Klämpfl
PM Florian Klämpfl wrote 15 lines
Am 23.03.2019 um 11:52 schrieb Dimitrios Chr. Ioannidis via fpc-devel: > Hi, > > I'm using the heapmgr unit and, for the atmega328p, AFAIU the default heap size is 80 bytes. Cause it's too small for > my needs, I changed to 512 bytes ( -Ch512 ). But now I'm worrying for the stack and heap collision. > > Can anybody know any resources, docs regarding FPC stack and heap management for the AVR platform ? Any hints, tools ? The sources ;) For the embedded targets, the stack grows downward from the highest ram address. So set a suitable stack size so you do not exceed total memory, test with stack checking on, then you should be fine.

Out of interest I tried to see how stack checking worked. One of the puzzles is that function Sptr is empty, so it will return whatever values happen to be in r24-r25. Is this correct behaviour? I would have thought (based on how Sptr is implemented for other architectures) that it should return the value of the SP io register, something like this: function Sptr : pointer; assembler; nostackframe;
asm
in r24, 0x3d // SPL
in r25, 0x3e // SPH
end;
Any thoughts?

Reply by email

Christo Crause
to Florian Klämpfl: The sources ;) For the embedded targets, the stack grows downward from the highest ram…
PM Florian Klämpfl wrote 16 lines
Am 23.03.2019 um 11:52 schrieb Dimitrios Chr. Ioannidis via fpc-devel: > Hi, > > I'm using the heapmgr unit and, for the atmega328p, AFAIU the default heap size is 80 bytes. Cause it's too small for > my needs, I changed to 512 bytes ( -Ch512 ). But now I'm worrying for the stack and heap collision. > > Can anybody know any resources, docs regarding FPC stack and heap management for the AVR platform ? Any hints, tools ? The sources ;) For the embedded targets, the stack grows downward from the highest ram address. So set a suitable stack size so you do not exceed total memory, test with stack checking on, then you should be fine.

I did some testing of stack checking on AVR (the long version is here: https://github.com/ccrause/freepascal/wiki/Investigating-stack-and-heap-management-(avr-embedded)). The short version is that I suspect there are a couple of problems with the current code:
* The AVR implementation of function Sptr (which should return the stack pointer I believe) is missing.
* The variable StackBottom (the stack limit) is not calculated correctly because some of the required pointer declarations are not correctly linked with corresponding external symbols.
* The current stack margin defined in system.inc of 16384 exceeds the SRAM in most AVR 8 bit controllers (the only exception is atmega1284P), so a smaller margin should be selected for the AVR target.

If anyone can confirm these issues I can log a bug with patches. If I missed the plot (most of the relevant RTL code was unchanged for 8 years or longer) I would appreciate it if someone can point out where I made errors or misinterpreted code or specifications.

Reply by email