Serial RPC protocol
The goal of this series of articles is to explain the design of a serial remote procedure call protocol which uses UART as the underlying protocol, starting from functional requirements, software architecture design, implementation and testing of the RPC protocol on a microcontroller.
Motivation
There are various serial request-response based protocols based on UART which are either fixed packet length, variable packet length or string-based protocols. The protocol varies from based on application to application. The goal of this serial RPC protocol is to develop a simple framework which can be easily integrated to an embedded system and also provide a Python library to control the servers connected to a host (which is usually an SBC/PC). The protocol must be able to support request/response-based data transfer for synchronous communication between host and servers and notification-based data transfer for asynchronous data transfers.
Terminologies used
Through the series of articles, the terms RPC client and bus master, RPC server and bus target are used interchangeably.
Functional requirements
Requirement 1: Protocol operating environment
The serial RPC protocol is designed to operate in a single master multiple target system bus where the master sends requests to a target device on the system bus and the device responds to the request. The bus master must not send any requests to any other device/target on the bus until the device/target currently addressed responds or the response times out.
Requirement 2: Operation of RPC notification packets
The bus master has complete control over enabling/disabling notification packets from the bus targets. The bus master can control the flow of notifications from the bus targets using special packets called control and status packets.
Requirement 3: Addressing of bus target by bus master
Each bus target has a unique 4-bit address value ranging from 0 to 15. The bus master can address each bus target using its individual target address.
Requirement 4: Error detection capabilities
The bus master must be able to detect corruption in received packets. It must also send out request packets with a corruption detection mechanism in order. The bus targets must be capable of detecting framing errors and packet corruption.
Requirement 5: Control and status reporting by bus target
The bus target must be able to report on the size of the notification buffer in its software stack, the number of entries in the notification buffer and whether notifications enabled or not.
Get Patrick A Joseph’s stories in your inbox
Join Medium for free to get updates from this writer.
Requirement 6: Bus operating conditions
There should be no collision of packets sent over the system bus. The bus line is a differential half-duplex line similar to RS-485 lines. All bus targets must monitor the bytes being sent out by the bus master and the bus target which is sending out notifications and must reject packets whose target address does not match with that bus targets address. The bus master must ensure that at any time only one bus target must be sending out notifications to the bus master. When the bus target continues sending over notification packets to the bus master and the bus master tries to send out a control & status packet or the request packet, the bus master must keep on trying at regular timeout intervals until the try count reaches a count of 127 and the bus master must report a timeout.
Software development plan
The software development involves the following stages: serial RPC, protocol rules, bus and packet structure, working and software architecture of serial RPC bus master and RPC bus target, proof of concept implementation of bus target RPC code in C, integration of bus target code in a microcontroller, implementation of bus master RPC software in Python, designing test setup and test cases and development of PyTest test suite and finally documenting the test results and the performance metrics.
Serial RPC protocol rules, bus and packet structure
In this phase, the rules of the protocol are defined more clearly, and the bus structure is explained with a diagram. This phase also defines the RPC packets which are used by the RPC protocol and the purpose of each packet and how the packets are interpreted.
Software architecture & working of bus master and bus target
In this phase, the behavior of the bus master and the bus target are explained. The software architecture of the bus master and the bus target are explained with the help of flow charts and explains the corner cases in the protocol.
Proof of concept implementation in C
In this phase, a proof-of-concept implementation of the bus target RPC protocol is done in C. The C API functions are defined and a demonstration code is added to show the working of the C implementation of the bus target RPC server. Various test cases are written to validate the working of the bus target RPC server.
Integration of bus target RPC server code in a microcontroller
In this phase, the C implementation of the bus target RPC server is integrated into an embedded application to demonstrate the use of the protocol on a real embedded system. The RPC server is interfaced with the microcontroller’s SDK’s UART driver, and the working of the RPC server is tested out by sending serial commands.
Implementation of RPC client (bus master)
In this phase, the RPC client/ bus master software is implemented in Python on the host PC. The software architecture and APIs of the Python code is clearly defined in this phase. This phase is completed by writing a simple Python code to communicate with the bus target.
Designing test setup and test cases and development of PyTest test suite
In this phase, the various test cases and the test matrix is prepared to test the performance of the RPC client and RPC server implementations. The testing is completely done using PyTest. The tests will primarily focus on the request-response time, processing speed of notification packets and stress testing of the RPC client (bus master) and RPC server (bus target) implementations.
Documenting the test results and the performance metrics
In this phase, the test results from the PyTest test suite are documented and analyzed.
