AVR Freaks

I completely missed the fact that it was Xmega so:

 

DDRF = PORTF_DIR

PORTF = PORTF_OUT

 

and for completeness

 

PINF = PORTF_IN

  scanf("%d",i);

Exactly what do you think this scanf() is connected to? (hint: with the code you have written so far the answer is nothing). Anyway of everything you posted this bit:

#include <avr/io.h> 

int main() {
    DDRF = (1<<0)|(1<<1)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6);

    int i;
    scanf("%d",i);

    switch (i) {

        case 1:
            PORTF = (1<<0)|(0<<1)|(0<<2)|(0<<3)|(0<<4)|(0<<5)|(0<<6);
            break;

        case 12:
            PORTF = (0<<0)|(1<<1)|(0<<2)|(0<<3)|(0<<4)|(0<<5)|(0<<6);
            break;

        case 14:
            PORTF = (0<<0)|(0<<1)|(1<<2)|(0<<3)|(0<<4)|(0<<5)|(0<<6);
            break;

        case 22:
            PORTF = (0<<0)|(0<<1)|(0<<2)|(1<<3)|(0<<4)|(0<<5)|(0<<6);
            break;

looks like it could be real C though for my money all the pointless (0 << n) stuff obscures the bit you ARE setting each time. I think it would just be clearer as:

#include <avr/io.h> 

int main() {
    DDRF = 0x7F; // bottom 7 bits output

    int i;
    scanf("%d",i);

    switch (i) {

        case 1:
            PORTF = (1<<0);
            break;

        case 12:
            PORTF = (1<<1);
            break;

        case 14:
            PORTF = (1<<2);
            break;

        case 22:
            PORTF = (1<<3);
            break;

You have not completed this code and I have no idea what the significance of 1 / 12/ 14 / 22 is? Perhaps some comments? But as you are inviting user input (and annoying users have the habit of typing anything!) you have to consider how to handle the case when it isn't one of those specific values - in other words switch() statements almost invariably require a "default:" case to catch "everything else".

 

Before the "#include <avr/io.h>" you seem to have several copies of the same thing? It is completely nonsensical. If I take just one of the "int main()" from there:

int main() 
{

  DDRF = (1<<0)|(1<<1)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6);
  int i;

  scanf("%d",i);

  switch (i) {
  case 1.2:
    PORTF = (1<<0)|(0<<1)|(0<<2)|(0<<3)|(0<<4)|(0<<5)|(0<<6);
    break;
  case 120:
    PORTF = (0<<0)|(1<<1)|(0<<2)|(0<<3)|(0<<4)|(0<<5)|(0<<6);
    break;
  case 12:
    PORTF = (0<<0)|(0<<1)|(1<<2)|(0<<3)|(0<<4)|(0<<5)|(0<<6);
    break;
  case 1.2:
    PORTF = (0<<0)|(0<<1)|(0<<2)|(1<<3)|(0<<4)|(0<<5)|(0<<6);
    break;
  case 120:
    PORTF = (0<<0)|(0<<1)|(0<<2)|(0<<3)|(1<<4)|(0<<5)|(0<<6);
    break;
  case 12u:
    PORTF = (0<<0)|(0<<1)|(0<<2)|(0<<3)|(0<<4)|(1<<5)|(0<<6);
    break;
  case 1.2uA:
    PORTF = (0<<0)|(0<<1)|(0<<2)|(0<<3)|(0<<4)|(0<<5)|(1<<6);
    break;
  default:
    printf("no such selection");
  }
  return o;
}

"case 1.2" ? A switch() in C uses an integer value as the switch control so I doubt the C compiler would even accept "1.2" but even if it did it would convert to int and treat it as just "1" anyway. 

 

This is further compounded by the fact that you seem to have three almost identical cases. Two are exactly "case 1.2:" and for good measure there is a very curious "case 1.2uA" in there too. Well for a start C won't let you have two cases with the same value. But then there's that "uA" suffix on the 3rd. While it's true that there are certain characters you can add to the end of C literal constants such as "U" and "L" (to mean "unsigned" and "long") then C might be willing to tolerate a "u" suffix but I'm not aware of "A" being valid C??

 

As it happens you also have cases for "12" and "12u". That's a bit of a conundrum for a couple of reasons. Like I say you can't have duplicates. But like I say by a strange coincidence "u" is a valid suffix for a numeric constant. By default literal constant in C are "int" (by implication that is "signed int") so "12" means a signed integer value of 12. While "12u" means an "unsigned integer value of 12". I imagine the head of the C compiler will probably explode at this stage. I think it's going to reject this as duplicate even though there's that subtle difference in sign.

 

To be honest I wonder if you may not be better off learning about things like this (the fundamentals of C) in a PC environment where things like scanf() "just work". 

 

Oh and that code does:

  return o;
}

A couple of things wrong with that. One is that it appears to be a lower case letter O not the digit 0 (zero). But the other is that this is an embedded micro - there is no where to return to. Most C compilers do have a "catch" so that if you ever make the mistake or returning from main() then there's usually an infinite loop to "hold it". But there may be adverse side-effects. For example in avr-gcc that loop is preceded by a cli() so if the main() code was using interrupts in some way they are turned off. So the general structure of an embedded micro program should generally always be:

int main() {
    one_time_initialisaiton_stuff();
    while (1) {
        the_core_stuff_done_repeatedly();
    }
    // it never gets this far
}

 

ATXmega as I am playing around with the atxmega256au

 

Why are you writing all of this now ?...have you tried & got working an led blinking yet?  Start with the basics.

raven231996 wrote:

Please I when why are int8_t, int16_t and every other data type declaration used in embedded C instead of the normal int, double, float etc.

 

Are they used based on the number of bits of the ports on a microcontroller or what (an application example will help)

 

Thank you

The book you are learning C from should tell you about < stdint.h > and why it exists. If it doesn't tell you then get a better book.

 

Bottom line is that if I write "char", "short", "int", "long", "long long" in C you cannot possibly tell me how many bits are used in each of those and hence what numeric range they might be able to hold. For example on PCs "int" typically is 32 bits and can hold -2147483648 .. +2147483647 and yet "int" on an AVR is just 16 bits and can only hold -32768 .. +32767 so if you write:

int n = 12434567;

On a PC then that will work but on an AVR 'n' will actually contain -10,617. If, on the other hand I used:

#include <stdint.h>

int32_t n = 12434567;

then that is bound to work on PC, AVR or any other kind of architecture I build it on. What's more the reader can see by my choice of "int32_t" that I only ever expect 'n' to hold values in the range -2147483648 .. +2147483647

 

It's a very unwise programmer in this day and age (of all kinds of architectures and bit widths) to ever use base types like unsigned/signed char, short, int, long, long long. The only one you can probably rely on is char (the third one that is neither signed char nor unsigned char) that can still be used when you deal with characters not numbers.

 

I was given the whole firmware to study

That means you'll probably be diagramming how the pieces of the pie fit together...if you don't have a clear vision of how the different gears interact, it will be hard to make useful progress.  While eventually hiding the inner working of each section is great to avoid information overload, ease maintenance, portability, etc'---not knowing how the basic system works is a fast path to nowhere.