Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

CCS при pic18F452 мине ли 73% рама почват проблемите
http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=4793		 Страница 1 от 1
Автор:  forest_gump [ Пет Сеп 14, 2007 10:56 pm ]
Заглавие:  CCS при pic18F452 мине ли 73% рама почват проблемите
Здравейте на всички, много интересен проблем констатирах наскоро със pic18f452 и компилатор за него CCS, когато мине 73% заетоста на рама по някакъв необясним начин започва да меши променливите, примерно тези които са глобални , до момента във който рама е зает на по-малко от 73% нещата биват, прибавям нещо което по никакъв начин не променя работата на останалият код примерно създавам и инклудвам нов сорс файл и в него дефинирам буфер който дори и не използвам, заетоста на рама минава 73% и се наблюдава омешване на променливите но по-странното е че само определени променливи омешва тези които са дефинирани във основният сорс файл на проекта. Махам/закоментарвам прибавеното и след това нещата се оправят. Нямам дебъгване, намам и WDT, има прекъсвания но са от кодер и по време на омотването не ги активирам. Пробвах със няколко версии на компилатора и резултата е един и същ. Допускам че може и аз греша някъде, кода стана много тлъст но за сметка на това доста непрегледен 8O .
С две думи ако никой не е наблюдавал подобно явление значи аз съм осрал някъде нещата :oops:
Автор:  bateAz [ Пет Сеп 14, 2007 11:12 pm ]
Заглавие: 
Как разбра, че омешва променливите, а не е нещо друго?
Автор:  forest_gump [ Съб Сеп 15, 2007 2:24 pm ]
Заглавие: 
@Бате, дали омешва и друго не си направих труда да ровя, устройството е със LCD бутони и менюта, имам указатели /глобални променливи/ които сочат текущите прозорци и разните му там фунции на бутоните, като стане кашата всичко се обърква , указателите сочат каквото им падне и съответно се отварят произволни менюта и т.н. Имам дебъгер ICD (C)-Pirev, но имам някакъв проблем по който сега се ровя и не мога да дебъгвам никакви пикове от 18-та серия.
Автор:  setoy [ Съб Сеп 15, 2007 2:39 pm ]
Заглавие: 
Махни оптимизациите на местата, за които се съмняваш, може да помогне. #opt 0 и #opt 7-8 за останалите места. Имам някакво смътно усешане, че ако ползваш #locate на определени места в кода и паметта почне да намалява... но не е потвърдено още на 100%. И кажи какво е станало :)
Автор:  [ Съб Сеп 15, 2007 3:08 pm ]
Заглавие: 
ICD-тата се скапват в режим дебъгване, пък и в програмиране, ако имаш голям кондезатор на MCLR пина, или външно куче. Ориентиоравачно, 47-100k & 10-100nF на MCLR са приемливи стойности за да влезне в режим дебъгване/програмиране.

"Омазване" на променливите може да се случи, ако дефинираш твои с #locate и/или #byte и същевременно оставиш компилатора и той да си заделя памет за автоматични променливи. Погледни в листинг файла, кои променливи се препокриват и направи размествания в #locate & #byte дефинициите, или ги премахни напълно и остави компилатора да си заделя сам паметта.

Интересно ми е, да споделиш какво е станало.
Автор:  dumfree [ Съб Сеп 15, 2007 3:59 pm ]
Заглавие: 
А възможно ли е стека да стига до променливите и от там да става омазването.
На мен ми разказваха за такъв случай.
Автор:  setoy [ Съб Сеп 15, 2007 4:16 pm ]
Заглавие: 
Цитат:
Syntax:
#locate id=x
Elements:
id is a C variable,
x is a constant memory address
Purpose:
#LOCATE works like #BYTE however in addition it prevents C from using the area.
Examples:
// This will locate the float variable at 50-53
// and C will not use this memory for other
// variables automatically located.
float x;
#locate x=0x50


Пише, че заделените с #locate променливи не би трябвало да ги припокрива. Обаче имам чувството, че не винаги май е така. Има ли шанс да съм прав? И какво в този случай? #reserve ?
Автор:  Predator_MF [ Нед Сеп 16, 2007 10:30 am ]
Заглавие: 
Има такава вероятност, правил съм го с #reserve и нямах проблеми, мое мнение е да избягваш такива дефиниции в CCS като цяло, че при всяка следваща версия на компилатора има някакви несъответствия (явно недокоментирани)
Автор:  Yanek [ Нед Сеп 16, 2007 4:21 pm ]
Заглавие: 
dumfree написа:
А възможно ли е стека да стига до променливите и от там да става омазването.
На мен ми разказваха за такъв случай.


Омазването за което споменаваш би могло да се случи, но не на процесор от типа на пика. Там както знаеш стека е хардуерен, а другият който компилатора организира е с предварително запазване на РАМ-а и би изпищял веднага. Това за което говориш на мен лично се е случвало на стари IAR компилатори за MSP430. При новите версии ти изплюва съобщение за достигната процентна граница от стека. При условие, че не променяш адреса на стека, разбира се.
Автор:  Gogo [ Нед Сеп 16, 2007 10:20 pm ]
Заглавие: 
Провери дали не се получава нещо като описаното тука:
http://mcu-bg.com/mcu_site/viewtopic.php?p=48855&highlight=static#48855
Автор:  gicho [ Пон Сеп 17, 2007 8:38 am ]
Заглавие: 
Не познавам тоя компилатор, ама звучи точно като недостатъчно стек. Пробвай да премахнеш някой вътрешни променливи и да ги изнешен като глобални, както и да предаваш по-малко аргументи на функциите.
Не знам как някой компилатор би могъл да сметне колко стек ще му трябва по време на компилирането - така може да се завърти изпълнението, че да не знае. Особено ако се използват библиотечни функции - например printf / sprints използват вътрешно динамично заделяне и могат да отлюштят стотина байта RAM.
При атмел / gcc стека е от края на рама надолу докъдето стигне и нищо не може да те спаси от това, да стигне до последните променливи в рама. На пик ще е подобно, просто няма хардуерна защита от разпростиране на стека.
Автор:  forest_gump [ Чет Сеп 20, 2007 7:34 pm ]
Заглавие: 
В проблема се оказа че има вина задкормилното у-во, сиреч аз, получава се настаняване на масив от типа:
Код:
char text_to_print[] = "text_text_text";
char buffer_to_print[20];
int16 chislo_long;
.
.
.
.
sprintf(buffer_to_print, "%S %Lu", text_to_print , chislo_long);

върху променлива за която е заделена памет от компилатора някъде в съседство на масива , и във хелпа си пише че "sprintf" не проверява за размера на буфера но кой да прочете, но поради някаква причина когато паметта се заеме до определено ниво както в моя случай например това се оказва фатално.
Страница 1 от 1 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/