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

[Буратино]

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

[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 файл линкера. Если сумма сегмента данных, объема стека и динамической кучи (если вы ее используете) укладывается в размер ОЗУ вашего процессора, скорее всего все будет работать нормально.

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