sys/stdio_nimble: add new stdio module using nimble #12012

HendrikVE · 2019-08-15T12:16:20Z

Contribution description

Implement a new module stdio_nimble, which uses UART and nimble in parallel for stdio. The characteristic for stdin is writable and the characteristic for stdout uses the indicate mechanism to publish the system's output to a connected device. Calls of "_send_from_ringbuffer" to send data via nimBLE are chained together using a callback in nimBLE called "_gap_event_cb".

Module can be enabled with USEMODULE += stdio_nimble

UART can be disabled with CFLAGS += -DSTDIO_NIMBLE_DISABLE_UART

For automatic advertising a new module is provided: "auto_nimble_advertise". It will take care to enable advertising on disconnect and disable on connect.

Module can be enabled with USEMODULE += auto_nimble_advertise

Advertised device name can be configured with
CFLAGS += -DAUTO_NIMBLE_ADVERTISE_DEVICE_NAME='"name"'

Testing procedure

You can download the matching android app (source) which was developed in parallel to this contribution at the Google Playstore for your smartphone, but you can also use any other bluetooth developement app, like Nordics "nRF Connect"-App, available for Android and iOS.

All you have to do is adding USEMODULE += stdio_nimble to the Makefile of an application, for example default and run it on a nrf52dk board. Now you can open the app, connect to the device and input commands to the shell and receive its output via bluetooth. UART input and output are still working in parallel to this.

Issues/PRs references

needs sys/nimble_autoadv: add new module #13425
needs sys/isrpipe: add isrpipe_write #17336
needs sys/tsrb: add tsrb_clear #17337

haukepetersen

I did not look into the code in too much detail (yet), but there are some issues that we should think about before going into the fine details:

additional thread: this is only needed because of the 'bug/behavior' of NimBLE, where the hacky delay is added, right? When actually merging this, I would prefer to gain more insights on this behavior and save that memory. Or at least as a work around, I would prefer to post delayed events to NimBLEs event queue instead...
static memory allocation: there is (i) no need for that here, and (ii) the way malloc is used is extremely dangerous (return value is not checked at all)
use of msg: the way the type field is used to encode a buffers length is a nice big old security nightmare: if you send an invalid message from any other thread to this thread, it enables someone to print out a lot of otherwise hidden memory...
BLE behavior: I have not made up my mind yet, but I think the advertising behavior coded in this PR should at least be optional or made in a way it can be disabled (e.g. a sub-module?). I guess we have two typical use-cases: (i) this code is used in an otherwise BLE-unrelated context (e.g. hello-world example on nrf boards), or (ii) it is used with some BLE application (e.g. nimlbe_gatt). For the first case, is makes sense to tell the node to advertise at some point. But for the second option, there is potential trouble when the user application will also try to start advertising...

HendrikVE · 2019-09-24T14:27:30Z

@haukepetersen This PR includes now completely rewritten code. Instead of an additional thread, it's using nimBLE's callback architecture, so most of your previous concerns are invalid by now. There is also a second new module auto_nimble_advertise, which only handles advertising, which is not mandatory for stdio_nimble to work.

HendrikVE · 2019-09-24T14:29:20Z

This PR depends on:

haukepetersen · 2019-09-26T12:08:16Z

Coll, will have another look

haukepetersen · 2020-02-07T16:02:20Z

Finally I got to reviewing this PR, sorry for the delay. First to my test results:

the NimBLE shell does not seem to work for me, using the default example @ nrf52dk, compiling with USEMODULE="stdio_nimble auto_nimble_advertise". The shell over uart works as expected. Also I was able to connect from my node using the RIOT shell app from the Playstore. However, when issuing shell commands (like ps or help), the output in the app is scrambled and incomplete:
Running the same configuration without the additional uart shell (CFLAGS += -DSTDIO_NIMBLE_DISABLE_UART) behaves exactly the same. Output for unkown shell commands looks fine, but the output for known shell commands (ps, saul, help) is broken.

Additional, some thoughts about the structure of this PR:

I (still) don't like to combine uart with stdio_nimble. I understand, that this might have helped with the implementation, but structural it is a mess. Further, it does not help, that parts are (quote) copy-pasted from stdio_uart module . I think this is screwing with our (current) STDIO concept of only having a given STDIO device at any time. If we want to multiplex over more than a single STDIO device, this should be implemented generically on a systems level, not be hacked into specific STDIO implementations... So I would strongly opt for removing the complete uart support from this module!
I am not a 100% happy with the auto_nimble_advertise module. It implements partly generic and partly specific behavior, without allowing for more advanced configuration. E.g. it is in the current state designed for connectable advertisements only, supporting specifically a single connection, and no further AD fields... All this is not really implied by the name?! I would propose to generify this module by encapsulating a more generic and configurable core module with a simplified wrapper that then exposes an option to use it via auto_init. And having this in a separate PR is probably not a bad idea...
the buffering seems to be odd to me: if I read the code correctly, it is for stdio_write and stdio_read blocking, if there is not enough space in the buffers. IMO, it would be more straight forward to simply drop data in case of filled buffers. Of course the buffer sizes should be configurable, so that applications with a lot of STDIO thoughput can simply up their buffers to mitigate data loss. Actually, e.g. stdio_uart is also implemented this way.

haukepetersen

Some more findings in the code. I think there is some room for improvement concerning the buffer handling in particular (which would also allow for significant code simplification).

haukepetersen · 2020-02-07T15:47:43Z

sys/auto_init/auto_init.c

@@ -196,6 +196,16 @@ void auto_init(void)
    extern void nimble_riot_init(void);
    nimble_riot_init();
 #endif
+#ifdef MODULE_STDIO_NIMBLE


I would prefer to put the initialization of stdio_nimble and auto_nimble_advertise into the generic NimBLE initialization in pkg/nimble/contrib/nimble_riot.c. This would be more in line with other nimble-based modules, and even more important it would ensure the initialization order and make sure that NimBLE is always initialized before stdio_nimble_init() is called...

Done, thanks for the hint!

haukepetersen · 2020-02-07T16:03:00Z

Makefile.dep

@@ -457,7 +466,9 @@ endif

 ifneq (,$(filter stdin,$(USEMODULE)))
  ifneq (,$(filter stdio_uart,$(USEMODULE)))
-    USEMODULE += stdio_uart_rx
+    ifeq (,$(filter stdio_nimble,$(USEMODULE)))


how about ifneq (,$(filter stdio_uart stdio_nimble,$(USEMODULE)))?

I'm reverting to pre-PR state, because UART-in-parallel feature is removed.

haukepetersen · 2020-02-07T16:04:11Z

sys/auto_nimble_advertise/Makefile

@@ -0,0 +1,5 @@
+ifeq (gnu, $(TOOLCHAIN))
+  CFLAGS += -Wno-cast-function-type


maybe better fix the code instead of suppressing the warning?!

I removed this one. Honestly, I don't even remember anymore the reason why I've added this. There is not even a warning after removing this.

haukepetersen · 2020-02-07T16:06:34Z

sys/include/stdio_nimble.h

+/**
+ * @brief UUID for stdio service (value: e6d54866-0292-4779-b8f8-c52bbec91e71)
+ */
+static const ble_uuid128_t gatt_svr_svc_stdio_uuid


should better be allocated in the C file. If they should be available to other modules, I a define in the header is the better choice.

Having it like this would mean the compiler could possibly allocated this memory once for every compilation unit this header is included...

This header wasn't meant to be included by another module, as stdio_nimble is initiated by the auto_init mechanism. I moved these parts out anyway.

haukepetersen · 2020-02-07T16:07:56Z

sys/include/stdio_nimble.h

+/**
+ * @brief Dummy access callback, because nimble requires one
+ */
+static int gatt_svr_chr_access_noop(


if this function is implemented in the header file, it should at least be inlined. But why not put it into the *.c file?!

Moved in to .c

haukepetersen · 2020-02-07T16:12:14Z

sys/stdio_nimble/stdio_nimble.c

+
+/* copy-pasted from stdio_uart module */
+#ifndef STDIO_NIMBLE_DISABLE_UART
+static void _init_stdio_uart(isrpipe_t *isrpipe)


why have a separate function for these 2 lines? The code becomes easier to read if they are put directly into stdio_init.

Done, because UART-in-parallel feature is removed.

haukepetersen · 2020-02-07T16:13:16Z

sys/stdio_nimble/stdio_nimble.c

+}
+#endif
+
+static void _stdio_nimble_write(const void* buffer, size_t len)


same here, there is not really a reason for splitting this function if it is only used once. For a bad compiler this might just increase code size...

Because UART-in-parallel feature is removed, I merged _stdio_nimble_write in to stdio_write. I generally like it to put code for different purposes in to their own functions. Both are for writing data, but if you see it at a lower level one is for sending to uart and the other for sending to nimble. That's why I've put them in separated functions.

haukepetersen · 2020-02-07T16:15:31Z

sys/stdio_nimble/stdio_nimble.c

+    switch (event->type) {
+
+        case BLE_GAP_EVENT_CONNECT:
+            _clear_ringbuffer();


why clear it? Wouldn't it be nicer to get all the node's output that was produced prio to the connect event? This way one could even see the boot messages (provided the buffer space is configured accordingly).

The problem I see here is that this is somewhat a strange behaviour. You also wouldn't expect to get old output from your old session when you start a new ssh session on a remote machine. In my opinion it could limit the use cases of this module, because people don't want to get the old output. Either because it's irrelevant output of a previous session or even worse something that should be kept secret and is now sent to someone else. In addition, even if not clearing the buffer, the boot message would be sent only on the first connection. But instead one could think about sending a welcome message after connecting.

haukepetersen · 2020-02-07T16:16:12Z

sys/stdio_nimble/stdio_nimble.c

+                _send_stdio = false;
+            }
+            _conn_handle = event->connect.conn_handle;
+            ble_att_set_preferred_mtu(MTU_MAX_NIMBLE);


these functions should only be called if event->connect.status == 0, right?!

Yes, fixed now. Thanks!

haukepetersen · 2020-02-07T16:19:24Z

sys/stdio_nimble/stdio_nimble.c

+        if (isrpipe_write_one(&_stdin_isrpipe, _stdin_data[i]) == -1) {
+
+            /* sleep for 5 ms to give consumer thread time to consume given data */
+            xtimer_usleep(5000);


It seems bad to me to block the NimBLE host thread for potentially some time. As mentioned above: I think the way to go is simply to drop data in case the buffer(s) run full!

Fixed by dropping characters that don't fit into the ring buffer as you suggested.

HendrikVE · 2020-02-10T16:13:53Z

Thank you very much for your detailed review! I've pushed several fixups, but the simpler buffer handling with potential data drop is still on it's way.
Also, I still need to think about a better advertisement module.

Well, I don't know why the output is broken four you, it's working on my phone ... classic ... *sigh*
I guess we will have to test my phone with your compiled application to identify whether it's a bug in the app.

HendrikVE · 2020-02-20T16:32:11Z

Data drop for full buffers is implemented now.

I've outsourced the automated advertisement module. It's now in PR #13425. This PR was rebased to it. Therefore #13425 is now a dependency for this PR.

HendrikVE · 2021-12-27T14:03:54Z

#17446 is now a dependency that should be merged first.

fjmolinas · 2022-01-17T12:23:43Z

#17446 is now a dependency that should be merged first.

The dependency is now in!

HendrikVE · 2022-01-19T15:40:43Z

Rebased to master

fjmolinas

I re-tested today and still experience the same issue, I'm running the examples/twr_aloha test between two boards, one with `stdio_nimble. This is what happend:

2022-01-26 16:22:16,128 # twr req CC:95 -c 5
2022-01-26 16:22:16,129 # [twr]: start ranging
2022-01-26 16:22:17,119 # {"t": 89578, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:18,109 # {"t": 90570, "src": "C3:29", "dst": "CC:95", "d_cm": 37}
2022-01-26 16:22:19,099 # {"t": 91570, "src": "C3:29", "dst": "CC:95", "d_cm": 36}
2022-01-26 16:22:20,134 # {"t": 92570, "src": "C3:29", "dst": "CC:95", "d_cm": 40}
2022-01-26 16:22:21,124 # {"t": 93570, "src": "C3:29", "dst": "CC:95", "d_cm": 38}
> twr req CC:95 -c 100 -i 100
2022-01-26 16:22:25,759 # twr req CC:95 -c 100 -i 100
2022-01-26 16:22:25,759 # [twr]: start ranging
2022-01-26 16:22:25,849 # {"t": 98309, "src": "C3:29", "dst": "CC:95", "d_cm": 32}
2022-01-26 16:22:25,940 # {"t": 98402, "src": "C3:29", "dst": "CC:95", "d_cm": 31}
2022-01-26 16:22:26,028 # {"t": 98501, "src": "C3:29", "dst": "CC:95", "d_cm": 33}
2022-01-26 16:22:26,164 # {"t": 98601, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:26,253 # {"t": 98701, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:26,345 # {"t": 98801, "src": "C3:29", "dst": "CC:95", "d_cm": 31}
2022-01-26 16:22:26,434 # {"t": 98902, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:26,524 # {"t": 99001, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:26,660 # {"t": 99101, "src": "C3:29", "dst": "CC:95", "d_cm": 36}
2022-01-26 16:22:26,750 # {"t": 99201, "src": "C3:29", "dst": "CC:95", "d_cm": 33}
2022-01-26 16:22:26,839 # {"t": 99301, "src": "C3:29", "dst": "CC:95", "d_cm": 36}
2022-01-26 16:22:26,928 # {"t": 99402, "src": "C3:29", "dst": "CC:95", "d_cm": 36}
2022-01-26 16:22:27,065 # {"t": 99501, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:27,154 # {"t": 99601, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:27,245 # {"t": 99701, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:27,335 # {"t": 99801, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:27,423 # {"t": 99902, "src": "C3:29", "dst": "CC:95", "d_cm": 31}
2022-01-26 16:22:27,560 # {"t": 100001, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:27,650 # {"t": 100101, "src": "C3:29", "dst": "CC:95", "d_cm": 33}
2022-01-26 16:22:27,738 # {"t": 100201, "src": "C3:29", "dst": "CC:95", "d_cm": 36}
2022-01-26 16:22:27,964 # {"t": 100402, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:28,054 # {"t": 100501, "src": "C3:29", "dst": "CC:95", "d_cm": 32}
2022-01-26 16:22:28,144 # {"t": 100601, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:28,234 # {"t": 100701, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:28,323 # {"t": 100801, "src": "C3:29", "dst": "CC:95", "d_cm": 33}
2022-01-26 16:22:28,459 # {"t": 100902, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:28,550 # {"t": 101001, "src": "C3:29", "dst": "CC:95", "d_cm": 32}
2022-01-26 16:22:28,639 # {"t": 101101, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:28,728 # {"t": 101201, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:28,865 # {"t": 101302, "src": "C3:29", "dst": "CC:95", "d_cm": 34}
2022-01-26 16:22:28,955 # {"t": 101401, "src": "C3:29", "dst": "CC:95", "d_cm": 32}
2022-01-26 16:22:29,044 # {"t": 101501, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:29,135 # {"t": 101601, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:29,223 # {"t": 101702, "src": "C3:29", "dst": "CC:95", "d_cm": 32}
2022-01-26 16:22:29,449 # {"t": 101802, "src": "C3:29", "dst": "CC:95", "d_cm": 32}
2022-01-26 16:22:29,540 # {"t": 101901, "src": "C3:29", "dst": "CC:95", "d_cm": 35}
2022-01-26 16:22:29,629 # {"t": 102001, "src": "C3:29", "dst": "CC:95", "d_cm": 36}
2022-01-26 16:22:29,720 # {"t": 102101, "src": "C3:29", "dst": "CC:95", "d_cm": 30}
help
2022-01-26 16:22:49,001 # Serial port disconnected, waiting to get reconnected...
2022-01-26 16:22:50,003 # Serial port disconnected, waiting to get reconnected...
2022-01-26 16:22:51,004 # Serial port disconnected, waiting to get reconnected...
2022-01-26 16:22:52,005 # Try to reconnect to /tmp/dwafde again...
2022-01-26 16:22:52,006 # Reconnected to serial port /tmp/dwafde
> 2022-01-26 16:22:52,985 #
> 2022-01-26 16:22:52,986 # {"t": 124303, "src": "C3:29", "dst": "CC:95", "d_cm": 37}

The disconnected/reconnected happened at the time where I disconnected ble-serial because it was stuck, and on re-connect the applications resumed. But then I inverted who initiated the requests and it worked fine, event ith more intensive loads. So I guess its more of a combination of both use cases than stdio-nimble itself.

Still worried about mutex_lock in something that can be called in ISR though, could lead to a deadlock I think.

Regarding the test, I would have preferred an example, but will not nitpick on that. The test should be a tests-with-config though.

Once those two issues are addresed I think we can squash this one.

fjmolinas · 2022-01-26T15:59:19Z

sys/stdio_nimble/stdio_nimble.c

+ssize_t stdio_write(const void* buffer, size_t len)
+{
+#if IS_USED(MODULE_STDIO_NIMBLE_DEBUG)
+    mutex_lock(&_debug_print_mutex);


I have the same concern as https://github.com/RIOT-OS/RIOT/pull/12012/files#r792789326

sys/include/stdio_nimble.h

fjmolinas · 2022-01-26T16:00:58Z

pkg/nimble/contrib/nimble_riot.c

+#ifdef MODULE_STDIO_NIMBLE
+    extern void stdio_nimble_init(void);
+    /* stdio_nimble_init() needs to be called after nimble stack initialization
+     * and before nimble_autoadv_init() */
+    stdio_nimble_init();
+#endif
+


Lets leave it or a follow up.

examples/default/Makefile

dist/pythonlibs/testrunner/spawn.py

tests/shell_ble/tests/01-run.py

tests/shell_ble/README.md

dist/pythonlibs/testrunner/spawn.py

HendrikVE · 2022-01-28T16:01:30Z

Unfortunately I don't have the hardware to try examples/twr_aloha but I tried replicating the output behaviour and everything went fine using this configuration for me. When I am sending too many messages then nimble has no time to send the data and then I get a timeout and once in a while also the following message: 16:40:00.395 | ERROR | main.py: Bluetooth connection failed: [org.bluez.Error.Failed] Operation failed with ATT error: 0x11 (Unsupported Feature or Parameter Value)

HendrikVE · 2022-01-28T16:03:29Z

But since my bluetooth adapter seems to be a bit crappy I can't differentiate whose fault it is.

fjmolinas · 2022-01-28T16:21:34Z

Please squash @HendrikVE!

HendrikVE · 2022-01-28T16:43:41Z

While checking my squashed commits I noticed my changes in boards/nrf52dk/Makefile.dep. At the time I simply extended the existing rules, but now it seems that this is not necessary anymore as it was removed in the meantime. The test compiles and runs without these changes. So I guess I should remove it?

HendrikVE · 2022-01-28T18:25:40Z

Found out that nordic_softdevice_ble was removed after the 2020.10 release. So these changes do not have any effect => remove

Implement a new module stdio_nimble, which uses nimble for stdio. The characteristic for stdin is writable and the characteristic for stdout uses the indicate mechanism to publish the system's output to a connected device. Data will be sent out asynchronously via callout functions. The module can be enabled with "USEMODULE += stdio_nimble" Co-authored-by: Francisco Molina <femolina@uc.cl>

fjmolinas

ACK

fjmolinas · 2022-01-28T20:45:20Z

@haukepetersen your comments were quite some time ago, do you mind taking a look?

fjmolinas · 2022-01-28T20:45:51Z

@haukepetersen your comments were quite some time ago, do you mind taking a look?

Or dismissing your review, whatever feels more pertinent.

Stale review

fjmolinas · 2022-02-04T10:10:07Z

I discarded @haukepetersen since it's been stale for quite a while. I think there was enough time for him to take a look. Let's get this in and get some usage feedback. Thanks for sticking through for so long @HendrikVE!

HendrikVE · 2022-02-04T18:15:25Z

Awesome, thank you so much @fjmolinas for all your work on this! I'm happy to see this merged into master :) I hope to get around to fix my app soon.

HendrikVE force-pushed the nimble_shell_module branch 2 times, most recently from a50ee27 to 99e7f3a Compare August 15, 2019 13:05

tcschmidt requested a review from haukepetersen August 17, 2019 00:03

miri64 added Area: BLE Area: Bluetooth Low Energy support Area: sys Area: System Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Aug 28, 2019

haukepetersen requested changes Aug 28, 2019

View reviewed changes

HendrikVE force-pushed the nimble_shell_module branch from 99e7f3a to 0c232fc Compare September 24, 2019 14:23

HendrikVE force-pushed the nimble_shell_module branch from 0c232fc to 89a1d09 Compare September 24, 2019 14:36

HendrikVE mentioned this pull request Sep 24, 2019

Question: Shell commands via telnet #12233

Closed

HendrikVE force-pushed the nimble_shell_module branch from 89a1d09 to d933865 Compare October 18, 2019 10:10

HendrikVE mentioned this pull request Nov 8, 2019

What service do I have to use in RIOT to use this? HendrikVE/RiotBleShellApp#1

Closed

HendrikVE force-pushed the nimble_shell_module branch from d933865 to 6f018f6 Compare January 8, 2020 13:03

HendrikVE mentioned this pull request Jan 10, 2020

sys/shell: new module shell_lock #13082

Merged

HendrikVE force-pushed the nimble_shell_module branch from 6f018f6 to 2709a9a Compare January 15, 2020 14:18

haukepetersen previously requested changes Feb 7, 2020

View reviewed changes

HendrikVE force-pushed the nimble_shell_module branch from 43c044c to 78f939f Compare February 10, 2020 16:10

HendrikVE force-pushed the nimble_shell_module branch from 0ed647f to 0ab2234 Compare February 11, 2020 00:38

HendrikVE requested review from aabadie, fjmolinas and jia200x as code owners February 19, 2020 10:25

HendrikVE mentioned this pull request Feb 20, 2020

sys/nimble_autoadv: add new module #13425

Merged

HendrikVE force-pushed the nimble_shell_module branch from 3c956ef to c66a928 Compare February 20, 2020 16:27

HendrikVE requested a review from haukepetersen February 20, 2020 16:33

HendrikVE force-pushed the nimble_shell_module branch from 9d04046 to 6583c61 Compare December 17, 2021 01:32

HendrikVE force-pushed the nimble_shell_module branch from 54a5b69 to e488836 Compare January 19, 2022 15:31

fjmolinas reviewed Jan 26, 2022

View reviewed changes

fjmolinas added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jan 28, 2022

HendrikVE force-pushed the nimble_shell_module branch from 6b4f3a3 to b5a8c75 Compare January 28, 2022 16:28

github-actions bot removed the Area: examples Area: Example Applications label Jan 28, 2022

HendrikVE and others added 4 commits January 28, 2022 19:26

tests/shell_ble: add variant of shell test for stdio_nimble

7ab1344

pkg/nimble: configure nimble values for stdio_nimble

e840b61

sys/stdio_nimble: implementation of stdio_available

f91751e

HendrikVE force-pushed the nimble_shell_module branch from b5a8c75 to f91751e Compare January 28, 2022 18:27

github-actions bot removed the Area: boards Area: Board ports label Jan 28, 2022

fjmolinas approved these changes Jan 28, 2022

View reviewed changes

fjmolinas merged commit 14f22c1 into RIOT-OS:master Feb 4, 2022

HendrikVE deleted the nimble_shell_module branch February 7, 2022 11:47

OlegHahm added this to the Release 2022.04 milestone Apr 25, 2022

crasbe mentioned this pull request Feb 5, 2025

sys/stdio_nimble: Send Callout called indefinitely even without anything to send #21192

Open

		@@ -0,0 +1,5 @@
		ifeq (gnu, $(TOOLCHAIN))
		CFLAGS += -Wno-cast-function-type

sys/stdio_nimble: add new stdio module using nimble #12012

sys/stdio_nimble: add new stdio module using nimble #12012

Uh oh!

Conversation

HendrikVE commented Aug 15, 2019 • edited by fjmolinas Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Uh oh!

haukepetersen left a comment

Choose a reason for hiding this comment

Uh oh!

HendrikVE commented Sep 24, 2019

Uh oh!

HendrikVE commented Sep 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

haukepetersen commented Sep 26, 2019

Uh oh!

haukepetersen commented Feb 7, 2020

Uh oh!

haukepetersen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HendrikVE commented Feb 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HendrikVE commented Feb 20, 2020

Uh oh!

HendrikVE commented Dec 27, 2021

Uh oh!

fjmolinas commented Jan 17, 2022

Uh oh!

HendrikVE commented Jan 19, 2022

Uh oh!

fjmolinas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

HendrikVE commented Aug 15, 2019 •

edited by fjmolinas

Loading

HendrikVE commented Sep 24, 2019 •

edited

Loading

HendrikVE commented Feb 10, 2020 •

edited

Loading