11

I'm trying to design an efficient communication protocol between a micro-controller on one side and an ARM processor on a multi-core TI chip on the other side through SPI.

The requirements for the needed protocol:

1 - Multi-session with queuing support, as I have multiple sending/receiving threads, so it will be more than one application using this communication protocol and I need the protocol to handle queuing these requests (I will keep holding the buffer if the transmission is queue but I just need the protocol to manage scheduling the queues).

2 - Works over SPI as an underlying protocol.

3 - Simple error checking.

In this thread: "Simple serial point-to-point communication protocol", PPP was a recommended option, however I see PPP does only part of the job.

I also found Light weight IP (LwIP) project featuring PPP over serial (which I assume that I can use it over SPI), so I thought about the possibility of utilizing any of the upper layers protocols like TCP/UDP to do the rest of the required jobs. Fortunately, I found TI including LwIP as part of their ethernet SW in the starterware package, which I assume to ease porting at least on the TI chip side.

So, my questions are:

1 - Is it valid to use LwIP for this communication scheme? Won't this introduce much overhead due to IP headers which are not necessary for a point to point (on the chip level) communication and kill the throughput?

2 - Will the TCP or any similar protocol residing in LwIP handle the queuing of transmission requests, for example if I request transmission through a socket while the communication channel is busy transmitting/receiving request for another socket (session) of another thread, will this be managed by the protocol stack? If so, which protocol layer manages it?

3 - Is their a more efficient protocol stack than LwIP, that meets the above requirements?

Update 1: More points to consider

1 - SPI is the only available option, I use it with available GPIOs to indicate to the master when the slave has data to send.

2 - The current implemented (non-standard) protocol uses DMA with SPI, and a message format of《STX_MsgID_length_payload_ETX》with a fixed message fragments length, however the main drawback of the current scheme is that the master waits for a response on the message (not fragment) before sending another one, which kills the throughput and does not utilise the full duplex nature of SPI.

3- An improvement to this point was to use a kind of mailbox for receiving fragments, so a long message can be interrupted by a higher priority one so that fragments of a single message can arrive non sequentially, but the problem is that this design lead to complicating things especially that I don't have much available resources for many buffers to use the mailbox approach on the controller (master) side. So I thought that it's like I'm re-inventing the wheel by designing a protocol stack for a simple point to point link which may not be efficient.

4- What kind of higher level protocols can be normally used above SPI to establish multiple sessions and solve the queuing/scheduling of messages?

Update 2: Another useful thread "A good serial communications protocol/stack for embedded devices?"

Update 3: I had a look at Modbus protocol, it seems to specify the application layer then directly the data link layer for serial line communication, which sounds to skip the unnecessary overhead of network oriented protocols layers.

Do you think this will be a better option than LwIP for the intended purpose? Also, is there a widely used open source implementation like LwIP but for Modbus?

Community
  • 1
  • 1
Wessam
  • 111
  • 1
  • 1
  • 7
  • spi is master slave not bidirectional. If you want to use lwip or some other protocol you probably want to use serial/uart not spi. lwip will have a lot of overhead, you could probably just do your own thing instead. – old_timer Sep 24 '13 at 17:29
  • @dwelch - USB is master/slave as well, but that's easily solved with periodic polling of slaves. – Chris Stratton Sep 24 '13 at 19:29
  • 1
    Unfortunately SPI is the available option, I already use it along with another GPIO to indicate to the master when data is available at slave. – Wessam Sep 25 '13 at 00:48
  • Chris, understood, but also understand that usb was designed for that and much of the polling is built into the hardware, not necessarily something that software has to be constantly doing. – old_timer Sep 25 '13 at 04:01
  • Sure, having to do polling in software is a slight inefficiency, but it looks like the OP has a hardware attention signal implemented anyway, so that won't be an issue. – Chris Stratton Sep 25 '13 at 14:52

2 Answers2

4

I think that perhaps you are expecting too much of the humble SPI.

An SPI link is little more a pair of shift registers one in each node. The master selects a single node to connect to its SPI shift register. As it shifts in its data, the slave simultaneously shifts data out. Data is not exchanged unless the master explicitly clocks the data out. Efficient protocols on SPI involve the slave having something useful to output while the master inputs. This may be difficult to arrange, so you usually need a means of indicating null data.

PPP is useful when establishing a connection between two arbitrary endpoints, when the endpoints are fixed and known a priori, PPP would serve no purpose other than to complicate things unnecessarily.

SPI is not a very sophisticated nor flexible interface and probably unsuited to heavyweight general purpose protocols such as TCP/IP. Since "addressing" on SPI is performed by physical chip-select, the addressing inherent in such protocols is meaningless.

Flow control is also a problem with SPI. The master has no way of determining that the slave has copied the data from SPI the shift register before pushing more data. If your slave SPI supports DMA you would be wise to use it.

Either way I suggest that you develop something specific to your purpose. Since SPI is not a network as such, you only need a means to address threads on the selected node. This could be as simple as STX<thread ID><length><payload>ETX.

Added 27 September 2013 in response to comments Generally SPI as its names suggests is used to connect to peripheral devices, and in that context the protocol is defined by the peripheral. EEPROMS for example typically use a common or at least compatible command interface across vendors, and SD/MMC card SPI interface uses a standardised command test and protocol.

Between two microcontrollers, I would imagine that most implementations are proprietary and application specific. Open protocols are designed for generic interoperability and to achieve that might impose significant unnecessary overhead for a closed system, unless perhaps the nodes were running a system that already had a network stack built in.

I would suggest that if you do want to use a generic network stack that you should abstract the SPI with device drivers at each end that give the SPI a standard I/O stream interface (open(), close(), read(), write() etc.), then you can use the higher-level PPP and TCP/IP protocols (although PPP can probably be avoided since the connection is permanent). However that would only be attractive if both nodes already supported these protocols (running Linux for example), otherwise it will be significant effort and code for little benefit, and would certainly not be "efficient".

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • 1
    Most of these points (except maybe ultimate throughput) would apply to USB as well, yet it's considered entirely reasonable to run network protocols over USB to external network adapters, and was even back in the era of 12MB/s USB which SPI can probably match with moderate care. There's really no reason the same solution methods, such as master periodically polling slaves, couldn't be used with SPI. – Chris Stratton Sep 24 '13 at 19:27
  • 1
    @ChrisStratton: True, but perhaps hardly worth the effort (at least for the application described). USB is far more complex than SPI and defines hardware, interconnect, software stacks and device profiles. SPI defines none of that, and SPI controllers are far more primitive, in fact you can implement SPI with GPIO and software. The payback with USB is the ability to connect to third-party devices; with SPI, third party devices such as SD/MMC cards and EEPROMs use far simpler protocols. – Clifford Sep 24 '13 at 22:43
  • You can implement USB with GPIOs too. The point is if SPI is what is available, it can be made to work - your concerns inefficiencies, not roadblocks. – Chris Stratton Sep 25 '13 at 00:03
  • Thanks for your answer and comments, do u mean that ppp does a job that is already handled by spi as the connection is already established? Please refer to the edited question for some added points related to your answer. – Wessam Sep 25 '13 at 03:45
  • @ChrisStratton: I have never heard of anyone implementin a bit-bashed USB and would be surprised if it were sucessful or even USB-IF compliant. Bit-bashing SPI is common. – Clifford Sep 25 '13 at 10:06
  • @Wessam: I am saying the PPP does a job that is not relevant to a fixed/permanent between known and never changing devices. SPI does not "handle" the establishment of a connection because the connection is always there. – Clifford Sep 25 '13 at 10:09
  • Bit banged USB (generally slave side) is quite commonly done on the attiny and atmega series parts without a true usb interface. Compared to that, running a higher level protocol over hardware SPI is simple. – Chris Stratton Sep 25 '13 at 12:30
  • @Clifford: Yes I got that point, so what standard higher level protocols are normally used over spi? – Wessam Sep 26 '13 at 10:17
  • @Wessam: My comment to that was too long, so I added to the answer. – Clifford Sep 27 '13 at 14:43
  • @Clifford: Thanks for the last addition, please check update 3 in the question. – Wessam Sep 27 '13 at 18:52
1

I assume you dont really want or have room for a full ip (lwip) stack on the microcontroller? This just sounds like a lot of overkill. Why not just roll your own simple packet structure to move the data items you need to move. Depending on how spi is supported on both sides you may or may not be able to use it to define the frame for your data, if not a simple start pattern, length and a trailing checksum and maybe tail pattern would suffice for finding packet boundaries in the stream (no different than a serial/uart solution). You can even use the PPP solution for that with a start pattern and I think end pattern with the payload using a two byte pattern whenever the start pattern happens to show up in the data. I dont remember all the details now.

Whatever your frame is then add a packet type and your handshakes, or if the data is going to just be microcontroller to arm then you dont even need to do that.

To get back to your direct question. Yes, I think that an ip stack (lwip or other) will introduce a lot of overhead. both bandwidth and more important the amount of code needed to support that stack will chew up rom/ram on both sides. If you ultimately need to present this data in an ip fashion (a website hosted by the embedded system) then somewhere in the path you need an ip stack, etc.

I cant imagine that lwip manages your queues for you. I assume you would need to do that yourself. the various queues might want to talk to a single driver that deals with the single spi bus (assuming there is a single spi bus with multiple chip selects). It also depends on how you are using the spi interface, if you are allowing the arm to talk to multiple microcontrollers and the packets of data are broken up into a little bit from this controller a little from that controller so that nobody has to wait to long before they get a few more bytes of data. Or will a complete frame have to move from one microcontroller before moving onto the next gpio interrupt to pull that guys data? The long and short of it is I would assume you have to manage the shared resource just like you would in any other situation where you have multiple users of a shared resource (rtos, full blown operating system, etc). I dont remember lwip that well at all but with a full blown berkeley sockets application interface the user could write separate applications where each application only cared about one TCP or UDP port and the libraries and drivers managed separating those packets out to each application as well as all of the rules for the IP stack.

If you are not already doing experiments with moving data over the spi interface(s) I would start with simple experiments first just to get the feel for how well it is or isnt going to work, the sizes of transfers you can do reliably per spi transction, etc. Your solution may naturally just fall out of those experiments.

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • Thanks for your detailed answer, actually the current implemented scheme mentioned in point 2 is already working fine with the drawback of the half duplex and blocking on single message response. That's why I'm looking for standard stack that is normally used over SPI, even to implement it in a standard fashion instead of a new re-design with possible introduced drawbacks. – Wessam Sep 26 '13 at 10:22