Skip to content

MKR1000: Updated periph config and SWD flashing #3

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

Merged
merged 1 commit into from
May 3, 2017

Conversation

kbumsik
Copy link

@kbumsik kbumsik commented May 3, 2017

This PR to push one commit to PR#6666.

This includes three changes:

  1. Corrections to the pin configurations for SPI, UART, LED.
  2. Change ADC setting according to PR#6929. This requires rebasing the branch to the newest master branch.
  3. Added SWD flashing/debugging with PROGRAMMER=jlink.

I will start working porting ATWINC1500 wifi driver soon. Maybe I will make another PR after PR#6666 is done?

Copy link
Owner

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for opening this PR. The changes are really good. I just have a very minor style comment.

Regarding the ATWINC1500 driver, I think the best is to provide a PR with branch based on this PR: just create this new branch from this one. Then mention in the PR that it depends on PR RIOT-OS#6666.

.miso_pad = SPI_PAD_MISO_3,
.mosi_pad = SPI_PAD_MOSI_0_SCK_1
},
{
{ // SPI Pins connected to WINC1500 wifi module
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use C style comment

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opps. I changed it

@aabadie aabadie merged commit eebf287 into aabadie:mkr1000 May 3, 2017
aabadie pushed a commit that referenced this pull request Aug 4, 2019
The evtimer_msg test is expanded to also delete entries.

Furthermore the messages that are printed should now show
numbers that are very close (if not equal). Something like
this:
At    740 ms received msg 0: "#2 supposed to be 740"
At   1081 ms received msg 1: "#0 supposed to be 1081"
At   1581 ms received msg 2: "#1 supposed to be 1581"
At   4035 ms received msg 3: "#3 supposed to be 4035"

The function evtimer_print is also called to show the
intermediate status of evtimer entries.
aabadie pushed a commit that referenced this pull request Sep 2, 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
aabadie pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
aabadie pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
aabadie pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
aabadie pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3.
aabadie pushed a commit that referenced this pull request Jun 11, 2020
…d IDs

When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
aabadie pushed a commit that referenced this pull request Feb 18, 2022
The ENTROPY test always fails on this board

main(): This is RIOT! (Version: buildtest)
mbedtls test

  SHA-224 test #1: passed
  SHA-224 test #2: passed
  SHA-224 test #3: passed
  SHA-256 test #1: passed
  SHA-256 test #2: passed
  SHA-256 test #3: passed

  ENTROPY test: failed
aabadie pushed a commit that referenced this pull request Mar 10, 2023
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE

### Contribution description

The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.

### Testing procedure

Any application using MTD in conjunction with a board with an at24cxxx.


19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1

### Contribution description
Hi! 🦎

When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.

### Testing procedure

Before this patch:

Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
    #0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
    #1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
    #2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
    #3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
``` 
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.



Co-authored-by: Hendrik van Essen <[email protected]>
Co-authored-by: Teufelchen1 <[email protected]>
aabadie pushed a commit that referenced this pull request Mar 10, 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 <[email protected]>
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