Closed Floessie closed 6 years ago
@Floessie,
that seems correct.
In the current v10 version the stack size type is configurable configSTACK_DEPTH_TYPE
and is defined here as uint16t
. So the documentation is slightly out of date.
I think that @RichardBarry or @aggarg is still in the process of sorting out a migration in this direction, and so it is something that should interest him. You might want to raise it on the freeRTOS.org web site.
I'll leave this open and see what happens in the first bug-fix release of v10.
I found two more references, and added the backwards compatibility option discussed.
(also reverted the EIND references. still can't understand why the #definition was not being expanded in the macro. anyway... whatever).
Not been following the EIND discussion recently, but from your last comment "still can't understand why the #definition was not being expanded in the macro" I'm surmising the EIND was being #defined to something that was not being pre processed as expected. If that is the case, and if the macro was in an assembler file with a .s extension, then try changing the extension to .S (upper case) if it is to be preprocessed.
Off issue topic, but I was trying to prettify the portSAVE_CONTEXT
macro by using __EIND__
and a define for this in portmacro.h
. So, there were no .s or .S files involved.
Anyway, it was just to make things pretty, so I reverted it to use the 0x3C
value.
Hi Phillip,
I just stumbled upon the return type of
uxTaskGetStackHighWaterMark()
: It'sUBaseType_t
, and that is defined asunsigned char
in this port. The stack size is provided asunsigned short
words to xTaskCreate(), thus theoretically 64kB are possible here.Wouldn't it be better to patch
tasks.c
to make it returnunsigned short
instead ofUBaseType_t
, asprvTaskCheckFreeStackSpace()
correctly returns auint16_t
? OtherwiseuxTaskGetStackHighWaterMark()
will return a misguiding value.Thanks, Flössie