NRF52 build fails if MICROPY_PY_BLE_NUS enabled

[jerryneedell]

enabling MICROPY_PY_BLE_NUS in bluetooth_conf.h results in the following error.
It builds fine if this is left disabled.

$ make BOARD=feather52 SD=s132
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
Generating build-feather52-s132/genhdr/mpversion.h
GEN build-feather52-s132/genhdr/qstr.i.last
QSTR updated
GEN build-feather52-s132/genhdr/qstrdefs.generated.h
FREEZE freeze
LINK build-feather52-s132/firmware.elf
build-feather52-s132/supervisor/serial.o: In function serial_bytes_available': serial.c:(.text.serial_bytes_available+0x0): undefined reference to mp_hal_stdin_any'
collect2: error: ld returned 1 exit status
Makefile:306: recipe for target 'build-feather52-s132/firmware.elf' failed
make: *** [build-feather52-s132/firmware.elf] Error 1

[jerryneedell]

I tried adding mp_hal_stdin_any to nrf/drivers/bluetooth/ble_uart.c.
The build compiled with this added, but the BLE REPL did not work.

I added this function to ble_uart.c:

bool mp_hal_stdin_any(void) {
return (!isBufferEmpty(mp_rx_ring_buffer));
}

I attempted to base this on what was in nrf/mphalport.c but is not compiled when MICROPY_PY_BLE_NUS is enabled.

[microbuilder]

The REPL/UART code changed with the migration to CircuitPython, which handles the UART abstraction differently. Migrating BLE UART support is at the top of my ToDo list now that the base nRF52 stuff is working ... we've been ignoring the SD until now. The reason the flag fails is because it relies on the MicroPython REPL abstraction layer which we don't use anymore.

[jerryneedell]

Thanks for the update and clarification. I'll look forward to trying it out. Thank you for all the work you have put into this. No rush on my part. I'll (try to) be patient ;-)
I have been playing with some of the ubluepy examples and they seem to work so far. I had tried the NUS in the past and could connect to it, but the apps I was using could not properly send the EOL so I could not get very far. I could see the prompt, but never get it to accept any input since it never saw proper EOL. It looks like this has been fixed in the Adafruit BLE Connect app, so I was trying to test it.

[microbuilder]

I'll get this fixed this week and a PR sent out. I had the same EOL problem, and the OS X and iOS Bluefruit LE Connect apps now have an option to change the EOL character(s) because of that, which should help. The Android version is updated internally, but I need to schedule in some time with the app dev to do some final tests before pushing it out, but I'll try to get that wrapped up soon as well.

[microbuilder]

You can see the release notes here:

• https://itunes.apple.com/us/app/adafruit-bluefruit-le-connect/id1082414600?mt=12
• https://itunes.apple.com/us/app/adafruit-bluefruit-le-connect/id830125974?mt=8

[microbuilder]

Fixed in #528