What parts are needed for a PC. Assembling a gaming PC with your own hands

The IAR Workbench environment is proprietary and requires licensing (if your code exceeds 32 KB), but it is quite sufficient for home use.

Directly the development environment, which includes the compiler. After installing IAR, you will need to register it by filling out a form on the company’s website. Specify a real mailbox, a license key will be sent to you.

You will need to download the archive from the ST Microelectronics website - it contains:

• CMSIS(Cortex Microcontroller Software Interface Standard) - a library that defines the operation of the core, that same Cortex M3 (we'll talk about it later);
• SPL(Standart Peripheral Library) - a standard peripheral library that will save you a lot of effort in configuring a particular peripheral;
• Examples- if you need to learn how a new peripheral works for you, then this folder contains many examples for all occasions.

Once IAR is running, create a workspace File ⇒ New ⇒ Workspace. Next is a new project, menu Project ⇒ Create New Project...

The program can be written in assembler, C or C++. We will use the C programming language.

The created project must be configured; to do this, open the menu Project ⇒ Options. In the tab General Options select the target microcontroller - STM32F100x4.

Besides, in Library Configuration put a tick Use CMSIS. The IAR environment already includes this library and it is not necessary to add it to the project, however new versions may issue a warning like:

Warning : Label ‘xxxxx’ is defined pubweak in a section implicitly declared root

The problem is solved by replacing some lines in the built-in CMSIS library: where CODE:REORDER is mentioned, add NOROOT(1) . For example:

PUBWEAK NMI_Handler
SECTION .text:CODE:REORDER:NOROOT(1)
NMI_Handler

Next, add the path where the *.c and *.h files will be stored - to do this, go to the tab C/C++ Compile r ⇒ Preprocessor and add &PROJDIR& (a variable containing the path to the project folder).

In the Debugger section, select as debugger ST-LINK. Check the boxes Use flash loader And Verify in the tab Download.

FAQ. IAR C compiler for Atmel AVR microcontrollers

V. Poletaev

Frequently asked questions
answers to frequently asked questions about the IAR C compiler for Atmel AVR microcontrollers are given by V. Poletaev ( [email protected])

There are several versions of the compiler - 1.40, 1.41, 1.50, but for some reasons version 1.40c is most widespread in Russia. The compiler version can be found in the ewa90d.txt file - not to be confused with the shell version.

Question: I installed IAR Embedded Workbench and “patches” for it. What else do I need?

Answer: Version 1.40 comes with not entirely correct .xcl files for the linker. In addition, the descriptions of microcontroller registers in it are incomplete. For normal operation, it makes sense to either take a set of .xcl- and h-files from a newer version of the compiler, or from the Atmel website (ftp://www.atmel.com/pub/atmel/avr030.zip; ftp://www .atmel.com/pub/atmel/io_def.zip).

The files from these archives should be rewritten into the appropriate directories instead of those supplied with the compiler.

When working in the Embedded workshop, the correct .xcl file name should be specified separately for each target in Project|Options|XLINK|Include|XCL file name, enabling Override default.

Question: Where to begin?

In addition, it is recommended to visit the section http://www.atmel.com/atmel/products/prod201.htm on the Atmel website and download a number of documents from there:

• AVR030: Getting Started With C for AVR (http://www.atmel.com/atmel/acrobat/doc1483.pdf). A good example to get started quickly. As an appendix it comes with ftp://www.atmel.com/pub/atmel/avr030.zip - a collection of correct .xcl files for various microcontroller configurations.
• AVR032: Linker Command Files for the IAR ICCA90 Compiler (http://www.atmel.com/atmel/acrobat/doc1079.pdf). This describes how to compose .xcl files. Just a retelling of the documentation from IAR. As an application there is another example with .xcl files, but earlier. It is better to use the option from Getting Started.

In this section there are a number of documents devoted to working with C and worthy of careful reading, of which I especially note AVR035: Efficient C Coding for AVR (http://www.atmel.com/atmel/acrobat/doc1497.pdf).

For effective work, you should also take the latest edition of the datasheet and errata for the selected microcontroller from http://www.atmel.com/atmel/products/prod200.htm and carefully study them, especially the errata.

Question: Is IAR C different from standard ANSI C?

Answer: Yes. IAR C includes various extensions related to the implementation of a compiler for a microprocessor with a Harvard architecture (two address spaces - for code and data) and for more efficient operation in the limited conditions of microcontrollers. For more details, see AT90S C Compiler Programming Help, section Language extensions.

The execution system (library) lacks functions related to operating system calls (file operations, etc.).

Question: Is it possible to put tables (rows, etc.) in ROM?

Answer: Yes. There is a language extension for this - the reserved word flash. A variable described using this word is located in the address space of the code and is read-only.

Flash char aaa = “aaa”; flash char bbb = “bbb”; flash char ccc = “ccc”; flash char flash *xxx = (aaa, bbb, ccc, 0);

If more than one level of nesting is used, as in the above example (an array of pointers to lines), then flash should be present for each level.

Question: How to pass a char flash * string to a function? Directly writing a string in function parameters does not work: printf_P(“String\n”);

Answer: Option 1.

Describe it separately:

( static flash char str = “String\n”; printf_P(str); )

Option 2. Use explicit type conversion:

Printf_P((char flash *)(int)“String\n”);

You can shorten the entry slightly using #define:

#define F (char flash *)(int) printf_P(F“String\n”);

In this option, the line will be placed in the CSTR segment. By default, this segment is located in the data address space, so for it to work correctly, you need to fix the XCL file. We need to remove the mention of CSTR from the line:

Z(DATA)CSTR,CONST=9000-FFFF

(if this line is present in the source XCL file) and paste it into the line:

Z(CODE)INTVEC,RCODE,CDATA0, CDATA1,CCSTR,SWITCH, FLASH,CODE=0-1FFFF

Option 3. Use the –E switch.

This option is only available when working with the compiler from the command line. After specifying this key, the compiler places string data in the CSTR segment and data of type const in CONST, and considers that these segments are located in the address space of the code.

This option also requires fixing the XCL file to move CSTR and CONST to the -Z(CODE) line.

In addition, this option may cause problems using a library translated without the –E switch.

And finally, in this version the compiler issues a warning message Dangerous configuration, which can only be disabled together with all warnings, which is inconvenient.

In my opinion, the most acceptable are the first and second options.

Question: How to convert a char * pointer to char flash *?

Answer: Use intermediate int:

Char *s; char flash *p; p = (char flash *)(int)s;

Question: Where are const variables located?

Answer: It depends on the installed compiler options. By default (if neither of the -y or -E options is specified), these variables are placed in the CONST segment, which is considered to be in the data address space. This mode was made with the expectation of using external non-volatile data memory and is not used in most cases. Additionally, in this mode, the linker places these variables in the code region at the same addresses, which can cause serious problems.

If the –y – “Writable constants and strings” mode is set, then the compiler builds the code in full compliance with the ANSI standard, placing constants and strings in the address data space. Their initial values ​​are stored in the code address space in the CDATA0 or CDATA1 segments for constants and CCSTR for strings, and at the time of startup they are rewritten into RAM into the IDATA0/IDATA1 and ECSTR segments, respectively. The main disadvantage of this mode is the unproductive use of RAM.

The option with the –E key was discussed above. It is not possible to use the –y and –E switches at the same time.

To write the optimal version of the program, it is better not to use const, but to describe immutable data as flash, which will lead to their explicit placement in program memory without unnecessary RAM consumption.

Question: What is the most convenient way to work with bits in registers of external devices?

Answer: First, describe a useful macro:

#define Bit(n) (1<< (n)) Для установки бита n в порту p: p |= Bit(n); Для сброса бита: p &= ~Bit(n); Для проверки бита: if ((p & Bit(n)) != 0) ...

A complete list of all bits is available on the Atmel website in the software section, file io_def.zip. You should place these .h files from this archive in the C:\IAR\EW22DEMO\A90\INC\ directory instead of the existing ones.

Question: printf doesn't work for me. What should I do to correctly output information to the serial port?

Answer: First, include a separate putchar function in your program:

Int putchar(int c) ( while ((USR & (1<< UDRE)) == 0); UDR = c; return c; }

The standard putchar in the library represents a single RET statement and does not perform any output.

To access the named register bit names, take the correct .h file from io_def.zip.

This function should be enabled only when compiling under target=release, otherwise the Terminal I/O window may refuse to work under the debugger. The simplest way to do this is to define the DEBUG symbol for target=debug (Project|Options|ICCA90|#define, enter symbol) and surround the putchar definition with conditional compilation directives (e.g. #ifndef DEBUG ... #endif).

Secondly, you should insert a procedure for setting the serial port baud rate at the beginning of your program. For example, for quartz 5.53 MHz and baud rate 115200, you need to set:

UBRR = 2; UCR = 0x18;

Thirdly, regular printf will only work with the –y – “Writable constants and strings” mode enabled.

Fourth, you need to choose the right version of the printf function. For details, see AT90S C Compiler Programming Help, Configuration, Input and output.

The standard printf function requires at least 134 bytes of stack RAM to operate. This is a terrible waste, so there are shortened versions of printf that have significantly less formatting capabilities (in particular, they do not support setting the output width field), but do not require so much RAM to operate.

As a final solution to the problem, I would recommend doing the following:

Take the file C:\IAR\\EW22DEMO\A90\ETC\intwri.c as a basis and make the following changes in it:

• add the line #include “pgmspace.h”;
• replace the function description with int printf_P (const char flash *format, ...);
• change the hex array type from const to flash: static flash char hex = “0123456789ABCDEF”.

After this, do not forget to make the necessary changes to the XCL file (move the CSTR to the CODE section).

Of course, you need to insert putchar and port initialization.

After that, forget about the existence of printf and use only printf_P.

Question: I don't have enough RAM. What to do?

In short, enable size optimization. If possible, use byte (char) variables. Do not overload the stack with large local variables. Try to make functions of a large (moderately!) size - this way the compiler will distribute the maximum number of variables into registers. It is better to judge the effectiveness by listing with the insert mnemonics mode enabled. It is better to pass no more than 2 input variables to functions - this way they will go into registers. Place constants in ROM with the flash keyword.

Carefully study the used .xcl file - it is included in the delivery only as an example and is ineffective in some places. Set the lower limit of all DATA segments (RSTACK, CSTACK, IDATA1, UDATA1, ECSTR) to 60 - this will ensure full use of RAM, without holes. Specify the sizes of the hardware (RSTACK) and software (CSTACK) stacks.

Question: My port A is not working. Why?

Answer: Port A is used as an address-data bus when working with external RAM. If it is not used, then in the .xcl file you should comment out the line -e?RSTACK_IN_EXTERNAL_RAM=? C_STARTUP.

Question: Is it possible to create the output file in binary form?

Answer: Yes. To do this, specify mpds as the output format. The resulting file with the extension .tsk will be the ROM image.

Question: How to replace a library module with your own?

Answer: The easiest way is to place the source file with it in your project working directory and connect it to the project file. Then the shell itself will figure out its type (.c or .s90) and take care of docking it before the library one.

Question: What is the best way to debug a program?

Answer: If you need to debug an algorithm that is independent of the operation of the peripheral, you can use C-SPY. The advantage is debugging at the source text level (but you can also view assembly text), the disadvantage is that there is practically no periphery.

If you need to work with standard peripherals, you can use Atmel AVR studio 3.0, which quite accurately emulates the behavior of crystals. To transfer a file to it, you must specify the type of output format debug to xlink. If the characters in the source text window in Astudio are distorted, then you should install a suitable monospace font (for example, terminal for DOS encoding of Russian letters or Courier for Windows) in the Edit|Fonts menu... ATTENTION! IAR addresses program memory byte by byte, while Atmel addresses program memory by word. Therefore, if in the map file from the linker the subroutine has the address 1234h, then in astudio you need to specify the address 1234h/2=091Ah.

Question: Does EWA90 only work on Windows?

Answer: Shell - yes. However, there are command-line versions of the compiler, assembler, and linker that work fine under MS-DOS, using the built-in DOS Extender from Phar Lap Software, Inc.

The main difficulty when working with them is the huge number of keys. I recommend first working in a Windows shell, and then taking the list of keys from the listing header and placing it in the makefile.

Question: Periodically, when compiling a completely correct file, a system error is thrown. What to do?

Answer: Repeat compilation. This is some kind of compiler error that sometimes occurs.

Answer: On the Russian website of Atmel there is a selection of practical recommendations: http://www.atmel.ru/AVR/AVR.htm and http://www.atmel.ru/Spec/Spec.htm.

Answers to questions about AVR asked by visitors to the ATMEL website can be found at http://www.atmel.ru/FAQ/FAQ.htm.

You can ask questions to the Russian representatives of Atmel - the EFO company through the Atmel conference on the website http://www.efo.ru.

A large number of AVR specialists regularly communicate in the microcontroller conference on the Telesystems website -