Introduction to Test Driven Development To be used

Introduction to Test Driven Development (To be used throughout the course) Building tests and code for a “software radio” Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

Concepts n n n Stages in a conventional radio Stages in a software radio Goals for the “long term” project Concept of test driven development Digital rectification Tests for integer array rectification n Tests for float array rectification (C++ compiler) n Tests for rectification in assembly code n n More details of test driven development 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 2

Conventional “AM” radio RF STAGE Antenna Pickup AUDIO STAGE Mixer Low pass Filter Rectifier Low pass Filter + amplifier Local Oscillator IF STAGE 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada Audio out M. 3

Review of AM radio operation Analog Version n Incoming signal @ frequency 1010 k. Hz n IF-STAGE Local (tunable) oscillator @ 660 k. Hz n Mixed with incoming signal (multiplication) n Get sum and difference frequencies 350 k. Hz and 1670 k. Hz n Low pass filter to get constant frequency for remainder of audio date at 350 k. Hz n AUDIO STAGE n Rectify signal to get AM modulation n Rectification means that you spread the signal over a wide band of frequencies n Low pass filter to get required audio range 50 Hz to 7 k. Hz n 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 4

Software “AM” radio concept RF STAGE Antenna Pickup AUDIO STAGE Mixer Low pass Filter Rectifier Low pass Filter + amplifier Local Oscillator IF STAGE Audio out Most stages handled with high speed software 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 5

Software “FM” radio concept RF STAGE Antenna Pickup AUDIO STAGE What ever is needed Rectifier Low pass Filter + amplifier Audio out Most stages handled with high speed software 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 6

Real “software” radio n Looking at RF stage to bring in wireless signal n Software radio is the rest of it n Update communication protocols n Change noise suppression characteristics “on the fly” n Etc. n Dr. Gannouchi is doing research in this area n Joint M. Sc. student Andrew Kwan n Excellent topic for pair presentation (12 minute talk – 14 slides max – at the end of term). Exact details to be given later. 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 7

A basic example for the coding practices adopted through the term Going to use the rectification stage of this “softradio” as a “code example” all through the course. We may also look at “single-side band modulation” (involves IIR filtering) as a second “code example” followed all though the term. 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 8

Customer Requirements n Wants to get “product out of the door” as fast as possible n Less time spend on development the better, but it has to work n Developing in C++ is easier than developing in assembler code, but is it fast enough n Risk analysis – take one representative part of the code and explain the differences between the speeds from C++ code (Debug and Release Mode) and assembly code 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 9

Expected relative advantages n Compiler debug mode n Slow but easy to understand the code flow when doing “very low level debug at assembly level” (A real NO-NO) n Compiler release (optimized) mode n Faster than debug mode n Optimized, possibly out of order instructions, difficult to follow n “US” – assembly mode n Probably faster than compiler debug n Gain skills needed to handle optimized assembly n “US” – optimized assembly mode n Time consuming; use only after profiling the compiler code n Faster than compiler when “we” understand the special situations that arise n Probably based on “trying assembly code” to see where the issues are, then “optimizing the output from the release compiler version” 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 10

Standard testing practice n Heavy on documentation TLD Test Last Development 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 11

Test Driven Development n Requires “automated testing framework” n High Level customer tests for embedded systems – personally find these hard to do. This example is “an exception” because we have “really knowledgeable” customer. n Done in consultation with customer. Even better if customer writes the tests. n Doing research into developing a process for this. n Read paper handed out n Developer Tests for embedded systems – E-TDD n n 12/18/2021 Have found many advantages – research and teaching Being used by local firm Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 12

Test Driven Development Work with customer to check that the tests properly express what the customer wants done. Iterative process with customer “heavily involved” – “Agile” methodology. CUSTOMER DEVELOPER 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 13

Lets apply TDD to rectification issue Overall technique n Decide on a particular test action with the customer n Write the test(s) n Write the simplest possible code to satisfy the test(s) n “Refactor” the code to improve “quality” n Definition of “quality” is unclear in the literature n Ease of “use” or “reuse” of code n Reliable to use – “robust” n My additional idea – meets speed requirements for the embedded situation n See paper handed out for more details 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 14

Express Customer Requirements as tests using E-TDD Tests 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 15

Now expand the Customer Tests to do what the customer has requested 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 16

Note that writing the tests has automatically generated the function interface information n Why int* and float* rather than just void as you are passing in the address of the output n 12/18/2021 Design decision – sort of standard with “C” to pass back a pointer to thing being changed Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 17

Floating point version of the Tests Essentially a cut-and-paste version of integer code 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 18

Stage 1 – Compile / Link the tests n Obviously the Link is not going to work – as the code for functions Half. Wave. Rectify. XXX( ) have not been written n If obviously going to fail – WB (why bother)? n Basically – You are TESTING THE TESTS n n 12/18/2021 Are you calling the functions you expect to call. Better handled by doing Code Review first, and then use compiler / linker to CHECK the Code Review did not miss something (PSP – personal software process). C++ can overload function names (done via name mangling). What are the name-mangled names needed for the assembly code? – This stage will show you. Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 19

Name mangled names can be seen from linker C++ name as used in C++ code 12/18/2021 The name mangled name generated by by the C++ compiler in response to function overloading. These are the “assembly code” names Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 20

Next step: Write just enough code to satisfy the linker – C++ stubs 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 21

Problems uncovered n The following unanswered question has been raised when developing the C++ code How does the processor know how to run a function in debug mode or in release mode? n Explain later – compiler option which you will use during Assignment 1 n n Just how do you write an assembly code stub? 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 22

Write assembly code using a couple of techniques n Use knowledge of what you need to do from other assembly code functions n n n Need to specify section of memory where the code will be placed Need to specify name of function (linker told us that) Need to do a “return to “C” n Cheat -- use mixed mode in IDDE n Compile and link a “C++” function with the same name (in debug mode). n Load the code into the processor n Bring up the source code window, right click and select MIXED MODE 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 23

Assembly code stubs assemble (compile) but generate 200 linker error messages 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 24

Understanding the error messages n Tiger. SHARC is a high speed processor designed for “ 32 -bit” operation n 68 K designed for 8 -bit and 16 -bit. Can do 32 -bit but much slower n Blackfin designed for 16 -bit and 32 -bit. Can do 8 -bit but slower. n Strings are normally handled as 8 -bit characters n Tiger. SHARC has two character modes n CHAR 8 bit – like normal “C++” string, minimizes space usage, but slow. n CHAR 32 bit – Maximizes speed, but storage area is larger n C++ compiler (debug mode) normally generates CHAR 32 type of strings – so we must do that in our assembly code. 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 25

Fix the code for CHAR 32, and run the tests n We lost control of the processors in the debug environment. 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 26

Why did we lose control? n IDDE environment uses a “boundary scan” approach to debug (another lecture) n That’s the ICE interface discussed in Tuesday’s class n It is possible to get the IDDE environment (on the PC) out of sync with the processors (on the evaluation board). n I find this happens when I generate poor code, or when I spent a lot of time coding before down loading anything to the board 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 27

Recovery process n n n Don’t lose control – write good code Do incremental builds so you are continually writing and testing code n E-TDD encourages this – write a test, then write just enough code to satisfy the tests If you lose control n Try selecting each processor (DSPA then DSPB) in processor window. Then select DEBUG | HALT n If that fails, then in this order (easier restart process) 1. 2. 3. 4. 5. 12/18/2021 Exit from E-TDD GUI, Exit from Visual. DSP IDDE Power down the board Walk-around your chair twice (or count to 10) Power up board, then reactivate Visual. DSP IDDE and the GUI Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 28

We “accidentally” pass some tests without writing any code 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 29

With the GUI running, we can just “click” on failed test to see details 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 30

Concepts covered n n n Stages in a conventional radio Stages in a software radio Goals for the “long term” project Concept of test driven development Digital rectification Tests for integer array rectification n Tests for float array rectification (C++ compiler) n Tests for rectification in assembly code n n More details of test driven development 12/18/2021 Concepts of TDD, Smith, ECE, University of Calgary, Canada M. 31