AVR C

[bogdan2013]

I'm a beginner of programming MCU and I know only basics . I want to learn more about this programming language .
On some scripts I saw this commands :

voilatile
TTCR
TIMSK
uint8_t
TCNT

What are doing each ?

P.S. : If you know a website or something where I can learn more about AVR C (without basics) you could send me a message or a reply here .

[firewalker]

Have a look at the tutorial bellow.

http://www.fourwalledcubicle.com/AVRArticles.php

Alexander.

[olsenn]

Call me weird, but I don't even like to use the stdint.h as I like to use the least amount of code I'm unfarmiliar with as possible. Things like uint8_t I would just instantiate directly (volatile unsigned char).

As  for TTCR/TIMSK/TCNT... these represent the registers in the IC and the values that are stored in them. Your AVR IC at its lowest level is not a general purpose device (say like an FPGA) but rather dedicated hardware which needs to be configured prior to use. Things like interrupts, timers/counters, UART, ADC etc. need to be set-up by writing values to specific registers in the chip. Download the .pdf datasheet (full, not summary) for your device from Atmel's website, and read the ENTIRE thing. This will explain everything for you.

Until you get the hang of things, I'd highly recommend starting out with a simple reference design (blinking an LED). Make sure you understand what each line of the example code is doing. Once the light turns on (literally and metaphorically) you will be ready to begin your own adventure into the world of microcontrollers. May the force be with you!

[bogdan2013]

Thanks , Alexander . I will se what I can learn from there .

I know to do more than to blink LED . Now I have multiplexed 4 x 7 segment display . All working fine .
I put my birth year and a little display tester (with button) .
What I want to do :
If I press an button to increase number and if I press another button to decrease that number .

[Psi]

uint8_t
Example:  uint8_t MyVariable;
- This just tells the compiler your declaring an 'unsigned 8 bit integer'  There is also uint16_t and signed versions  int8_t  int16_t etc..
Basically it's just another way to write "byte" or "word"


volatile
Example:  volatile uint8_t MyInterruptVariable;
- In simple terms, it's a message to the compiler to pay attention because the variable value may change.
This happens when you use interrupts because they interrupt your main code at unpredictable times.
If you use a variable in an interrupt handler and in your main code as well you should declare it "volatile".
This way the compiler knows that it may change at any time and to never assume it's value.


TCNT
TIMSK
Example:  TCNT = 128;
These are hardware registers inside the AVR micro to do with the hardware timers.
You read/write values to them to configure the timers and read the current timer value.
Read the datasheet for info on what they control and what bits do what.

[nctnico]

uint8_t
Example:  uint8_t MyVariable;
- This just tells the compiler your declaring an 'unsigned 8 bit integer'  There is also uint16_t and signed versions  int8_t  int16_t etc..
Basically it's just another way to write "byte" or "word"

I'd recommend using the stdint.h types if you want to be sure about the width of a variable. On microcontrollers it can make a difference so if you want your code to be portable be sure to use a type with a guaranteed numbers of bits.

[bingo600]

Things like uint8_t I would just instantiate directly (volatile unsigned char).

Why on earth would you make it volatile ?

And ... uint8_t is there for a reason , on an old unisys the chars were 9-bits.
uint8_t guarantees 8-bits.

int is usually the "native" register size , so it's 32bit on a 32bit mcu and 64-bit on a 64-bit mcu.

uint32_t & uint_64t guarantees you the desired size.

So they can come in quite handy

/Bingo

[AlfBaz]

Why on earth would you make it volatile ?

As PSI has already stated, if the compiler sees the use of a variable in a code section it may load it into one of the cpu registors once, see that none of the code is operating on it and assume that its value is unchanged or only changed by the code section it is compiling. Volatile will force the compiler to reload the value every time it uses it. Thats why a lot (if not all) hardware registers are usually defined as volatile, because the code doesn;t change their value the hardware does

[IanB]

But I think the question is "why would you equate uint8_t to volatile unsigned char" rather than just unsigned char? The uint8_t definition does not itself include the volatile attribute.

Also, the volatile keyword should be used with discretion. Making things volatile that don't need to be will impact the performance of your code.

[nctnico]

Why on earth would you make it volatile ?

As PSI has already stated, if the compiler sees the use of a variable in a code section it may load it into one of the cpu registors once, see that none of the code is operating on it and assume that its value is unchanged or only changed by the code section it is compiling. Volatile will force the compiler to reload the value every time it uses it. Thats why a lot (if not all) hardware registers are usually defined as volatile, because the code doesn;t change their value the hardware does

Volatile is only usefull for hardware registers and semaphores/mutexes between seperate processes (including interrupts). You'll make your code a lot slower and larger if you declare every variable as volatile.

[AlfBaz]

Volatile is only usefull for hardware registers and semaphores/mutexes between seperate processes (including interrupts). You'll make your code a lot slower and larger if you declare every variable as volatile.

Sorry about that, I didn't see your question in the contect IanB pointed out. I was under the inpression you thought volatile was never needed, which clearly you dont.

[bingo600]

Volatile is only usefull for hardware registers and semaphores/mutexes between seperate processes (including interrupts). You'll make your code a lot slower and larger if you declare every variable as volatile.

You left out IO register definitions/pointers 

And yes (Thnx Ian) i know what volatile are , and the huge impact it can have on code , as you're not allowed to cache the values.
Witch bascically invalidates the optimizer

/Bingo

[nctnico]

IO=hardware registers 

[andyturk]

You'll make your code a lot slower and larger if you declare every variable as volatile.

"volatile" isn't going add that much of a performance penalty. In essence, it's the opposite of the (now outdated) "register" declaration, and tells the compiler to make sure the value must be written to memory on each update/assignment (and read from memory on each use). Unless you've turned off debugging and have cranked up the optimization to the highest levels, the compiler is probably going to treat most variables as "volatile" anyway, since that's the easiest way to generate correct code.

You don't see a lot of "volatile" declarations in typical C because most code doesn't have to worry about asynchronous access. It's not so much about performance, but rather about correctness.

Of course, some people advocate throwing "volatile" on everything you can. Personally, I think that's goofy. If you want to do that, go get yourself an embedded BASIC interpreter and forget about coding in C.

[IanB]

It's my understanding that "volatile" has far greater importance in embedded code on a micro than on a desktop computer.

On a desktop you handle threading and concurrency using higher level abstractions like critical sections and semaphores. I've never had need of volatile in desktop programming (though that might be different perhaps if I were writing a device driver).

However, on a micro you may have a variable mapped to an I/O port that gets updated asynchronously by the hardware. You need to make sure that variable is declared volatile so that whenever you access it you get the current value and not a stale cached value.

[darrylp]

Desktop programming generally is on a OS running userspace and system programs separated, thus rarely do you need to cross that boundary and see the car that is voilatile.

MCU s are combined user + system and thus you will often need to be aware a var can be voilatile to your code.

Sent from my HTC One X using Tapatalk 2

[alm]

"volatile" isn't going add that much of a performance penalty. In essence, it's the opposite of the (now outdated) "register" declaration, and tells the compiler to make sure the value must be written to memory on each update/assignment (and read from memory on each use). Unless you've turned off debugging and have cranked up the optimization to the highest levels, the compiler is probably going to treat most variables as "volatile" anyway, since that's the easiest way to generate correct code.

Without the volatile keyword, avr-gcc with -Os (default optimizations for production code) will leave variables in registers or even optimize them away if not used (the famous for (i=0;i<1000;i++); getting removed). Adding the volatile keyword will definitely cause a performance penalty. How significant this is compared to the rest of the code will of course vary.

[andersm]

On a desktop you handle threading and concurrency using higher level abstractions like critical sections and semaphores. I've never had need of volatile in desktop programming (though that might be different perhaps if I were writing a device driver).

The memory hierarchy on modern desktops is so complex you're unlikely to use volatile there either. The Linux kernel comes with a nice explanation of why volatile is considered harmful.