FWT-124 FWT-149 We have made changes to ouR TOS #109
Merged
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
… some queue naming in threadx_demo.
…g]" for all the getters to "The returned [thing]"
Also changed all usages of "retrieve" in comments to "get" because Magee hates everything I do.
…num names properly included in documentation.
…es the names and the getters for them. Names are stored in a fixed-size buffer for each class, and are copied out in the getter. This required changing all the classes which is why there appear to be so many changes. Also, initializable is still a virtual class but it's no longer an interface i.e. it does have a cpp.
…es the encapsulated UART instance
…snprint instead of vsprint, because it's slightly safer.
…snprint instead of vsprint, because it's slightly safer.
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer # Conflicts: # samples/rtos/threadx-demo/main.cpp # src/core/io/platform/f3xx/UARTf3xx.cpp # src/core/io/platform/f4xx/UARTf4xx.cpp
…hould wait for the queue if it is full. Also added an error counter for write errors.
…onversionLayer' into feature/aclowmclaughlin/threadxConversionLayer
mjmagee991
approved these changes
Dec 3, 2024
mjh9585
approved these changes
Dec 5, 2024
…and prior to the kernel being initialized. Also fixed a ThreadUART bug with the mutex (they weren't being initialized)
aclowmclaughlin
deleted the
feature/aclowmclaughlin/threadxConversionLayer
branch
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.