The CyDAQ's firmware is split across two cores. One core (core 0) is running PetaLinux and the other (core 1) is bare metal. PetaLinux is used to handle the main communication. It can be broken into two parts: communication between the lab computer and the CyDAQ and communication between the first core and second core. The two cores communicate with one another using a Remote Procedure Call (RPC) framework having the first core acting as a client and the second being the server. The second core acts as a main server and handles all the high speed sampling, PID controller updates, and the rest of the data processing.
The CyDAQ's firmware is split across two cores. One core (core 0) is running PetaLinux and the other (core 1) is bare metal. PetaLinux is used to handle the main communication. It can be broken into two parts: communication between the lab computer and the CyDAQ and communication between the first core and second core. The two cores communicate with one another using a Remote Procedure Call (RPC) framework having the first core acting as a client and the second being the server. The second core acts as a main server and handles all the high speed sampling, PID controller updates, and the rest of the data processing.
## Core 0
## Core 0
PetaLinux handles communication with the lab computer by communicating over a USB serial and USB Ethernet Gadget device, all on one USB connection. To communicate with the computer PetaLinux over a teletype (ttyGS0) device file. It is able to output over the UART port by writing to the other device file (ttyPS0). This has been done in the comm library.
PetaLinux handles communication with the lab computer by communicating over a USB serial and USB Ethernet Gadget device, all on one USB connection. To communicate with the computer, PetaLinux sends the message over a teletype (ttyGS0) device file. It is able to also output over the UART port by writing to the other device file (ttyPS0). This has been done in the comm library.
## Communication
## Communication
The communication between the two cores is done with a Remote Procedure Call (RPC) framework. This framework sets up the main core as a client and the other cores as servers. This framework works wonderfully for Asymmetric Multiprocessing (AMP) applications like the CyDAQ. The server will sit “busy” waiting to be interrupted using a CPU interrupt to handle and command it has been sent. Our version of this framework is built upon other frameworks and libraries. We use openAMP to handle the setup of our RPMsg (Remote Processor Messaging) and to set up our remoteproc (Remote Processor). We use this API because it is both compatible with running on the initial framework of linux and bare metal. It used the VirtIO Media Access Control to handle the main channel of communication between the two cores over some shared memory. More on this in our RPC page.
The communication between the two cores is done with a Remote Procedure Call (RPC) framework. This framework sets up the main core as a client and the other cores as servers. This framework works wonderfully for Asymmetric Multiprocessing (AMP) applications like the CyDAQ. The server will sit “busy” waiting to be interrupted using a CPU interrupt to handle and command it has been sent. Our version of this framework is built upon other frameworks and libraries. We use openAMP to handle the setup of our RPMsg (Remote Processor Messaging) and to set up our remoteproc (Remote Processor). We use this API because it is both compatible with running on the initial framework of linux and bare metal. It used the VirtIO Media Access Control to handle the main channel of communication between the two cores over some shared memory. More on this in our RPC page.
