Embedded Signal
Processing
Project 4: Moving-Average Filter, Debug, SysTick, MCU
Clock Cycle Count, and Compiler Optimization
Overview
M.S. students randomized
groups of two each week, never working with same student, unless
otherwise directed by instructor.
Ph.D. students have option to choose their groups (all Ph.D. or
mix), with or without randomization.
The objective of this project is to become familiar with:
- Programming a moving-average filter using the 16-bit ADC and
12-bit DAC on the FRDMK64F
using mbed.org online IDE
- Using the debug tools
NOTE: Use the Project Report Template and see below
for minimum required data content
your reports and demos.
IN NO CASE may code or files or data or pictures be exchanged
between student groups, there is to be NO COPYING of group
reports!
Also, each student must be able to independently
answer any questions themselves during demos.
All students are expected to learn all aspects of every project.
Nevertheless, students are encouraged to collaborate (not copy)
during the lab sessions.
- Some technical notes:
- The FRDMK64F board uses the 100-pin MK64FN1M0VLL12
MCU, with
- maximum operation frequency of 120 MHz, 1 MB of flash, 256
KB RAM,
- full-speed USB controller, Ethernet controller
- 12-bit DAC (see pin DAC0_out on the Arduino header)
- 16-bit ADC (see pins A0 to A5 on the Arduino header)
- 68 GPIO (see pins AD0 to AD15 on the Arduino header)
- The 100-pin package on the FRDMK64F has one DAC module, the 121-pin and
144-pin packages have two DAC modules.
- For more ADC information, see:
Part 1, A Moving-Average Filter
- See below for minimum required data
content for your reports and your demos
- In this part, programming the 16-bit ADC and 12-Bit DAC aare
used to implement a moving-average filter on the FRDMK64F using
mbed IDE is investigated
- First, create and run the code as follows:
- Log into your mbed.org
account
- Go to the mbed
compiler view
- Create a new program using Mbed::MenuBar::NewProgram (blue
arrow below) and
- selecting the FRDM-K64F platform,
- gpio example program template,
- and name frdm_mvgAvgFil_01 (blue circle below) as shown
below
Fig. 1
- Open the Program Folder and double-click main.cpp (blue
arrow below) to open the main program file as shown below
Fig. 2
- Inspect the main.cpp program code (use main.cpp tab in blue
circle above)
- Click the Mbed::MenuBar::Compile button (red arrow above)
- Make sure that you observe
"success" for the compilation at the bottom of the mbed
window, as before
- Also, note that the file "frdm_whateverYourFileName.bin"
should have been downloaded to your computer
- At this point, you have just confirmed that everything is
working normally as in previous projects
- Plug in your FRDM-K64F board
- Create and run the project code as follows:
- Delete any .bin file that was compiled above and downloaded
to your computer, since we will next replace the default
gpio_example with our own code
- Next: edit the code in the main.cpp frame of the mbed
compiler, as follows
#include "mbed.h"
DigitalOut gpo(D0);
DigitalOut led(LED_RED);
AnalogOut dac0out(DAC0_OUT);
AnalogIn adc0in(A0); //A0 = PTB2
Serial pc(USBTX, USBRX);
int main()
{
if(1){
uint32_t div1=0,div2=0,busClk=0,adcClk=0;
SystemCoreClockUpdate();
pc.printf("SystemCoreClock= %u
\r\n",SystemCoreClock);
div1=( (SIM->CLKDIV1) &
SIM_CLKDIV1_OUTDIV1_MASK)>>SIM_CLKDIV1_OUTDIV1_SHIFT;
div1=1+div1;
div2=1+( (SIM->CLKDIV1)
&
SIM_CLKDIV1_OUTDIV2_MASK)>>SIM_CLKDIV1_OUTDIV2_SHIFT;
busClk=SystemCoreClock*div1/div2;
pc.printf("Divider1== %u div2=%u \r\n",div1,div2);
pc.printf("MCGOUTCLK= %u, busClk = %u
\r\n",SystemCoreClock*div1,busClk);
ADC0->SC3 &=
~ADC_SC3_AVGE_MASK;//disable averages
ADC0->CFG1 &=
~ADC_CFG1_ADLPC_MASK;//high-power mode
ADC0->CFG1 &= ~0x0063 ; //clears
ADICLK and ADIV
ADC0->CFG1 |= ADC_CFG1_ADIV(2); //divide
clock 0=/1, 1=/2, 2=/4, 3=/8
//ADC0->SC3 |= 0x0007;//enable 32
averages
if (((ADC0->CFG1)& 0x03) == 0)
adcClk =
busClk/(0x01<<(((ADC0->CFG1)&0x60)>>5));
if (((ADC0->SC3)& 0x04) != 0) adcClk
= adcClk/(0x01<<(((ADC0->SC3)&0x03)+2));
pc.printf("adcCLK= %u \r\n",adcClk);
}
uint32_t mask16=1<<16;
uint32_t dat1=(PTC->PDOR) | mask16;
//set Port Data Output Register
uint32_t dat0=(PTC->PDOR) &
(!mask16); //clear
uint16_t tpAdc0in=1;
DAC0->C0 = 0; //reset state
DAC0->C1 = 0;
DAC0->C0 =
DAC_C0_DACEN_MASK // Enable
| DAC_C0_DACSWTRG_MASK // Software Trigger
| DAC_C0_DACRFS_MASK; // VDDA selected
uint16_t tpDat[50];
uint32_t tpSum=0;
for(int nn=0;
nn<4; nn++)
{
tpAdc0in=adc0in.read_u16();
tpSum=tpSum+tpAdc0in;
tpDat[nn]=tpAdc0in;
//wait((float)(0.1e-6));
DAC0->DAT[0].DATL =
(uint8_t)((uint16_t)(2000>>4)
& 0xFF);
DAC0->DAT[0].DATH = (uint8_t)(((uint16_t)(2000>>4)
>> 8) & 0x0F);
}
while (true)
{
//example
using write to a single bit, DOarduino=PTC16
(PTC->PDOR)=dat0; //clear
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat0; //clear
tpAdc0in=adc0in.read_u16();
tpSum=tpSum+tpAdc0in-tpDat[0];
for(int
nn=1; nn<4; nn++)
tpDat[nn-1]=tpDat[nn];
tpDat[3]=tpAdc0in;
(PTC->PDOR)=dat0; //clear
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat0; //clear
//wait((float)(0.1e-6));
DAC0->DAT[0].DATL =
(uint8_t)((uint16_t)(tpSum>>6)
& 0xFF);
DAC0->DAT[0].DATH = (uint8_t)(((uint16_t)(tpSum>>6)
>> 8) & 0x0F);
//wait((float)(0.1e-6));
}
}
- Next, set up a signal generator in the lab:
- First, connect the signal generator output to an
oscilloscope
- Connect the "gnd" pin on the signal generator to the
oscilloscope ground clip
- Set the signal generator to a 50 KHz triangle wave, with
offset and peak voltages such that the signal lies between
0.5 and 2.5 volts as shown below (Note: different equipment may require different
settings!)
Fig. 4
- Check that the triangle wave is correct, using the
oscilloscope, as follows:
Fig. 5
- Make sure the signal is between 0 and 3 Volts, to avoid damaging your board!
- Plug in your FRDM-K64F board
- Connect the "gnd" pin on the Arduino header to the
oscilloscope ground clip and to the signal generator ground
clip
- Load and run the program that was created above
- Only AFTER you make sure that the
signal is between 0 and 3 volts, connect the signal generator
to Arduino-header pin A0 (PTB2), the 16-bit ADC pin
- Connect the oscilloscope to the DAC output:
- Connect the "gnd" pin on the Arduino header to the channel
2 oscilloscope ground clip
- Connect channel 2 of the oscilloscope to the Arduino
header DAC0_out pin
- Compile and load the program
- Press reset and run the program
- Press the "single" button on the oscilloscope to capture a
single trace as shown below
- You should see a digital signal as follows:
Fig. 6
- What is the sampling frequency of the system in sample/s as
computed from your oscilloscope trace as illustrated above?
(this is sample rate R1 in your
report)
- If your output looks like the figure above, your circuit is
behaving like a 4-point moving average
filter.
- Plot the output in your report as the "4-point moving average filter", and
you must show both traces as above
- What is the
theoretical impulse response h[n] of a 4-point moving
average filter?
- What is the
theoretical z-transform H(z) of a 4-point moving average
filter?
- What is the
theoretical frequency response H(w) of a 4-point moving
average filter?
- For the sample
rate above, at what frequency in
radians/sample do you expect the first null (see
magenta arrow in picture below, for first null definition)
in the frequency response of a 4-point moving average
filter?
- For the sample
rate above, at what frequency in
Hertz do you expect the first null in the
frequency response of a 4-point moving average filter?
- Change the input frequency of the triangle wave to measure
your predicted null frequency, and do you observe a null
(zero) output? Adjust the frequency to measure the
frequency where the output signal null occurs. (this is null frequency F1 in your report)
- Change the code to perform an 8-point moving average
- Return your signal generator to the
original settings including the input frequency that
was changed
- Compile and load the program
- Press reset and run the program
- Press the "single" button on the oscilloscope to capture a
single trace
- Plot the output in your report as the "8-point moving average filter", and
you must show both traces as above
- What is the
theoretical frequency response H(w) of an 8-point moving
average filter?
- Why is the output signal amplitude smaller?
- For the sample
rate above, at what frequency in
Hertz do you expect the first null in the
frequency response of an 8-point moving average filter?
- Change the input frequency of the triangle wave to measure
your predicted null frequency, and do you observe a null
(zero) output? Adjust the frequency to measure the frequency
where the output signal null occurs. (this is null frequency F2 in your report)
- Visit mbed-src
to see the details of AnalogIn.h and DigitalOut.h and
other items which reside in the mbed library
- Even more instructive to see DigitalOut.h:
- Export your project as a zip archive using right-click the
program folder in mbed, exportProgram, k64fTarget,
toolchainZipArchiveWithRepositories
- Unzip the archive that is downloaded
- Navigate to the mbed folder to inspect all the header
files and definitions within them
- Change the signal
generator to a sine wave function (FUNC
button)
- Vary the input frequency from 5 KHz to 150 KHz in 5 KHz
steps, and plot the measured and
theoretical frequency response in dB,
20*log10(Vout/Vin), using the ratio of the peak-peak voltages
at each frequency, as below:
Fig. 7
- You may use (after fixing the errors in this file) the excel
template p04sincPlotAvgTemplate.xlsx
You must fix the data and theory
in this template file
- Does your measured frequency response match the theoretical
response?
Part 2, Debug, SysTick, MCU Clock Cycle
Count, and Compiler Optimization
- See below for minimum required data
content for your reports and your demos
- In this part, program debugging and disassembly is done on the
FRDMK64F using KDS/KSDK IDE or
improvised Eclipse/Platformio
IDE
- First, ceate and export adcSysTick code as follows:
- Log into your mbed.org
account
- Go to the mbed
compiler view
- Right-click create the following new program,
frdm_adcSysTick_01
- Next: edit the code in the main.cpp frame of the mbed
compiler, as follows
#include "mbed.h"
DigitalOut gpo(D0);
DigitalOut led(LED_RED);
AnalogOut dac0out(DAC0_OUT);
AnalogIn adc0in(A0); //A0 = PTB2
Serial pc(USBTX, USBRX);
int main()
{
volatile uint32_t
div1=0,div2=0,busClk=0,adcClk=0,xx=0;
volatile uint32_t mask16=1<<16;
volatile uint32_t dat1=(PTC->PDOR) |
mask16; //set Port Data Output Register
volatile uint32_t dat0=(PTC->PDOR) &
(!mask16); //clear
volatile uint16_t tpAdc0in=1;
volatile uint32_t clkStart = 0, clkStop =
0, adcClkDiff = 0,gpioClkDiff = 0;
if(1) {
ADC0->SC3 &=
~ADC_SC3_AVGE_MASK;//disable averages
ADC0->CFG1
&= ~ADC_CFG1_ADLPC_MASK;//high-power mode
ADC0->CFG1
&= ~0x0063 ; //clears ADICLK and ADIV
ADC0->CFG1 |=
ADC_CFG1_ADIV(0); //divide clock 0=/1, 1=/2, 2=/4, 3=/8
}
DAC0->C0 = 0; DAC0->C1 = 0; //reset
DAC state
DAC0->C0 = DAC_C0_DACEN_MASK |
DAC_C0_DACSWTRG_MASK| DAC_C0_DACRFS_MASK;
SysTick->LOAD = (uint32_t)
0x00010000; //initialize clock counter
SysTick->CTRL = 0x5;
clkStart = SysTick->VAL;
while (true) {
//example using
write to a single bit, DOarduino=PTC16
(PTC->PDOR)=dat0; //clear
clkStart =
SysTick->VAL;
(PTC->PDOR)=dat1; //set ADD
BREAKPOINT HERE
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat0; //clear
clkStop =
SysTick->VAL;
gpioClkDiff =
clkStart -clkStop;
clkStart =
SysTick->VAL;
tpAdc0in=adc0in.read_u16();
clkStop =
SysTick->VAL;
adcClkDiff =
clkStart -clkStop;
xx=adcClkDiff+gpioClkDiff; // ADD
BREAKPOINT HERE
(PTC->PDOR)=dat0; //clear
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
(PTC->PDOR)=dat1; //set
//wait((float)(0.1e-6));
DAC0->DAT[0].DATL =
(uint8_t)((uint16_t)(tpAdc0in>>4)
& 0xFF);
DAC0->DAT[0].DATH =
(uint8_t)(((uint16_t)(tpAdc0in>>4) >> 8) &
0x0F);
//wait((float)(0.1e-6));
(PTC->PDOR)=dat0; //clear
}
}
- Set the signal generator for an input triangle wave at 40
KHz from 0.5 to 2.5 volts as in Fig. 5 above
- Make sure the signal is between 0 and 3 Volts, to avoid damaging your board!
- Plug in your FRDM-K64F board
- Compile and load the program
- Press reset and run the program
- Press the "single" button on the oscilloscope to capture a
single trace as shown below
- You should see a digital signal as follows:
Fig. 8
- Once this is running in mbed, export it to your debug IDE
- For either debug IDE, first export your project in KDS
format as follows
- The Kinetis format export will be used for both KDS and
improvised Eclipse/Platformio
IDE
- In your mbed window leftmost pane, right-click your
4-point moving average program folder
frdm_adcSysTick_01 (red arrow below) and choose
ExportProgram (red circle below)
Fig. 9
- Set target FRDM-K64F and Toolchain Kinetis Design
Studio (blue circle above)
- Click the exportButton, and
frdm_adcSysTick_01_kds_64f.zip should be downloaded to your
computer
- Next, import the adcSysTick
code into KDS IDE as follows:
- NOTE: if you are using the
improvised Eclipse/Platformio IDE, see
instructions for debug
using the Eclipse/Platformio IDE
- Run Kinetis Design Studio on your computer
- Right-click and close any open projects
- Import your mbed project using MenuBar::File::Import
(red arrow below)
- in popup1 choose general::existingProjectIntoWorkspace and
click next (blue arrow below),
- and in popup2 push selectArchiveButton (yellow circle
below)
- Browse to your
frdm_adcSysTick_01_kds_k64f.zip file
(yellow circle below) that was exported above, and
click finish
Fig. 10
- Open the
frdm_adcSysTick_01 folder, and double-click main.cpp to open
it
- If all goes well, you should see the following
Fig. 11
- Make sure that this code is your
4-point moving average code
- Plug in your FRDM-K64F board
- After importing, and before doing
anything else, clean the debug and release
configurations as follows, and in this order:
- In KDS, run MenuBar::Project::clean
- In KDS, run MenuBar::Project::clean again (running clean
twice can often force build on second pass of clean)
- Run
MenuBar::Project::BuildConfigurations::SetActive::Release
(blue arrows and green circle below)
- In KDS, run MenuBar::Project::clean (yellow circles
below)
- In KDS, run MenuBar::Project::clean again (running clean
twice can often force build on second pass of clean)
- In KDS, right-click the project folder in the left pane and
select BuildProject
- If you run into problems, check the following possible
solutions (one step at a time)
- You may perhaps need to update a linker flag depending on
the version of tools installed. Make the change in : C++
Build -> Settings -> Tool Settings
- For KDS >= 3.0, you might perhaps need to add linker
flag -specs=nosys.specs
- and possibly may need to change any file extension that
is .s to .S (lowercase to uppercase)
- Run MenuBar::Project::BuildConfigurations::SetActive::Debug
(blue arrows and green circle below)
- In KDS, run MenuBar::Project::clean
- In KDS, run MenuBar::Project::clean again (running clean
twice can often force build on second pass of clean)
- In KDS, right-click the project folder in the left pane and
select BuildProject
- Once you have done theses steps, you should observe the
creation of the creation of new directories "Debug" and
"Release" as shown in the two red rectangles below
Fig. 12
- On a
Mac-Yosemite-pyOCD KDS setup, in KDS, create your debug configuration:
MenuBar::Run::debugConfiguration and double-clcik
GDBhardwareDebugging
- WARNING: On a PC-based setup, in
KDS, the following steps may vary
and most likely you must create your debug
configuration differently:
MenuBar::Run::debugConfiguration and double-clcik
GDBopenOcdDebugging. See further
details on other setup differences on PC and Linux
KDS Freescale instructions in Section 1.2 and Section 2.5 of
Kinetis
Design Studio V3.0.0- User's Guide
- WARNING: for
platformio-based debug, see the platformio debug
instructions
- a) On Mac-Yosemite use MenuBar::Run::debugConfiguration
and double-clcik GDBhardwareDebugging, and in MainTab:
- C/C++Application, click searchProjectButton and browse
to select your firmware.elf location, such as
Debug/rdm_mvgAvgFil_01.elf
- BuildConfig selectBuildConfigurationUseActive
and select EnableAutoBuildButton
- click applyButton
- b) in debuggerTab,
- check "use remote target"
- Set Jtag GenericTcpIp localhost:3333 (same port
as printed from pyocd-gdbserver)
- Use the full ARM GDBCommand
- instead of just "gdb:" in the GDBcommand area,
replace it with "arm-none-eabi-gdb"
- click applyButton
- c) in startupTab
- uncheck initilizationCommandResetDelay
- uncheck initilizationCommandHalt
- check LoadImage and loadSymbols
- check useProjectBinary
- check runtimeOptionSetBreakpointAt and enter "setup"
in the box
- check runtimeOptionsResume
- click applyButton
- d) in commonTab
- check saveAsSharedFile
- check displayFavoritesDebug
- check allocateConsole
- check launchInBackGround
- click applyButton
- click closeButton
- In KDS, add 2 breakpoints to main.cpp
- open main.cpp and add 2 breakpoints at the ADD BREAKPOINT HERE lines denoted
above
- Add breakpoints by double-clicking in the bar to the left
of the 2 lines in main.cpp (little buttons will appear to
indicate the breakpoints)
- On a PC/linux, you might be
abe to skip the next 2 pyocd server steps
- in a command terminal test your pyocd by running the
command: pyocd-gdbserver -l
- Then run the pyocd sever by using the command:
pyocd-gdbserver
- Next, in KDS, run MenuBar::Project::clean
- In KDS, run MenuBar::Project::clean again (running
clean twice can often force build on second pass of clean) as
follows. Note the options to rebuild immediately at blue
arrows below.
Fig. 13
- Run MenuBar::Project::BuildConfigurations::SetActive::Debug
- In KDS, run MenuBar::Project::clean
- In KDS, run MenuBar::Project::clean again (running clean
twice can often force build on second pass of clean)
- In KDS, right-click the project folder in the left pane and
select BuildProject
- Right-click your project folder in the left-most pane of KDS
design studio, and select buildProject
- Or, build the by clicking the drop-down arrow to the right
of the hammer-button in the menuBar, and selecting "Debug"
- Make sure there are no problems reported in the
problemPane at the bottom of KDS
- The console should show a successful build of
frdm_adcSysTick_01.elf and
frdm_adcSysTick_01.bin, as below
Fig. 14
- Make sure your pyOCD server is still running in the
terminal, ...if not, then run the pyocd sever by using the
command: pyocd-gdbserver
- Run debug in the main KDS window,
- by clicking the drop-down arrow of the debug icon and run
frdm_adcSysTick_01 Debug,
- or MenuBar::Run::DebugConfigurations
- the green LED should flicker as it uploads to the
FRDM-K64F
- And a popup should appear asking to confirm switch to
debug perspective, and click OK, as below
Fig. 15
- Note: if you get "Problem Occurred:
Program file does not exist"
- Your debug elf was probably not found
- Use MenuBar::Run::debugConfiguration and double-clcik
GDBhardwareDebugging, and in MainTab:C/C++Application,
click searchProjectButton and browse to select your
firmware.elf location, such as
Debug/frdm_adcSysTick_01.elf
- Note: if you get “problem occurred”
details: localhost3333 timeout, go back to the terminal and
make sure pyocd-gdbserver ran on port 3333
- On some Apple/Mac setups, some programs may require
communication through a terminal (such as a printf()
statement in a program)
- For future reference, if a terminal is needed for
input/output (it is not needed now) on an Apple/Mac, open
a new command termina an run the command:
- Click the main.cpp tab (blue circle below) to see the source
code
- Click the resume button (red circle below) to proceed to the
next breakpoint
- The green highlights in main.cpp and disassembly (blue
arrows below) show the program stopped at the breakpoint
- The "00006a6" hexadecimal in disassembly is the program
counter, and "ldr r0, [pc, #32]" is the assembly language
instruction
- How many lines of assembly language code are required for
each "(PTC->PDOR)=dat1;" line in C++? (this is the number of lines assembly code per GPIO
write L1 in your report)
- Click resumeButton again, and watch the program proceed to
the next breakpoint, "00005b4" in disassembly
- You can also view generic registers (green circle below) and
variables (purple circle below)
- Next use skipAllBreakptsButton (yellow arrow below) and
resumeButton
- Execution will be uninterrupted until you press the
suspendButton (green arrow below)
- After halting, click on the register tab (green circle
below), and scroll down until you see the"pc" the program
counter and see that it agrees with the disassembly window
Fig. 16
- Continue exploring the debug interface
- Press the reset button on the FRDM-K64F to run the program
- Move the osciloscope probe channel 1 from the signal
generator to the D0 GPIO line on the Arduino header pin D0
(PTC16)
- Press the "single" button on the oscilloscope to capture a
single trace as shown below
- You should see a digital signal as follows:
Fig. 17
- Measure the time for the ADC conversion (region between the
arrows) (this is oscilloscope
measured ADC conversion time T1 in your rport)
- Halt the program,
- Reload the program, and rerun to the breakpoints
- Copy and paste a full disassembly of two
"(PTC->PDOR)=dat1;"lines for your report as follows:
Fig. 18
- Continue stepping through breakpoints several times until
you complete a few loop cycles
- Open the variables, and note the values of variables
adcClkDiff and gpioClkDiff
- Open the variables in debug
- Convert the hexadecimal value of adcClkDiff to decimal, and this is ADC decimal clock count C1
in your report
- Convert the hexadecimal value of gpioClkDiff to decimal,
and this is GPIO decimal clock count
C2 in your report
- At 120 MHz MCU clock, what is the ADC
conversion time T2 based on clcok count C1
- Click TerminateButton (yellow circle above) to terminate
- Finally, adjust optimization of the compiler to observe the
change in the assembly language code
- Right-click your project (yellow circle below) and select
Properties (red arrow below)
- In the popup, select C++Settings::ToolSettings::Optimization
(red circles below)
- Under OptimizationLevel, select Optimize-level "01" (blue
circle below)
Fig. 19
- Click OK
- Rebuild your project
- Load and run it
- Again, observe the disassembly and paste a full disassembly
of two "(PTC->PDOR)=dat1;"lines for your report as follows:
Fig. 20
- Has the compiler optimiztion reduced the number of lines of
assembly language code?
- Will the code run faster with this optimization?
Report Data
- Minimum required data content for
your report and demos
- Required theory content:
- For the 8-point moving average filter, provide:
- the impulse response h(n),
- the z-transform H(z),
- and the frequency response H(w).
- Required software code excerpt content:
- Main.cpp code to do the 8-point average (only the most
important lines, approx 6 lines of code)
- Required tabular data content:
- The values for:
- Measured System default sample
rate R1 in samples/second as defined above
- Measured 4-point mvg-avg
null frequency F1 in Hz
- Measured 8-point mvg-avg null
frequency F2 in Hz
- Measured ADC decimal clock
count C1
- Measured GPIO decimal clock count
C2
- Measured oscilloscope ADC
conversion time T1
- Measured ADC conversion time T2
- The "number of lines assembly
code per GPIO write" L1
- Required pictures/photos content:
- Legible picture (if pdf of your report is
"zoomed/magnified") showing ADC input and DAC output
voltages for "4-point moving
average filter" similar to Fig. 6
above
- Legible picture (if pdf of your report is
"zoomed/magnified") showing ADC input and DAC output
voltages for "8-point moving
average filter" similar to Fig. 6
above
- Legible picture (if pdf of your report is
"zoomed/magnified") showing "8-point moving average filter
frequency response" similar to Fig. 7 above
- Legible picture (if pdf of your report is
"zoomed/magnified") showing assembly language
code for two "(PTC->PDOR)=dat1;" lines similar to Fig. 18
above
- Legible picture (if pdf of your report is
"zoomed/magnified") showing "compiler O1-optimized" assembly
language code for two "(PTC->PDOR)=dat1;" lines similar
to Fig. 20 above
- Project Demos
- Be prepared to demonstrate and discuss items such as:
- Demonstrate triangle wave for 4-point and 8-point moving
average filter as Fig. 6 and 7
- Change the clocks
- Change averaging
- Change compiler optimization
- Demonstrate timing such as Fig. 17
- Set breakpoints
- Start and stop the debugger
- Find variables and registers
- Demonstrate a full clean/build
- Be prepared to answer questions such as:
- What is impulse response of the filters?
- What is frequency response of the filters?
- What is z-transform of the filters?
- What is dc response of the filters?
- What port number is ADC (PT???)
- What port number is DAC(PT???)
- What is ADC0->CFG1?
- What is ADC0->SC3?
- What is the base address of ADC0?
- Will the code run faster with optimization?
- Will the code be smaller with optimization?
Report:
- See above project description for required
report data content.
- NOTE Report Template Use the Project Report Template
( embDspProjTemplate.docx) for your report.
- One pdf-format must be emailed to the instructor at the
beginning of the class meeting of the demo.
- One hardcopy per student, plus
one extra hardcopy for the instructor, should be brought to
class for the demo.
- Do not add extraneous pages or put explanations on separate
pages unless specifically directed to do so. The instructor will
not read extraneous pages!
- YOU MUST ADD CAPTIONS AND FIGURE NUMBERS TO ALL FIGURES!!
Copyright 2015 T. Weldon
Freescale, Kinetis are registered trademarks of Freescale
Semiconductor, Inc. Texas Instruments, TI, C2000, and
Code Composer Studio are a registered trademarks of Texas
Instruments Incorporated. Adafruit is a registered
TradeMark of Limor Fried. ARM, Cortex and Keil are
registered trademarks of ARM Limited (or its subsidiaries).
Apple, Yosemite, Mac OS, iPhone, iPad, MacBook, Mac, iTunes, and
Xcode are trademarks of Apple inc. All other product or service
names are the property of their respective owners. Arduino
is a registered trademark of Arduino.