Става въпрос за лонг инт променлива в С30 - инкрементира се с единица. Наглед ясно и просто занимание обаче като изключа оптимизацията стойността на променливата започва да се променя с огромни стойности и по време което явно е случайно. Като включа оптимизатора нещата са наред но въпроса ме тормози защо се получава така. Бях чел във форума за делариране на променливи които се държат по подобен начин но не мога да открия темата. Има ли някой представа какво може да се обърква?

Дали не я омазваш някъде. Някъде да пишеш извън границите на буфер,стека да омазваш и т.н. По скоро проблемите обикновенно са от такова естетство.

Обикновенно проблема е обратен. Оптимизацията причинява странно поведение на програмата

Здравейте. Като стана въпрос за оптимизацията...... вие с какви параметри я пускате ????

Обикновено четенето на генерирания асемблерски код помага да се ориентираш за проблема...

p.s. темата, която си чел вероятно е тази, но не знам доколко има връзка с твоя случай
http://www.mcu-bg.com/mcu_site/viewtopi ... E3&start=0

Променливата се инкрементира при ивенти които са на 2-3 сек и просто не би трябвало да приема изведнъж такива огромни стойности. В момента съм дал борда да го тестват и не мога да си правя експерименти но наистина е странно че с оптимизацията се държи добре а без нея се омазва. Като получа борда ще го почопля и ще постна резултати.

така без сорс какво да кажем,
но гаранция - грешката е "твоя"

като ти чета "разсъжденията" - и аз съм за "грешката е изцяло твоя"

volatile ?

наистина е странно че точно при оптимизация бачка а без оптимизация не. обикновенно е обратното, и тука даже ти предложиха да ползваш volatile, което в такива случаи помага, но в твоя би трябвало да навреди
впрочем сигурен ли си че точно СЪС оптимизация работи? и както ти каза вече някой, в такива случаи се гледа асемблерския код. наивен е този който си мисли че може да дебъгва без да знае асемблер. дори джава и .нет средите показват асемблерския псевдокод, познай от три пъти защо.

Наистина не се изразих коректно в последния си пост. Имах предвид че кода е доста ясен а променливата променя стойността си само при инкрементиране. Поведението беше странно и защото бях тествал таргета може би около 2 седмици без никакви проблеми от този сорт. Имах съмнения че ИСД-то почва да се побърква - бях оставил компа и ИСД-то включени няколко дена. Ще проверя задължително асемблера лошото е че не знам дали сега ако изключа оптимизацията ще се прояви.

Ето един сценарий, при който с оптимизация работи, а без оптимизация - не и при който дори академично познание на асемблер няма да помогне особено. Не е същия компилатор или uC, но е пример при това личен.
Определил съм си стека с дълбочина например 64. Точно на адреса след тях се разполага въпросната променлива. Без оптимизация: локалните променливи се разполагат в стека, работните регистри преди всеки "call", както и адресa за връщане след излизане от подпрограма. При достатъчен брой влизания в подпрогами с локални променливи и т.н. се получава препълване на стека и запис в адреса отвъд ръба му, с което променя нежелано съдържанието на въпросната променлива. Тук вече зависи от средата дали ще изпищи или не. IAR-ци например в по-старите версии си мълчат. При това, ако ще пищи това може да стане единствено runtime или при симулиране, поради липса на друг механизъм. От друга страна с оптимизация ви е ясно - спестяване на "call" и тенденция към разполагане на кода на функцията в извикващата функция - достатъчно за да намали размера на употребявания стек.

Проблема се оказа че външно устройство което подава данните - въпросния евент на 2-3 сек - е спряло да работи. Аз (в лицето на мцу-то) чакам за определен символ и в следствие на това в н мерен масив се записват н*м данни. Трябваше да му направя проверка още в началото но все си намирах по-интересни задачи. Проблема доста напомня този от предишния пост. Препълването на масива скапва въпросната променлива.

Знаеш ли какво е отврат ?
Да търсиш софтуерен бъг в устройство с дефектен хардуер, на което софтът му е ОК.

Мен ми се е случвало обратното.