sbi and cbi on Xmega

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi to all,
a question on xmega.
I ma made a simple C program that blink a led using the virtual port1. I don't use the toggle bit but I SET and CLEAR the bit.

so if I write
VPORT1.OUT |= (1<<1);

WHY THE COMPILER DOESEN'T USE THE sbi INSTRUCTION AND WRITE SO MUCH INSTRUCTIONS?

IN R24,0x15 In from I/O location
ORI R24,0x02 Logical OR with immediate
STD Z+1,R24 Store indirect with
SER R24 Set Register
SER R25 Set Register
LDI R18,0x00 Load immediate

And so also for to clear the bit?
what I've to write for to permit at the compiler to optimize and use the SBI instruction?
I'm using the "Os" optimization.
Thanks.
Davide

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because you are doing a compound bitwise OR operation and assignment operation with the register, this will generate what is commonly called "read-modify-write" assembly code. This explains the IN,ORI,STD sequence that you see above. I don't know what is going on with the SER,SER,LDI instructions without seeing a true listing of your code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, you're right, but why on an mega32 the code:
PORTD |= (1<<0)
is compiled as:
sbi POTRD,0?
why on xmega not?

How can I use the sbi instruction on xmega for optimize the code?

Here's the code that I use for xmega.

void My_Example2( void )
{
static uint8_t flag = 0;
uint16_t loop_del = 0;
// Map the ports.
PORT_MapVirtualPort1(PORTCFG_VP1MAP_PORTD_gc );
// Configure VPORT0 as input and VPORT1 as output.
PORT_SetDirection( &VPORT1, 0xFF );
while (true)
{
for(loop_del=65535; loop_del >0; --loop_del);
if(flag==1)
{
VPORT1.OUT |= (1<<0);
flag = 0;
}
else
{
VPORT1.OUT &= ~(1<<0);
flag = 1;
}
}
}

Thanks
Davide

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just noticed this behavior too:

VPORT1.OUT &= (uint8_t)~_BV(0);

generates:

IN        R24,0x15       In from I/O location
ANDI      R24,0xFE       Logical AND with immediate
ADIW      R26,0x01       Add immediate to word
ST        X,R24          Store indirect
SBIW      R26,0x01       Subtract immediate from word

Why is the compiler not using the SBI / CBI instructions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I may be naive here, but I always thought that this situation is why the chip designers of the Xmega (and ARM) gave us not only the OUT register, but also the OUTSET, OUTCLR, and OUTTGL registers.

Now, the Xmega designers saw the ugly mess they were creating out of AVR I/O space, and tossed us the virtual port thingy. For all ports? ... Nooooo, that would be too easy.

I guess the first question I'd have is whether you get the same behaviour at all optimization levels. The next would be what the result is if you do a very plain assignment of a single bit--e.g. "VPORT1.OUT = 0x04;"

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I installed the latest winavr package and now the sbi and CBI instructions are used with the virtual ports.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

darighi wrote:
WHY THE COMPILER DOESEN'T USE THE sbi INSTRUCTION [...]
The compiler is limited to to using instructions as they are allowed to be used. The SBI and CBI instructions are limited to I/O ports in the range 0 to 0x1f. Most of the xmega I/O ports are outside that range.

Note, however, that the VPORTs are in the range useable by SBI/CBI. If you want the compiler to use SBI/CBI you'll have to learn how to use the VPORTs.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I may be naive here, but I always thought that this situation is why the chip designers of the Xmega (and ARM) gave us not only the OUT register, but also the OUTSET, OUTCLR, and OUTTGL registers.

They are truly glorious. Not only do they give you the flexibility to force the compiler to avoid a read-modify-write cycle, you also get the associated benefits; namely much faster maximum I/O toggling rates, as well as guaranteed atomic operations since the writes can be performed in a single operation.

Learing the XMEGA and UC3 features during my internship is giving me a big sense of love for both of them -- as soon as I get back home, I'm going to see what I can do with them and some native C code.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

a big sense of love for both of them

Do you get exposure to the ARM chips and especially the Cortex ones there?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel Norway is only AVRs, so no. I'd like to get into ARMs some day, but for now the UC3's capabilities are doing a good job of snagging my interest.

I need to decide on a thesis subject this year that involves electronics, so I'll probably find a use for a UC3 in there as the brain of it.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but for now the UC3's capabilities are doing a good job of snagging my interest

Dean,

I know you are the "man from Atmel" but I'd really suggest putting effort into ARM rather than AVR32 (or even Xmega) if looking for the "next step up" from AVR8. As I say this does not preclude continuing to concentrate on Atmel silicon but it'd really help if they could get a bit of a shifty on with the M0 and M3's !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eventually I'll get experience with ARMs, but despite what the nay-sayers are saying here my experience with the AVR32s have been a good one; they've got a LOT of power for a small package. Not the same thing as an ARM for multimedia (the AVR32 APs are out of production I think, which are designed for multimedia stuff) but for applications just needing a lot of capabilities in a small package they're great.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!