## atMega program to xMega problem/learning

10 posts / 0 new
Author
Message

After a lot of time passing away doing a lot of electronics (all except being bussy with AVR)...

I needed to pick up my old FAN control project.

Where I developed with help from this board an good working sample in an atmega environment I needed to change to Xmega for additional purposes. So today I started converting my code and ran into some trouble.

Kindly requesting here  t point me in the right direction to solve these gaps.

What I understood so far is that converting code is not that difficult (all remains the same, only big difference is the references to object of the AVR).

```ISR (PORTA_INT0_vect)
{
uint8_t changedbits;
uint8_t our_pina;

changedbits = our_pina ^ portbhistory;
portbhistory = our_pina;

/* PA0 changed & high */
if((changedbits & (1 << PA0))&&(~our_pina & (1 << PA0)))
{
rpmcount[0]++;
}
/* PA1 changed & high */
if((changedbits & (1 << PA1))&&(~our_pina & (1 << PA1)))
{
rpmcount[1]++;
}
/* PA2 changed & high */
if((changedbits & (1 << PA2))&&(~our_pina & (1 << PA2)))
{
rpmcount[2]++;
}
/* PA3 changed & high */
if((changedbits & (1 << PA3))&&(~our_pina & (1 << PA3)))
{
rpmcount[3]++;
}
/* PA4 changed & high */
if((changedbits & (1 << PA4))&&(~our_pina & (1 << PA4)))
{
rpmcount[4]++;
}
}```

Above I copied a part of my code, what I do not understand is how to modify 1<<PA0, what I read so far is often it is in the underneath form:

`PORTD.DIR |= (1<<PIN0)|(1<<PIN1)|(1<<PIN2)|(1<<PIN3)|(1<<PIN4)|(1<<PIN5);`

I am looking for a way to address a PIN directly, but probably because it is too basic I am unable to find it myself.

In the above example the PIN is releated to PORTD, however when using in my if statement I cannot include PORTD.DIR etc (i presume).

(Furthermore I do not say the above piece is correct at all, since I am still busy converting and was not able to do a single compile nor tryout)

xMega has a different IO system.

For changing single pins, you can do:

```PORTA.OUTSET = (1<<SomeBit)

PORTA.OUTCLR = (1<<SomeBit)

or even

PORTA.OUTTGL = (1<<SomeBit)```

There are also DIRSET and DIRCLR registers for changing the direction of specific bits.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

Sebas06 wrote:
only big difference is the references to object of the AVR

Correct.

So the first thing you need to do is to spend some time familiarising yourself with the new architecture.

• Using the debugger
• Using the UART
• etc, etc, ...

https://www.avrfreaks.net/comment...

Then you can start thinking about how to port your old code to the new architecture

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

awneil wrote:

Sebas06 wrote:
only big difference is the references to object of the AVR

• Using the debugger
• Using the UART
• etc, etc, ...

Thank you for your response to my (in your eyes simple) question... However if I told you I already made a freq capturer, pulse width capturer, led blinking by timer, led by PWM (and FAN also), debugging in Atmel Studio and was busy with UART DMA -> which I never got to work, but based on interrupt no problem. Are you willing to help me with my question (or should I copy my codes from above mentioned projects?)?

At this moment I only do not see 1<<PA1 -> how this works equally in xmega, but I will continue searching for what I am missing.

The Xmega device header files don't redefine the pin names for every port like the Mega device header files do.

From a Mega device header file:

```#define PA7     7
#define PA6     6
#define PA5     5
#define PA4     4
#define PA3     3
#define PA2     2
#define PA1     1
#define PA0     0

#define PB7     7
#define PB6     6
#define PB5     5
#define PB4     4
#define PB3     3
#define PB2     2
#define PB1     1
#define PB0     0

#define PC7     7
#define PC6     6
#define PC5     5
#define PC4     4
#define PC3     3
#define PC2     2
#define PC1     1
#define PC0     0
```

```// Generic Port Pins
#define PIN0_bm 0x01
#define PIN0_bp 0
#define PIN1_bm 0x02
#define PIN1_bp 1
#define PIN2_bm 0x04
#define PIN2_bp 2
#define PIN3_bm 0x08
#define PIN3_bp 3
#define PIN4_bm 0x10
#define PIN4_bp 4
#define PIN5_bm 0x20
#define PIN5_bp 5
#define PIN6_bm 0x40
#define PIN6_bp 6
#define PIN7_bm 0x80
#define PIN7_bp 7
```

So things like (1 << PA2) can be replaced by PIN2_bm or (1 << PIN2_bp).

[edit: typos]

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

Make Xmega Great Again!

Last Edited: Mon. Dec 28, 2015 - 06:03 PM

Sebas06 wrote:

Sorry, you missed my point.

The point is that, you say, the XMega architecture is new to you - so that is the thing where you need to start from basics.

What I meant was,

• Blinking an LED on the XMega;
• Using the debugger on the XMega
• Using the UART on the XMega

Indeed, having already done all those projects, this should not take you very much time; but these are where the differences lie, so this is the "new" stuff that you need to learn

These are exactly the things I do whenever I am starting out with a new architecture

At this moment I only do not see 1<<PA1 -> how this works equally in xmega

So doing the LED blink on the XMega - and comparing that with how you did it on the AVR - would show you exactly that!

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

Greg_Muth wrote:

```// Generic Port Pins
#define PIN0_bm 0x01
#define PIN0_bp 0
#define PIN1_bm 0x02
#define PIN1_bp 1```

Where, presumably,

• the "_bm" suffix means "bit mask"

• the "_bp" suffix means "bit position"

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Dec 28, 2015 - 06:31 PM

The xMega IO system is quite different. I like it, but it is a lot different from tiny and mega AVR.

Get to know it. Then look at your mega source and you'll likely find just a few adaptations will make it work smoothly on xMega.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

Torby wrote:
The xMega IO system is quite different.

Hence, as I say, the OP has to start again from basics with it - trying to treat it as if it's just the same as the Mega is not going to work!

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

Yesterday I reviewed my code and changed the rest of it. I am aware that things work differently.
I changed the rest of my code as well, at this moment it compiles without errors.

Unfortunately I cannot test, because I cannot select a simulator nor my programmer (probably because my computer needs a reinstall).
Will try to fix it today. Then I can test if I did it correct ;-)

Furthermore the remarks concerning the header file were extremely helpful with respect to my question.

@awnail, when I mentioned I wrote and ran those programs I did that on xmega (it is how I started with mega and also how I started with xmega -> without those steps you are unable to go further)

Last Edited: Wed. Dec 30, 2015 - 05:25 AM