FWT-124 FWT-149 We have made changes to ouR TOS #109
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tializable::init().
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer # Conflicts: # src/rtos/BytePool.cpp
…tePool pure abstract class that serves to hide the templated BytePool class when passing it into methods
…pposed to be, and added override keyword to all the inheritors of it.
…flect its flexibility.
…e convention. Switched the names of BytePool and BytePoolBase to more accurately reflect the inheritance structure. Created an enum for ThreadX error return values and switched Semaphore, Queue, and Mutex return values to that appropriate enum type.
…zable.hpp and Threadx.hpp.
…ctor and deconstructor.
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer # Conflicts: # src/rtos/Threadx.cpp
mjmagee991
requested changes
Nov 3, 2024
samples/rtos/threadx-demo/main.cpp
Outdated
| * Struct that holds the arguments for the controller thread | ||
| */ | ||
| typedef struct controller_thread_args { | ||
| rtos::Queue* queue; |
There was a problem hiding this comment.
Can you name this queue better? I don't really understand what it's for. Also, each member here should have a comment just like you would have in a class
|
Also don't forget to set the HAL timebase source to another timer before starting the kernel incase something (most the low level drivers) needs to wait for a period of time and doesn't call the TX_wait method. |
…tations of registerNotifyFunction from the classes that have that method, and added todos for them.
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer
mjmagee991
reviewed
Nov 9, 2024
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer
… up the example and added comments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Authors: Rue & Diego
Implemented ThreadX conversion layer. Now, inside the core::rtos namespace, we have c++ objects that wrap the functionality of threadx's c structs. This means that hopefully, those working with RTOS in the future will never have to touch threadx directly. They will never have to sully their bright, beautiful minds with *shudder* complicated c pointer stuff.
Implemented:
BytePools
Threads
EventFlags
Mutexes
Queues
Semaphores
General Structure:
All of the threadx objects inherit from an initializable abstract class that basically just means they need to have an initialize function that registers them with the threadx kernel. This is important because we want to create the c++ objects before we start the kernel, but we have to register them with the kernel after the kernel has started, while the kernel is running.
Unimplemented:
Notification functions; some of the data types have notification functions, but due to c function pointer and c++ object member function weirdness it is difficult to create wrapper functions for these notification functions. The general framework for these notification functions is build into Initializable but is unimplemented for now.
Wrapper Classes:
In addition to our threadx wrappers, we are working towards thread-safe wrapper classes for our own common communication protocols. UARTTX (name courtesy of Diego), our thread-safe UART implementation, works on the surface exactly like normal UART, but actually buffers outputs and works with threadx to ensure thread safety. Plans are in place to create another wrapper like this for CAN and CANopen, possibly. Other communication protocols may be added in the event they become necessary.