Below is a list of different directions this project can go from this point. Getting a Petalinux and Baremetal implementation to work and communicate was the main focus of our project, and future work can build upon that. We also included some performance improvement strategies.
GUI
Socket Communication
The existing GUI uses serial to communicate with the CyDAQ, which has some limitations. Sending and receiving serial messages in a way that can safely handle sudden disconnections, for example, requires a lot of overhead and was the source of many of our GUI bugs. This could be prevented with a socket-based connection established between the host PC and the Petalinux COMM application. Socket connections are designed to handle unstable connections much better than serial connections. On top of that, network connections introduce error correction in the IP layer, which is something that serial can’t do.
Socket communication would also be a viable solution to enable live sampling data. The current firmware implementation only transfers sample data after sampling is complete. If a socket connection exists, that data could be sent in chunks to the GUI, which could allow for live graphing if wanted.
SCP Transfer Speed Increase
The current implementation uses SCP over the Ethernet USB Gadget to transfer sample data to the host PC. We were only able to reach around 5MB/s transfer speed at the highest with this method. This is much slower then the observed 20MB/s when measuring raw transfer speed over the network with IPerf3 here. We believe this is due to the fact that SCP adds a lot more overhead (encryption manly), as it's a secure protocol. There might be a way to disable this, and should be investigated if you chose to use SCP in the future.
TCP File Transfer
A raw TCP connection could also be used to transfer sample data (either all at once or live). TCP implementations in C and Python are very standard, so there should be many different resources or libraries out there to consult. The implementation might require a lot of time to get right, which is why we weren't able to do it ourselves on top of getting Petalinux working. A TCP file transfer would most likely give the best performance, as there is minimal overhead but still comes with error correction.
Module Level Logging
Our current GUI uses the default Python logging library to handle debug messages sent to the console, shown in the debug screen, and written to a crash log. The current logging configuration adds all logs to a single module, which sometimes makes it difficult to filter out log messages for certain sections of the application. This could be improved upon by defining many different modules in the GUI. For example, each individual page in the GUI could have its own module, and then the debug page could have checkboxes that filter the modules based on what the user selects.
Web-Based User Interface
The user interface could be completely rewritten as a web app. Petalinux is capable of running any application that can run on other Linux distributions (assuming resource requirements are maintained), so it’s safe to assume that it could run a web-based application that a connected PC could simply connect to for a user interface. This would greatly simplify the configuration process, as sending messages between the host PC and CyDAQ could be abstracted away by the web service chosen.
Careful consideration must also be made on which web service is chosen. The CyDAQ only has 1GB of RAM, some of which is reserved already. Petalinux also runs its entire root filesystem in RAM in our current configuration. Some web applications have high RAM usage, and Petalinux will not be able to function well if the usage is exceeded. More research into a lightweight web service would need to be done if this option is to be considered.
Firmware
Speed Up The Boot Time Of The Onboard Linux
The current boot time for the CyDAQ is around 20 seconds, which is longer than the full bare-metal project. The main reason is that Linux is being flashed to the RAM on every bootup and wiped on shutdown. There are a few possible solutions to this problem we came up with. These include changing to a faster SD card, disabling unused Linux features, and pre-loading the Linux system on the SD card. These have a few downsides, including the high cost of a premium SD card, extensive knowledge of Linux required, and the need to format and reload the firmware after every change.
Increase USB Gadget Throughput
It's probably possible to configure the Ethernet USB Gadget in a way that increases transfer speed. We were able to reach 20MB/s in our testing with the standard configuration, so a higher speed might not be needed but it is an option. More research would be needed for this though.
DAC Mode For Audio Signal
There are two design paths for this. Using the Xilinx Quad SPI IP would be easy to implement but would require a fix to the problem of the core constantly resetting. Creating a custom SPI IP is another path that could be taken that would provide customizability but extensive knowledge of VHDL and Xilinx IPs is needed.
Linux Sandbox
The concept of Linux Sandbox involves a Python wrapper for the Vitis software, intending to enable students to utilize Python scripts to manage the CyDAQ. To achieve this, the sandbox must convert Python scripts into C programs compatible with the CyDAQ.
Open-source and DSP experiments
A long-term goal of this project is to open-source the CyDAQ so it can be given to other universities for use and to create different lab experiments on CyDAQ, especially for DSP applications.