-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Interrupt-Handling on msp430 is buggy #3
Labels
State: invalid
State: The issue / PR is not valid
Type: bug
The issue reports a bug / The PR fixes a bug (including spelling errors)
Milestone
Comments
This issues was taken from the µkleos issue tracker (http://ukleos.org/issues/2). Does anyone (@kaspar030?) knows more details? |
Jesus, that was three years ago. I've no idea what was wrong... |
Let's open this again, when we know if and what is wrong. |
OlegHahm
referenced
this issue
in OlegHahm/RIOT
Nov 6, 2013
patch native board for current Makefile structure
Kijewski
added a commit
that referenced
this issue
Feb 26, 2014
shell: adapt register prefix command to new shell api
nmeum
added a commit
to nmeum/RIOT
that referenced
this issue
May 1, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 8, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 8, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 9, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 11, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 12, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 13, 2017
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this issue
May 16, 2017
rfuentess
referenced
this issue
in rfuentess/RIOT
May 19, 2017
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
May 26, 2017
Execute an OTtask as soon as there is a new one
roberthartung
added a commit
to roberthartung/RIOT
that referenced
this issue
Jun 29, 2017
roberthartung
added a commit
to roberthartung/RIOT
that referenced
this issue
Jul 24, 2017
ZetaR60
pushed a commit
to ZetaR60/RIOT
that referenced
this issue
Jun 30, 2018
Less layers by joining commands
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 8, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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.
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 8, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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.
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 8, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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
to keestux/RIOT
that referenced
this issue
Jun 9, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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.
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 9, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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.
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 9, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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.
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 9, 2020
When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#3.
keestux
added a commit
to keestux/RIOT
that referenced
this issue
Jun 10, 2020
…d IDs When CDC ACM is used as stdio the first thread in the test may have a different ID than RIOT-OS#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.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
Jul 26, 2020
This change is a temporary patch to fix the compilation errors with the STM32 MCU implementation of the new low-level GPIO API until PR RIOT-OS#3 for micropython is merged. Once this PR is merged, this patch can be dropped.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
Jul 26, 2020
This change is a temporary patch to fix the compilation errors with the STM32 MCU implementation of the new low-level GPIO API until PR RIOT-OS#3 for micropython is merged. Once this PR is merged, this patch can be dropped.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
Jul 26, 2020
This change is a temporary patch to fix the compilation errors with the STM32 MCU implementation of the new low-level GPIO API until PR RIOT-OS#3 for micropython is merged. Once this PR is merged, this patch can be dropped.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
Jul 26, 2020
This change is a temporary patch to fix the compilation errors with the STM32 MCU implementation of the new low-level GPIO API until PR RIOT-OS#3 for micropython is merged. Once this PR is merged, this patch can be dropped.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
Sep 3, 2020
This change is a temporary patch to fix the compilation errors with the STM32 MCU implementation of the new low-level GPIO API until PR RIOT-OS#3 for micropython is merged. Once this PR is merged, this patch can be dropped.
schulztr
pushed a commit
to schulztr/RIOT
that referenced
this issue
Jul 7, 2021
New version of generate.py and affordances JSON scheme
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this issue
Jan 28, 2022
The ENTROPY test always fails on this board main(): This is RIOT! (Version: buildtest) mbedtls test SHA-224 test RIOT-OS#1: passed SHA-224 test RIOT-OS#2: passed SHA-224 test RIOT-OS#3: passed SHA-256 test RIOT-OS#1: passed SHA-256 test RIOT-OS#2: passed SHA-256 test RIOT-OS#3: passed ENTROPY test: failed
chrysn
pushed a commit
to chrysn-pull-requests/RIOT
that referenced
this issue
Sep 16, 2022
sixlowapp: fix small typo
bors bot
added a commit
that referenced
this issue
Feb 15, 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 <hendrik.vanessen@ml-pa.com> Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
bors bot
added a commit
that referenced
this issue
Feb 21, 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 19292: sys/phydat: Fix unit confusion r=benpicco a=maribu ### Contribution description Previously, `UNIT_G` was used for g-force with the correct symbol `g`, `UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs` (which is an alternative correct symbol). To avoid confusion between G-Force, Gauss, and Gram the units have been renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition, gram now uses the correct symbol `g`; which sadly is the same as for g-force. But usually there is enough context to tell them apart. ### Testing procedure Green CI ### Issues/PRs references None 19294: sys/shell: don't include suit command by default r=benpicco a=benpicco 19295: gcoap: Finish the gcoap_get_resource_list_tl -> gcoap_get_resource_list renaming r=benpicco a=chrysn ### Contribution description In #16688, an argument was added to the `gcoap_get_resource_list` function by creating a new function `gcoap_get_resource_list_tl` with a deprecation and roll-over plan. This plan has not been acted on so far. This PR shortens the original plan by just adding the argument to `gcoap_get_resource_list` and removing `gcoap_get_resource_list_tl` in a single go. The rationale for this deviation is that while it's a public API, its only two practical consumers are the (built-in) well-known/core implementation, and the (built-in) CoRE Resource Directory (cord) endpoint. Moreover, a further change to this API (switching over to `coap_block_slicer_t`) is expected to happen within this release cycle, which would take something like 4 total releases to get through otherwise, which is unrealistic for an API that there are no known external users of. A second commit clean up ToDo items (in the changed function's documentation) that referred to a IETF draft that has long been abandoned by the CoRE WG. ### Testing procedure Plain inspection and CI passing should suffice. ### AOB There is a second analogous pair left over from #16688, `gcoap_req_send` / `gcoap_req_send_tl`. As that *is* expected to be used widely, I prefer not to mix these two concerns, and get the present one through without unnecessary hold-up. Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: chrysn <chrysn@fsfe.org>
bors bot
added a commit
that referenced
this issue
Feb 21, 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 19292: sys/phydat: Fix unit confusion r=benpicco a=maribu ### Contribution description Previously, `UNIT_G` was used for g-force with the correct symbol `g`, `UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs` (which is an alternative correct symbol). To avoid confusion between G-Force, Gauss, and Gram the units have been renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition, gram now uses the correct symbol `g`; which sadly is the same as for g-force. But usually there is enough context to tell them apart. ### Testing procedure Green CI ### Issues/PRs references None Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
bors bot
added a commit
that referenced
this issue
Feb 22, 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>
bors bot
added a commit
that referenced
this issue
Feb 22, 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
State: invalid
State: The issue / PR is not valid
Type: bug
The issue reports a bug / The PR fixes a bug (including spelling errors)
No description provided.
The text was updated successfully, but these errors were encountered: