Update Firmware Overview authored by jesseg64's avatar jesseg64
...@@ -5,7 +5,7 @@ The CyDAQ's firmware is split across two cores. One core (core 0) is running Pet ...@@ -5,7 +5,7 @@ The CyDAQ's firmware is split across two cores. One core (core 0) is running Pet
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. 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. This is tells the server to stop and handle the 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. This is tells the server to stop and handle the 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 Protocol 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.
## Core 1 ## Core 1
The Bare Metal Core acts as a server. It only runs commands when it is told to by the client (PetaLinux) and will run that command until completion or when it is told to stop. This runs a main application process that is used to wait for commands. This is paired with an interrupt handler to set flags, call commands and to enter sub application processes (i.e. the balance beam loop). The Bare Metal Core acts as a server. It only runs commands when it is told to by the client (PetaLinux) and will run that command until completion or when it is told to stop. This runs a main application process that is used to wait for commands. This is paired with an interrupt handler to set flags, call commands and to enter sub application processes (i.e. the balance beam loop).