UART sensors cleanup #182
Merged
UART sensors cleanup #182
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
Originally posted by @dlech in #175 (comment) |
laurensvalk
force-pushed
the
uart-process
branch
2 times, most recently
from
c5df748 to
736e8bd
Compare
dlech
reviewed
Jul 11, 2023
This way we know it is initialized when pbdrv_init completes.
The device connection manager and the uart device driver never need to run at the same time, so drive them from a single process. This reduces complexity and code size, and also reduces the time needed to handle devices disconnecting since there are no longer multiple timeouts to wait on. It also separates the pup_uart code further so it can run on other devices like EV3 which don't have the same connection manager.
- There were two different variables both named prev_type_id used for different things. - Now uses one child protothread for the dcm and the uart sensor since they run at different times. - Moved where the affirmative ids are kept.
There were mixes of port_data, data, and dev for the same types, which were not related to the actual data variables. Things like data->pt where very different from data_pt. All pbdrv_legodev_pup_uart_dev_t are local to this file, so call them ludev for short.
Instead of using numerous goto's, we can return an error like we do everywhere in pbio. In this case bind it to the device for easy access.
This makes the main uart thread cleaner. Instead of resetting one thread with PT_INIT midway from another thread, organize them as follows: - spawn synchronization, exit on error - run send + receive in parallel until no data This in turn can be spawned from the higher level process on platforms that support device detection, or just called indefinitely on platforms where uart mode is always active.
laurensvalk
force-pushed
the
uart-process
branch
from
736e8bd to
cf3b1e1
Compare
laurensvalk
force-pushed
the
uart-process
branch
from
cf3b1e1 to
74a732b
Compare
It was placed in legodev_pup to avoid the need for an extra process. But since it isn't enabled on Move Hub anyway, it makes more sense to place it where it belongs.
laurensvalk
force-pushed
the
uart-process
branch
from
74a732b to
ef4cd2c
Compare
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.
This implements a start to pybricks/support#1140:
I have intentionally avoided much change to the
dcmanduartdevcode in this commit to make the change easier to process. We could do a few more cleanups though:uartdev,data,port_dataname for the main data structuredata->ptis not the same asdata_pt, which can make it harder to follow.PT_SCHEDULEmacro in a few places when we don't need the return value.