embedded - Chip to chip communication protocol over SPI -

i'm trying design efficient communication protocol between micro-controller on 1 side , arm processor on multi-core ti chip on other side through spi.

the requirements needed protocol:

1 - multi-session queuing support, have multiple sending/receiving threads, more 1 application using communication protocol , need protocol handle queuing these requests (i keep holding buffer if transmission queue need protocol manage scheduling queues).

2 - works on spi underlying protocol.

3 - simple error checking.

in thread: "simple serial point-to-point communication protocol", ppp recommended option, see ppp part of job.

i found light weight ip (lwip) project featuring ppp on serial (which assume can use on spi), thought possibility of utilizing of upper layers protocols tcp/udp rest of required jobs. fortunately, found ti including lwip part of ethernet sw in starterware package, assume ease porting @ least on ti chip side.

so, questions are:

1 - valid use lwip communication scheme? won't introduce overhead due ip headers not necessary point point (on chip level) communication , kill throughput?

2 - tcp or similar protocol residing in lwip handle queuing of transmission requests, example if request transmission through socket while communication channel busy transmitting/receiving request socket (session) of thread, managed protocol stack? if so, protocol layer manages it?

3 - more efficient protocol stack lwip, meets above requirements?

update 1: more points consider

1 - spi available option, use available gpios indicate master when slave has data send.

2 - current implemented (non-standard) protocol uses dma spi, , message format of《stx_msgid_length_payload_etx》with fixed message fragments length, main drawback of current scheme master waits response on message (not fragment) before sending one, kills throughput , not utilise full duplex nature of spi.

3- improvement point use kind of mailbox receiving fragments, long message can interrupted higher priority 1 fragments of single message can arrive non sequentially, problem design lead complicating things don't have available resources many buffers use mailbox approach on controller (master) side. thought it's i'm re-inventing wheel designing protocol stack simple point point link may not efficient.

4- kind of higher level protocols can used above spi establish multiple sessions , solve queuing/scheduling of messages?

update 2: useful thread "a serial communications protocol/stack embedded devices?"

update 3: had @ modbus protocol, seems specify application layer directly data link layer serial line communication, sounds skip unnecessary overhead of network oriented protocols layers.

do think better option lwip intended purpose? also, there used open source implementation lwip modbus?

i think perhaps expecting of humble spi.

an spi link little more pair of shift registers 1 in each node. master selects single node connect spi shift register. shifts in data, slave simultaneously shifts data out. data not exchanged unless master explicitly clocks data out. efficient protocols on spi involve slave having useful output while master inputs. may difficult arrange, need means of indicating null data.

ppp useful when establishing connection between 2 arbitrary endpoints, when endpoints fixed , known a priori, ppp serve no purpose other complicate things unnecessarily.

spi not sophisticated nor flexible interface , unsuited heavyweight general purpose protocols such tcp/ip. since "addressing" on spi performed physical chip-select, addressing inherent in such protocols meaningless.

flow control problem spi. master has no way of determining slave has copied data spi shift register before pushing more data. if slave spi supports dma wise use it.

either way suggest develop specific purpose. since spi not network such, need means address threads on selected node. simple stx<thread id><length><payload>etx.

added 27 september 2013 in response comments spi names suggests used connect peripheral devices, , in context protocol defined peripheral. eeproms example typically use common or @ least compatible command interface across vendors, , sd/mmc card spi interface uses standardised command test , protocol.

between 2 microcontrollers, imagine implementations proprietary , application specific. open protocols designed generic interoperability , achieve might impose significant unnecessary overhead closed system, unless perhaps nodes running system had network stack built in.

i suggest if want use generic network stack should abstract spi device drivers @ each end give spi standard i/o stream interface (open(), close(), read(), write() etc.), can use higher-level ppp , tcp/ip protocols (although ppp can avoided since connection permanent). attractive if both nodes supported these protocols (running linux example), otherwise significant effort , code little benefit, , not "efficient".