... | ... | @@ -11,10 +11,10 @@ The following sub-chapters will describe the functionality of the OpenLab commun |
|
|
|
|
|
== OpenLab communication protocol
|
|
|
|
|
|
The interpreter is based on the communication protocol described in [21]. This protocol standardises the way of communication between a OpenLab device and the OpenLab GUI.
|
|
|
The interpreter is based on the communication protocol described in [1]. This protocol standardises the way of communication between a OpenLab device and the OpenLab GUI.
|
|
|
This ensures that the OpenLab GUI is able to connect to, and communicate with, any OpenLab device. Regardless if it is microcontroller-based, FPGA-based or soundcard-based.
|
|
|
The protocol was written from the OpenLab device perspective. This means that every command that is declared by the protocol is sent by the GUI.
|
|
|
On the other hand, every reply is sent from the OpenLab device. Two versions of the OpenLab communication protocol are described by [21].
|
|
|
On the other hand, every reply is sent from the OpenLab device. Two versions of the OpenLab communication protocol are described by [1].
|
|
|
|
|
|
{empty} +
|
|
|
|
... | ... | @@ -35,7 +35,7 @@ Table 1 shows the layout of the binary protocol, including the command- and repl |
|
|
|
|
|
{empty} +
|
|
|
|
|
|
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_binarytable.PNG[caption="Figure 1: ",title="Binary-Mode command- and reply-structure, modified (21)",height=600,align="center"]
|
|
|
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_binarytable.PNG[caption="Table 1: ",title="Binary-Mode command- and reply-structure, modified (1)",height=600,align="center"]
|
|
|
|
|
|
{empty} +
|
|
|
|
... | ... | @@ -60,7 +60,7 @@ Every command sent by the GUI is analyzed by the corresponding process. Dependin |
|
|
|
|
|
{empty} +
|
|
|
|
|
|
Figure 39 shows a diagram of the structure of this entity. Each process is dedicated to a specific function.
|
|
|
Figure 1 shows a diagram of the structure of this entity. Each process is dedicated to a specific function.
|
|
|
|
|
|
{empty} +
|
|
|
|
... | ... | @@ -85,11 +85,11 @@ After a command was successfully received by the Command Interpreter, the proces |
|
|
|
|
|
{empty} +
|
|
|
|
|
|
Figure 40 illustrates the flow diagram of the Command Interpreter - process.
|
|
|
Figure 2 illustrates the flow diagram of the Command Interpreter - process.
|
|
|
|
|
|
{empty} +
|
|
|
|
|
|
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_cmd_flow.PNG[caption="Figure 1: ",title="Flow diagram of the command interpreter process as part of the FPGA design",align="center"]
|
|
|
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_cmd_flow.PNG[caption="Figure 2: ",title="Flow diagram of the command interpreter process as part of the FPGA design",align="center"]
|
|
|
|
|
|
{empty} +
|
|
|
|
... | ... | @@ -117,15 +117,15 @@ In order to inform the Command Execution State Machine, the Command Interpreter |
|
|
This process is responsible for executing the command received from the GUI. The process continuously listens to the Command Interpreter to instantly execute a new available command.
|
|
|
If a new packet was received, the state machine will first check the command code.
|
|
|
According to the value of the command code, the next state will execute the command and generate the corresponding reply.
|
|
|
The structure of the state machine is described by the following diagram seen in figure 41.
|
|
|
The structure of the state machine is described by the following diagram seen in figure 3.
|
|
|
|
|
|
{empty} +
|
|
|
|
|
|
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_proto_SM.PNG[caption="Figure 1: ",title="Diagram of the command execution state machine",align="center"]
|
|
|
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_proto_SM.PNG[caption="Figure 3: ",title="Diagram of the command execution state machine",align="center"]
|
|
|
|
|
|
{empty} +
|
|
|
|
|
|
As shown in figure 41, the state machine itself can reach the following states:
|
|
|
As shown in figure 3, the state machine itself can reach the following states:
|
|
|
|
|
|
{empty} +
|
|
|
|
... | ... | @@ -171,7 +171,7 @@ every time a new command was received. |
|
|
|
|
|
* WAIT_PC_REC
|
|
|
|
|
|
Every time a sample data packet was send by the FPGA, the actual state switches to
|
|
|
Every time a sample data packet was sent by the FPGA, the actual state switches to
|
|
|
the WAIT_PC_REC state. This state is used as a wait state. The state waits a defined
|
|
|
number of clock cycles in order to prevent the receiving buffer of the PC from overflowing.
|
|
|
After completing execution of the WAIT_PC_REC state, the current state switches back
|
... | ... | @@ -180,7 +180,7 @@ procedure can be interrupted by any incoming command. |
|
|
|
|
|
{empty} +
|
|
|
|
|
|
* WAIT_NACK_FIN
|
|
|
* WAIT_NACK_FIN (deprecated)
|
|
|
|
|
|
This state is reached after a NACK message was sent by the FPGA. It resets some
|
|
|
internal signals and variables to prepare the state machine for any new command. The
|
... | ... | @@ -208,8 +208,7 @@ selection and the sample acquisition system. |
|
|
CMD_SCS decides which channel is turned on or off depended on the payload data.
|
|
|
This state is also responsible for correctly setting the amplification-stage. This is done by
|
|
|
setting a bit pattern to the input of the de-multiplexer. This bit pattern is directly extracted
|
|
|
from the SET CHANNEL SETTINGS message. The amplification-stage selection process
|
|
|
is described in chapter 4.2.3 of this thesis. After execution, the CMD_SCS state will set
|
|
|
from the SET CHANNEL SETTINGS message. After execution, the CMD_SCS state will set
|
|
|
the next state to ACK.
|
|
|
|
|
|
{empty} +
|
... | ... | @@ -223,7 +222,7 @@ value of the sample rate received from the GUI is already prepared to be used by |
|
|
sampling-data-and-triggering entity of the FPGA design.
|
|
|
This means that the value already represents the amount of clock cycles the FPGA has
|
|
|
to wait before storing a new sample. So complex mathematical operations are not necessary.
|
|
|
The sampling procedure will be discussed in chapter 5.4. After completion, the next
|
|
|
The sampling procedure will be discussed in chapter https://es.technikum-wien.at/openlab/openlab_wiki/wikis/OpenLab_osci_FPGA_imp3[Sampling data and triggering]. After completion, the next
|
|
|
state changes to the ACK state.
|
|
|
|
|
|
{empty} +
|
... | ... | @@ -233,20 +232,20 @@ state changes to the ACK state. |
|
|
This state gets activated by the CHECK_DATA state if the SET SAMPLING MODE command
|
|
|
was received by the Command Interpreter process. The CMD_SSM state reads
|
|
|
data from the received payload and sets settings for the ETS sampling mode. A general
|
|
|
description of ETS can be found in chapter 6. The implementation of the ETS sampling
|
|
|
mode is described in chapter 7. Again, after completion, the next state will be changed to
|
|
|
description of ETS can be found in chapter https://es.technikum-wien.at/openlab/openlab_wiki/wikis/ETS_theory[Equivalent Time Sampling - Theory]. The implementation of the ETS sampling
|
|
|
mode is described in chapter https://es.technikum-wien.at/openlab/openlab_wiki/wikis/SETS_FPGA[Sequential Equivalent Time Sampling - FPGA Implementation]. Again, after completion, the next state will be changed to
|
|
|
the ACK state.
|
|
|
|
|
|
{empty} +
|
|
|
|
|
|
* REPLY_SD
|
|
|
|
|
|
This state is responsible for reading the sample data provided by the sampling-data-andtriggering
|
|
|
This state is responsible for reading the sample data provided by the sampling-data-and-triggering
|
|
|
entity of the FPGA design.
|
|
|
The REPLY_SD state prepares every sample data packet and starts their transmission.
|
|
|
Regardless of the selected sampling mode, the REPLY_SD state will handle the data collection.
|
|
|
This state prepares the Extended-Sample-Data packet as described by the binary
|
|
|
protocol in [21].
|
|
|
protocol in [1].
|
|
|
|
|
|
{empty} +
|
|
|
|
... | ... | @@ -326,7 +325,7 @@ OpenLab device and the OpenLab GUI is considered as non-critical. |
|
|
|
|
|
{empty} +
|
|
|
|
|
|
The paper "A Tutorial on CRC Computations" [26] is concerned to CRC algorithm and how
|
|
|
The paper "A Tutorial on CRC Computations" [2] is concerned to CRC algorithm and how
|
|
|
they are structured. The CRC16 calculation consists of two processes. One process is responsible
|
|
|
for calculating the CRC of the header of a message. The other process calculates the
|
|
|
payload CRC.
|
... | ... | @@ -344,4 +343,11 @@ flag is set by the Command Execution State Machine. |
|
|
|
|
|
{empty} +
|
|
|
|
|
|
== Bibliography
|
|
|
|
|
|
. Schloffer Harald: _Development of a low-cost micro-controller based oscilloscope including equivalent time sampling_, University of Applied Sciences FH Technikum Wien, 2016
|
|
|
. TEMLASO V. RAMABADRAN, S. S. G.: A Tutorial on CRC Computations. Iowa State University, 1988.
|
|
|
|
|
|
{empty} +
|
|
|
|
|
|
== https://es.technikum-wien.at/openlab/openlab_wiki/wikis/home[Home] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/OpenLab_osci_FPGA_imp[<OpenLab Oscilloscope FPGA IP-Core] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/OpenLab_osci_FPGA_imp2[Data communication between FPGA and PC>] |