Си-шный компилятор в AVR Studio меняет последовательность команд

[svv11]

Си-шный компилятор в AVR Studio меняет последовательность команд, как это блокировать?
Разбираясь почему нет нормального обмена с внешним АЦП просматривал дизассемблер и увидел такую вот граблю. Получалось, что чтение происходило раньше чем на пине формировался синхросигнал, хотя в Си-шном коде последовательность правильная и код линейный. Я так понимаю компилятор переставил команды, чтобы не загружать лишний раз переменную из RAM. Может есть какая либо директива которая бы локально отключала всякую компиляцию в фрагменте и компилировала как есть? Стал писать ассемблерную вставку, но на будущее хотелось бы обходиться по возможности без вставок, больно уж много всяких правил в этом В Си-шном ассемблере, до сих пор есть вопросы как правильно обращаться к переменным. Может кто подскажет где посмотреть программы с примерами, у Шпака как-то не всё понятно.

[Nikopol]

Напишите кусок на асме и вставьте куда надо через директиву asm. Компилятор уж точно не будет оптимизировать код.

[svv11]

Написал на ассемблере да не пойму в чём ошибка, студия ругается.
Вот фрагмент, где тут грабли?

//---------------------------------------------------------------
unsigned short	Signal;

  asm volatile
    (
    "LDS r24,0x0708" "\n\t" /* PORTJ.IN  мл. байт АЦП   */ 
    "LDS r25,0x0728" "\n\t" /* PORTK.IN 2 ст. бита АЦП */         
    "SBI 0x15,1"     "\n\t"   /* PF1=1 (~CD)                  */
    "SBI 0x15,0"     "\n\t"   /* PF0=1 (~CD)                  */
    "STS %0,R30"     "\n\t" /* сохранить мл байт          */
    "ANDI r24,0x03"  "\n\t"
    "STS %1,r25"     "\n\t" /* сохранить 2 ст. бита       */
    :"=M" (Signal & 0x00FF), "=M" (Signal ›› 8) /* выходные операторы         */
    :"0"  (Signal & 0x00FF), "1" (Signal ›› 8)     /* входные операторы           */
    :"r24", "r25"                                            /* резервирование регистров */
    );
//------------------------------------------------------------------------

нужен аналог выражения:

	Signal = ((PORTK.IN & 0x03) ‹‹ 8) | PORTJ.IN;

[_guardianangel]

Выложите код и листинг. По имеющимся данным ниче конкретного сказать не могу.

[svv11]

Выложите код и листинг. По имеющимся данным ниче конкретного сказать не могу.

Код очень объёмный, а листинг не сформируется пока не будет устранена ошибка.
Лучше так поясню:
Нужно прочитать два порта и положить результат в двух байтную переменную. В старшем байте значимы только два бита, остальные биты нужно очистить.

[SasaVitebsk]

Си-шный компилятор в AVR Studio меняет последовательность команд, как это блокировать?

Сишный компилятор не будет менять последовательность команд. Это просто бред. Особенно это касается портов ввода-вывода. Все порты ввода-вывода объявлены как volatile. Соответственно компилятор не будет даже делать оптимизацию по эти операциям.
Например допустимо написать:
PORTC;
Если бы это было бы простая переменная, то компилятор просто выкинул данную строку. А в данном случае будет сгенерирована операция чтения порта С. Результат - проигнорирован.

2. AVR Studio - не компилятор. Надоело на форумах читать такую ересь. Но хоть немного интересуйтесь теорией того, с чем вы работаете. AVR Studio - это оболочка + ассемблер + симулятор-отладчик. Компилятор Си - внешний. Я так понимаю, что GNU C вы подключили.

[_guardianangel]

Для примера набросал

#include ‹ctype.h›
#include ‹stdint.h›
#include ‹stdio.h›
#include ‹inttypes.h›
#include ‹avr/io.h›
#include ‹avr/iom16.h›


int i;

volatile int main(void)
{
	for(;;)
	{
		i = ((PINA & 0x03) ‹‹ 8) | PINB;
		PORTC = 0x02;
	}
	return(-1);
}

Листинг

tst.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000a0  00000000  00000000  00000074  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .bss          00000002  00800060  000000a0  00000114  2**0
                  ALLOC
  2 .debug_aranges 00000020  00000000  00000000  00000114  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_pubnames 00000021  00000000  00000000  00000134  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_info   00000092  00000000  00000000  00000155  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_abbrev 00000059  00000000  00000000  000001e7  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_line   0000006d  00000000  00000000  00000240  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_frame  00000020  00000000  00000000  000002b0  2**2
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_str    00000065  00000000  00000000  000002d0  2**0
                  CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:

00000000 ‹__vectors›:
   0:	0c 94 2a 00 	jmp	0x54	; 0x54 ‹__ctors_end›
   4:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
   8:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
   c:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  10:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  14:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  18:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  1c:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  20:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  24:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  28:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  2c:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  30:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  34:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  38:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  3c:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  40:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  44:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  48:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  4c:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›
  50:	0c 94 47 00 	jmp	0x8e	; 0x8e ‹__bad_interrupt›

00000054 ‹__ctors_end›:
  54:	11 24       	eor	r1, r1
  56:	1f be       	out	0x3f, r1	; 63
  58:	cf e5       	ldi	r28, 0x5F	; 95
  5a:	d4 e0       	ldi	r29, 0x04	; 4
  5c:	de bf       	out	0x3e, r29	; 62
  5e:	cd bf       	out	0x3d, r28	; 61

00000060 ‹__do_copy_data›:
  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	e0 ea       	ldi	r30, 0xA0	; 160
  68:	f0 e0       	ldi	r31, 0x00	; 0
  6a:	02 c0       	rjmp	.+4      	; 0x70 ‹.do_copy_data_start›

0000006c ‹.do_copy_data_loop›:
  6c:	05 90       	lpm	r0, Z+
  6e:	0d 92       	st	X+, r0

00000070 ‹.do_copy_data_start›:
  70:	a0 36       	cpi	r26, 0x60	; 96
  72:	b1 07       	cpc	r27, r17
  74:	d9 f7       	brne	.-10     	; 0x6c ‹.do_copy_data_loop›

00000076 ‹__do_clear_bss›:
  76:	10 e0       	ldi	r17, 0x00	; 0
  78:	a0 e6       	ldi	r26, 0x60	; 96
  7a:	b0 e0       	ldi	r27, 0x00	; 0
  7c:	01 c0       	rjmp	.+2      	; 0x80 ‹.do_clear_bss_start›

0000007e ‹.do_clear_bss_loop›:
  7e:	1d 92       	st	X+, r1

00000080 ‹.do_clear_bss_start›:
  80:	a2 36       	cpi	r26, 0x62	; 98
  82:	b1 07       	cpc	r27, r17
  84:	e1 f7       	brne	.-8      	; 0x7e ‹.do_clear_bss_loop›
  86:	0e 94 49 00 	call	0x92	; 0x92 ‹main›
  8a:	0c 94 4e 00 	jmp	0x9c	; 0x9c ‹_exit›

0000008e ‹__bad_interrupt›:
  8e:	0c 94 00 00 	jmp	0	; 0x0 ‹__vectors›

00000092 ‹main›:


int i;

volatile int main(void)
{
  92:	82 e0       	ldi	r24, 0x02	; 2
	for(;;)
	{
		i = ((PINA & 0x03) ‹‹ 8) | PINB;
  94:	99 b3       	in	r25, 0x19	; 25
  96:	96 b3       	in	r25, 0x16	; 22
		PORTC = 0x02;
  98:	85 bb       	out	0x15, r24	; 21
  9a:	fc cf       	rjmp	.-8      	; 0x94 ‹main+0x2›

0000009c ‹_exit›:
  9c:	f8 94       	cli

0000009e ‹__stop_program›:
  9e:	ff cf       	rjmp	.-2      	; 0x9e ‹__stop_program›

Вродь все правильно

[svv11]

Сишный компилятор не будет менять последовательность команд. Это просто бред. Особенно это касается портов ввода-вывода. Все порты ввода-вывода объявлены как volatile. Соответственно компилятор не будет даже делать оптимизацию по эти операциям.
Например допустимо написать:
PORTC;
Если бы это было бы простая переменная, то компилятор просто выкинул данную строку. А в данном случае будет сгенерирована операция чтения порта С. Результат - проигнорирован.

Код пишется для ATxmega128A1, порты к которым идёт обращения настроенны как виртуальные и обращение к ним идёт как к регистрам с младшими адресами - командами за 1 такт, кампилятор и не знает что это порты. Что меняет местами не сомневайтесь, я внимательно проверял.

2. AVR Studio - не компилятор. Надоело на форумах читать такую ересь. Но хоть немного интересуйтесь теорией того, с чем вы работаете. AVR Studio - это оболочка + ассемблер + симулятор-отладчик. Компилятор Си - внешний. Я так понимаю, что GNU C вы подключили.

Конечно я прекрасно понимаю, что компилятором является подключёный к студии GCC и согласен что выразился не корректно, но это для укрочения писанины, да и боялся перепутать (на работе Xmega дома PIC), поэтоме не стоит так "разорятся". Но несмотря на агресивное выступление, всё же есть за что сказать спасибо: натолкнули на мысль объявить некоторые регистры конфигурации виртуальных портов как volatile. Но это уже не в этом проекте. Всё равно прийдётся наверно воспользоваться ассемблером чтобы работал быстрей.

[svv11]

guardianangel а как бы тегами code воспользоваться, а то теряюсь в догадках, что за глазастыми смайликами спрятано. Можно наверное отредактировать то что уже выложено.

[svv11]

А не подкинет ли кто примерчик на ассемблере c синтаксисом для GCC WinAVR, или просто укажите ошибку в том фрагменте что я в начале выложил.?