Skip to content
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

pr/nanocoap/block2 fixes 2 #4

Merged
merged 5 commits into from
Oct 13, 2018

Conversation

kb2ma
Copy link

@kb2ma kb2ma commented Oct 8, 2018

A few more fixes for block2. See RIOT issue #8932 for details.

@bergzand
Copy link
Owner

Much appreciated!

@bergzand bergzand merged commit a8e1e97 into bergzand:pr/nanocoap/block2 Oct 13, 2018
@kb2ma kb2ma deleted the nanocoap/block2-fixes2 branch February 4, 2019 17:25
bergzand pushed a commit that referenced this pull request Sep 5, 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
bergzand pushed a commit that referenced this pull request Feb 23, 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants