In this post we get through labs 8 and 9. This will teach us how to archive a project and restore from archives; then it will discuss using interrupts in our programs.
About:
Through Avnet, Xilinx and Element14, a training program to learn about the Zynq 7000 platform which is System On Chip combining an FPGA with an ARM processor. This comes to the students as complete development board packed with goodies like a wireless chip from MuRata (BT/BTLE/WIFI), 8GB Flash memory, onboard RAM, USB to JTAG (JTAG programmable over USB), Arduino-style headers (3.3V compatible only), Microphone, Bi-Color LED, and two additional expansion ports.
See all blog posts for this training here.
Lab 8 - Archiving
This is all about the process of using source control with the SDK package. It is advised to never just simply zip the Windows folder and send that out as it likely will have a lot of problems. Each user's workplace preferences are unique.
For archiving the source files, this is pretty easy - File --> Export
"Archive file" under General is chosen. We then chose all the items to inlcude in the archive. As can be seen in the screenshot below, we picked everything. This will include all SW applications, FSBL, and Board Support Packages.
I got an error during the export as shown below; but the lab mentions that we may need to go back and do a "Refresh" before we export.
That did the trick for me - I was able to export after doing a refresh. It seems that a refresh does a build of the project; and for some reason redoing the build seems to make SDK happier.
We then follow through and export our Launch Configs and our Breakpoints as unique exports using almost the same methods as before.
I was curious about the files, so I took a peek. The breakpoint file is just an XML which spells out the filename and line number (and a bunch of other info) for each breakpoint.
<?xml version="1.0" encoding="UTF-8"?> <breakpoints> <breakpoint enabled="true" persistant="true" registered="true"> <resource path="/" type="8"/> <marker charStart="-1" lineNumber="-1" type="org.eclipse.cdt.debug.core.cFunctionBreakpointMarker"> <attrib name="org.eclipse.cdt.debug.core.breakpointType" value="0"/> <attrib name="org.eclipse.cdt.debug.core.ignoreCount" value="0"/> <attrib name="org.eclipse.tcf.debug.tcfStamp" value="true"/> <attrib name="requestedLine" value="-1"/> <attrib name="charEnd" value="-1"/> <attrib name="org.eclipse.debug.core.enabled" value="true"/> <attrib name="org.eclipse.cdt.debug.core.installCount" value="0"/> <attrib name="message" value="Function breakpoint: [function: _exit]"/> <attrib name="requestedSourceHandle" value=""/> <attrib name="org.eclipse.debug.core.id" value="org.eclipse.cdt.debug.core"/> <attrib name="org.eclipse.cdt.debug.core.sourceHandle" value=""/> <attrib name="charStart" value="-1"/> <attrib name="org.eclipse.cdt.debug.core.function" value="_exit"/> <attrib name="org.eclipse.cdt.debug.core.condition" value=""/> <attrib name="workingset_name" value=""/> <attrib name="workingset_id" value="org.eclipse.debug.ui.breakpointWorkingSet"/> </marker> </breakpoint> <breakpoint enabled="true" persistant="true" registered="true"> <resource path="/" type="8"/> <marker charStart="-1" lineNumber="-1" type="org.eclipse.cdt.debug.core.cFunctionBreakpointMarker"> <attrib name="org.eclipse.cdt.debug.core.breakpointType" value="0"/> <attrib name="org.eclipse.cdt.debug.core.ignoreCount" value="0"/> <attrib name="org.eclipse.tcf.debug.tcfStamp" value="true"/> <attrib name="requestedLine" value="-1"/> <attrib name="charEnd" value="-1"/> <attrib name="org.eclipse.debug.core.enabled" value="true"/> <attrib name="org.eclipse.cdt.debug.core.installCount" value="0"/> <attrib name="message" value="Function breakpoint: [function: main]"/> <attrib name="requestedSourceHandle" value=""/> <attrib name="org.eclipse.debug.core.id" value="org.eclipse.cdt.debug.core"/> 1 <attrib name="org.eclipse.cdt.debug.core.sourceHandle" value=""/> <attrib name="charStart" value="-1"/> <attrib name="org.eclipse.cdt.debug.core.function" value="main"/> <attrib name="org.eclipse.cdt.debug.core.condition" value=""/> <attrib name="workingset_name" value=""/> <attrib name="workingset_id" value="org.eclipse.debug.ui.breakpointWorkingSet"/> </marker> </breakpoint> <breakpoint enabled="false" persistant="true" registered="true"> <resource path="/Test_Peripherals/src/testperiph.c" type="1"/> <marker lineNumber="273" type="org.eclipse.cdt.debug.core.cLineBreakpointMarker"> <attrib name="org.eclipse.cdt.debug.core.breakpointType" value="0"/> <attrib name="org.eclipse.cdt.debug.core.ignoreCount" value="0"/> <attrib name="org.eclipse.tcf.debug.tcfStamp" value="true"/> <attrib name="requestedLine" value="273"/> <attrib name="org.eclipse.debug.core.enabled" value="false"/> <attrib name="org.eclipse.cdt.debug.core.installCount" value="0"/> <attrib name="message" value="Line breakpoint: testperiph.c [line: 273]"/> <attrib name="requestedSourceHandle" value="C:\Speedway\ZyncSW\2017_4\SDK_Workspace\Test_Peripherals\src\testperiph.c"/> <attrib name="org.eclipse.cdt.debug.core.condition" value=""/> <attrib name="org.eclipse.cdt.debug.core.sourceHandle" value="C:\Speedway\ZyncSW\2017_4\SDK_Workspace\Test_Peripherals\src\testperiph.c"/> <attrib name="org.eclipse.debug.core.id" value="org.eclipse.cdt.debug.core"/> <attrib name="workingset_name" value=""/> <attrib name="workingset_id" value="org.eclipse.debug.ui.breakpointWorkingSet"/> </marker> </breakpoint> </breakpoints>
See for instance lines 45-47:
<breakpoint enabled="false" persistant="true" registered="true"> <resource path="/Test_Peripherals/src/testperiph.c" type="1"/> <marker lineNumber="273" type="org.eclipse.cdt.debug.core.cLineBreakpointMarker">
And this matches our breakpoints from the SDK / Debug view -
The "run Configs" file was very similar.
They note here that to export our workspace preferences do still require manually backing up the windows folder; so we go to the subfolder and copy-paste the preference files into a new Backups folder.
That completes the archiving process! Most was very easy as there is a wizard which guides you through it.
We switch SDK to a new 'workspace' which is like starting fresh - there are no applications, HDLs; BSPs, or anything else.
Importing the files is basically the same in reverse - File --> Import ; chose file then hit OK.
Most the files that we archived were pretty small in size. The main backup which include the programs was about 6 mb; the rest were between 1-4k. These could all be used to check in/ out from a Source control program. I wonder if Vivado or SDK can integrate directly with things like TFS or GIT... Anyone?
Lab 9 - Interrupts
Interrupts are a good way to catch things which happen quickly without impacting too much main code - for hardware this could be for things like an encoder input or button press. We don't want to have to continually scan buttons for transitions and would rather just use an interrupt. This essentially works like a hardware input which; when asserted; has a dedicated function of code to deal with the input. For something like a button; the interrupt would fire code to say "something happened" and the Interrupt Service Routine (ISR) code block will execute. Typically, ISRs should be written to be 'short and sweet'. This is because they are essentially 'blocking' code and we need to get the processor back to the original task. When the interrupt fires, the processor has to stack up all its current tasks, handle the interrupt, then un-stack everything and keep going. Xilinx even mentions that they have different types of interrupts which can do things like enhance power saving if they are waiting on a resource like memory. That means that one should never use a 'delay' in an ISR; and we would typically just update a variable then exit the ISR and let the regular program take back over.
In this example. we re-open the PWM lesson from earlier; but the 'non-interrupted' version. In this, we let the hardware side handle invalid input to PWM brightness levels. The software code is then updated to include interrupt handling. The interrupt itself still comes from the PL side; but the software does the code execution when this occurs.
There wasn't too much else to this lesson other than that. I did notice (again) that there is a bug in this example code - see the screenshot below.
The word 'select' has the letter 's' dropped every time an interrupt occurs. My guess is this has to do with timing as the processor comes out of the interrupt routine; but I'm not sure.
I should be finishing up the last two labs tomorrow and starting on my project! Parts won't be here for a few more days, but I think I'll be OK.
