Avr studio examples of programs in assembler. Practical programming of Atmel AVR microcontrollers in assembly language

INTRODUCTION Microcontrollers, their origin and application
Background of microcontrollers
Greek style electronics
Why AVR?
What's next?

PART I. GENERAL PRINCIPLES OF DESIGN AND OPERATION OF ATMEL AVR

Chapter 1. Overview of Atmel AVR microcontrollers

Chapter 2. General structure, memory organization, clocking, reset

Chapter 3: Introduction to Peripherals

Chapter 4. Interrupts and Power Saving Modes

PART II. PROGRAMMING ATMEL AVR MICROCONTROLLERS

Chapter 5. General principles of programming MCUs of the AVR family

Chapter 6. AVR Command System

Chapter 7. Arithmetic Operations

Chapter 8. Programming Timers

Chapter 9. Using EEPROM

Chapter 10. Analog Comparator and ADC

Chapter 11: SPI Programming

Chapter 12. TWI (12C) interface and its practical use

Chapter 13. UART/USART Programming

Chapter 14. Power Saving Modes and Watchdog Timer

APPLICATIONS

Annex 1. Basic parameters of Atmel AVR microcontrollers

Appendix 2. Atmel AVR Commands
Arithmetic and logical instructions
Bit Operation Instructions
Comparison Commands
Control Transfer Commands
Unconditional jump and subroutine call commands
Check-Skip Instructions and Conditional Branch Instructions
Data transfer commands
System Control Commands

Appendix 3. Program texts
Demo program for data exchange with flash memory 45DB011B via SPI interface
Exchange procedures via 12C interface

Appendix 4. Exchange data with personal computer and debugging programs via UART
Working with COM port in Delphi
COM port and Windows API
Working with COM through ready-made components
Installing an RTS line in DOS and Windows
COM2000 program
Debugging programs using a terminal program

Appendix 5. Glossary of common abbreviations and terms
Correspondence of terms in Russian to their translation into English
Correspondence of terms in English to their translation into Russian

Literature
Subject index

Now, having written the first article in the series, I understand that I got a little excited and made the same mistake as my predecessors, putting the phrase “for beginners”. It would be more accurate to formulate the topic “For beginners in assembly language programming,” that is, I assume that the reader already has at least a superficial understanding of what a microcontroller is, otherwise it will take us a lot of time just to get acquainted with this topic. For those who are not at all familiar with them, I can recommend a series of articles by S. Ryumik, “AVR Microcontrollers,” which is absolutely wonderful in my opinion, published in the Radioamator magazine (Nos. 1-11 for 2005). In this cycle, ATmega8 is selected as the base controller, however, general functional units The above controller and ATtiny13 are practically the same.

To get acquainted directly with the ATtiny13 microcontroller, I recommend the book by A.V. Evstifeev "AVR microcontrollers of the tiny family. User's manual" (M.: Publishing house "Dodeka-XXI", 2007. - 432 pp.). It contains translated and systematized datasheets for the entire range of controllers of the tiny family, and, in my opinion, should be a desktop reference for those involved in programming microcontrollers.

However, as the story progresses, I will give some information regarding those nodes and modules of the controller that will be used in the written programs.

But all this is a lyrical digression. Let's return directly to the story.

The ATtiny13 controller, despite its small size, has very good functional characteristics. And the small number of pins is more than compensated by the number of functions that each of them performs. The pinout and description of the pins are presented below:

The table is taken from the above-mentioned book by A.V. Evstifeeva.

As you can see, each pin can perform at least three functions, or even many more. At first we will not consider alternative functions, but only the basic one - digital input/output.

As can be seen from the figure and table, all pins, with the exception of power pins, have the name PB followed by serial number. What does this mean? All controller pins are combined into 8 pieces for ease of working with them, and each group of 8 pins is allocated three special I/O registers. In general, the concept of registers is key when working with controllers, especially in assembler. Let's take a closer look at each of the three above-mentioned registers. All of them are single-byte cells in the controller memory. Each bit corresponds to one of the controller outputs, and the bit number in the register coincides with the output number (for example, the 0th bit is responsible for the PB0 output, the 1st bit is responsible for the PB1 output, etc.). All registers have their own name, by which they are accessed when writing programs. What kind of names are these?

1. The DDRB register is responsible for the direction of information transmission of each controller pin. If any bit of this register is “0”, then the corresponding output will be an input, and if “1”, then the output. Moreover, each output is configured individually and anywhere in the program. This means that under different conditions or at different times, the same pin can be configured as an input or as an output, independently of the other pins.

2. The PINB register contains Current state all pins: if voltage is applied to the pin, then a logical “1” is written to the corresponding bit; if there is no voltage, a logical “0” is written. This register is mainly used to read the state of a pin that is in input mode.

3. The PORTB register performs a dual function depending on the direction of information transfer. If the pin operates as a digital output, then writing a “1” to any bit of the PORTB register causes voltage to appear on the corresponding pin, and writing “0” causes the voltage to disappear. Thus, in output mode, it is this register that determines the state of each pin. In mode digital input writing a logical "1" to any bit leads to the connection of the built-in pull-up resistor on the corresponding pin, and writing a "0" - to disabling it. What kind of thing is this “pull-up resistor”, and what is it intended for? If the pin acts as a digital input, then the input buffer resistance is quite high and the input current is quite small. Therefore, any electrical interference can lead to spontaneous switching of the output to an arbitrary state. To prevent this from happening, a resistor with a resistance of several tens of kilo-ohms is connected between the input and the power source, “pulling up” the input potential to the supply voltage (hence the name). The current flowing through this resistor is small enough not to interfere with the rest of the circuit, but large enough to prevent accidental pin switching. We will often use pull-up resistors when working with buttons, because when they are not pressed, the pins they are connected to are essentially "hanging" in the air and are subject to interference.

It should be mentioned that at power-up all registers are reset to 0 and each pin acts as a digital input without a pull-up resistor.

Now that we have at least some idea of ​​WHAT is needed to work with controller inputs, it's time to find out HOW to work with them.

Let's write our first work program in assembler. First, I will give a complete algorithm for creating a new project, but in the future I will omit it, focusing only on the text of the program itself.

1. Go to the asm folder and create a new folder in it. Rename it to a name convenient for us. To be specific, I will refer to them by our step number. In this case "step2".

2. Right click click on the build.bat file and change the path to the source file, indicating the newly created folder (step2). After this my contents look like this:

"F:\Prog\AVR\asm\avrasm32 -fI %F:\Prog\AVR\asm\step2\main.asm
pause"

It may differ for you depending on where you unpacked the archive.

3. Go to the Asmedit folder and run the program ASM_Ed.exe

4. In the window that opens, write the text of the program. I will dwell on this point in more detail, since it is the main one in our lesson today, as well as in subsequent ones.

What is the text of an assembler program? It may include several elements written according to certain rules:

Assembly instructions with or without operands depending on the instruction syntax. Between the command name and the first operand there must be either a space, a tab, or any number of both. The operands are separated by a comma, which can also be preceded or followed by an arbitrary number of spaces or tabs;

Directives, each of which begins with a ".";

Labels, which are places in the program arbitrarily named by the user that may need to be navigated to. Each label ends with a ":" character;

Comments starting with ";". All text from the beginning of the comment to the end of the line is ignored when creating the hex file and can be completely arbitrary;

Empty lines for better structure and readability of the program.

There can be no more than one command on each line. However, the simultaneous presence of a label in a line followed by a command and a comment is allowed.

Using these rules, we will write a program that will turn on LED2 while the SB1 button is held down, and turn it off if the button is released. The text of the program is presented below:

.include "F:\Prog\AVR\asm\Appnotes\tn13def.inc"
sbi DDRB, 4 ;РВ4 - output (LED2)
sbi PORTB, 2 ; Turn on the pull-up resistor on PB2 (SB1 button)
sbic PINB, 2 ;If PB2=0 (button pressed), skip next. line
sbi PORTB, 4 ;Installing PB4 in 1 (turning off the LED)
sbis PINB, 2 ;If PB2=1 (button released), skip next. line
cbi PORTB, 4 ;Setting PB4 to 0 (LED on)

Let's look at it in more detail. The first line contains the "include" directive, written according to the above rules with a dot at the beginning. Its purpose is to include the file specified behind it in the program text. As I said in the first step, we will need the file "tn13def.inc". In this line, you will need to change the path to the location of the Appnotes folder on your computer. Why do we need to include this file? A curious reader can look into it and read its contents, but most likely he will understand little of it at first. For now, I will say that it contains a correspondence between the names of registers, which the assembler does not know by default, with their physical addresses in the controller.

The following lines are assembler commands. The attentive reader will notice that a total of four are used various commands. Let's look at the purpose of each.

The sbi instruction has two operands: the first is the register name, the second is the bit number. As a result of its execution, the specified bit in the specified register is set to "1".

The cbi command is similar in syntax to the above and performs the exact opposite function - it resets the specified bit in the specified register to "0".

The sbis command is also similar in syntax to the above. However, unlike them, it does not perform any operations with registers, but only checks the state of the specified bit in the specified register, and if it is equal to "1", it skips the line following the command. Otherwise, the line following it is executed, as well as all the others after it.

The sbiс command is the opposite of the sbis command. It skips the next line if the specified register bit is "0".

Now, summing up all of the above, let's try to understand the algorithm of the program. To start, I'll do this literally line by line.

1 line. The include directive includes the tn13def.inc file, which contains register definitions.

2nd line. The sbi command sets "1" in bit 4 of the DDRB register, thereby switching the PB4 pin to the output. If you look at the board diagram (Fig. 1 of the previous step), you can see that LED2 is connected to this pin. After the command and the sign ";" a comment has been written that briefly explains the meaning of the actions performed in the line.

3 line. The same sbi command sets "1" in bit 2 of the PORTB register, connecting the internal pull-up resistor to the PB2 pin, to which the SB1 button is connected. Since we did not change the state of bit 2 of the DDRB register, this pin will remain an input, which is what we actually need.

4 line. The sbic command checks for the presence of a logical "0" at the PB2 input using the PINB register. If you look closely at the diagram, you can see that the buttons, when pressed, close the corresponding terminal with the common wire. This is a standard technique, since when the button is released, a logical “1” is present on the output due to the pull-up resistor, and when the button is pressed, a logical “0” appears due to the connection of the output to the common wire. So, if there is a logical “0” at pin PB2, that is, the button is pressed, we skip the next line, and if the button is released, then we execute it.

5 line. In it, the sbi command sets a logical “1” in bit 4 of the PORTB register, thereby turning off LED2. An astute reader may wonder why the LED turns off if we apply voltage to the output. The answer lies in the design. The LED is connected with the anode to the power wire, and the cathode to the controller output. Therefore, if you apply voltage to the output, the potentials of the anode and cathode will be equal, and the LED will go out. If a logical “0” is output to the output, then voltage will be applied to the LED and it will light up. Thus, a pair of lines 4 and 5 turns off LED2 when the button is released.

6 line. The meaning is opposite to the 4th. The sbis command checks for the presence of a logical “1” at the PB2 input, that is, it checks whether the button is released. If the button is released, the next line is skipped and the next line goes to the next one. But since the 7th line is the last, there is a transition to the 2nd line. If the button is pressed, then line 7 is executed.

7 line. Opposite of 5th. The cbi command resets bit 4 of the PORTB register to "0", thereby turning on LED2. Thus, a pair of lines 6 and 7 turns on LED2 when the SB1 button is pressed.

As you can see, we didn’t do anything particularly difficult. Using knowledge of only 3 registers and 4 instructions, we wrote our first program. What to do with her next? If you haven't forgotten yet, we continue to write the program creation algorithm.

5. Having written the program text in the editor window, select the “File” menu item, and in the list that opens, click “Save As...”. In the file saving window, select the step2 folder we created and specify the file name “main”, since this is the name we specified in the “build.bat” file

After saving, the program window should look like this:

6. Create a hex file. To do this, click the "II" button on the toolbar. The following window should appear:

It notifies us that the assembly was completed without errors and the firmware file “main.hex” was created with a volume of 6 words, that is, 12 bytes. I note that a similar program in C would have at least 5 times the volume.

7. Having gone to the step2 folder, we find an addition to it in the form of a newly created main.hex file, which can now be sewn into the controller with any programmer, which must be done in order to see the results of the program we wrote. After flashing the controller, if the circuit is assembled correctly, everything should work according to the algorithm we developed: when the buttons are released, LED2 should be off, and while button SB1 is held down, it should be on.

Before the next step, I suggest you do the following tasks:

1. Add to the program processing of pressing the SB2 button with the opposite algorithm: when the SB2 button is released, LED1 should be lit, and when pressed, it should be off.

2. Write a program to control LED2 using both buttons. When the SB1 button is pressed, the LED should light up and remain on until the SB2 button is pressed, which turns it off until the next press of SB1.

Everyone Good evening! I am broadcasting from a cozy world called “assembler”. I’ll immediately explain what the topic concerns AVR microcontrollers- and I don’t yet know whether this post will be useful to those who want to use assembler for any other task. The fact is that literally a few days ago I started learning assembler from scratch - I need to make one device - and I decided to do everything in it myself. So, one fine day I realized that Learning assembler is absolutely useless! Assembly language can only be understood! That is, to all those who want to program in assembly language, I strongly recommend that you delve in detail into how the microcontroller PHYSICALLY works, and then study the intricacies of the commands.
So, I’ll probably start a small series of articles in which I’ll tell you from the very beginning how exactly I understood certain things in assembly language programming - I think for those who do not understand at all what ASM is, I will be just such a “translator” from the language of those who are very good at this matter.

I’ll say right away that I more or less got into this topic at the instigation of DIHALT - therefore these articles will be a kind of translation from a super-duper assembly-microcontroller language into a language understandable to most people. Well, I hope the gurus will correct me as the play progresses, and if I suddenly explain something incorrectly, they will correct me.
So, the first conclusions about assembler that I made a couple of days ago shocked me to the core - and I sat reading DI HALT articles from 11 pm to 5 am - after which I went to bed satisfied and happy. I understood the essence of assembly language programming for microcontrollers.
How can this be explained even more simply? I think we need to start from the very essence.
***
Initially, we will not go into technical details (we will talk about them in the next article) - just imagine there are 3 characters:
1. Microcontroller - This is the Englishman Steve, who came to the Russian. He knows perfectly English language, but he doesn’t understand Russian at all - not a single word. English only. He lost the argument and pledged to do whatever the Russian asked him to do without question.
2. Assembler - This is the translator Vasya, whose mother is English and father is Russian. He knows both English and Russian perfectly.
3.We - This is a Russian to whom an Englishman has come. Well, that is, we are us =) At the same time, we know Russian perfectly and (!!!) a little English - just a little, with a dictionary.
***
Imagine this situation - an Englishman is sitting on a chair in your room. And you are sitting at your computer and reading this post, when suddenly your window suddenly opened! That's bad luck! The wind is blowing, the curtain has turned into a sail... It would be nice to close it! But it’s too lazy to get up from the chair, take your feet off the system unit, stuff them into slippers, put down your mug of coffee (beer) and go fight the elements. And then you suddenly realize that we have an Englishman in the room who has lost his bet and it’s time to chase him! And you say to him so sweetly, “Dude! Please close the window, and then you can sit down on the chair again!” and he sits, looks at you in bewilderment and does nothing! You can, of course, hit the cabbage soup - but then he still won’t understand you! Then you call your translator friend Vasily - he comes and sits down next to the Englishman on a chair. And you say - Translate: “Steve, go and close the window, and then sit back on the chair!” The translator translates into English - the Englishman understands and goes and closes the window, and then comes and sits on a chair.
At this point, you just need to understand the role of the assembler in this “We-Assembler-Controller” chain
That is, how would everyone understand what assembler is? Then read on.
***

So, let's imagine this situation. You say to Vasya - “Listen, well, in short, this is the case - I forgot the calculator at home, divide 56983 by 2 and tell Steve to do so many push-ups with your fists” and Vasya counts on the calculator and tells Steve in English “Do push-ups with your fists 28491 times” It is called "DIRECTIVE"- in other words, a directive is a task for Vasya, the result of which is Steve’s action.

There is another situation - you say to Vasya “Tell Steve to do 28491 push-ups” and Vasya simply translates your words into English. It is called OPERATOR

It's simple - there is a directive and there is an operator. The operator is your direct instruction to Steve what to do - Vasya here only translates your request into English. And the Directive is a task for Vasya himself - and Vasya first does what you told him, and then, depending on the result, he tells Steve something.

Now we will torture the Englishman regularly! But first we need to get to know our translator Vasya better. You need to know the following - Vasya always obeys you unquestioningly - what he was told, he does. Vasya’s calculator does not have decimal places - if you look at the example with push-ups, then 56983 \ 2 = 28491.5 - but Vasya’s everything after the decimal point is cut off - and he sees only an integer - and it doesn’t matter whether there will be 28491.000001 or there will be 28491.9999999 - for Vasya this is one big deal will be 28491 in both cases. Nothing is rounded. More important information about Vasya. Vasya is cruel - he doesn’t care about the fact that Steve is fucking doing push-ups twenty-eight thousand times. They told him that Vasya translated. And not only did he translate, but he also forced me to do what you asked. So if Steve dies on the twenty-three thousand five hundred and thirteenth push-up, it will be entirely your fault.

Actually, that's all for now. In the next post we will dig deeper - for now it’s enough to just understand this. Just imagine this situation and understand what’s what, who plays what role and how the directive differs from the operator.
And then we will try to call everything by its proper name and roughly estimate how assembler works with a microcontroller like an adult.

A clone of the famous Tetris, written in assembly language. It fits entirely into the 512 byte boot sector (it requires only 446 bytes of space, which is exactly the maximum bootloader size in the MBR).

MBR is a section containing the code and data necessary for the subsequent loading of the operating system and located in the first physical sectors. The very first 446 bytes of the disk are given over to the bootloader code. It is in this place that TetrOS is written.

Naturally, due to such properties, it is loaded before any operating system- it does not require any OS, it works on its own. Yes, yes, you heard right, TetrOS is its own bootloader.

This is what it looks like on the screen:

And the source code on the boot sector looks like this:

And yes it is all source. Do you remember that it weighs only 446 bytes?

You can run this “miracle operating system” under qemu or even actually install it on the boot partition of a disk or flash drive.

Launch

Just install qemu:

sudo apt-get install qemu

and run:

Loading to a USB flash drive

Copy the image to a flash drive. Let's say if the flash drive is mounted as /dev/sde, you will need to run the following command to write to it boot sector TetrOS:

sudo dd if=tetros.img of=/dev/sde

Game description

The developer managed to cram a not-so-boring design into just 512 bytes of memory. Each brick in the game has its own color, is controlled by buttons, in case of defeat the game ends, the bricks are generated randomly... BolgenOS was not even close!

Unfortunately, due to the size, some features had to be abandoned. The game does not have scoring, restart the game without rebooting, or display what the next brick will be.

Name: Practical programming of Atmel AVR microcontrollers in assembly language 2nd edition

Publisher:"BHV-Petersburg"

The year of publishing: 2011

Pages: 354

Language: Russian

Format: DjVu

Size: 12.2 MB

The operating principles, architectural features and programming techniques of Atmel AVR microcontrollers are superimposed.

Ready-made recipes are provided for programming the basic functions of modern microelectronic equipment: from responding to a button press or constructing a dynamic display to complex data recording protocols in external memory or features of real time clock connection. Special attention focuses on the exchange of data from microelectronic devices with a personal computer, and provides examples of programs. The book takes into account the features modern models AVR and related microcircuits of recent years of production.
The application contains the main parameters of AVR microcontrollers, a list of commands and texts. The applications contain the main parameters of AVR microcontrollers, a list of commands and program texts for them, as well as a list of terms and abbreviations used.
For students, engineers and radio amateurs

7. Microcontrollers, their origin and application
8. Background of microcontrollers
10. Greek style electronics
12. Why AVR?
14. What's next?
17. PART L GENERAL PRINCIPLES OF DESIGN AND OPERATION OF ATMEL AVR
19. Chapter 1. Overview of Atmel AVR microcontrollers
21. AVR families
23. Features of practical use of the AVR MK
23. About consumption
25. Some features of using AVR in circuits
27. Chapter 2. General structure, memory organization, clocking, reset
27. Program memory
29. Data memory (RAM, SRAM)
31. Non-volatile data memory (EEPROM)
32. Clock methods
34. Reset
37. Chapter 3: Introduction to Peripherals
38. I/O ports
39. Timers-counters
41. Analog-to-digital converter
42. Serial ports
43. UART
46. ​​SPI interface
50. TWI interface (I2C)
50. Universal Serial Interface USI
53. Chapter 4. Interrupts and power saving modes
53. Interrupts
57. Types of interruptions
58. Energy Saving Modes
61. PART II. PROGRAMMING ATMELAVR MICROCONTROLLERS
63. Chapter 5. General principles of programming MKs of the AVR family
63. Assembler or C?
67. AVR programming methods and tools
67. Code editor
68. About AVR Studio
70. Arrangement of the assembler
71. Programmers
75. About hex files
78. Commands, instructions and notation of the AVR assembler
79. Numbers and expressions
80. Directives and functions
84. General structure of the AVR program
85. Interrupt handling
89.RESET
90. The simplest program
92. Delay
94. Counter program
96. Using interrupts
97. Timer delay
98. Counter program using interrupts
101. About configuration bits
105. Chapter 6, AVR Command System
105. Control transfer instructions and SREG register
111. Check-pass commands
113. Logical operations commands
114. Shift instructions and bit operations
116. Arithmetic operations instructions
118. Data transfer commands
122. System management commands
123. Performing standard procedures in assembler
125. About the stack, local and global variables
127. Chapter 7. Arithmetic Operations
128. Standard arithmetic operations
129. Multiplying multi-digit numbers
131. Division of multi-digit numbers
134. Operations with fractional numbers
136. Random number generator
138. Operations with numbers in BCD format
143. Negative numbers in MK
147. Chapter 8. Programming timers
147. 8- and 16-bit timers
149. Formation of a given frequency value
153. Countdown
158. Accurate time correction
160. Frequency meter and period meter
160. Frequency meter
164. Periodometer
167. Dynamic display control
168. LED indicators and their connection
171. Programming dynamic display
174. Timers in PWM mode
179. Chapter 9. Using EEPROM
179. Once again about the safety of data in EEPROM
181. Write and read EEPROM
183. Storing constants in EEPROM
187. Chapter 10. Analog comparator and ADC
187. Analog-digital operations and their errors
190. Working with an analog comparator
193. Integrating ADC on a comparator
194. Operating principle and calculation formulas
198. Integrating ADC program
201. Built-in ADC
204. Example of using an ADC
206. Program
215. Chapter 11. SPI Programming
215. Basic operations via SPI
216. Hardware option
218. Software option
219. About types of non-volatile memory
221. Write and read flash memory via SP!
224. Exchange program with memory 45DB011B via SPI
225. Writing and reading flash cards
225. Connecting MMS cards
228. Submission of commands and initialization of MMC
232. Writing and reading MMS
237. Chapter 12. TW1 (I2C) interface and its practical use
237. Basic protocol 1 2 C
240. Software emulation of I 2 C protocol
241. Writing data to external non-volatile memory
241. Exchange modes with AT24 memory
243. Program
247. Clock with I 2 C interface
255. Data recording
259. Reading data
261. Chapter 13. UART/USART Programming
262. UART initialization
263. Transmitting and receiving data
266. Example of setting the DS1307 clock using UART
271. Techniques for protecting against communication failures
271. Parity check
273. How to organize a correct exchange
274. Additional features of USART
276. Implementation of RS-232 and RS-485 interfaces
280. Level converters for RS-232
283.RS-485
285. Chapter 14. Power saving modes and watchdog timer
286. Programming energy saving mode
287. Example of a battery-powered device
289. Finalization of the program
293. Using a watchdog timer
299. APPLICATIONS
301. Appendix 1. Basic parameters of Atmel AVR microcontrollers
309. Appendix 2. Atmel AVR Commands
310. Arithmetic and logical instructions
311. Bit Operation Instructions
312. Comparison commands
313. Control transfer commands
313. Commands for unconditional jump and call of subroutines
314. Check-skip commands and conditional jump commands
315. Data transfer commands
316. System management commands
317. Appendix 3. Program texts
317. Demonstration program for data exchange with flash memory 45DB011B via SPI interface
321. Exchange procedures via the I2C interface
329. Appendix 4. Data exchange with a personal computer and debugging programs via UART
329. Working with COM port in Delphi
335. Installing an RTS line in DOS and Windows
337. COM2000 program
339. Debugging programs using a terminal emulator
341. Appendix 5. Dictionary of frequently used abbreviations and terms
347. Literature
349. Subject index