Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • O openlab_wiki
  • Project information
    • Project information
    • Activity
    • Members
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Wiki
    • Wiki
  • Activity
Collapse sidebar
  • openlab
  • openlab_wiki
  • Wiki
  • OpenLab_osci_FPGA_imp1

OpenLab_osci_FPGA_imp1 · Changes

Page history
added content to OpenLab_osci_FPGA_imp1.asciidoc authored Mar 09, 2017 by Patrick Schmitt's avatar Patrick Schmitt
Hide whitespace changes
Inline Side-by-side
OpenLab_osci_FPGA_imp1.asciidoc
View page @ e4793a4a
......@@ -39,8 +39,35 @@ image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_
{empty} +
The fixed fields are, regardless of the type of the message, fixed in size. They form the header of a message. This is valid for command and reply messages.
The header consists of the command or reply code, the device identifier, the channel number, payload size and the header checksum.
The optional fields are directly dependent on the type of the package. The size is variable. Those fields are also called the payload of the message.
Some commands or replies only consist of the header field. The payload field of commands is used to transfer configuration data like channel and trigger settings.
In case of reply messages, the payload can carry sample data or information necessary for the GUI. The payload is, just like the header of the message, protected by a checksum.
In case of defect packets, errors can be detected by either the FPGA or the GUI. CRC16 is not able to reconstruct corrupted data.
However, the FPGA and the GUI are able to request the required data again if necessary. Defect sample data packets are currently ignored by the GUI to prevent displaying errors.
{empty} +
The upcoming chapter will explain the integration of the binary-protocol into the FPGA design.
{empty} +
== FPGA protocol interpreter and reply generator
The FPGA design of the communication protocol interpreter consists of several processes. Those processes together form the protocol interpreter of the FPGA design.
Every command sent by the GUI is analyzed by the corresponding process. Depending on the type of the command, a reply is than being generated by another process.
{empty} +
Figure 39 shows a diagram of the structure of this entity. Each process is dedicated to a specific function.
{empty} +
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_proto_interpret.PNG[caption="Figure 1: ",title="Structure of the FPGA protocol interpreter and reply generator component",align="center"]
{empty} +
== https://es.technikum-wien.at/openlab/openlab_wiki/wikis/home[Home] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/board_TIVAC[<Microcontroller-based TIVAC] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/sig_proc_osci_hardware[Signal Processing Front-End (XMC,TIVAC,DE0-Oscilloscope)>]
Clone repository
  • ETS_theory
  • OpenLab_RCL_uC_imp
  • OpenLab_SignalToolkit
  • OpenLab_UI_source_uC_imp
  • OpenLab_firm_ip_intro
  • OpenLab_logic_uC_imp
  • OpenLab_osci_FPGA_imp
  • OpenLab_osci_FPGA_imp1
  • OpenLab_osci_FPGA_imp2
  • OpenLab_osci_FPGA_imp3
  • OpenLab_osci_FPGA_imp4
  • OpenLab_osci_LPC_imp
  • OpenLab_osci_TIVAC_imp
  • OpenLab_osci_XMC_imp
  • OpenLab_siggen_ATMEL_imp
View All Pages