ECE 362 Lab Verification / Evaluation Form Experiment 5

Transcription

1 ECE 362 Lab Verification / Evaluation Form Experiment 5 Evaluation: IMPORTANT! You must complete this experiment during your scheduled lab perior. All work for this experiment must be demonstrated and verified by your lab instructor before the end of your scheduled lab period. STEP DESCRIPTION MAX SCORE 4.0 Prelab Questions Turning on an LED A Level-Based Light Button A Simple LED Toggler An Embedded Reaction Timer 10 TOTAL 25 Signature of Evaluator: Student Name: Class #: - Signature: Date: Page 1 of 7

2 Experiment 5: Fundamentals of Embedded C 1.0 Introduction The initial portion of the semester has focused on developing microcontroller firmware in assembly. This is valuable as a learning exercise, and helps students to gain a greater understanding of what takes place under the hood of the microcontroller and compiler. In industry and in practice, however, embedded firmware is written in higher-level languages, such as C or C++. In this experiment, students will learn basics of writing embedded firmware using higher-level languages, and how the various constructs used in the assembly-based labs translate over into C. 2.0 Objectives 1. To understand fundamental programming techniques in C 2. To be able to translate between a piece of firmware written in assembly and one written in C 3.0 Equipment and Software 1. Standard ECE362 Software Toolchain (Installation instructions available in Experiment 0: Getting Started) 2. STM32F0-DISCOVERY development board (For procurement instructions, see Experiment 0: Getting Started) 4.0 Prelab 4.1 Read section 5 of this document for background information 4.2 Describe in logical operators (AND, OR, NOT, etc.) the process of setting individual bits in a register (without affecting other bits). 4.3 Describe in logical operators (AND, OR, NOT, etc.) the process of clearing individual bits in a register (without affecting other bits). 4.4 Describe in logical operators (AND, OR, NOT, etc.) the process of toggling individual bits in a register (without affecting other bits). 4.5 Describe the purpose of the extern keyword in C 5.0 Background 5.1 Unions and Structures One of the most important aspects of firmware is the ability to access the various system registers used by the microcontroller for configuring the array of peripherals which it provides. For example, one might wish to enable the system clock to the GPIOC peripheral, as a step in allowing programmatic Page 2 of 7

3 control of the system LEDs. In assembly language, the code to perform that operation might look something like this:.equ RCC, 0x equ AHBENR, 0x14 gpioconfig: #Activate GPIOC Clock in RCC Configuration ldr r5, =RCC ldr r6, =AHBENR ldr r0, [r5, r6] ldr r1, =0x orrs r0, r0, r1 str r0, [r5, r6] Fig. 1. Register Access (Assembly) Among the great advantages of C in comparison with Assembly are portability and convenience for improved programmer productivity. Having to know the exact memory locations of the various system registers needed to configure peripherals is a considerable roadblock to effective programming, and as the register locations may change from processor to processor, code written for one device may have to be rewritten to support a different device. To address these issues, device manufacturers such as STMicroelectronics provide peripheral libraries and header files which define items such as system registers in pre-made unions and structures for ease of use by the end programmer. With such library files included in one's code, a C code snippet for performing the same access as that of figure 1 might resemble the following: 5.2 Bit Manipulation in C RCC->AHBENR = 0x ; Fig 2. Register Access (C) Often times, instances will arise in which the values of individual bits in a register must be manipulated, without changing the values of the other bits in the register. C provides several bitwise operators for these purposes Setting Individual Bits Consider the scenario in which you wish to set a bit or bits without altering other bits. This can be done through the use of the bitwise OR ( ) operator: /* Set those bits in register which are equal to '1' in the * bitmask */ Register = Register Bitmask; Page 3 of 7

4 5.2.2 Clearing Individual Bits Register = Bitmask; Next, consider the scenario in which you wish to clear a bit or bits without altering other bits. This can be done through the use of the bitwise AND ( & ) operator: /* Clear those bits in the register which are equal to '0' * in the bitmask */ Register = Register & Bitmask; Register &= Bitmask; Performing a bitmask in this way can be counterintuitive. For clarity of code, it is often preferable to set the positions to be cleared with a '1', negating the bitmask, and then using that in the bitwise AND. C provides the bitwise NOT ( ~ ), or negation operator for this purpose: Thus, /* Define a bitmask */ Bitmask = b ; Bitmask2 = ~(Bitmask); /* Bitmask2 == b */ /* Clear those bits in the register which are equal to '1' * in the bitmask */ Register = Register & ~(Bitmask); Register &= ~(Bitmask); Toggling Individual Bits On other occasions, it may be desirable to 'toggle' individual bits (that is to say, clear bits which are read as '1' and set those which are read as '0'). An example of when such a function might be used is in creating a light blinker, where the present state of a bit (such as one corresponding to a digital output state) is not necessarily known. This can be done through use of the bitwise XOR ( ^ ) operator: /* Toggle those bits in the register which are equal to '1' * in the bitmask */ Register = Register ^ Bitmask; Page 4 of 7

5 Register ^= Bitmask; 5.3 Interrupts in C In experiment 4, students created interrupt service routines in assembly. This was done by defining a global label for the ISR which corresponds to its entry within the vector table. Next, students would redefine the weak vector table mapping to the default handler, directing the mapping instead to the ISR which they had created. In C, this process can be made considerably simpler. After initializations, the timer 2 interrupt service routine resembles the following: extern void TIM2_IRQHandler() { //Timer 2 ISR code goes here } Note the use of the extern compiler keyword. This informs the compiler that the function TIM2_IRQHandler is defined outside of the current file (in this case, TIM2_IRQHandler is defined in the device startup assembly file, alongside all of the other interrupt service routine names defined in the vector table). In using interrupts in C for the STM32F0, be sure to utilize the ISR names defined in the startup assembly file vector table. 5.4 Header Guards The assembly firmware written in the course up to this point has been fairly simple, with the majority of the code written in a single, large assembly file. With the advent of C, however, programs will become substantially more complex, and code will be spread across multiple files. C makes this simple and straightforward, through the use of header files and the #include directive. A minor wrinkle arises, however, with issues of inclusion. Suppose we have a simple include file, include.h, which defines a simple C struct, as shown: File include.h : struct foo { int member; }; In C and other high-level languages, it is possible to nest files hierarchically. Thus, imagine the project includes a second header file, include2.h, which references include.h : File include2.h : #include "include.h" Finally, both include files are referenced within the C code of the project: File main.c : #include "include.h" #include "include2.h" Page 5 of 7

6 In this situation, known as double inclusion, the file main.c has indirectly included two copies of the header file include.h, resulting in two identical definitions of the structure type foo. This is a violation of fundamental C principles, and will result in a compiler error. The solution to inclusion issues such as double inclusion is the usage of what are referred to as header guards. Revisiting the file include.h, suppose we define the file conditionally, as follows: File include.h (revised): #ifndef INCLUDE_H #define INCLUDE_H struct foo { int member; }; #endif The compiler directive #ifndef is a conditional directive, read as if not defined. In this case, the compiler looks to see if a given macro (INCLUDE_H, in the above example) has been defined. If not, then all of the code between #ifndef and #endif is included into the compiled C code. The next line immediately below the definition test defines the macro in question. In this way, the first instance of include.h will define the macro in question and include all of the relevant source code. For any future attempts to include the same code within a given C project, however, the definition test will fail (INCLUDE_H is already defined), and the code in question will be skipped. 6.0 Experiment For this experiment, students will be recreating code examples from experiments 3 and 4, using C instead of assembly. Note that when writing C code, use of hardware abstraction layer (HAL) functions is prohibited and code examples using HAL functions will not receive credit for demonstration; students may and are encouraged to use the unions and structures provided in STM header files, as per figure 2 of this document. 6.1 Turning on an LED Recreate in C the assembly code snippet of problem 6.1 of experiment 3. For a reminder, the code Description: Write a piece of code which configures the microcontroller pin corresponding to LD4 (blue LED) on the STM32F0 discovery board as a standard digital output. Once configured, output a logic 1 on this pin, lighting up the blue LED. 6.2 A Level-Based Light Button Recreate in C the assembly code snippet of problem 6.3 of experiment 3. For a reminder, the Page 6 of 7

7 Description: Write a piece of code which configures the microcontroller pins for B1 (blue button) as a standard digital input, and LD3 and LD4 (the blue and green LEDs) as standard digital outputs. Once done, your code segment should activate the blue LED when button B1 is not pressed (green LED should not be lit). When button B1 is pressed, the blue LED should be turned off and the green LED should be turned on. 6.3 A Simple LED Toggler Recreate in C the assembly code snippet of problem 6.3 of experiment 4. For a reminder, the Description: With user LED LD3 initially off, create a program which toggles LD3 upon pressing user pushbutton B1 (push once to turn it on, again to turn it off, and so on). The timer 2 update interrupt should fire every 5ms, and the code should perform proper button debouncing. 6.4 An Embedded Reaction Timer Recreate in C the assembly code snippet of problem 6.4 of experiment 4. For a reminder, the Description: Create a simple reaction timer. The timer is started when the user presses user pushbutton B1. It then counts out 5 seconds. At the end of 5 seconds, the program should light user LED LD4. During the running of the program, the program should track presses of button B1. If the user presses button B1 within half a second of the 5 second goal (4.5s 5.5s), the program should light user LED LD3. Should the user press the button too early or too late, or if 10 seconds has passed, the program should perform 2 subsequent 1-second flashes of user LED LD3, then turn the LED off. Once a victory or loss has occurred, a subsequent press of B1 should reset the reaction timer and allow the user to play again. 7.0 Sources Cited [1] Wikipedia. Include Guard. [Online] Available: Page 7 of 7