sambuc/atomthreads
1
0
Fork 0
mirror of https://github.com/kelvinlawson/atomthreads.git synced 2026-10-22 02:37:27 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

STM8 port: Update README with RAM layout details.

Browse Source
This commit is contained in:
Kelvin Lawson
2010-03-01 22:11:21 +00:00
parent 02bdad201f
commit 417d7b5abb
1 changed files with 50 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ports/stm8/README
+50 -29
View File
@@ -282,9 +282,9 @@ architecture, from the 8-bitters up.
A good rule of thumb when using Atomthreads on the STM8 architecture is A good rule of thumb when using Atomthreads on the STM8 architecture is
that a minimum of 1KB RAM is required in order to support an application that a minimum of 1KB RAM is required in order to support an application
with 4 or 5 threads and the idle thread. If approximately 128 bytes per with 4 or 5 threads and the idle thread. If a minimum of approximately
thread stack is acceptable then you will benefit from the easy-to-read, 128 bytes per thread stack is acceptable then you will benefit from the
portable implementation of an RTOS herein. easy-to-read, portable implementation of an RTOS herein.
The major consumer of RAM when using Atomthreads is your thread stacks. The major consumer of RAM when using Atomthreads is your thread stacks.
Functionality that is shared between several kernel modules is farmed out Functionality that is shared between several kernel modules is farmed out
@@ -300,21 +300,34 @@ application code does, and what memory model is used etc, but generally
you should find that 128 bytes is enough to allow for the thread to be you should find that 128 bytes is enough to allow for the thread to be
switched out (and thus save its registers) while deep within a kernel switched out (and thus save its registers) while deep within a kernel
or application call stack, and similarly enough to provide stack for or application call stack, and similarly enough to provide stack for
interrupt handlers interrupting while the thread is deep within a interrupt handlers interrupting while the thread is deep within a kernel
kernel or application call stack. We have seen a little more than 128 or application call stack. You will need to increase this depending on
bytes being used, however, when the application code itself is made up what level of stack the application code in question requires.
of several subroutines.
While 128 bytes has so far been found to be sufficient for the stack
needs of all of the automated test module threads, the main test thread
does typically require more due to the additional variables and
subroutines called.
You may monitor the stack usage of your application threads during runtime
by defining the macro ATOM_STACK_CHECKING and calling
atomThreadStackCheck(). This macro is defined by default in the Makefile
so that the automated test modules can check for stack overflows, but you
may wish to undefine this in your application Makefiles when you are happy
that the stack usage is acceptable. Enabling ATOM_STACK_CHECKING will
increase the size of your threads' TCBs slightly, and will incur a minor
CPU cycles overhead whenever threads are created due to prefilling the
thread stack with a known value.
With careful consideration and few threads it would be possible to use With careful consideration and few threads it would be possible to use
a platform with 512 bytes RAM, but not all of the automated test suite a platform with 512 bytes RAM, but not all of the automated test suite
would run on such a platform (some of the test modules use 6 threads: a would run on such a platform (some of the test modules use 6 threads: a
main thread together with 4 sub-threads and the idle thread). main thread together with 4 test threads and the idle thread).
The RAM layout used for the automated test applications is as follows: The RAM layout used for the automated test applications is as follows:
RAM Top: RAM Top:
* Startup Stack (64 bytes) * Startup Stack (64 bytes)
* Main Thread Stack (Variable size)
* Data & BSS area (thread stacks, other application data) * Data & BSS area (thread stacks, other application data)
RAM Bottom. RAM Bottom.
@@ -327,27 +340,35 @@ reused once the OS is started, but for the purposes of the automated test
applications it is not reused. Generally you would ensure that this is applications it is not reused. Generally you would ensure that this is
reused in your own application code. reused in your own application code.
The application's data starts at the bottom of RAM, and this includes most The application's data starts at the bottom of RAM, and this includes all
of the thread stacks which are statically allocated arrays. The idle thread of the thread stacks which are statically allocated arrays. The idle
and automated test thread stacks are allocated here and are 128 bytes each. thread, main thread, and automated test thread stacks are allocated here.
The remaining area between the startup stack (RAMTOP-64) and the end of the If your application includes a large amount of data which is nearing the
data/BSS areas is allocated to the main thread stack. As this thread top of RAM, then you must be careful that conflicts do not occur with the
typically requires the largest stack, this uses all of the remaining RAM startup stack. The startup stack uses the 64 bytes from RAMTOP down. This
between the top and bottom. In general for the automated tests this thread is not reserved with the linker, so you will receive no warning if your
does most of the processing and requires more than 128 bytes (it has been own data encroaches on this area. It may not matter because the startup
seen to exceed 146 bytes). You can check that sufficient RAM is available stack is only used before the OS is started, but if the data here cannot
for the main thread by viewing the MAP file for the application. This shows be corrupted before the OS is started then you should make other
how much RAM is used by the data and BSS areas. If you have 2048 bytes RAM, arrangements, such as moving the startup stack elsewhere or placing data
subtract the data and BSS size values from 2048, and subtract the amount which can be overwritten in this area. To check whether your application
used for the startup stack (64 bytes) to figure out the remaining space data overlaps with the startup stack you can view the MAP file for the
available for the main thread stack. Again, for your own applications you application. This shows how much RAM is used by the data and BSS areas.
will probably be reusing the startup stack area, so can exclude that from If you have 2048 bytes RAM, then you will need to ensure that the
your calculations. The default layout provided with Atomthreads matches application data uses less than (2048-64) bytes, or be sure that it is
the STM8S-Discovery with 2KB RAM. The linker file reserves the first safe to utilise that area for the startup stack before the OS is started.
0x500 bytes for data areas. The region from here up to the end of RAM
(0x800) is used for the main stack, and the 64 byte startup stack. The The default layout provided with Atomthreads matches the STM8S-Discovery
default main stack size is therefore (0x300 - 64) 704 bytes. with 2KB RAM. The linker file reserves the first 0x500 bytes for data
areas. The region from here up to the end of RAM (0x800) is used for the
the 64 byte startup stack and any other data you require. You may wish
to place some of your thread's stacks in the area above 0x500, or you may
prefer to increase the size of the data area beyond 0x500. A simple
layout would be to allow everything up to (RAMTOP-64) to be used for
application data, leaving the top 64 bytes for use by the startup stack.
This way the linker would warn you if your application data overlapped
with the startup stack.
As mentioned previously, this RAM layout is only the one utilised by the As mentioned previously, this RAM layout is only the one utilised by the
test applications. You may choose whatever layout you like. test applications. You may choose whatever layout you like.