Fix too small return type for uxTaskGetStackHighWaterMark()

[Floessie]

This PR fixes #27 by replacing the uint8_t return type of uxTaskGetStackHighWaterMark() with uint16_t.

[feilipu]

@Floessie

Let's sit on this to see whether @RichardBarry or @aggarg fixes it upstream in the first v10 bug fix release.

[Floessie]

I'm fine with waiting for an upstream solution. Happy New Year! 🎆

[feilipu]

@Floessie please read the aws/amazon-freertos discussion, where Richard has commented. This issue goes back "forever" and I guess it probably won't be changed because of compatibility issues.

IMHO, perhaps it makes sense to just do an improved pull request version with configSTACK_DEPTH_TYPE as the return type, and make sure it is defined as uint16_t for your purposes? Thoughts?

[Floessie]

@feilipu I just read the discussion, and I understand this is an compatibility problem for Richard. So yes, I'll fix it here and provide you with an updated PR.

[Floessie]

@feilipu Like so?

[feilipu]

Just add this one.

And this one, and this one. I think they need to be changed too.

And also the definition of the struct needs changing too, here.

And here, you should enter the default info to make this obvious... like this.

/* Set the stack pointer type to be uint16_t, otherwise it defaults to unsigned long */
#define portPOINTER_SIZE_TYPE               uint16_t

+/* Set the stack depth type to be uint16_t. */
+#define configSTACK_DEPTH_TYPE               uint16_t

/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */

Not sure what effect this will have. I don't have much time for testing right now, sorry.
Let me know how you go with it.

I'm trying to fix #26 currently. Not sure why my simple fixes don't work...

[Floessie]

@feilipu I see. Not sure about the last one, as we already have a default here, but if you think it's necessary, I'll add it, too.

[feilipu]

Yes. The last one is just adding a configuration line, that already exists identically as the default. The only reason to put it there is to anchor a comment that the default return type for uxTaskGetStackHighWaterMark() has been changed to configSTACK_DEPTH_TYPE. I would add the comment later, or you can include it if you prefer.

Also, regarding the comment on the aws 12 issue, I'm considering whether it would make some sense to use the configENABLE_BACKWARD_COMPATIBILITY flag to wrap the old vs. new uxTaskGetStackHighWaterMark() return type definition. I think that it would be useful.

I think it is only the uxTaskGetStackHighWaterMark() definition that needs to be compatibility wrapped, as everything else would just flow more correctly anyway using the new configSTACK_DEPTH_TYPE definition rather than uint16_t or uint32_t as is currently (and variously) defined.

[feilipu]

I think that it is done now. Please, check that everything is good for your needs.
Currently I don't have sufficient time to test fully, sorry.

Since I've added the backwards compatibility conditionals into Release 10.0.0-6 it should be useful for @RichardBarry too.

[feilipu]

Ouch. I missed the references to xTaskCreateStatic(), in task.c and elsewhere, that also have references to uint32_t that should be changed to configSTACK_DEPTH_TYPE.

Along with references to vApplicationGetTimerTaskMemory() and vApplicationGetIdleTaskMemory() that need to be modified to use the configSTACK_DEPTH_TYPE.

These are across Varianthooks.cpp, tasks.c, and timers.c.

[Floessie]

@feilipu

Ouch. I missed the references to xTaskCreateStatic(), in task.c and elsewhere, that also have references to uint32_t that should be changed to configSTACK_DEPTH_TYPE.

Well, I saw that, but considered it as "not a problem". Yes, it would be nice to save a few bytes here, but it's not too small.

Along with references to vApplicationGetTimerTaskMemory() and vApplicationGetIdleTaskMemory() that need to be modified to use the configSTACK_DEPTH_TYPE.

I'll take a look at those places and provide you with a follow-up PR.

Thanks for solving this issue!

Best,
Flössie

[feilipu]

Just fixed it.

Found some more issues. Please stand by.

And now, please test 10.0.0-7.

[feilipu]

This PR is now in the mainline FreeRTOS v10.1.0.

At some stage in the near future (once it is clear there are no patches needed), I'll move this repository to be v10.1.0.

Work in progress for v10.1.1 here.