RE: nRF51822 - wired communication

Ole Morten — Tue, 11 Mar 2014 10:19:23 GMT

Yes, this is a second revision chip, so that should work fine.

RE: nRF51822 - wired communication

Joe Merten — Mon, 10 Mar 2014 19:06:08 GMT

Regarding Torbjørn's post: Thanks for your correction - seemst that I'd read it too sloppy.

Regarding Chip revision: Am I right, that my »N51822 QFAAG0 1342AA« is 2nd revision, have 6-byte rx fifo and therefore should be able to communicate at up to 1 MBaud without lost bytes as long as I use HW handshake?

RE: nRF51822 - wired communication

Ole Morten — Mon, 10 Mar 2014 14:59:07 GMT

I'd recommend using either SPI or UART for such application, since there is no hardware for a TWI slave in the nRF51822. As long as you use second revision chip, all of which has 6 byte UART buffers, and enable flow control, you should have no problem with lost bytes. With first revision chips, with only 2 byte buffers, overflow could occur if the transmitting chip wasn't quick enough to stop sending data.

Also, you don't seem to quote Torbjørn correclty; his point is that you should either use flow control (which is the preferred solution), or use a low baud rate, not both.

To achieve the lowest possible current consumption, I'd recommend you to use as high baud rate as possible, so the serial interfaces are turned on for as short time as possible.

There is an example of how the raw softdevice API can be serialized over UART in the SDK, and it should be perfectly possible to make this run on an STM. Take a look at the code in ble_s110_serialization folder, nrf51822\Board\nrf6310\ble_s110_serialization.

An alternative to exposing the raw softdevice API would be to implement most of the BLE-functionality on the nRF51822 itself, and then expose only a higher level interface to the other chip. Even if you choose to do so, you should be able to reuse significant parts of the serialization work, if you want to.