Bare nRF51822 alternative to the micro:bit

[mfalkvidd]

Can we use a bare nRF51822 instead of the micro:bit?

[fO-000]

It certainly works in theory, but the current code uses a lot of the micro:bit APIs. Hopefully, I'll have time to adapt bare nRF51822 later.

Also, you might be interested in the btlejack project.

[BJamin99]

Looking at btlejack, it seems like the micro:bit APIs can be used and target non micro:bit boards. That project appears to just use a config file (ble400.json) that is used when compiling the code for the adafruit bluefruit le friend and ble400 boards, where the key difference is that the tx and rx pins are remapped. This also needs the following code in main.cpp after uBit.init():

#ifdef YOTTA_CFG_TXPIN
  #ifdef YOTTA_CFG_RXPIN
    #pragma message("Bluing firmware will use custom serial pins")
    uBit.serial.redirect(YOTTA_CFG_TXPIN, YOTTA_CFG_RXPIN);
  #endif
#endif

There is also support for the NRF devel board using the pca10031.json file which adds a baudrate of 1M to the config.

I tried compiling this project with the ble400.json config added and it seemed to compile fine. I have yet to flash it to a board though to test.

Two things that are easier with the micro:bit over the bare boards are identifying the board connected to the system, and flashing new firmware to the board. The first is easier as the microbit has a unique vid/pid to be able to identify it from the generic USB-to-UART ICs that are used on other boards. The second is easier as the microbit emulates a mass storage drive to drop firmware on whereas other boards need to be programmed using SWD.

For btlejack, flashing isn't supported on non-microbit boards, and there are extra command-line parameters for specifying the tty for the serial ports to be used.

[BJamin99]

I was able to flash the above on an Adafruit Bluefruit LE Friend. Modifying the blueing microbit.py file to have it look for the description of the generic USB to UART IC on that board ("CP2104 USB to UART Bridge Controller - CP2104 USB to UART Bridge Controller") allows bluing to identify the device and try to use it. No luck with getting it to work yet though, but here is what I see when I hook up wireshark to the USB port.

Bluing sends "0x000000" to the Bluefruit (i.e. reset). Bluefruit responds with header "0xff000a" and ASCII data "OP_RESET" Bluefruit sends "0x00" Bluefruit sends "0x00" (note: somewhere between bluefruit responding with OP_RESET and here, the Bluefruit visibly resets) Bluefruit sends header "0xff001e" and ASCII data "Entered host_cmd_handler fiber" Bluefruit sends header "0x000000" (i.e. ready).

But then Bluing doesn't seem to send anything back to the Bluefruit. Enabling debug output on Bluing shows that it sees the OP_RESET coming in from the bluefruit, but then it seems not get the "Entered host_cmd_handler fiber" message or the "ready" message.

[BJamin99]

The issue is with the two single byte sends (perhaps one before reset and one after reset?). The code in serial_protocol.py assumes it is getting a three byte header. What happens is that the header becomes 0x0000ff, so the code then waits for 255 bytes of data, but the only remaining data in the buffer is 0x001e, so it hangs waiting for the remaining 253 bytes. Either the Bluefruit needs a change to not send these 0x00 serial messages, or serial_protocol.py needs to change to discard those single byte messages.

[BJamin99]

Put in a hack to solve that issue. The basic assumption is that an evt_code of 0 will always have a zero length, so if it doesn't, discard any leading 0 bytes to get to the actual evt_code. Pull request #30 has been opened with the changes.

[fO-000]

@BJamin99 Thank you so much for your work!