есть программа, состоит из 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, поможет ? там вроде нет шагов назад.

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

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

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

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

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

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

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

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

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

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

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

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

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

Увеличил стек до 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
Может здесь причина?

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

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

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



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



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

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

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

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

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

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

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

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

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

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

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

Цитата из хелпа 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.

Заменил ассемблерную функцию на СИ-шную
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; (СИ это вам не математика :-)

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

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

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


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

Всем привет.
Я можнт что-то не понимаю скажите а разве между этими строками есть разница.
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;

tp=(int)aa1*8+bb1;

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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



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



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

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



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

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

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

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


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

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

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

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

Да, после приведенного кода снимаю все возражения и обвинения Извиняюсь, не смотрел ваши библиотеки, ограничился лишь анализом приведенного куска. Подумал, что раз уж вы выложили кусочек кода, то решили облегчить мне задачу поиска исходников этих библиотек и в представленном коде есть все, что необходимо для обсуждения.
Бывает, что некоторые темы я пропускаю
Это да, с этим я не спорю. Я пытался спорить с чьим-то утверждением, что компилятор может разместить его в куче.
Где там? В куче? Зарадибога. Заметьте, вы получили указатель не "на свободное место в куче", а на свободный участок указанного вами размера. В этот участок никто больше не залезет. Но и вы не имеете права лезть за границы этого участка.
Никакого краха. В кучу возвращается выделенный вам участок, на который указывал OW_Rom_Device. Остальные участки если и были выделены кому-то без вашего ведома продолжают существовать.

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

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

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



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