Структура массивов, Совсем что-то все плохо:( Опции

[Буратино]

IAR C/C++ Compiler for AVR
5.10A/W32 [Evaluation] (5.10.1.3)
Проц - Mega88 (SRAM 1024 байта)

Код

main
{
...
  struct{ //объявляю структуру данных
    unsigned long
     _Arr_Shift_Delay[11];
    unsigned char
     _Arr_Nomer_Datchika[11],
     _Num_Sensor[111],
     _BAT_Sensor[111],
     _Time_SensorSH[111],
     _Time_SensorH[111],
     _Time_SensorL[111];
  }  Buffer_Values;

         IndexArr=0;
         Buffer_Values._Time_SensorSH[IndexArr]=(temp_timer>>16); // Инициализирую поля в структуре
         Buffer_Values._Time_SensorH[IndexArr]=(temp_timer>>8);
         Buffer_Values._Time_SensorL[IndexArr]=(temp_timer);

         Tx_Buffer[7]=Buffer_Values._Time_SensorSH[IndexArr]; // Считываю значения в массив "Tx_Buffer"
         Tx_Buffer[8]=Buffer_Values._Time_SensorH[IndexArr];
         Tx_Buffer[9]=Buffer_Values._Time_SensorL[IndexArr];
...
}

Блин, а че это в массиве Tx_Buffer левые значения?
если грузить Tx_Buffer вот так:

Код

         IndexArr=0;
         Buffer_Values._Time_SensorSH[IndexArr]=(temp_timer>>16);  
              Tx_Buffer[7]=Buffer_Values._Time_SensorSH[IndexArr];
         Buffer_Values._Time_SensorH[IndexArr]=(temp_timer>>8);
              Tx_Buffer[8]=Buffer_Values._Time_SensorH[IndexArr];
         Buffer_Values._Time_SensorL[IndexArr]=(temp_timer);
             Tx_Buffer[9]=Buffer_Values._Time_SensorL[IndexArr];

то все в поряде

Сообщение отредактировал Буратино - Jul 17 2009, 16:49

[Rst7]

Никак volatile где-то забыт?

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

[Буратино]

Не, никаким местом оно к прерываниям не касается.
Все внутри main. Многоточия вообще можно убрать. Мелочь какая или ошибка. пол дня сижу, не могу понять что не так

Получается, Что в Tx_Buffer[7],Tx_Buffer[8],Tx_Buffer[9] заливается первым (верхним в листинге) Buffer_Values._Time_SensorSH[IndexArr]

Сообщение отредактировал Буратино - Jul 17 2009, 16:53

[Сергей Борщ]

Проц - Mega88 (SRAM 1024 байта)

На стеке данных размещается структура размером 555+22+44 байта. Можно предположить, что стек налезает на данные или стек данных налезает на стек возврата.

[Буратино]

Полный абзац. Меняю размерности массивов, все подвисает и глючит.
Не может это быть связано с размером кода на выходе? Размер получаемого файла *.HEX с максимальной оптимизацией равен 3,81к, без нее 5,69к
Я раньше пробовал использовать ICCAVR, он сообщал программисту сколько использовано флеши, как в ИАре посмотреть сколько остается?

Сообщение отредактировал Буратино - Jul 18 2009, 10:29

[MrYuran]

как в ИАре посмотреть сколько остается?

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

[DpInRock]

Меняю размерности массивов

А зачем эта структура локальная?
Локальные переменные не следует использовать без прямой на то необхдимости.(Впрочем, как и глобальные конечно).
Переместите их объявление выше мэйна и все перестанет глючить.

Сообщение отредактировал DpInRock - Jul 18 2009, 11:20

[Сергей Борщ]

Не может это быть связано с размером кода на выходе?

Нет. Если бы не хватало флеша, компилятор вам сообщил бы об этом и не смог бы сделать hex.

Я раньше пробовал использовать ICCAVR, он сообщал программисту сколько использовано флеши, как в ИАре посмотреть сколько остается?

Во-первых включите выдачу всех сообщений (Tools->Options->Messages->Show build messages-> all). Размер занятого ОЗУ и флеша будет показан в окне Messages после линковки. Но вы вообще понимаете, что у АВРа совершенно разные адресные пространства ОЗУ и флеша? И что проблемы ваши в ОЗУ. Сколько ОЗУ вы зарезервировали под стек данных?

Переместите их объявление выше мэйна и все перестанет глючить.

Смелое заявление.

[Буратино]

А зачем эта структура локальная?
Локальные переменные не следует использовать без прямой на то необхдимости.(Впрочем, как и глобальные конечно).
Переместите их объявление выше мэйна и все перестанет глючить.

Сейчас попробую. Дело в том ,что я намеряно снес все в "маин" так как посчитал ,что компилятору будет легче с локальными данными. В принципе локально они мне и нужны.

2 176 bytes of CODE memory (+ 8 range fill )
483 bytes of DATA memory (+ 42 absolute )

Код

  struct{
    unsigned long
     _Arr_Shift_Delay[11];
    unsigned char
     _Arr_Nomer_Datchika[11],
     _Num_Sensor[50],
     _BAT_Sensor[50],
     _Time_SensorSH[50],
     _Time_SensorH[50],
     _Time_SensorL[50];
  }  Buffer_Values;

Errors: none

Сообщение отредактировал Буратино - Jul 18 2009, 11:56

[DpInRock]

Чисто теор., локальные данные располагаются в стеке. И чисто теоретически, такая память под стек считается разделяемой с другими переменными, такими же локальными. Но когда локальная переменная занимает всю оперативную память - как тут компилятор справляетя - не знаю. И знать не хочу.

[Буратино]

вынес за main объявление структуры, увеличил размер стека с 0х20 до 0х40 все встало на свои места

[sergeeff]

Коллега Борщ вам же даже посчитал, что ваша структура массивов требует чуть менее 1 Кб ОЗУ. А вы имели резерв под стек 32 байта и при этом всем морочите голову, почему ни хрена не работает.

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

[Буратино]

Коллега Борщ вам же даже посчитал, что ваша структура массивов требует чуть менее 1 Кб ОЗУ. А вы имели резерв под стек 32 байта и при этом всем морочите голову, почему ни хрена не работает.

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

Я слабо знаком с внутренним устройством и принципами работы компилятора (точнее совсем не знаком), а электроника и программирование для меня всего лишь хобби.
НО я считал, что если я объявил массив/структуру массивов, то за писят лет построения компиляторов можно было сделать так, чтоб я потом мог работь с данными а не ловить глюки в самых экзотических местах.
Дело было так:
У меня маленькая система управляемых по радиоканалу датчиков. Каждый из них общается с главным модулем, который сливает инфу на камп (тоже по радиолинку).
Для того, чтоб получаемые данные сто процентно доставлялись к кампу, я сделал некое подобие буфера, куда откладывается инфа, которая по мере возможности передается в систему.
Вот этот (урезаный) буфер:

Код

  struct{
    unsigned long
     _Arr_Shift_Delay[11];
    unsigned char
     _Arr_Nomer_Datchika[11],
     _Num_Sensor[20],
     _BAT_Sensor[20],
     _Time_SensorSH[20],
     _Time_SensorH[20],
     _Time_SensorL[20];
  }  Buffer_Values;

Данные помещаются в конец, а читаются с начала. Типа кто первый пришел, тот первым и уйдет.

Но даже с таким маленьким буфером глюки остались. В процессе работы, когда буфер заполняется информацией, случается, что реальные данные в нем "портятся":( Естественно это приводит к полному краху всей дальнейшей работы.

Мне нужно под стек еще больше чем 0х40? Типа посчитать в экселке размер всех моих переменных и структуры, накинуть процентов 20 и "застолбить" это число в настройках ИАра? А шо, "оно само" никак не могло научится делать это за меня?
И потом, нафиг вообще эти массивы пихать в стек? Что они там забыли? Ниче не понимаю.

Сообщение отредактировал Буратино - Jul 19 2009, 00:00

[sergeeff]

И потом, нафиг вообще эти массивы пихать в стек? Что они там забыли? Ниче не понимаю.

Это вы очень верно про себя написали. Куда и чего "пихать" - это ваше личное дело. Обычно стековые переменные обрабатываются быстрее, но при этом "видны" (т.е. могут читаться/писаться) только в той процедуре, где они объявлены. Контроль потребного размера стрека - нетривиальная задача, т.к. функции вызывают друг друга в достаточно сложных сочетаниях, не говоря уже о рекурсивных функциях.

Если ваш проект несложен, то можно все крупные структуры данных сделать глобальными, и тогда суммарный объем памяти можно легко проконтролировать, изучая map файл линкера. Если сумма сегмента данных, объема стека и динамической кучи (если вы ее используете) укладывается в размер ОЗУ вашего процессора, скорее всего все будет работать нормально.

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

[Буратино]

укладывается в размер ОЗУ вашего процессора, скорее всего все будет работать нормально.

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

Код

    
...  
for(j=0;j<11;j++)    
{
   Buffer_Values._Arr_Nomer_Datchika[j]=1;          //цикл инициализации массива маски
}
...
for(j=0;j<11;j++)
{
   if ( Buffer_Values._Arr_Nomer_Datchika[j]==1)       //       проверка маски
   {  
       ...
   }
}
...

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

Сообщение отредактировал Буратино - Jul 19 2009, 13:57