forked from RIOT-OS/RIOT
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugtest hotfixes #4
Closed
OlegHahm
wants to merge
19
commits into
miri64:decouple_network_stack
from
OlegHahm:plugtest_hotfixes
Closed
Plugtest hotfixes #4
OlegHahm
wants to merge
19
commits into
miri64:decouple_network_stack
from
OlegHahm:plugtest_hotfixes
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
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
Included cb771e6 into RIOT-OS#768 |
Included 370480c into RIOT-OS#644 |
miri64
pushed a commit
that referenced
this pull request
Sep 10, 2019
The test randomly fails on `native` due to timers being not accurate but it cannot be otherwise. So better disable it than raising fake errors. main(): This is RIOT! (Version: buildtest) Testing generic evtimer This should list 2 items ev #1 offset=1000 ev #2 offset=500 This should list 4 items ev #1 offset=659 ev #2 offset=341 ev #3 offset=500 ev #4 offset=2454 Are the reception times of all 4 msgs close to the supposed values? At 662 ms received msg 0: "#2 supposed to be 659" At 1009 ms received msg 1: "#0 supposed to be 1000" At 1511 ms received msg 2: "#1 supposed to be 1500" Traceback (most recent call last): File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 33, in <module> sys.exit(run(testfunc)) File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/dist/pythonlibs/testrunner/__init__.py", line 29, in run testfunc(child) File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 26, in testfunc assert(actual in range(expected - ACCEPTED_ERROR, expected + ACCEPTED_ERROR)) AssertionError
miri64
pushed a commit
that referenced
this pull request
Feb 27, 2023
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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.
Since thread_exit() seems to be broken on iot-lab_M3 this is an important fix for tomorrow. ;)