WinAvr в вопросах и ответах

[redradist]

Народ у меня проблема с WinAVR, помогите !!!! Короче установил WinAVR-20100110 вроде все нормально ... Студия версии 4.18 . Скачал проект управление RGB светодиодами с помощью ШИМ, компилирую исходники проекта - всё нормально ... Как только начинаю в исходнике, что-то изменять компилятор начинает неверно компилировать, то есть например в функции удалил одну строку, вроде бы все нормально компилируется, но программа не работает ... начинаюю разбираться, открываю дезасемблированый код и что я вижу по программе в ассемблере нету некоторых строк которые есть на С ... Смешаю эту строку которая не откомпилировалась с помощью Enter-ов, открываю дезассемблер после компиляции и О чудо строка появилась и при отладке выполняетссяя нормально ... Но дальше также, кое какие строки на Си есть, а в асм нет ... и при отладке программа работает неправильно и кое где зависает ...
Что это такое, подскажите как от этого избавиться, может WinAVR-20100110 глячыыйй !!!!!!!!!!!!!

[ARV]

вы просто не владеете в должной мере языком Си - это факт. а без конкретного кода (исходного и вами переделанного) никаких более конкретных рекомендаций вам никто не даст - напряг с экстрасенсами среди электронщиков...

[redradist]

К примеру этот код компилируется нормально:
//R_channel=PB1
//G_channel=PB2
//B_channel=PB3
#include <avr/io.h>

#define R_channel OCR0A
#define G_channel OCR1AL
#define B_channel OCR1BL

unsigned Pov = 0, Kash = 500, r =0, g = 0, b = 0;

SIGNAL0(SIG_INTERRUPT0)
{
if(Kash>100)
{
Kash=Kash-50;
}
}

SIGNAL1(SIG_INTERRUPT1)
{
if(Kash<1000)
{
Kash=Kash+50;
}
}

ISR(TIMER0_OVF_vect)
{
Pov++;
if(Pov==Kash)
Pov = 0;
else if(r<255)
{
R_channel--;
G_channel++;
r++;
}
else if(g<255)
{
G_channel--;
B_channel++;
g++;
}
else if(b<255)
{
B_channel--;
R_channel++;
b++;
}
else
r = g = b = 0;
return 1;
};

void init_pwm()
{


DDRB=0x1C;
TCCR1A=(1<<COM1A1)|(1<<COM1B1)|(1<<WGM10);
TCCR1B=(1<<CS10);
TCCR0A=(1<<COM0A1)|(1<<WGM00);
TCCR0B=(1<<CS00);
OCR0A=0xFF;
OCR1AL=0x00;
OCR1BL=0x00;
}
int main(void)
{
init_pwm();
while(1)
{
}
}

А вот это не компилируется должным образом:
//R_channel=PB1
//G_channel=PB2
//B_channel=PB3
#include <avr/io.h>

#define R_channel OCR0A
#define G_channel OCR1AL
#define B_channel OCR1BL

unsigned Pov = 0, Kash = 500, r =0, g = 0, b = 0;

SIGNAL0(SIG_INTERRUPT0)
{
if(Kash>100)
{
Kash=Kash-50;
}
}

SIGNAL1(SIG_INTERRUPT1)
{
if(Kash<1000)
{
Kash=Kash+50;
}
}

ISR(TIMER0_OVF_vect)
{
Pov++;
if(Pov==Kash)
Pov = 0;
else if(r<255)
{
R_channel--;
G_channel++;
r++;
}
else if(g<255)
{
G_channel--;
B_channel++;
g++;
}
else if(b<255)
{
B_channel--;
R_channel++;
b++;
}
else
r = g = b = 0;
return 1;
};

void init_pwm()
{
DDRB=0x1C;
TCCR1A=(1<<COM1A1)|(1<<COM1B1)|(1<<WGM10);
TCCR1B=(1<<CS10);
TCCR0A=(1<<COM0A1)|(1<<WGM00);
TCCR0B=(1<<CS00);
OCR0A=0xFF;
OCR1AL=0x00;
OCR1BL=0x00;
}
int main(void)
{
init_pwm();
while(1)
{
}
}

В чем подвох ... В асемблерном тексте просто отсутствуют строка DDRB=0x1C; ... И что ж Я не владею должным образом С ?

[asteroid7]

А какой смысл "удалённой" строки? Что она есть, что её нету - ничего не меняется. Оптимизатор её и выкинул, т.к. к порту "B" вообще нет обращений.

p.s. код в приведённых примерах не имеет отличий. за исключением двух CR CR в void init_pwm()

[ARV]

А какой смысл "удалённой" строки? Что она есть, что её нету - ничего не меняется. Оптимизатор её и выкинул, т.к. к порту "B" вообще нет обращений.

оптимизатор не мог выкинуть DDRB ни при каких условиях, т.к. DDRB определена как volatile-переменная. ща посмотрим, что на самом деле происходит

[ARV]

докладываю по первому варианту:
1. компилится с кучей варнингов, но без ошибок.
2. прерывания у вас возвращают результат - это странно.
3. SIGNAL для обработчиков прерываний давно не рекомендовано к применению

второй вариант:
1. компилится с теми же замечаниями, что и первый вариант.
2. в результате генерируется 100% идентичный первому варианту hex.

что там у вас не так - сие мне не ведомо.

[redradist]

Всем спасибо, я понял ошибку ... Я забыл добавить файл #include <avr/interrupt.h> и поэтому он пропускал иногда при компиляции строки и неправильно компилировал ... Компилятор просто не знал макросы функций ISR и остальных ...

[asteroid7]

оптимизатор не мог выкинуть DDRB ни при каких условиях, т.к. DDRB определена как volatile-переменная. ща посмотрим, что на самом деле происходит

Как же мне хотелось плюсануть компилятору WinAvr за AI. Определив, что порты используют альтернативные функции... Жёсткий volatile убил мой плюс

[TICLIR]

Здравствуйте,у меня сново непонятки,в динамической индикации, а конкретно опрос кнопок вот первый код при котором в протеусе всё работает,а на железе почему то не работает кнопка которая подключена к нижнему по коду порту т.е. на 4 индикатор, а кнопок у меня 3 так как на 1 индикаторе сделано гашение не значещего 0.

Код: Выделить всё

 void matt (int f){ //функ динамической индикации с опросом кнопок //////////////////////////
 if(razr==0){
  m=f/100;
  h2_0;h3_0;h4_0; //тушим 2-3-4 индикатор
  if(m){cifr(m);h1_1;} // зажигаем 1
  }
  if(razr==1){
  m=(f%100)/10;
 h1_0;h3_0;h4_0;
 cifr(m);h2_1;
 }
  if(razr==2){
   m=(f%100)%10;
  h1_0;h2_0;h4_0;
 cifr(m);h3_1;
 }
  if(razr==3){
  m=parm;
  h1_0;h2_0;h3_0;cifr(m);h4_1;
  }
 if(PINC&0x20){
   knop|=(1<<(razr));//  и запись в переменную knop 
   }
  else {
  knop&=~(1<<(razr));
   }
  if((PINC&0x20)!=0)knop_c=knop;//вспомогат перемен для выдержки времени
 razr++;
 if(razr>3) razr=0;
 return;
 } 

Но стоило мне поменять порядок, вот так

Код: Выделить всё

 /**********функ динамической индикации с опросом кнопок **********/
 void matt (int f){ 
 if(razr==3){
  m=parm;_delay_us(80);
  h1_0;h2_0;h3_0;dp0;cifr(m);h4_1;
  }
   if(razr==2){
   m=(f%100)%10;
  h1_0;h2_0;h4_0;dp0;
 cifr(m);h3_1;;
 }
 if(razr==1){
  m=(f%100)/10;
 h1_0;h3_0;h4_0;
 cifr(m);h2_1;dp1;
 }
 if(razr==0){
  m=f/100;
  h2_0;h3_0;h4_0;dp0;
  if(m){cifr(m);h1_1;_delay_us(80);}
  }
  if(PINC&0x01){
   knop|=(1<<(razr));//  и запись в переменную knop 
   }
  else{
  knop&=~(1<<(razr));
  }
  if(PINC&0x01)knop_c=knop;//вспомогат перемен для выдержки времени
 razr++;
 if(razr>3) razr=0;
 return;
 } 

и всё заработало,и всё бы хорошо, да интересно в чём дело?

[Ar-Gen-Tum]

WinAVR хороший компилятор. Его, разве что, надо "уметь готовить".
Makefile, как правило содержит опцию создания листинга, на ассемблере.
Посему деассемблировать код смысла ваще никакого нет.
Можно добавить опцию создания файла программы на ассемблере.
(Смотрю в листинг частенько, не "намудрил-ли" чего оптимизатор.)

[ARV]

функ динамической индикации с опросом кнопок

вы, что ли, не по прерыванию делаете динамическую индикацию? или эту функцию вызываете из обработчика прерывания? и то и другое - весьма нехорошо, первое - просто ужасно. и, судя по всему, вы еще и вычисление символов делаете в этой функции?! это просто ужасно!

чтобы все хорошо работало, надо следовать давным давно продуманным алгоритмам. например, я старался описать их в своей статье http://arv.radioliga.com/content/view/172/49/
а по поводу подготовки данных для индикации - в этой статье http://arv.radioliga.com/content/view/106/49/

рекомендую ознакомиться. надеюсь, алгоритмы вам понравятся и вы сделаете свою программу лучше, понятнее, проще и, главное, успешно работающей.

[VasaShmidt]

Здравствуйте! Уважаемые знатоки, подскажите, как в WinAvr работать с сегментами памяти контроллера. Проблема такая: есть сегмент данных контроллера, в котором надо выделить несколько маленьких сегментиков. В каждый из сегментиков надо напихать разных переменных и иметь возможность обращаться к ним как по имени переменной, так и просто в начало сегментика ткнуться. В IAR все необходимые манипуляции можно было совершить при помощи таких конструкций, как:
#pragma memory dataseg=my_seg
__segment_begin("my_seg")
__segment_end("my_seg")
Есть ли что-нибудь аналогичное для WinAvr? Подскажите хотябы, куда копать... Дня три уже из гугля не вылезаю...

[lix]

а зачем это надо?

[VasaShmidt]

Для попытки реализации ModBus. Предвосхищая подобные вопросы:
- ModBus по ТЗ нужен;
- именно так реализовать хочу попробовать, потому что другие варианты, пришедшие мне в голову, отмелись по разным причинам на зачаточной стадии;
- переписывать в IAR или ещё в чём-то не вариант, ибо остальной кусок проги весьма велик и написан в WinAVR.

[avreal]

а зачем это надо?

Например, собирать какие-то таблицы (структур-описателей обработчиков) из разных .c файлов в одну секцию для последующей обработки. При этом достаточно добавить исходник к проекту, и его обработчик появится в таблице автоматически. Очень удобно.

Код: Выделить всё

// cmd.h
typedef struct {
  // bla-bla-bka
} command_t;

// file1.c
command_t cmd1 SECTION(cmd_section) = { ... }; // поместили в секцию cmd_section

// file2.c
command_t cmd2 SECTION(cmd_section) = { ... }; // поместили в секцию cmd_section

// file3.c
void foo() {
    command_t *cmd_table = SECTION_BEGIN(cmd_section);
    int total_commands = (SECTION_END(cmd_section) - SECTION_BEGIN(cmd_section)) / sizeof(command_t);
    //    и тут спокойно работаем
}

VasaShmidt, давно собирался на эту тему мини-статеечку написать, похоже, таки доберусь сегодня-завтра.
Если раньше никто не ответит, то я это дело устрою.

___________
Всё, побёг я домой.

[Ar-Gen-Tum]

...
Проблема такая: есть сегмент данных контроллера, в котором надо выделить несколько маленьких сегментиков. В каждый из сегментиков надо напихать разных переменных и иметь возможность обращаться к ним как по имени переменной, так и просто в начало сегментика ткнуться. В IAR все необходимые манипуляции можно было совершить при помощи таких конструкций, как:
...

А объявление просто структуры не подходит?
Можно ведь объявить много маленьких структур, а в них напихать много маленьких переменных.
Переменные в свою очередь тоже могут быть структурами.
Сегмент обычно понятие физическое. Например минимальный блок флеш-памяти,
стираемый за раз.

[VasaShmidt]

avreal, спасибо Вам огромное! Именно то, что надо! C нетерпением жду статью

Ar-Gen-Tum, просто структура не подходит. Просто надо бы иметь набор абсолютно не связанных между собой по смыслу переменных, которые в определённый момент можно было бы прочитать как массив байт. Если это реализовать структурой, то, во-первых, это вызовет большую путаницу с именами, а во-вторых, не очень удобно её трансформировать в массив. Поэтому и хочу попробовать вот такое вот извращение, подсмотренное когда-то для IAR.

[ARV]

Ar-Gen-Tum, просто структура не подходит. Просто надо бы иметь набор абсолютно не связанных между собой по смыслу переменных, которые в определённый момент можно было бы прочитать как массив байт. Если это реализовать структурой, то, во-первых, это вызовет большую путаницу с именами, а во-вторых, не очень удобно её трансформировать в массив. Поэтому и хочу попробовать вот такое вот извращение, подсмотренное когда-то для IAR.

имхо, по-моему вы правы: это извращение! ведь как вы узнаете, какой байт в этом "сплошном" массиве принадлежит той или иной переменной? линкер ведь вправе размещать переменные по своему усмотрению в любом порядке - мотивы его поведения могут быть от вас скрыты...

и даже логическое противоречие просматривается: переменные логически не связаны, но объединять их в кучу - значит, уже находить нечто общее... а раз есть что-то общее - они логически связаны и, следовательно, структура для них подойдет

[VasaShmidt]

линкер ведь вправе размещать переменные по своему усмотрению в любом порядке - мотивы его поведения могут быть от вас скрыты...

Если я правильно поняла, то для реализации того, что я задумала, придётся мне писать скрипт для линкера. Логично предположить, что с ним можно будет договориться, что и куда размещать.

и даже логическое противоречие просматривается: переменные логически не связаны, но объединять их в кучу - значит, уже находить нечто общее... а раз есть что-то общее - они логически связаны и, следовательно, структура для них подойдет

Переменные будут группироваться в кучи по принципу разрешения чтения/записи для компьютера. (Если посмотреть в протокол ModBus, там будет две таблички регистров - из одной таблички можно только читать, а в другую можно ещё и писать.) На мой взгляд, объединять по этому принципу в одну структуру массив ошибок и данные с АЦП как-то странно... Поэтому и хочу попробовать сделать именно так. Может быть, если бы я хотябы что-то писала на Си до этого, я бы и придумала какое-нибудь решение поадекватнее, но, к сожалению, я программист по ошибке Так что буду Вам благодарна, если подскажете что-нибудь дельное, кроме структуры.

[ARV]

вы поняли правильно, скрипт и т.п. - в результате программа теряет основное качество хорошо написанной программы: портируемость. даже если вы не планируете сейчас портировать ее на другой компилятор, платформу, микроконтроллер и т.п. - качество программы все равно должно быть определяющим.

ну а в остальном я вам вряд ли помогу - не в моих правилах советовать то, что я сам бы не стал делать...