Страшные глюки с Philips 80C32, уже не знаю что деклать Опции

[Shedon]

Есть сабжевый контроллер, есть прога на си, код хранится во внешней флэш, на 64кб, есть графический дисплей с контроллером SED1335, стал замечать следующею зависимость: чем больше программа по объёму тем больше становится глюков, сейчас прога весит без оптимизации 56889bytes of code. глюки заключаются в следующем перестаёт выводить графику на экран()рисует какие-то линии от болды), и зависает на этом, причём скол-во глюков зависит неким образом от оптимизации. Больше всех глючат функции обращения к контроллеру дисплея, обработка прерывания от таймера и функции си типа sprintf, vsprintf
. Вот ниже привожу пример как у меня построена работа с дисплеем, эта функция рисует точку в один пихел.

Код

#define BASE_ADDR          0x5000
#define DISP_W_D ((char volatile*) 0x018000)
#define DISP_W_C ((char volatile*) 0x018001)
#define DISP_R_D ((char volatile*) 0x018001)
#define DISP_R_C ((char volatile*) 0x018000)

__data unsigned char n_bit,n_bat,d_byt;
__data unsigned int adress;

//...
//...

void put_pixel(int tx, int ty)
{
   n_bat = tx/8;
   n_bit = tx-n_bat*8;
   adress = BASE_ADDR+(ty*40+n_bat);

   *DISP_W_C=0x46;
   *DISP_W_D=adress;
   *DISP_W_D=adress>>8;
   *DISP_W_C=0x43;
   d_byt=*DISP_R_D;

   d_byt |= (0x80>>n_bit);

   *DISP_W_C=0x46;
   *DISP_W_D=adress;
   *DISP_W_D=adress>>8;
   *DISP_W_C=0x42;
   *DISP_W_D=d_byt;
}

Контроллер дисплея подключён как внешняя память, т.е. здаётся мне глюки происходят при обращение к внешней памяти. Как мне кажется я где-то ошибаюсь с настройками компилятора, да забыл написать, компилятор IAR8051 v6.11, эмулятор PICE51, ниже привожу коммандные файлы с настройками проекта может кто что подскажет, заранее спасибо.

Все файлы проекта компилируются со след. параметрами:

Код

--no_wrap_diagnostics --only_stdout
--core=pl
--code_model=n
--data_model=l
--nr_virtual_regs=8
--calling_convention=pr
--place_constants=data
--require_prototypes
--migration_preprocessor_extensions
-e
--enable_multibytes
-r
-lCN indic
--no_cse
--no_inline
--no_code_motion
--no_unroll
-IC:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\inc\FileName.c

Илинкуются след. образом:

Код

-IC:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\config
-D_EXTENDED_STACK_START=2000
-D_EXTENDED_STACK_END=23FF
-D_EXTENDED_STACK_SIZE=3FF
-D?DPS=86
-D_NR_OF_VIRTUAL_REGISTERS=8
-D?DPMASK=1
-D?CBANK=90
-D_CODEBANK_START=8000
-D_CODEBANK_END=10000
-D_IDATA_STACK_SIZE=0x90
-D_PDATA_STACK_SIZE=0x90
-D_XDATA_STACK_SIZE=0xFFF
-e_medium_read=_formatted_read
-l "KALIBR.MAP"
-xsm
-p80
-IC:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\lib\clib\
-f "lnk51ew.xcl"
-FINTEL-EXTENDED
graf_r.R51
indic.R51
obr_klav.R51
pribor.R51
proverka.R51
sint_nch.R51
svitok.R51
upr_pkan.R51
ZNGENM10.R51
gui.R51
AT24C32.R51
ExchangePC.R51
C:\PROGRA~1\IARSYS~1\EMBEDD~1.2EV\8051\lib\clib\cl-pli-nlpd-1e.r51
-o KALIBR.hex

В итоге программа получается след. размеров:
55 565 bytes of CODE memory
70 bytes of DATA memory( + 11 absolute )
10 262 bytes of XDATA
149 bytes of IDATA
8 bits of BIT memory

[IgorKossak]

Позволю и себе высказаться.
Что касается стека, то поведение МК в этом случае очень симптоматично и причина, скорее всего, кроется именно в этом. Особенно когда я увидел ссылки в сообщениях на функции sprintf.
Но. Контроль стека предварительным заполнением его какой нибудь детерминированной величиной не на все 100% может дать нужный результат. Дело в том, что когда компилятор выделяет некое пространство в стеке под временные переменные, он просто меняет значение указателя стека (которое может указывать за пределы сегмента стека), но не обязательно что-то пишет в выделенное пространство. Поэтому в работе может сложиться впечатление, что стека ещё достаточно, но программа, тем не менее, падает, т. к. локальные переменные могут быть уже вне сегмента стека и затирают какие-нибудь глобальные переменные или случается прерывание, которое изменяя глобальные переменные на самом деле изменяет свой адрес возврата.
Поэтому, как ещё одна мера предосторожности, нужно расположить под стеком наименее ответственный сегмент данных, например сегмент со стрингами. Глюки в этом случае будет легче выявить и они не будут приводить к падению программы.

[-Tумблер-]

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

Сушествует, конечно и второй метод (но я его считаю первым!!).
Это - определение экстремального значения указателя стека.
Очевидно, для x51 это тривиальный поиск максимума. (щас найдем):

#define SP_RESEARCH

#ifdef SP_RESEARCH
idata byte sp_pointer;
#endif

void main (void)
{
#ifdef SP_RESEARCH
/* search from this value */
sp_pointer = SP;
#endif

.
.
.

}

В какой-нибудь самой "глубокой" процедуре прерывания
(в таймерной например):
interrupt void T0_int (void)
{
TH0=wdTh;
TL0+=wdTl;
...
#ifdef SP_RESEARCH
/* max search !*/
if (sp_pointer < SP) sp_pointer=SP;
#endif
...
}

Далее по какому - нибудь событию (нажатие кнопки, таймер, "всегда")
выведем sp_pointer в COM-порт. Довольно быстро обнаружим
максимум. конечно, можно предложить вариант, когда это
не сработает - договоримся не делать таких проектов "И ФСЕ".

Замечу, что поскольку речь шла об IAR, это надо
сделать для ОБОИХ стеков.
IAR любит использовать 2 стека. И оба желательно контролировать.

Сочетание обоих методов позволяет решить проблему.

Очевидно, это уже из серии дискуссии "кто и как тестирует.."
Совершенно очевидно, если бы автор программы контролировал
этот важнейший параметр по мере изготовления продукции,
те действовал "по шагам" ничего подобного бы не случилось.
А теперь нет гарантий, что этот проект вообще можно довести
до качественного результата.