*HWWLQJVWDUWHGZLWKWKH,$5 (PEHGGHG:RUNEHQFK $QGWKH,$5&FRPSLOHUIRU$WPHO$95ŠGHYLFHV

Transcription

1 ,$5$SSOLFDWLRQ1RWH$95 *HWWLQJVWDUWHGZLWKWKH,$5 (PEHGGHG:RUNEHQFK $QGWKH,$5&FRPSLOHUIRU$WPHO$95ŠGHYLFHV 6800$5< This application note provides new users with an introduction to the Embedded Workbench programming environment and shows how the C compiler ICCA90, can be used to develop programs for the Atmel AVR range of microcontrollers. The note provides software screenshots and comprehensive details for a complete application..(<:25'6 :KHUHGR,VWDUW" The Engineer, faced with an embedded application to design, invariably asks this question. When the development environment is new as well it becomes doubly difficult. If the target processor is also new the effort involved can be excessive. This application note takes you on a guided tour of a simple application, from start to finish, in an attempt to relieve the burden. :KDWDUHWKHSUREOHPV" The development of an embedded application goes through a series of phases, each presenting the Engineer with a problem to solve: What is the specification? Which Processor should I use? How should I program it? How do I design the hardware? How do I develop and test the firmware and software? 7KH6ROXWLRQ The specification is set by the requirements of the project. However it is common to modify this as the project progresses, to take advantage of the facilities of the target processor being used. Very often an Engineer will spot an improvement in specification, as the design progresses, which will enhance the product, at little or no extra cost. It is thus important that a development system is used that allows modular development, easy software maintenance and simple target modifications. The first three problems are solved in one, welcome to the Atmel AVR and the IAR Embedded Workbench. 1

2 The combination of a fast, FLASH programmable range of Atmel AVR microcontrollers, and the comprehensive set of powerful development tools provided by IAR Embedded Workbench is very difficult to beat in the 8-bit world. The starting point for this application note is how to set the system up ready for compilation. Setting up the Embedded Workbench The Embedded Workbench contains a comprehensive set of development tools for most micro-based systems. The system employs a PROJECT based environment, in line with the way large programs are usually developed. Those of you that have used Integrated Development Environments (IDE s) software before, such as Visual BASIC or C++, will be familiar with this approach. A project is opened and files added to the project as the software is developed. This allows large projects to be handled on a modular basis, and teams of Engineers to be employed to speed up development. Most software projects would also have at least two versions, one for DEBUG purposes, with extra code to enable you to see what is happening, and one for the final RELEASE. The Embedded Workbench automatically sets up two such folders for you, although you can create your own, and provides a project window in which the file tree is displayed. Files that are common to both are here automatically shared in a COMMON SOURCES folder if you do not create your own groups. The compiler converts the source code for each file into relocatable object code. The executable code is then built by the linker, using a linker command file (which you can and often should edit). The linker combines all the files and tells the system where the resulting code should be placed in memory, with the start-up code automatically added for low level initialization (which you can also edit). It is thus very important that the files that control the build process are accurate, and reflect the memory configuration of the target processor used. The Embedded Workbench is supplied with many files already tailored to popular devices to get you started. This note employs the supplied files, a header file io2313.h, and other files associated with the tiny memory model, to support the 20-pin classic AVR, AT90S2313. Details of how to edit the files to suit other target processors can be found in other application notes on the Atmel Website (Try AVR032) The procedure is as follows:- STEP 1 - CREATE A PROJECT. Select File-New-Project- Create. Type a Project Filename and press Enter. A project window will now open showing a Debug target, this can be changed to Release when you are ready. 2

3 The project can now have files added to it ready for compilation and linking. In this example the project is called 'select'. STEP 2 - OPEN A SOURCE FILE Select File-New-Source-OK A source editor window, titled untitled1, will open ready for the program to be entered. Save this now using file-save as and change the name to select.c: The editor is a powerful editor displaying text in varying colors and styles according to the nature of the text. e.g. C keywords are in Bold text, preprocessor directives (#) are in green italics and comments in blue italics. Indents are automatically remembered and the Enter key returns the cursor to the next line under the previous indent. This allows the program to be easily entered, read and followed. These options can be changed to suit your own style preferences. 3

4 The screenshot shows the sample program 'select.c' typed in, with formatting and text colors in the default settings. Note how the first few lines are a title block to contain the important tracking information for the program. The style of commenting adopted here is the C++ // version where it suits and the traditional C method of /* comment */ for the title block, where it is more convenient. Embedded Workbench allows you to mix this more modern method, with the traditional method, by ticking a check box in the options menu. How to do this is described later in this note. This application has been carefully thought out to provide many examples of how C can be applied to microcontroller applications. The methods used may be a little excessive for such a small application but it does illustrate many useful techniques for adoption in larger examples, such as passing and returning values in functions and arrays. The file 'select' is available for download from select.c to save you typing. STEP 3 - SAVE THE SOURCE FILE Select File - Save as - <filename> - OK Ensure that the filename extension is.c! (It is very easy to modify this by mistake.) If the colors of your text suddenly disappear then this might the cause. Resave the file with the.c extension to resolve this. STEP 4 - ASSIGN THE SOURCE FILE TO THE PROJECT The source file you have just created (or loaded in) should be allocated to the project. This must be done before any compilation or building can be achieved. Select the project window by clicking in it to make it active. Select project - files, a window will open containing a list of all the C files in your current directory. Click on the file required, in this case select.c, and select the add box. Your file will appear in the files in group window, so that you know exactly which files you are building and linking. The project window will change to show a common sources folder attached to the Debug folder as shown below. Clicking the plus sign will expand the file tree to show your source files. 4

5 The project window always gives you an up-to-date picture of your build state, showing all the files linked with your project. As the build progresses you will see this file tree expand to show all your library files, include files and any other C source files you add. If the file tree gets out of hand minimize the folders (by clicking the - sign) that you are not interested in. Keep the Debug folder active, for now is the time to configure the system for the correct build. STEP 5 - CHOOSE THE TARGET AND SET UP PROJECT BUILD OPTIONS The correct memory model and processor option for your chosen target processor must now be found or written. The memory attributes for various AVR targets are the subject of another application note on this site, refer to PA7, 'IAR C Compiler for AVR (ICCA90) utilization of AVR microprocessor memory space', for more details. For the AT90S2313, having a small memory, we need only t be concerned with one memory model called tiny memory model. By default this automatically builds using a processor configuration -v0 and a linker file called lnk0t.xcl. This is suitable for the AT90S2313, but could be improved, by modifying the linker file, to make the code more 'tight' for those difficult applications, and to ensure that the compiler warns you if the code or RAM usage gets too big. A good application note (AVR032 Linker file description with examples) exists on the both IAR s and Atmel Website showing you how to do this, and containing a new linker file specifically for the AT90S2313. The -v0 processor option allows a maximum program address range of 0-1FFF (8k bytes), an interrupt vector width of two bytes, and maximum data (SRAM) address range 0 - FF (256 bytes). The 1k words (2k bytes) FLASH, and 128 bytes SRAM of the AT90S2313, fall within this range. An important remark; why do the compiler create all this hassle for the user by having different kinds of processor options and memory models? This is basically for economical reasons memory economy that is. In embedded micro-controllers memory is a very scarce resource, and the different memory options are introduced to ensure that the created code is as efficient as possible. To program an embedded processor is thus a much more intriguing task than writing PC programs! 5

6 To set these options select Project-Options. A window will open to provide a means of setting various options. The General window displays the current processor configuration, memory model and output directories. This defaults to -v0, the tiny memory model and the Debug sub folder for file storage. Ensure that these are correct and then select the compiler options ICCA90. To get started leave all of the options at the factory settings except the '//' comments box, which you should tick to use the C++ comment style. When you are more proficient you can adjust the various options to improve such things as code optimization. The next category in the window, AA90, adjusts the Assembler, which is not used in this example. This can safely be ignored at present. The linker category, XLINK, sets up the linker and is very important, since this produces the executable code. Click the XLINK category and you should see a window like this: To start you will want to Debug the code using a simulator such as C-SPY in the Embedded Workbench, or AVR STUDIO from Atmel. The output format should thus be set to Debug info as shown here. This causes the linker to produce a file with a.d90 extension in the correct format for both of these packages. Later, when you have tested your code, you will want to produce ROM code for download to the target processor. This is achieved by clicking in the Other box and selecting Intel Extended. A subsequent build will then produce a file with a.a90 extension in the correct format for ROM download. 6

7 The C-SPY category sets up the integrated simulator and should be correct as set. The system is now ready for the project build. The WORKBENCH USER GUIDE has a good tutorial on the user interface. Refer to page 17 onwards of this user guide for more help. The Project Build The files attached to the project can now be built by selecting either Project - Make, or Project - Build All, or clicking the Make button Make only recompiles the files that have changed, while Build All recompiles all of them regardless. For large projects Build All can take a long time, so it is quicker to use Make in these circumstances. Individual files can also be compiled without linking to check for errors before building. This is useful for large, modular files, where it can become difficult to isolate errors to one file. If all is well the project window should change to reflect the included files (seen by expanding the tree with the + sign). In this case the two include files are shown attached to select.c. These two header files will be needed for most AVR projects, <io2313.h > (or the one to suit your AVR) defines all the port names, and <ina90.h > defines the intrinsic functions, allowing you to access all the peripheral functions of the AVR, such as interrupts and EEPROM. In addition to the project window update, a message window will appear, informing you of any errors or warnings. For a faultless build it should appear like this: If any errors or warnings are encountered 'clicking' on the message line will position the cursor on the faulty line in the editor window and attempt to inform you of the error. The most common error is to leave a brace off, so that opening and closing braces do not match. This produces a frightening screen full of errors. This is almost always a good indication of brace mismatch (unless you are very bad at typing!). 7

8 A list of the possible diagnostic messages, and what they mean, can be found in the ICC USER GUIDE, from page 227. In this case it must be a typing error somewhere, since the file is proven. Often a simple error, such as a comma, or a space, is the cause. The user guide attempts to make some suggestions as to the error made, but there is no replacement for experience. It is important to check for correct program structure BEFORE believing the error messages. This is best achieved by laying out the program neatly, matching the opening and closing braces by indents, and checking for correct start and end braces of functions. Only when these match correctly will the error messages make any sense. Simulation The program may now be tried out on a simulator to check that it does what it should. C-SPY is a very powerful simulator, forming part of the Embedded Workbench suite of programs. It allows simulation of all features of the processor, including interrupts, without any hardware being present. Clicking the magnifying class icon will automatically load the Debug file into C-SPY to reveal the C source as shown below: Before we start single-step the program, we will open a memory. Select Window-Memory to open up a memory monitor window: 8

9 Select the I/O SPACE segment and 8 bit view, as shown above, to display the port contents. This allows you to set and view port values as you step through the program. The port names are not displayed on C-SPY automatically, so you can just watch the contents of the port address (which you will have to look up) change, as you single step. This is a bit unwieldy, so there must be a better way! Here it is - in C-SPY you can add virtual registers, call them by whatever name you like and change values/watch these change instead. For this program we can add two virtual registers called PINB and PORTD for input and output respectively. This is achieved by selecting Options- Settings and then clicking the Register Setup folder. Two, new, virtual registers can be set up by clicking new and filling in the names and addresses required as shown below: You must ensure that the size of 1 byte is set up for each, and that the I/O memory segment is selected in the appropriate windows. (The addresses are in Hex and can be found in the Atmel data sheet for the device.) You can remove the working registers by select-all and remove-all to avoid having the working AVR registers displayed as well. This would only cause confusion, although it is interesting to see how the compiler uses the registers. 9

10 The register window can now be called up by Windows-Register instead of the I/O space window, providing a much less confusing interface to work with. The contents of PINB can be changed to reflect the pushbutton value as you step, and the resultant output shows up in the PORTD window. You may add as many of these as you need. It is probably a good idea to include the Data Direction Registers as well to ensure that you have initialized the ports correctly. Many aspects of the user interface can be adjusted, this illustrates just one useful one. The Report window displays information as you progress, but this may be safely closed for this application. Clicking the step icon now steps through the program line by line, with the result displayed at the port addresses in the memory (or register) window. Inputs can be simulated, by changing the hex number at the PIN address. As you step through the program the adjacent icons to the step icon may be needed to step into a function, step out of a function or run to the end of the function (useful for delay functions). The screenshot below shows the two windows resized to display the source window on top of the register window ready for the first line to be executed. For programs that make heavy use of mathematical functions and interrupts, C-SPY is invaluable. Opening up a Watch window, allows you to trace selected C variables as you progress and you can fully debug your program 10

11 using this method. A faster method is to just place the cursor over the variable to inspect; a small window showing the value of the variable will occur immediately. Simulation Quick Tour Simulation can now start. The trace icons give you quick access to the step functions. The main icons are shown below: Go to Cursor Reset Step Step Out Go Step Into Auto Step The Reset icon resets the cursor to the start of the main program use to reset back to the start and simulate again. The Step icon single steps the program, one line at a time use to step through the program carefully and view the results as the program progresses. Using Step on a function line runs that function at full speed and then comes back. The Step Into icon enters a function use to enter a function when you step onto a function call line. Step now single steps the function until the end brace is encountered and then returns to the calling function. The Step Out icon exits a function, running at full speed until it does so use to exit a slow function that you know works e.g. a time delay. The Auto Step icon allows you to set a speed of automatic stepping and watch the program proceed at a slow pace. The Go icon runs the program at full speed to the end or to the first breakpoint The Go to Cursor runs the program up to where you have put the cursor. A quick way to get where you want. The Stop icon, shown greyed out, stops program execution use to stop the auto step, or any other process. Since the first line of the main program is a function call the next action needs to be step-into. This takes the cursor to the start of the function init. Follow this by Step and you will see the ports changing. If you added the data direction registers, as discussed previously, you will also be able to check the port configuration is correct. (1 s for outputs, 0 s for inputs). The rest of the program can be single stepped in this manner. To simulate inputs requires that you step to the line above the input statement and then change the PINB number to the required value by clicking in the window and over typing the value. In our example this would be 00 for button press, or 01 for no button press. The next step input would use this value to make the appropriate decision. Problems arise with programs that use peripheral devices such as timers. The AVR has a 16-bit timer used in this example, TIMER1. Waiting for this to step out can take a long time, even with a fast Pentium PC. The solution to this is to make the Debug version have a very low time value, and single step 11

12 this version. The Release version can then be amended to the correct value and tested on the hardware. This allows you to test the structure of the program at least, without undue time wasting. Programs that make heavy use of the ports, but no interrupts, such as this example, are better simulated on the Atmel AVR STUDIO simulator (which can be downloaded free from their Web Site). This provides a similar environment to C-SPY, with some interrupt limitations, but provides easier access to the ports. Atmel worked closely with IAR to ensure complete compatibility and integration between systems, allowing you to freely switch between systems as you wish. The files are fully compatible and the Debug code is updated automatically when you rebuild the project. The window overleaf shows the same file loaded into STUDIO with the port windows opened. The access to the port is now very clear, with port names clearly labeled automatically, and the contents displayed in Binary as well as Hex. STUDIO also drives an ICE system if you have one, or a target board. This allows the program to be tested on hardware as well. Switching between systems is very easy because the user interface is very similar to C-SPY. The difference can be clearly seen at the ports though. This display shows port B, port D and the timer windows displayed. 12

13 It is now very clear what is happening at the ports with ticks appearing in the bit positions to show a logic '1' state. This view shows STUDIO in the same state as C-SPY, with the program ready to be single stepped (only now it is called 'trace into') and with all ports cleared. You will notice that the source file is no longer displayed in pretty colors though! Generating executable (ROM) code Once the program has been proven it can be tested on the hardware by rebuilding the program with the project options changed from Debug to Other-Intel-Extended. This produces a file with a.a90 extension suitable for download into the FLASH ROM of the AVR. The screenshot below shows the file produced by this action, downloaded into the Atmel ISP software ready for programming. This only takes a few seconds and the hardware can then be seen working. The code display is all in Hex of course. The black FF bytes are unused locations, with the used machine code appearing as blue Hex digits. The gap between the first two blue bytes (the reset vectors) and the main body, are the unused interrupt vectors. Amending the linker file, and rebuilding, could make the main body of the code start right after the reset vector. This uses the unused interrupt vector space and provides more room for code. This is just one example of where setting up the build options is important. It could make the difference between the code fitting or not. 13

14 The right-hand window displays the equivalent ASCII character, which is handy when dealing with programs containing a lot of character output. The Project Manager window allows you to document the code building process. The unused Data EEPROM window can be seen lurking in the background. The contents of each of these are fully editable at any stage. The project is now complete and ready for release, after testing fully. Example program details The example program used in this application note was contrived to show how low level access can be achieved on the AVR from C, and to demonstrate a few of the methods commonly employed. This section documents the hardware used and the structure of the program. The software has been fully commented to describe what each line does so please refer to select.c for this. Hardware diagram The circuit shows the simple hardware arrangement, with the LED common anode connected to the power supply. The circuit takes full advantage of the high current handling, and port flexibility of the AVR. The seven LED segments (a-g) are directly driven from the port pins, with current limit resistors limiting the sink current to a safe level. 14

15 The push button is arranged to take the port pin to 0V when pressed. The software arranges for the internal pull-up resistor to be enabled, saving an external resistor. The clock to the AVR is a simple integrated resonator/capacitors running at 4MHz. The supply rail should be decoupled using a ceramic capacitor of about 100 nf, AND, for high drive current applications, a tantalum bead capacitor of about 10uF (as shown below). The supply rail can be anything from 3-6v or so, as per the AVR specification. Port B SPI pins (PB5-7) have been left unused for ISP (In circuit Serial Programming) use to download the program should you wish. Hardware Circuit Diagram. C1 +5V 2 TANT 1 +5V 1 XTAL1 RESONATOR U1 RESET PD0 PD1 XTAL2 XTAL1 PD2 PD3 PD4 PD5 GND AT90S2313 VCC PB7 PB6 PB5 PB4 PB3 PB2 PB1 PB0 PD SW1 Pushbutton R1 R2 R3 R4 R5 R6 R a b c d e e f g CA f g d a c b Since the LED segments are driven in current sink mode, a logic '0', turns a segment on (active low). The truth table for displaying the numbers 0-9 can now be calculated using binary-hex conversion as shown in table 1. The push button is normally pulled high by the internal pull-up resistor of the AVR (enabled by configuring that port bit as an input, and setting the port bit high in the PORTB register) and goes low when pressed. In common with all CMOS devices, it is better to sink current rather than source, because of the more efficient N-channel output device in circuit at logic 0. The AVR has larger P-channel devices than most CMOS circuits, so it can source a significant amount of current as well. It would thus be possible to reverse the circuit above. This would require changing the display to a common cathode type and amending the program. 15

16 Table 1 - Seven segment decoding table SEGMENT g f e d c b a Hex number Port D bit Number x x x x x x x x x x10 Hex weighting In the example program these numbers have been inserted into an array stored in RAM for easy access. This provides a look up table, with the number to be displayed as the pointer and the data to display the number the contents at that address: //Definition of LED decoding look-up table stored in SRAM char led[]={0x40,0x79,0x24,0x30,0x19,0x12,0x02,0x58,0x00,0x10}; //displays Most large applications would want to use FLASH ROM for this function, because there is more of it. On a Harvard architecture device, such as the AVR (and PIC), this poses special access problems which are the subject of another application note. Program Structure C is a block structured language and consequently all C programs are best planned in this way. Many methods exist to plan program structures, structured English, and Flow Charts are just two examples. The method below you may find useful and is a modification of flowchart method, called Design Structure Diagrams (DSD). This is a very powerful method ideal for C and Assembly language. It produces more compact and simple to follow structures, which fit very nicely with C. DSDs use flowchart symbols (which every one must have used at some stage) but modifies them such that the process box has only one node, with entry and exit at the same node. This allows boxes to be attached to a line instead of inserting them between the lines. It also removes the confusing tramline effect encountered with flowcharts, makes the diagram more compact and forces you to structure your program! Loops show up as loops in a clockwise direction. 16

17 The DSDs for the example main program, and all the functions, are shown below. main init Define variables Define table init Configure Port B Configure Port D Do forever return If PB pressed ( pollpb() ) debounce time Next digit If digit>9 Scale time to ms Configure timer While timer<time end Display digit Digit=0 While PB pressed pollpb While timer<time Read If PB pressed return debounce return readpb 17

18 Program description - points of interest The DSDs clearly show the structure of the program and the functions. Each function has its own DSD. The main function shows a continuous loop after initial setting up of the variables and low level functions. This will be the normal feature of most embedded control functions. Loops show up clearly as clockwise lines, with arrows to show the direction. The main function takes action only if the pushbutton is pressed. Note how a function is called up from within the if statement - (if (pollpb==0)), one example of the flexibility of C. The layout of a C program is very flexible but it is good practice to keep the braces to show start and end of a code block in line with each other. This makes it easier to check that you have nested them correctly. Nested loops or decisions should also be indented to show them up, and so that you can match the source code with the DSD. The functions are contrived to show how values can be passed into them, and/or return values from them. This is shown, in the DSD, by the box at the side of the appropriate terminator box. For instance the function debounce, takes in a 16-bit value (int) and uses it to feed the 16-bit timer of the AVR (TCNT1), after scaling to convert it into milliseconds. The function pollpb takes nothing in (void) but returns the value of the pushbutton, '1' = not pressed, '0' = pressed. Hints and Tips The list below shows some useful tips which could help produce readable, tighter and more efficient code with ICCA90: Structure your program using some useful method and use it to dry run the program, before coding. Separate the program into functional blocks. Tab the source code in several times before you start typing. The editor has no margin control and this will allow a good print output to be obtained with margins. Comment your program as you progress, because you will never go back and do it later! (I have been there!) Keep to local auto variables wherever possible to allow the compiler to use and reuse registers instead of SRAM (faster execution and less code). Use char type variables wherever possible to reduce code size. Use the increment (e.g. x++) or decrement operator (e.g. x--) instead of x=x+1 or x=x-1 to allow the compiler to use the MCUs efficient INC and DEC instructions. Indent code blocks and matching braces to ease readability and maintenance. Define constants at the start of the program to make global changes easier later. e.g. #define DELAY (20) Use upper case characters for constants to make them show up as constants. That way you will not try to change them in the program! 18

19 Define the main function as type C_task to stop the compiler preserving and restoring registers on entry and exit, wasting valuable stack space. The main function will NEVER be exited in an embedded control program. Use FLASH ROM for constant storage ( using flash keyword) instead of SRAM (there is more of it). Accessing flash is more complicated with the AVR because it has a HARVARD architecture, with ROM and RAM accessed by separate address buses. This is covered by another application note. (This application example uses the look-up table in SRAM to take the easy way out!) :KDW\RXJDLQE\XVLQJ(PEHGGHG& Clearly, the low level adaptations that requires many lines of assembly code, can be done in C using the IAR C language extensions, thus increasing readability and portability. The arduous job of initializing the stack, setting up loops and decision branches, looking up addresses and other time consuming tasks, are now done by the compiler/linker. The powerful program development functions, strong integration with third party tools, and project management tools make this a very efficient system to use. &RQFOXVLRQ The combination of IAR Embedded Workbench and the Atmel AVR is a difficult one to beat in the 8-bit, or even 16-bit field of Embedded applications. Using C for Embedded application development considerably speeds up the development and software maintenance process, recouping the cost of the system usually in one or two projects. Contact information USA IAR Systems Inc. One Maritime Plaza San Francisco, CA Tel: Fax: info@iar.com SWEDEN IAR Systems AB P.O. Box S Uppsala Tel: Fax: info@iar.se GERMANY IAR Systems AG Posthalterring 5 D Parsdorf Tel: Fax: info@iar.de UK IAR Systems Ltd. 9 Spice Court, Ivory Square London SW11 3UE Tel: Fax: info@iarsys.co.uk Copyright 1999 IAR Systems IAR and C-SPY is registered trademarks of IAR Systems. IAR Embedded Workbench is a trademark of IAR Systems. Windows is a trademark of the Microsoft Corporation. All other products are registered trademarks or trademarks of their respective owners. Product features, availability, pricing and other terms and conditions are subject to change by IAR Systems without prior notice. 19