nRF51822 - wired communication

Question

In my current project, I have to develop a board with 2 mcu: 
 
 nRF51822 
 STM32F2/F4
The nRF51822 should running S110 SoftDevice and act as a kind of »over the air« modem, where the STM32 contains the main application business logic. 
 
 The question is now: What is the best way to communicate between nRF51822 and STM32?
Some alternatives: 
 
 RS232 
 I²C 
 SPI 
 any other?
The data rate should be at least 10 kbyte/s (e.g. 115.200 baud).
Regardless which of the above approaches I choose, the lower communication SW driver should be implemented interrupt driven to avoid data loss at the receiving side and unnecessary blocking at the transmitting side. E.g. for RS232 I could use app_uart for that. 
 
 For the case I choose RS232 
 I'm a bit alarmed because of this post : 
 
 … Use flow control (preferred) and a low baudrate, 9600 baud or less … 
 
 And this was confirmed by this post ; 
 
 … The CPU will be suspended when there is radio activity, to avoid disrupting the radio in any way. As long as the CPU is suspended, no application level interrupts will be processed … 
 
 But in this post , I read about the »6-byte buffer on latest chip revision«. How can I determine if my chip has a 2-byte or 6-byte buffer and what possible SW-modifications are needed to use the 6-byte buffer? 
 Can I use much higher baud rates with the 6-byte buffer (any limit) without loosing rx bytes?
(Yes, I'll use HWFC, even though that there was a »#define HWFC false« within boards/nrf6310.h) 
 Related posts: 
 
 devzone.nordicsemi.com/.../can-i-modify-uart-txd-interrupt-flag-set-nrf_uart0-events_txdrdy-to-1-in-software 
 devzone.nordicsemi.com/.../nrf51822-pca10001-uart-rx-interrupt-does-not-trigger 
 devzone.nordicsemi.com/.../does-simple_uart-example-buffer 
 
 Edit: My eval hardware is »N51822 QFAAG0 1342AA«, so the revision seems to be »QFAAG0«

Ole Morten · Accepted Answer

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
rf6310\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.