You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The "OS_DEBUG" macro, when enabled, ends up calling fprintf directly. On VxWorks the characters from these debug statements get intermixed with other output from the async utility task / console writer. This makes it just about impossible to read. Furthermore unit tests call the BSP function directly, so there is potentially a third task writing chars at the same time during tests, making it worse.
To Reproduce
Run functional/unit tests on VxWorks.
Expected behavior
Output should be at least decipherable/readable. Adding some sort of mutex on OS_BSP_ConsoleOutput_Impl() would probably help greatly.
System observed on:
MCP750, Vxworks 6.9
Additional context
Here is a cut and paste of some output from the "network-api-test" that I'm currently looking into for other issues. This isn't even the worst example I've seen. But it is very hard to see what's actually going on here.
Adds a real mutex for use with low level BSP console output.
This needs to be actually implemented in the BSP layer, so it
will be used by UtAssert outputs (pass/fail message) in addition
to OS_printf().
This also converts OS_DEBUG to use the same console output
rather than calling fprintf directly.
The combination of a mutex and all common print outputs
(UtAssert, OS_printf, OS_DEBUG) going through the same
path makes the test output on VxWorks much more coherent.
Adds a real mutex for use with low level BSP console output.
This needs to be actually implemented in the BSP layer, so it
will be used by UtAssert outputs (pass/fail message) in addition
to OS_printf().
This also converts OS_DEBUG to use the same console output
rather than calling fprintf directly.
The combination of a mutex and all common print outputs
(UtAssert, OS_printf, OS_DEBUG) going through the same
path makes the test output on VxWorks much more coherent.
Describe the bug
The "OS_DEBUG" macro, when enabled, ends up calling
fprintf
directly. On VxWorks the characters from these debug statements get intermixed with other output from the async utility task / console writer. This makes it just about impossible to read. Furthermore unit tests call the BSP function directly, so there is potentially a third task writing chars at the same time during tests, making it worse.To Reproduce
Run functional/unit tests on VxWorks.
Expected behavior
Output should be at least decipherable/readable. Adding some sort of mutex on OS_BSP_ConsoleOutput_Impl() would probably help greatly.
System observed on:
MCP750, Vxworks 6.9
Additional context
Here is a cut and paste of some output from the "network-api-test" that I'm currently looking into for other issues. This isn't even the worst example I've seen. But it is very hard to see what's actually going on here.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: