Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Структура массивов
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Буратино
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];


то все в поряде laughing.gif
Rst7
Никак volatile где-то забыт?

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

Получается, Что в Tx_Buffer[7],Tx_Buffer[8],Tx_Buffer[9] заливается первым (верхним в листинге) Buffer_Values._Time_SensorSH[IndexArr] cranky.gif
Сергей Борщ
Цитата(Буратино @ Jul 17 2009, 19:24) *
Проц - Mega88 (SRAM 1024 байта)
На стеке данных размещается структура размером 555+22+44 байта. Можно предположить, что стек налезает на данные или стек данных налезает на стек возврата.
Буратино
Полный абзац. Меняю размерности массивов, все подвисает и глючит.
Не может это быть связано с размером кода на выходе? Размер получаемого файла *.HEX с максимальной оптимизацией равен 3,81к, без нее 5,69к
Я раньше пробовал использовать ICCAVR, он сообщал программисту сколько использовано флеши, как в ИАре посмотреть сколько остается?
MrYuran
Цитата(Буратино @ Jul 18 2009, 14:27) *
как в ИАре посмотреть сколько остается?

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

А зачем эта структура локальная?
Локальные переменные не следует использовать без прямой на то необхдимости.(Впрочем, как и глобальные конечно).
Переместите их объявление выше мэйна и все перестанет глючить.
Сергей Борщ
Цитата(Буратино @ Jul 18 2009, 13:27) *
Не может это быть связано с размером кода на выходе?
Нет. Если бы не хватало флеша, компилятор вам сообщил бы об этом и не смог бы сделать hex.
Цитата(Буратино @ Jul 18 2009, 13:27) *
Я раньше пробовал использовать ICCAVR, он сообщал программисту сколько использовано флеши, как в ИАре посмотреть сколько остается?
Во-первых включите выдачу всех сообщений (Tools->Options->Messages->Show build messages-> all). Размер занятого ОЗУ и флеша будет показан в окне Messages после линковки. Но вы вообще понимаете, что у АВРа совершенно разные адресные пространства ОЗУ и флеша? И что проблемы ваши в ОЗУ. Сколько ОЗУ вы зарезервировали под стек данных?
Цитата(DpInRock @ Jul 18 2009, 14:13) *
Переместите их объявление выше мэйна и все перестанет глючить.
Смелое заявление.
Буратино


Цитата(DpInRock @ Jul 18 2009, 15:13) *
А зачем эта структура локальная?
Локальные переменные не следует использовать без прямой на то необхдимости.(Впрочем, как и глобальные конечно).
Переместите их объявление выше мэйна и все перестанет глючить.

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

Цитата(Сергей Борщ @ Jul 18 2009, 15:44) *

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
DpInRock
Чисто теор., локальные данные располагаются в стеке. И чисто теоретически, такая память под стек считается разделяемой с другими переменными, такими же локальными. Но когда локальная переменная занимает всю оперативную память - как тут компилятор справляетя - не знаю. И знать не хочу.
Буратино
вынес за main объявление структуры, увеличил размер стека с 0х20 до 0х40 все встало на свои места laughing.gif
sergeeff
Коллега Борщ вам же даже посчитал, что ваша структура массивов требует чуть менее 1 Кб ОЗУ. А вы имели резерв под стек 32 байта и при этом всем морочите голову, почему ни хрена не работает.

Замечания про то, что компилятор сам мол знает сколько надо памяти под разные типы данных и сам там чего-то выделяет - вредное заблуждение.
Буратино
Цитата(sergeeff @ Jul 18 2009, 20:22) *
Коллега Борщ вам же даже посчитал, что ваша структура массивов требует чуть менее 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 и "застолбить" это число в настройках ИАра? А шо, "оно само" никак не могло научится делать это за меня? smile.gif
И потом, нафиг вообще эти массивы пихать в стек? Что они там забыли? Ниче не понимаю.
sergeeff
Цитата(Буратино @ Jul 19 2009, 03:41) *
И потом, нафиг вообще эти массивы пихать в стек? Что они там забыли? Ниче не понимаю.


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

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

Если вы используете прерывания, там могут быть дополнительные нюансы.
Буратино
Цитата(sergeeff @ Jul 19 2009, 16:06) *
укладывается в размер ОЗУ вашего процессора, скорее всего все будет работать нормально.

"Скорее всего", меня не устраивает. Что если самолет или кораблик опираясь на это ваше "скорее всего" улетит, поплывет в сторону заполярного круга? Мне нужно чтобы все было ровно так как я хочу.
Сейчас у меня один сплошной глюк. Например: в программе есть что-то типа:
Код
    
...  
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 заливаются левые значения и все нафиг виснет. cranky.gif
Ясное дело, что я не знаю, не понимаю, не умею и ваще деревянный, но что делать?
Буратино
Таакс ,дело сдвинулось с мертвой точкиsmile.gif
Переместил объявление структуры назад в "main" и увеличил размер стека аш до 500 байт.
Около часа полет нормальный.
Нужно наверное садиться за книгиsmile.gif
sergeeff
Цитата(Буратино @ Jul 19 2009, 18:27) *
Нужно наверное садиться за книгиsmile.gif


Книги читать безусловно полезно, но что-то мне ни одна не попадалась, где излагалось то, про что я вам зжато рассказал. Может только в
help'ах на компилятор/линкер можно что-то найти.

Удачи!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.