OPERATION PRINCIPLE, ADVANCED PROCEDURES AND VALIDATION OF A NEW FLEX-SPI COMMUNICATION PROTOCOL FOR SMART IoT DEVICES

Abstract

In this paper, we report on hardware structure, operation mode and software development for a new advanced communication protocol whose aim is obtaining a fully shared SPI bus with a fixed amount of wires, without renouncing to advantages of a push-pull output stage and obtaining an architecture capable of great flexibility. All four signals of a classic SPI protocol are entirely shared by the slaves on bus: when a master wants to communicate with a particular device, it will perform an addressing at packet level: starting from its main characteristics, various adopted solutions to realize a shared SPI bus will be analyzed, explaining how a communication session is performed. The firmware structure was designed as a software stack composed by interacting layers, tracing model of similar protocols that share with FlexSPI some features. Some of the advanced procedures that can be performed thanks to this protocol will be discussed, highlighting the suitability of FlexSPI for dynamic smart objects; in fact, by adding these features to developed framework, it is possible to explore and appreciate expandability of this communication protocol, making it suitable to meet advanced IoT requirements of smart objects. FlexSPI can be built like aMAC layer above the SPI bus, to process all necessary pieces of information to perform the packet level addressing, using a stack having a layered architecture. This is idea followed in the firmware development, to implement this communication protocol, experimentally verified in the performed and reported communication tests, confirming that it is possible to obtain a shared push-pull bus.

Design and manufacturing of an ultrasonic reactor for biodiesel obtaining by transesterification

“…The inputs and outputs of this module (Fig. 8) are: external clock reference, time base to obtain the desired frequency; configuration allows the interaction of Taking as reference the frequency of work of the ultrasonic actuator (20kHz), it is decided to generate this signal with an electronic device of easy configuration, the integrated circuit reference AD9833, which has a wide range of configurable frequencies by means of the SPI communication protocol (serial peripheral interface) [38].…”

Technical Features and Functionalities of Myo Armband: An Overview on Related Literature and Advanced Applications of Myoelectric Armbands Mainly Focused on Arm Prostheses

“…The Arduino micro board receives the Myo armband EMG and IMU data through a HM-11 BLE module, while the recognized poses are reported on the touchscreen display in real-time. The realized electronic control board, the switching regulator used for the Raspberry Pi board power supply and the touchscreen mounted on the Raspberry Pi board, together with the related housing into the prosthesis socket, are shown in Figure 30A; the employed Lithium battery and the Myo armband are also indicated (Patrono et al, 2017;Visconti et al, 2017cVisconti et al, , 2017d.…”

FRAMEWORK IMPLEMENTATION, FIRMWARE DEVELOPMENT AND CHARACTERIZATION OF FLEX-SPI COMMUNICATION PROTOCOL: ENERGY CONSUMPTION ANALYSIS AND COMPARISON WITH I2C STANDARD

“…The first step for the development of the firmware has been the design of a suited software architecture, with the purpose of dividing and therefore optimizing the different required tasks to perform a shared SPI communication. FlexSPI, in fact, can be interpreted as a MAC layer above the physical SPI bus, handling addressing and all the extra procedures [2]. In this particular framework, only the master possesses an extra element on this stack, the Application layer, used to emulate a practical situation in which FlexSPI may be used.…”

“…Primitives exchange when the master is receiving.III. EXPERIMENTAL ANALYSES OF THE REALIZED FIRMWAREThe first test on the developed firmware has been the execution of a FlexSPI-based data exchange between two MSP-EXP430F5438 Experimenter Boards[2] [7][8]. One board has been programmed with master version of the firmware, while the other with the slave version; the connection of the necessary SPI pins is then obtained as reported in figure 7a.…”

“…Example of bad decode by the logic analyzer at maximum speed.By analyzing the waveforms in figure 7c, it is possible to note the presence of some delay between communication sessions. These delays have been voluntarily inserted because, in this first implementation, the slave has no way to communicate to the master that it is ready to start a new session, relying on MADSIS procedure[2]. For this reason, the master is forced to insert some delays to grant the correct behavior of the firmware.…”