Introduction to Test Driven Development (To be used throughout the course)

1. Introduction to Test Driven Development(To be used throughout the course) Building tests and code for a“software radio”

2. Concepts • 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 • Tests for float array rectification (C++ compiler) • Tests for rectification in assembly code • More details of test driven development Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

3. Conventional “AM” radio RF STAGE Antenna Pickup AUDIO STAGE Low passFilter+ amplifier Low passFilter Rectifier Mixer LocalOscillator IF STAGE Audio out Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

5. Software “AM” radio concept RF STAGE Antenna Pickup AUDIO STAGE Low passFilter+ amplifier Low passFilter Rectifier Mixer LocalOscillator IF STAGE Audio out Most stages handled with high speed software Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

6. Software “FM” radio concept RF STAGE AUDIO STAGE Antenna Pickup Low passFilter+ amplifier What everis needed Rectifier Audio out Most stages handled with high speed software Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

8. A basic example for the coding practices adopted through the term Going to use the rectification stage of this “soft-radio” 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. Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

9. Customer Requirements • Wants to get “product out of the door” as fast as possible • Less time spend on development the better, but it has to work • Developing in C++ is easier than developing in assembler code, but is it fast enough • 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 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

11. Standard testing practice • Heavy on documentation TLD TestLastDevelopment Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

13. 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 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

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

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

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

18. Floating point version of the TestsEssentially a cut-and-paste version of integer code Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

19. Stage 1 – Compile / Link the tests • Obviously the Link is not going to work – as the code for functions HalfWaveRectifyXXX( ) have not been written • If obviously going to fail – WB (why bother)? • Basically – You are TESTING THE TESTS • 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, M. Smith, ECE, University of Calgary, Canada

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

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

22. Problems uncovered • 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? • Explain later – compiler option which you will use during Assignment 1 • Just how do you write an assembly code stub? Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

23. Write assembly code using a couple of techniques • Use knowledge of what you need to do from other assembly code functions • 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” • Cheat -- use mixed mode in IDDE • Compile and link a “C++” function with the same name (in debug mode). • Load the code into the processor • Bring up the source code window, right click and select MIXED MODE Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

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

26. Fix the code for CHAR32, and run the tests • We lost control of the processors in the debug environment. Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

27. Why did we lose control? • IDDE environment uses a “boundary scan” approach to debug (another lecture) • That’s the ICE interface discussed in Tuesday’s class • It is possible to get the IDDE environment (on the PC) out of sync with the processors (on the evaluation board). • 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 Concepts of TDD, M. Smith, ECE, University of Calgary, Canada

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

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

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

31. Concepts covered • 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 • Tests for float array rectification (C++ compiler) • Tests for rectification in assembly code • More details of test driven development Concepts of TDD, M. Smith, ECE, University of Calgary, Canada