перезапуск программы, непонятно почему. Опции

[simsim]

есть программа, состоит из 2-х подпрограмм А и Б, выполняемых бесконечно в while (1) {} и real-time clock по timer0.
1-я выводит массив led[32] в порт D, 2-я обновляет led[32]. Проблема - два раза цикл вывода и обновления led[32] проходит нормально, в начале 3-го происходит перезапуск контроллера, замечаю по обнулению времени и led. watchdog выключен, да и время до сброса не одно, зависит от времени выполнения циклов в А и Б, и 2 сек, и 15 сек и больше, а происходит в одной и той же точке выполнения А и Б. в чем может быть дело ? как уйти от этого сброса ?
p.s. попробую отследить в AVR Studio, поможет ? там вроде нет шагов назад.

Сообщение отредактировал simsim - Jan 16 2007, 21:17

[bodja74]

SREG и регистры сохраняются в прерывании ?

[simsim]

SREG и регистры сохраняются в прерывании ?

Прога на СИ. специально не забочусь о них.

[SasaVitebsk]

p.s. попробую отследить в AVR Studio, поможет ? там вроде нет шагов назад.

Конечно поможет. А зачем шаги назад?

[GDI]

Индексы массивов не выходят ли за границы оных, стек не переполняется? Какой компилятор? Да может и исходник бы здесь тоже не помешал..

[_Bill]

есть программа, состоит из 2-х подпрограмм А и Б, выполняемых бесконечно в while (1) {} и real-time clock по timer0.
1-я выводит массив led[32] в порт D, 2-я обновляет led[32]. Проблема - два раза цикл вывода и обновления led[32] проходит нормально, в начале 3-го происходит перезапуск контроллера, замечаю по обнулению времени и led. watchdog выключен, да и время до сброса не одно, зависит от времени выполнения циклов в А и Б, и 2 сек, и 15 сек и больше, а происходит в одной и той же точке выполнения А и Б. в чем может быть дело ? как уйти от этого сброса ?
p.s. попробую отследить в AVR Studio, поможет ? там вроде нет шагов назад.

Код в Студию!!!

[prottoss]

есть программа, состоит из 2-х подпрограмм А и Б, выполняемых бесконечно в while (1) {} и real-time clock по timer0.
1-я выводит массив led[32] в порт D, 2-я обновляет led[32]. Проблема - два раза цикл вывода и обновления led[32] проходит нормально, в начале 3-го происходит перезапуск контроллера, замечаю по обнулению времени и led. watchdog выключен, да и время до сброса не одно, зависит от времени выполнения циклов в А и Б, и 2 сек, и 15 сек и больше, а происходит в одной и той же точке выполнения А и Б. в чем может быть дело ? как уйти от этого сброса ?
p.s. попробую отследить в AVR Studio, поможет ? там вроде нет шагов назад.

Возможно, из за переполнения стека данных, реомендую увеличить в два раза. Если пользуетесь ИАРом, то по умолчанию глубина стека данных равна 0x20 (или 32 - ИМХО для того, чтобы можно было, при входе впрерывание, сохранить все 32 регистра). Если какая то процедура в программе, кроме прерывания пользуется стеком данных, естественно, он переполнится, и корабль потонет

Поменять значение можно в Главное меню->Project->Options->General Options->System->Data Stack (RSTACK)

[vesago]

Согласен с GDI 9:10 - криво проинициализировали индекс или выходит за пределы. У меня такое бывало. Проц тогда постоянно перегружается.

[simsim]

Индексы массивов не выходят ли за границы оных, стек не переполняется? Какой компилятор? Да может и исходник бы здесь тоже не помешал..

Компилятор CodeVisionAVR 1.24.8, индексы в порядке, потому что два раза проходит нормально, а на третий выполняя то же самое перезапускается. Размер стека 256 байт, неужели мало? Что такое HEAP SIZE в настройках CVAVR ?

[prottoss]

Индексы массивов не выходят ли за границы оных, стек не переполняется? Какой компилятор? Да может и исходник бы здесь тоже не помешал..

Компилятор CodeVisionAVR 1.24.8, индексы в порядке, потому что два раза проходит нормально, а на третий выполняя то же самое перезапускается. Размер стека 256 байт, неужели мало? Что такое HEAP SIZE в настройках CVAVR ?

Я не пользовал CodeVisionAVR, но для ИАРа есть два стека - первый стек данных, второй - стек программ. Первый нужен для сохранения переменных, расположенных в регистрах, второй служит для выхода из подпрограмм.

HEAP SIZE - скорее всего, размер кучи в глобальной памяти данных SRAM. Куча - это память, доступная для программы. Используется для динамически создаваемых переменных, под которые компилятор не может выделить регистр.

Допустим Вы объявили массив, как глобальную переменную - он будет создан не в куче, а на этапе запуска стартап-кода.

Если же массив будет объявлен внутри функции, то, возможно, он будет создаваться динамически, во время выполнения функции, как раз в этой самой куче.

[simsim]

Индексы массивов не выходят ли за границы оных, стек не переполняется? Какой компилятор? Да может и исходник бы здесь тоже не помешал..

Компилятор CodeVisionAVR 1.24.8, индексы в порядке, потому что два раза проходит нормально, а на третий выполняя то же самое перезапускается. Размер стека 256 байт, неужели мало? Что такое HEAP SIZE в настройках CVAVR ?

Увеличил стек до 500. Теперь перезапускается после 5-го обновления массива leds, а не 3-го как раньше. В подпрограмме обновления leds есть обращение к ассемблерной подпрограмме -
#pragma warn- // this will prevent warnings
unsigned char asm_font(unsigned char aa1, unsigned char bb1) {
#asm
.def temp =r16
.def zh =r31
.def zl =r30
.def ak =r23
.def bk =r24
.def yh =r29
.def yl =r28
..................
lpm r30,z ; результат
ret
#endasm
}
#pragma warn+ // enable warnings
Может здесь причина?

[SasaVitebsk]

Допустим Вы объявили массив, как глобальную переменную - он будет создан не в куче, а на этапе запуска стартап-кода.

Если же массив будет объявлен внутри функции, то, возможно, он будет создаваться динамически, во время выполнения функции, как раз в этой самой куче.

Для IAR даже если массив объявлен внутри ф-ции, то он всё равно будет создан "на этапе запуска стартап-кода". Даже если он и будет создан динамически (не программистом а компилятором), то он будет создан за счёт памяти выделенной под это на этапе линковки. А куча полностью предоставлена программисту. (Как в С++ не знаю). Я могу выделить память и освободить её. М/у моими действиями ничего происходить с кучей не должно. Ничего без моего участия.
Таким образом учитывая, что парень не слышал о таком слове - куча не занята, и она явно к этому не имеет никакого отношения.

[prottoss]

Допустим Вы объявили массив, как глобальную переменную - он будет создан не в куче, а на этапе запуска стартап-кода.

Если же массив будет объявлен внутри функции, то, возможно, он будет создаваться динамически, во время выполнения функции, как раз в этой самой куче.

Для IAR даже если массив объявлен внутри ф-ции, то он всё равно будет создан "на этапе запуска стартап-кода".

А я Вам говорю, что в куче, давайте поспорим Ваши аргументы какие?

[GDI]

индексы в порядке, потому что два раза проходит нормально

это ничего не значит...

Теперь перезапускается после 5-го обновления массива leds

...и это тому подтверждение

#pragma warn- // this will prevent warnings
unsigned char asm_font(unsigned char aa1, unsigned char bb1) {
#asm
.def temp =r16
.def zh =r31
.def zl =r30
.def ak =r23
.def bk =r24
.def yh =r29
.def yl =r28
..................
lpm r30,z ; результат
ret
#endasm
}
#pragma warn+ // enable warnings

Что то я не вижу сохранение в стеке используемых регистров и, соответственно, последующего их восстановления, вполне может быть, что проблема в этом. А что показала проверка в AVR Studio?

[simsim]

Для IAR даже если массив объявлен внутри ф-ции, то он всё равно будет создан "на этапе запуска стартап-кода". [/quote] А я Вам говорю, что в куче, давайте поспорим Ваши аргументы какие?
[/quote]
Куча в нуле. Пробовал делать ее 100 - безрезультатно. Похоже что стек выбивает. AVR написала что "AVR Simulator: Stack pointer changed after subroutine call", не заметил после какой, долго идет симуляция, похоже после asm_font()

[SasaVitebsk]

Индексы массивов не выходят ли за границы оных, стек не переполняется? Какой компилятор? Да может и исходник бы здесь тоже не помешал..

Компилятор CodeVisionAVR 1.24.8, индексы в порядке, потому что два раза проходит нормально, а на третий выполняя то же самое перезапускается. Размер стека 256 байт, неужели мало? Что такое HEAP SIZE в настройках CVAVR ?

Увеличил стек до 500. Теперь перезапускается после 5-го обновления массива leds, а не 3-го как раньше. В подпрограмме обновления leds есть обращение к ассемблерной подпрограмме -
#pragma warn- // this will prevent warnings
unsigned char asm_font(unsigned char aa1, unsigned char bb1) {
#asm
.def temp =r16
.def zh =r31
.def zl =r30
.def ak =r23
.def bk =r24
.def yh =r29
.def yl =r28
..................
lpm r30,z ; результат
ret
#endasm
}
#pragma warn+ // enable warnings
Может здесь причина?

Если у Вас зависит от числа вызывов, то это однозначно указывает, что у Вас плывёт указатель стэка. Одного или другого.
Зачем Вы замыливаете причину??? Просто найдите и устраните! Как собирались. Верните всё как было (всё таки два цикла меньше чем 5 гнать) и прогоните в Studio. Обратите внимание на указатель стэка в одном и том же месте.

Теперь вопрос 2. Зачем Вы путаете Си и Asm если Вы ещё в самом начале пути??? Вы уверены что регистры которые Вы портите в Asm не использует компилятор??? Простите, но для меня Ваша прога, просто лишена смысла. Как можно результат занести в регистр? И что? А если при следующей компиляции компилятор поменяет использование регистров??? Это же его право! Я понимаю ещё если бы Вы с переменной работали, а используемые регистры сохраняли. И то! Зачем Вам вообще это. Используйте чистый Си. Я уверен, - то что Вы хотите сделать на Asm можно реализовать и в рамках языка! Просто спросите в форуме - как это сделать.

Приведу пример. В начале своего последнего проекта, я хотел делать ассемблерные п/п. Чтобы ускорить работу в некоторых местах. Но решил сделать это после отладки проекта. А, сначала, всё реализовать на Си. Теперь проект закончен. И, наверное я уже просто не буду этим заниматься. У меня просто банально всё работает. Производительность отличная. Так зачем этот цирк?

[prottoss]

В подпрограмме обновления leds есть обращение к ассемблерной подпрограмме ...

Может здесь причина?

С этого и надо было начинать. А весь код то посмотреть мона?

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

Чтобы все не спорили. Массивы, объявленные внутри функции(локальные), равно как и локальные переменные, и в С и в С++ размещаются на стеке. В ИАРе на стеке данных (CSTACK). В куче в С++ размещаются объекты созданные через вызов operator new. В "голом" С в куче "само" не размещается ничего. Программист может зарезервировать себе кусочек памяти в куче библиотечными функциями malloc, calloc и в этот кусочек разместить что захочет. Иначе никак.

Как можно результат занести в регистр? И что? А если при следующей компиляции компилятор поменяет использование регистров??? Это же его право!

В защиту автора функции: В данном случае речь идет о CV, а он использует именно R30:R31 для передачи параметров и возврата значений. Это описано в его доке и просто так не поменяется.

Приведу пример. В начале своего последнего проекта, я хотел делать ассемблерные п/п. Чтобы ускорить работу в некоторых местах. Но решил сделать это после отладки проекта. А, сначала, всё реализовать на Си. Теперь проект закончен. И, наверное я уже просто не буду этим заниматься. У меня просто банально всё работает. Производительность отличная. Так зачем этот цирк?

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

Код

unsigned char pass;
unsigned char asm_font(unsigned char aa1, unsigned char bb1) {
    return ++pass;
}

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

Код

void main() {
    for(;;)
        asm_font(1,2);
}

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

[AndryG]

Не вчитывался в посты народа ... звыняйте .. в АСМ-вставке Вы используете R30 - в CVAVR - это самый главный регистр - указатель стека!!! Вот с ним Вы беду и делаете.
Если Ваша вставка - функция - подавно все развалится - прочтите раздел хелпа по функциям асемблерным - там указано что и как сохранять на примере кода.

[defunct]

[quote name='prottoss' Если же
Для IAR даже если массив объявлен внутри ф-ции, то он всё равно будет создан "на этапе запуска стартап-кода".

А я Вам говорю, что в куче, давайте поспорим Ваши аргументы какие?

Вы оба неправы
Если массив объявлен внутри функции, место для него будет выделено в CSTACK

[Qwertty]

Не вчитывался в посты народа ... звыняйте .. в АСМ-вставке Вы используете R30 - в CVAVR - это самый главный регистр - указатель стека!!! Вот с ним Вы беду и делаете.
Если Ваша вставка - функция - подавно все развалится - прочтите раздел хелпа по функциям асемблерным - там указано что и как сохранять на примере кода.

Цитата из хелпа CV -
"The registers R0, R1, R22, R23, R24, R25, R26, R27, R30 and R31 can be freely used in assembly routines."
R30,R31 используются для возврата результата функции. Указатель стека - R28,R29.

[simsim]

Заменил ассемблерную функцию на СИ-шную
unsigned char asm_font(unsigned char aa1, unsigned char bb1)
{ unsigned int tp;
tp=(aa1*8)+bb1;
return font8[tp];
}
но теперь другая проблема- при отладке в AVR Studio аа1=207, tp получается равным 121 !!! не поддается осмыслению ...
p.s. ОТ перезапуска избавился.спасибо.

Сообщение отредактировал simsim - Jan 17 2007, 21:08

[simsim]

Заменил ассемблерную функцию на СИ-шную
unsigned char asm_font(unsigned char aa1, unsigned char bb1)
{ unsigned int tp;
tp=(aa1*8)+bb1;
return font8[tp];
}
но теперь другая проблема- при отладке в AVR Studio аа1=207, tp получается равным 121 !!! не поддается осмыслению ...
p.s. ОТ перезапуска избавился.спасибо.

Спасибо, нашел - tp=aa1; tp*=8; tp+=bb1; (СИ это вам не математика :-)

[SasaVitebsk]

Для IAR даже если массив объявлен внутри ф-ции, то он всё равно будет создан "на этапе запуска стартап-кода". Даже если он и будет создан динамически (не программистом а компилятором), то он будет создан за счёт памяти выделенной под это на этапе линковки. А куча полностью предоставлена программисту. (Как в С++ не знаю). Я могу выделить память и освободить её. М/у моими действиями ничего происходить с кучей не должно. Ничего без моего участия.
Таким образом учитывая, что парень не слышал о таком слове - куча не занята, и она явно к этому не имеет никакого отношения.

2 defunct поясни пожалуйста, что я сказал неправильно. Я не для спора, а для своего понимания. Смею предположить, что неверна лишь выдержка из поста Prottoss "на этапе запуска стартап-кода". Но я её просто как выдержку привёл, а имелл ввиду что сама прога полностью сгенерирована к моменту запуска. И место под переменные уже выделены. Это так не только в Си. С динамической памятью работать приходилось. Посмотри пожалуйста следующую за вырванной фразу. Я пишу, "Даже если он и будет создан динамически (не программистом а компилятором), то он будет создан за счёт памяти выделенной под это на этапе линковки." То есть я как раз и описываю этот вариант. В моём сообщении не это главное. Опишу чуть ниже.

2 Сергей Борщ по поводу первого раздела, именно это я и хотел сказать но у меня не получилось. Но я говорю немного уклончиво потому, что полностью компилятор не знает никто кроме разработчиков, а в полной мере проверить не удаётся. А в документах, можно кое что упустить. Пример специально для Вас Сергей Борщ. В библиотеках которые я выкладывал по поводу 18b20 применено динамическое распределение памяти. И там же использован массив локальный. приведу текст для понимания.

Код

//Чтение температуры
int8_t    read_scratchpad(uint8_t tip)
{
uint8_t    scratchpad[8];
uint8_t    crc    = 0;

OW_write_byte(READ_SCRATCHPAD);                // читаем scratchpad 0xBE
for    (uint8_t c1    = 0; c1    < 8; c1++)
{
    scratchpad[c1] = OW_read_byte();            // Принять данные с    1 Wire шины
    crc    =  OW_crc8(crc, scratchpad[c1]);        // Посчитать CRC8  для 1 Wire шины
}
crc=OW_crc8(crc, OW_read_byte());
OW_reset();
if (crc == 0)                                    // Проверить CRC8  для 1 Wire шины
{
   if(tip==DS18B20TIP)
     return ((scratchpad[1] << 4) | ((scratchpad[0]+8) >> 4));
   else    
     return ((scratchpad[1] & 0x80) |    ((scratchpad[0]+1) >> 1));
}
else return ( ERROR_CRC);                        // Message -80
}

Возможно Вы будете удивлены, но IAR данный массив размещает в регистрах. (Оптимизирует)


2 defunct. Главное, о чём я писал в своём сообщении, что если бы компилятор произвольно использовал бы кучу, то как с ней работать? А если я её освобождаю ниже занятого уровня? Я уверен, что она не занята. Потому, что мной она не занята. Он меня ещё может контролировать. Я его - нет. Поэтому я и высказал сомнение. Этого нет даже на PC.

[Dan_Dima]

Всем привет.
Я можнт что-то не понимаю скажите а разве между этими строками есть разница.
tp=(aa1*8)+bb1;
и
tp=aa1; tp*=8; tp+=bb1;

[dimka76]

Всем привет.
Я можнт что-то не понимаю скажите а разве между этими строками есть разница.
tp=(aa1*8)+bb1;
и
tp=aa1; tp*=8; tp+=bb1;

aa1 объявлена как char и при умножении aa1*8 вероятно происходит переполнение,
а tp объявлена как int и при tp=aa1; tp*=8; так как tp это int переполнения не происходит. Сделай простую проверку, объяви aa1 как int и посмотри результат своего первого выражения tp = (aa1*8) + bb1;

[satellite-plus]

Всем привет.
Я можнт что-то не понимаю скажите а разве между этими строками есть разница.
tp=(aa1*8)+bb1;
и
tp=aa1; tp*=8; tp+=bb1;

tp=(int)aa1*8+bb1;

[Dan_Dima]

Всем привет.
Я можнт что-то не понимаю скажите а разве между этими строками есть разница.
tp=(aa1*8)+bb1;
и
tp=aa1; tp*=8; tp+=bb1;

aa1 объявлена как char и при умножении aa1*8 вероятно происходит переполнение,
а tp объявлена как int и при tp=aa1; tp*=8; так как tp это int переполнения не происходит. Сделай простую проверку, объяви aa1 как int и посмотри результат своего первого выражения tp = (aa1*8) + bb1;

Насколько я помню подобные преобразования компилятор делает сам ( только проверил) так как преобразование идет к "большему" типу. Поэтому эти две записи эквивалентны.

[Dog Pawlowa]

Насколько я помню подобные преобразования компилятор делает сам ( только проверил) так как преобразование идет к "большему" типу. Поэтому эти две записи эквивалентны.

Конечно сам, но на каком этапе?
Отличие в записях в моменте преобразования.

[satellite-plus]

Насколько я помню подобные преобразования компилятор делает сам ( только проверил) так как преобразование идет к "большему" типу. Поэтому эти две записи эквивалентны.
[/quote]

IAR компилятору все равно к какому типу вы приравниваете. Если в выражении берут участие 8-ми битные данные, то будет применена 8-ми битная арифметика. Для оптимизации программы. А за переполнением следите сами.

[Dan_Dima]

Насколько я помню подобные преобразования компилятор делает сам ( только проверил) так как преобразование идет к "большему" типу. Поэтому эти две записи эквивалентны.

Конечно сам, но на каком этапе?
Отличие в записях в моменте преобразования.

Преобразование происходит по ходу выполнения вычислений если говорить о том как это делаеться в обычном С. В IAR может действительно надо принудительно описывать привидение типов в том же gcc такого нет.

[Dog Pawlowa]

Преобразование происходит по ходу выполнения вычислений если говорить о том как это делаеться в обычном С.

В приведенной формуле tp=(aa1*8)+bb1 компилятор IAR хранит временные результаты вычисления (aa1*8) того же типа, что и aa1 и ничего не нарушает. Переполнение происходит, так как программист не учел, что оно может произойти, а не по той причине, что IAR - это не "обычный С".

В IAR может действительно надо принудительно описывать привидение типов в том же gcc такого нет.

GCC действительно по другому работает, чем IAR - сталкивался с этим. Но, подчеркиваю, разобранный пример - не свидетельство ненормальной работы IAR.

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

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

Для того и существуют стандарты, чтобы точно описывать "как оно должно быть","как оно не должно быть" и "а вот это хз". Последнее отдано на откуп разработчикам компиляторов. Не больше.

Пример специально для Вас Сергей Борщ. В библиотеках которые я выкладывал по поводу 18b20 применено динамическое распределение памяти. И там же использован массив локальный.

Здесь вы путаетесь в терминах. В языке С динамическим распределением памяти называется именно работа с кучей. Локальные переменные, под которые память выделяется на стеке, в терминах С называются автоматическими. Переменные, под которые память выделяется на этапе запуска программы, называются статическими. К статическим относятся глобальные переменные и локальные переменные, объявленные с квалификатором static. В вашем примере динамического распределения я не увидел.

Возможно Вы будете удивлены, но IAR данный массив размещает в регистрах. (Оптимизирует)

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

2 defunct. Главное, о чём я писал в своём сообщении, что если бы компилятор произвольно использовал бы кучу, то как с ней работать? А если я её освобождаю ниже занятого уровня? Я уверен, что она не занята. Потому, что мной она не занята. Он меня ещё может контролировать. Я его - нет.

я не defunct, но попытаюсь ответить: вы не можете "освободить ниже занятого уровня". Вы говорите сколько вам памяти надо, malloc выделяет в куче участок такого размера и выдает вам указатель на него. Этот участок в вашем полном распоряжении и никто на него не покусится. Когда вы хотите освободить этот участок - вы передаете free указатель на участок. Размер освобождаемого участка менеджер памяти определит сам. Повторное освобождение какого-либо участка - это ошибка в программе. Но ничего не мешает другой части программы (другой функции, задаче, другому потоку) получить из этой же кучи другой участок.

[prottoss]

defunct был прав - массив, объявленный в функции, создается не в куче, а в стеке данных (я говрю про ИАР). Проверил листинг ассемблера - все так и есть. Единственное, в чем я был прав - массив, объявленный в функции - создается динамически!!! Так что, ребята, учитывайте это при создании приложений для АВР на ИАР .

[zltigo]

Единственное, в чем я был прав - массив, объявленный в функции - создается динамически!!!

Нет, не "динамически" а "автоматически" - Сергей уже обьяснял!!!

Так что, ребята, учитывайте это при создании приложений для АВР на ИАР .

Ни AVR, ни IAR здесь ни причем. "С", просто "С" стандартное поведение.

[prottoss]

Единственное, в чем я был прав - массив, объявленный в функции - создается динамически!!!

Нет, не "динамически" а "автоматически" - Сергей уже обьяснял!!!

Так что, ребята, учитывайте это при создании приложений для АВР на ИАР .

Ни AVR, ни IAR здесь ни причем. "С", просто "С" стандартное поведение.

А в чем разница между "динамически" и "автоматически"???

1. Если уж говорить по русски - я считаю что "динамически" - это на этапе исполнения кода, а Вы о чем глаголите???

2. Про стандартное поведение Си согласен, здесь все четко

[xemul]

Насколько я помню подобные преобразования компилятор делает сам ( только проверил) так как преобразование идет к "большему" типу. Поэтому эти две записи эквивалентны.

Конечно сам, но на каком этапе?
Отличие в записях в моменте преобразования.

Преобразование происходит по ходу выполнения вычислений если говорить о том как это делаеться в обычном С. В IAR может действительно надо принудительно описывать привидение типов в том же gcc такого нет.

По стандарту все операнды с разрядностью, меньшей int, в целочисленных выражениях обрабатываются как int, и к разрядности lvalue приводится только результат. Обработка операндов с меньшей разрядностью без приведения к int - интимное дело оптимизатора. Для проверки можете посмотреть асм листинг без оптимизации.

defunct был прав - массив, объявленный в функции, создается не в куче, а в стеке данных (я говрю про ИАР). Проверил листинг ассемблера - все так и есть.

И как следствие - задание соответствующего размера стека.

Единственное, в чем я был прав - массив, объявленный в функции - создается динамически!!!

Как уже заметил Сергей Борщ, такие переменные называются автоматическими, и в полном соответствии со стандартом языка создаются при входе в функцию и уничтожаются при выходе из нее. По умолчанию размещаются на стеке, но при включенном оптимизаторе легко могут оказаться в регистрах.

PS: извините за невольный частичный повтор - писАлось больше часа, задергали звонками и неотложными проблемами.

[prottoss]

Канешна, это все здорово очень, объясните тада, умные сотоварищи, зачем мне указывать размер стека данных, еслиФ все равно компилятор и иже с ними, создаст массив в этом самом стекеданных, то бишь нарушит мое НЕОСПОРИМОЕ правило???

[xemul]

Единственное, в чем я был прав - массив, объявленный в функции - создается динамически!!!

Нет, не "динамически" а "автоматически" - Сергей уже обьяснял!!!

Так что, ребята, учитывайте это при создании приложений для АВР на ИАР .

Ни AVR, ни IAR здесь ни причем. "С", просто "С" стандартное поведение.

А в чем разница между "динамически" и "автоматически"???

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

[prottoss]

Автоматическая переменная будет удалена автоматически при выходе из функции, в которой она была определена.

А что, она будет создана не динамически?

[xemul]

Канешна, это все здорово очень, объясните тада, умные сотоварищи, зачем мне указывать размер стека данных, еслиФ все равно компилятор и иже с ними, создаст массив в этом самом стекеданных, то бишь нарушит мое НЕОСПОРИМОЕ правило???

Не понял про "мое НЕОСПОРИМОЕ правило".
Вы же можете среднепотолочно прикинуть требуемый размер стека с учетом вложенности подпрограмм (и их потребностей для локальных переменных) и прерываний.
А у компилятора по стеку правило одно: сказали "Отсель", значит так и будет.

Автоматическая переменная будет удалена автоматически при выходе из функции, в которой она была определена.

А что, она будет создана не динамически?

Вы просили объяснить разницу между автоматическими и динамическими объектами в терминологии С.
А в жизни вообще все относительно - статические объекты с точки зрения программы существуют всегда, а с точки зрения ОС - только пока живет программа. Считать их динамическими?

[prottoss]

Канешна, это все здорово очень, объясните тада, умные сотоварищи, зачем мне указывать размер стека данных, еслиФ все равно компилятор и иже с ними, создаст массив в этом самом стекеданных, то бишь нарушит мое НЕОСПОРИМОЕ правило???

Не понял про "мое НЕОСПОРИМОЕ правило".
Вы же можете среднепотолочно прикинуть требуемый размер стека с учетом вложенности подпрограмм (и их потребностей для локальных переменных) и прерываний.
А у компилятора по стеку правило одно: сказали "Отсель", значит так и будет.

Угу, а тада зафига мне куча в Си??? Без плюсиков...

Вы же можете среднепотолочно прикинуть требуемый размер стека

Гон всезнайки????????????????????????

[xemul]

Канешна, это все здорово очень, объясните тада, умные сотоварищи, зачем мне указывать размер стека данных, еслиФ все равно компилятор и иже с ними, создаст массив в этом самом стекеданных, то бишь нарушит мое НЕОСПОРИМОЕ правило???

Не понял про "мое НЕОСПОРИМОЕ правило".
Вы же можете среднепотолочно прикинуть требуемый размер стека с учетом вложенности подпрограмм (и их потребностей для локальных переменных) и прерываний.
А у компилятора по стеку правило одно: сказали "Отсель", значит так и будет.

Угу, а тада зафига мне куча в Си??? Без плюсиков...

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

Вы же можете среднепотолочно прикинуть требуемый размер стека

Гон всезнайки????????????????????????

Вам не доводилось этим заниматься и установки стека по умолчанию достаточно? Ну и слава богу и разработчикам используемых Вами компиляторов.
Если помните, причина возникновения этого треда крылась в некорректной работе со стеком. Подобные треды возникают достаточно регулярно, и в них неоднократно обсуждались способы контроля переполнения и оценки требуемой глубины стека. Кста, Вы в них активно участвовали. Не отложилось?
И, плз, если Вы чего-то не знаете, не выставляйте это напоказ несколько агрессивным образом.

[defunct]

...

Respect!
Сомневаюсь, что у меня получилось бы лучше раскрыть вопрос.

2 defunct. Главное, о чём я писал в своём сообщении, что если бы компилятор произвольно использовал бы кучу, то как с ней работать? А если я её освобождаю ниже занятого уровня? Я уверен, что она не занята. Потому, что мной она не занята. Он меня ещё может контролировать. Я его - нет.

Компилятор с кучей не работает вовсе.
"Куча" - это просто куча - доступная в run-time память. Для того чтобы с ней работать нужен также run-time менеджер памяти.

Попробую продемонстрировать динамическое распределение памяти на простейшем примере. Допустим нам надо выделять массивы объемом 64 байта (например для хранения подготовленного к отправке пакета данных того же modbus), сколько их потребуется - неизвестно, каким будет их время жизни тоже низвестно. Представьте, что у Вас есть статический массив MyHeap, элементами которого являются некоторые структуры, например такие:

Код

typedef U8 PSTORAGE[64];
typedef U8 *PTR;

typedef struct __tagHeapPart
{
   U8 Busy;
   PSTORAGE storage;
} THEAP_PART, *PHEAP_PART;

THEAP_PART MyHeap[ 16 ];
#define COUNT( somearray )  (sizeof(somearray) / sizeof(somearray[0]))

пишем фукции динамического выделения и освобождения блока памяти:

Код

PTR my_alloc_part(void)
{
    U8 i;
    PTR retval = NULL;
    for (i = 0; i < COUNT(MyHeap); i++)
    {
        if (!MyHeap[i].Busy) // блок не занят
        {
             MyHeap[i].Busy = TRUE; // занимаем его
             retval = MyHeap[i].storage;
             break;
        }    
    }
    return retval;
}

void my_free_part(PSTORAGE pPart)
{
    if (pPart)
    {
        pPart[-1] = 0; // освобождаем блок (Busy = false)
    }
}

Т.о. с помощью my_alloc_part вам будет выделен кусочек статического массива, который Вы смело можете использовать столько сколько нужно. Когда этот кусочек будет ненужен - достаточно вызвать my_free_part и он опять вернется в "кучу".

[SasaVitebsk]

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

Для того и существуют стандарты, чтобы точно описывать "как оно должно быть","как оно не должно быть" и "а вот это хз". Последнее отдано на откуп разработчикам компиляторов. Не больше.

Пример специально для Вас Сергей Борщ. В библиотеках которые я выкладывал по поводу 18b20 применено динамическое распределение памяти. И там же использован массив локальный.

Здесь вы путаетесь в терминах. В языке С динамическим распределением памяти называется именно работа с кучей. Локальные переменные, под которые память выделяется на стеке, в терминах С называются автоматическими. Переменные, под которые память выделяется на этапе запуска программы, называются статическими. К статическим относятся глобальные переменные и локальные переменные, объявленные с квалификатором static. В вашем примере динамического распределения я не увидел.

Возможно Вы будете удивлены, но IAR данный массив размещает в регистрах. (Оптимизирует)

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

2 defunct. Главное, о чём я писал в своём сообщении, что если бы компилятор произвольно использовал бы кучу, то как с ней работать? А если я её освобождаю ниже занятого уровня? Я уверен, что она не занята. Потому, что мной она не занята. Он меня ещё может контролировать. Я его - нет.

я не defunct, но попытаюсь ответить: вы не можете "освободить ниже занятого уровня". Вы говорите сколько вам памяти надо, malloc выделяет в куче участок такого размера и выдает вам указатель на него. Этот участок в вашем полном распоряжении и никто на него не покусится. Когда вы хотите освободить этот участок - вы передаете free указатель на участок. Размер освобождаемого участка менеджер памяти определит сам. Повторное освобождение какого-либо участка - это ошибка в программе. Но ничего не мешает другой части программы (другой функции, задаче, другому потоку) получить из этой же кучи другой участок.

Я не путаюсь в терминах. Я пишу "В библиотеках которые я выкладывал по поводу 18b20 применено динамическое выделение памяти. И там же использован массив локальный." и это так и есть! Просто п/п пример, которой я привёл не использует динамического выделения, а использует локальный массив. Динамическое выделение исп. в другом месте этой же библиотеки.

Код

uint8_t OW_cnt_device(void)
{
uint8_t    Cnt_Device;                                // Число устройств на шине

Cnt_Device=0;
if(!OW_reset())                                // Начинается когда импульс присутствия обнаружен
{
   lastDiscrep = 0;                                // восстановите последнее несоответствие rom поиска глобальное
   OW_Rom_Device=CurrentAddr=malloc(8);            // Зарезервировать память под ROM
   while (Next())                                // Продолжить пока все дополнительные устройства не будут обнаружены
   {
     Cnt_Device++;
   }
}  return(Cnt_Device);
}


void OW_free(void)                                // Освободить память занятую под датчики
{
  free(OW_Rom_Device);                            // Освободить память
}

Я определяю колличество 1-wire устройств на шине (Cnt_Device) и их адреса в объёме Cnt_Device*7+1 сохраняю в куче.

Это было выложено в библиотеках для всеобщего 18.10.2006, что явно раньше этой дискусии.

А примером по локальному массиву, я возразил что он не всегда ложится на стэк. В моём случае компилятор при оптимизации разместил его в регистрах.

По поводу высказывания.

я не defunct, но попытаюсь ответить: вы не можете "освободить ниже занятого уровня". Вы говорите сколько вам памяти надо, malloc выделяет в куче участок такого размера и выдает вам указатель на него. Этот участок в вашем полном распоряжении и никто на него не покусится. Когда вы хотите освободить этот участок - вы передаете free указатель на участок. Размер освобождаемого участка менеджер памяти определит сам. Повторное освобождение какого-либо участка - это ошибка в программе. Но ничего не мешает другой части программы (другой функции, задаче, другому потоку) получить из этой же кучи другой участок.

Вы меня не поняли. Я имел в виду следующее. Представьте что я выполнил процедуру определения датчиков OW_cnt_device() и получил указатель на свободное место в куче. После этого компилятор без моего ведома разместил там ещё какое-то колличество переменных. Не зная об этом я беру и выполняю операцию OW_free(). В результате происходит крах проги. Поэтому я и высказал сомнение о реальности.

Я редко высказываюсь категорично. Приведу пример. В серьёзных (во всяком случае я об этом читал) системах/компиляторах (В винде этого нет) существуют так называемые "сборщики мусора". Которые убирают дыры образующиеся в куче при выполнении операций new/free. Таким образом менеджер памяти там очень мощный. Он может перераспределять данные, в том числе от разных пользователей/потоков. Здесь менеджер - один указатель и пара сравнений. Написано пользователь сам должен. Оно и понятно "обеднённая" система.

[prottoss]

Канешна, это все здорово очень, объясните тада, умные сотоварищи, зачем мне указывать размер стека данных, еслиФ все равно компилятор и иже с ними, создаст массив в этом самом стекеданных, то бишь нарушит мое НЕОСПОРИМОЕ правило???

Не понял про "мое НЕОСПОРИМОЕ правило".
Вы же можете среднепотолочно прикинуть требуемый размер стека с учетом вложенности подпрограмм (и их потребностей для локальных переменных) и прерываний.
А у компилятора по стеку правило одно: сказали "Отсель", значит так и будет.

Угу, а тада зафига мне куча в Си??? Без плюсиков...

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

Вы же можете среднепотолочно прикинуть требуемый размер стека

Гон всезнайки????????????????????????

Вам не доводилось этим заниматься и установки стека по умолчанию достаточно? Ну и слава богу и разработчикам используемых Вами компиляторов.
Если помните, причина возникновения этого треда крылась в некорректной работе со стеком. Подобные треды возникают достаточно регулярно, и в них неоднократно обсуждались способы контроля переполнения и оценки требуемой глубины стека. Кста, Вы в них активно участвовали. Не отложилось?
И, плз, если Вы чего-то не знаете, не выставляйте это напоказ несколько агрессивным образом.

Извиняюсь, был не прав

[makc]

Предложение ко всем участникам форума - квотить меньше и аккуратнее дабы не подпадать под предупреждение по пункту правил 3.4 (оверквотинг).

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

Я не путаюсь в терминах. Я пишу "В библиотеках которые я выкладывал по поводу 18b20 применено динамическое выделение памяти.

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

Это было выложено в библиотеках для всеобщего 18.10.2006, что явно раньше этой дискусии.

Бывает, что некоторые темы я пропускаю

А примером по локальному массиву, я возразил что он не всегда ложится на стэк. В моём случае компилятор при оптимизации разместил его в регистрах.

Это да, с этим я не спорю. Я пытался спорить с чьим-то утверждением, что компилятор может разместить его в куче.

Вы меня не поняли. Я имел в виду следующее. Представьте что я выполнил процедуру определения датчиков OW_cnt_device() и получил указатель на свободное место в куче. После этого компилятор без моего ведома разместил там ещё какое-то колличество переменных.

Где там? В куче? Зарадибога. Заметьте, вы получили указатель не "на свободное место в куче", а на свободный участок указанного вами размера. В этот участок никто больше не залезет. Но и вы не имеете права лезть за границы этого участка.

Не зная об этом я беру и выполняю операцию OW_free(). В результате происходит крах проги. Поэтому я и высказал сомнение о реальности.

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

Я редко высказываюсь категорично. Приведу пример. В серьёзных (во всяком случае я об этом читал) системах/компиляторах (В винде этого нет) существуют так называемые "сборщики мусора".

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

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

А в чем разница между "динамически" и "автоматически"???

"динамически" == "в куче", "автоматически" == "в стеке/регистрах", "статически" == "в специально зарезервированном линкером участке памяти, не в стеке и не в куче".

1. Если уж говорить по русски - я считаю что "динамически" - это на этапе исполнения кода, а Вы о чем глаголите???

Пытаемся обсуждать тематический вопрос с применением принятой в этой области терминологии. Чтобы избежать несуразностей, вызванных неправильной трактовкой "пимпочек", "загогулин" и "фИгни"

[prottoss]

А в чем разница между "динамически" и "автоматически"???

"динамически" == "в куче", "автоматически" == "в стеке/регистрах", "статически" == "в специально зарезервированном линкером участке памяти, не в стеке и не в куче".

1. Если уж говорить по русски - я считаю что "динамически" - это на этапе исполнения кода, а Вы о чем глаголите???

Пытаемся обсуждать тематический вопрос с применением принятой в этой области терминологии. Чтобы избежать несуразностей, вызванных неправильной трактовкой "пимпочек", "загогулин" и "фИгни"

Да, я стараюсь избегать создания массивов внутри функции... Тем паче, что, посмотрев код, на самом деле убедился в том, что ИАР выделил место под массив в стеке данных - он просто в начале функции взял, и увеличил значение регистра Y на размер моего объявленного массива! В принципе, в х86 компиляторах делается то же самое, но там размер памяти 4 Gb, здесь же иногда приходится крутится в 128 байтах да еще с практически всеми возможными задействованными прерываниями



НО, зачем тогда в опциях ИАРа стоит heap size для Си (без плюсиков) ? Оператор new использовать нет возможности, зачем же тогда куча?

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

НО, зачем тогда в опциях ИАРа стоит heap size для Си (без плюсиков) ? Оператор new использовать нет возможности, зачем же тогда куча?

Чтобы размещать в ней различные данные, используя функции malloc, calloc, free и т.д. из stdlib.h. Динамическое распределение памяти

[prottoss]

НО, зачем тогда в опциях ИАРа стоит heap size для Си (без плюсиков) ? Оператор new использовать нет возможности, зачем же тогда куча?

Чтобы размещать в ней различные данные, используя функции malloc, calloc, free и т.д. из stdlib.h. Динамическое распределение памяти

Вы сами то эти функции применяете в проектах?

[IgorKossak]

НО, зачем тогда в опциях ИАРа стоит heap size для Си (без плюсиков) ? Оператор new использовать нет возможности, зачем же тогда куча?

Чтобы размещать в ней различные данные, используя функции malloc, calloc, free и т.д. из stdlib.h. Динамическое распределение памяти

Вы сами то эти функции применяете в проектах?

Я, например, применяю.
Работает.

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

Вы сами то эти функции применяете в проектах?

На ARM - да, но там я пользую ++ и они "обернуты" в new и delete. В аврах - нет, не было необходимости. Когда для РС писал (еще под ДОСом) - тоже применял.

[prottoss]

НО, зачем тогда в опциях ИАРа стоит heap size для Си (без плюсиков) ? Оператор new использовать нет возможности, зачем же тогда куча?

Чтобы размещать в ней различные данные, используя функции malloc, calloc, free и т.д. из stdlib.h. Динамическое распределение памяти

Вы сами то эти функции применяете в проектах?

Я, например, применяю.
Работает.

Интересно, что делает контроллер, когда узнает, указатель равен NULL??? наверное начинает истерично мигать лампочками

[zltigo]

а Вы о чем глаголите???

Я об ОБЩЕПРИНЯТОЙ терминологии идущей от Авторов языка.

[IgorKossak]

Интересно, что делает контроллер, когда узнает, указатель равен NULL??? наверное начинает истерично мигать лампочками

Равенство нулю указателя легко проверить и уж потом принять решение.
Как один из вариантов - вызвать функцию истеричного мигания лампочками.

[prottoss]

а Вы о чем глаголите???

Я об ОБЩЕПРИНЯТОЙ терминологии идущей от Авторов языка.

Хорошо, хорошо, признаю - я заблуждался

[zltigo]

Вы сами то эти функции применяете в проектах?

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

[SasaVitebsk]

Prottoss последний мой проект целиком построен на динамической памяти. Именно AVR правда m640 (8к озу)

Фишка в том что программа в МК - это продолжение железа. И Вы и я это понимаем. NULL не может быть получен. Это говорит о том, что у Вас в проге что-то не верно. Если даже менеджер и не полный, значит вы сами должны контролировать.

Я работаю с данными типа файл. Этот файл приходит с PC. Внутри данных идут упорядоченные структуры. Они нескольких типов и разной длины. Длина файла не известна. Как можно с этим работать? Только куча и указатели. Причём Вы не поверите. Я сам не поверил. Удобно до безобразия. Наглядно и красиво. Вырву кусочек.

Код

  KomXx    = (struct AddrKomXx*) AdrActiveKom[i];            // Прочитать адрес текущей активной    команды
  if(KomXx->TimeStart>TekTime) continue;                // Если    не подошло время для исполнения    команды, то    пропустить данную команду
  switch (KomXx->Name) {
.........
  /* Команда "OUTG"    - "Вывод статической графики" */
  case 'G':
             KomG =    (struct    AddrKomG*) AdrActiveKom[i];    // Прочитать адрес текущей активной    команды
             KomG->TimeMashtabTek++;                    // Следующий такт
             if(KomG->TimeMashtabTek >=    KomG->TimeMashtab)// если    подошёл, то
               KomG->TimeMashtabTek=0;                    // иначе начать    заново
             OutPict(KomG->BegX,KomG->BegY,KomG->SizeX,KomG->SizeY,&KomG->Pict[0]);    // Вывести картинку
             if(KomG->TimeMashtabTek ==    0){                // если    подошёл, то
               KomG->TimeLife--;                        // Уменьшить время жизни
               KomG->BegX += KomG->VecX;                // Сместить    объект
               KomG->BegY += KomG->VecY;                // Сместить    объект
             }
             break;
  /* Команда "ANIMATE" - "Вывод    анимированной графики" */
  case 'M':
             KomM =    (struct    AddrKomM*) AdrActiveKom[i];    // Прочитать адрес текущей активной    команды
.....

[SasaVitebsk]

Где там? В куче? Зарадибога. Заметьте, вы получили указатель не "на свободное место в куче", а на свободный участок указанного вами размера. В этот участок никто больше не залезет. Но и вы не имеете права лезть за границы этого участка.

Не зная об этом я беру и выполняю операцию OW_free(). В результате происходит крах проги. Поэтому я и высказал сомнение о реальности.

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

Усложним задачу.

Давайте в цифрах. Для простоты начальный уровень 0. Потом я занял 100. Компилятор выделил 10.

Я освободил до нуля. И опять забрал кусок, на этот раз 200. И запортил его. Крах?


Я не говорю что так будет. Я говорю что это у меня не уложилось в голове, и поэтому я предположил что компилятор самостоятельно не имеет права использовать кучу. Что в принципе пишите и Вы.

Теперь ещё один момент. Конечно чисто теоретически поставленная мной задача(новая) вполне разрешима с хорошим менеджером кучи. Но мы то говорим о AVR.

Если брать например DELFI (C для PC я не пользую), то там я имею право например выделить память под A,B,C,D а потом освободить место из под B. Потом если я выделю память под переменную E, то я не знаю где её расположит менеджер кучи. Он может её расположить за D, а может (если размеры подойдут на место дырки . Я не в праве гадать. Если эти переменные использовать правильно, то разницы ведь нет. А объём оставшейся свободной памяти я получаю исправно.

Но в IAR AVR под С такого нет! Я был удивлён. Процедурой free, я могу только освободить одну или несколько переменных от конца кучи. Я не могу освободить B! Могу только B,C,D. Да и занять я могу просто место, а не создать переменную. Вроде это есть в C++. Не знаю. Не работал ещё.

Но это реально указывает на то, что менеджер очень упрощённый. Что в принципе обосновано. Если для МК делать что-то мощнее, то это будет слабо востребовано.