Есть вопрос к знатокам uVision (8.05).

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

Облазил весь uVision, но ничего не нашел.

В ИАРе таких проблем не было.

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

Н-да.
Ответов обилие.
Пришлось писать все в отдельных файлах и раздельно подключать к проекту.
Сразу обнаружилась куча минусов.
Если вызываетя функция и текущего файла, то сохраняются только регистры которые
эта фунция использует. А если такая же из другого, то сохраняются все регистровые переменные.
Поэтому оптимизация имеет печальный вид.
Если бы не глючность IAR C51, то снес бы на фиг.
Вообще непонятно.
Такие классные компиляторы IAR для AVR и ARM и такой отстой для C51.

Не очень понял вашу проблему. Лично у меня никаких проблем с этим не возникало. Правда я в 2-м делал.
Вот книжечка по кейловскому компилятору, может чем поможет.Нажмите для просмотра прикрепленного файла
Если ничего не прояснится, интересно было бы глянуть на проект.

За книжечку - спасибо.

А проблема, что во 2-ом, что в 3-ем, следующая.
Касается встроенного симулятора.

Если основной файл содержит следующее:

а файл func_def.c


то при проходе в симуляторе он никогда не входит в файл func_def.c
и в дизассемблерном окне в качестве комментария к коду показывает
строки из основного файла которые к этому коду отношения не имеют
искал как это пофиксить, но увы.
Сейчас приходится func_def.c вместо #include включать в проект, а функцию объявлять как extern
в основном файле. Тогда отладчике все Ок, НО перед вызовом таких функций компилятор
запихивает все переменные из регистров в память и вся регистровая оптимизация накрывается,
так как на этапе компиляции неизвестно какие регистры портит функция, а портить она
имеет право все регистры включая DPTR.
Если писать все в одном файле, то в отладчике все хорошо и оптимизация работает, но
получается такая помойка, что лучше пожертвовать оптимизацией.

Вот такие, блин, непонятные проблемы.
Глупость какая-то.

В ИАРе с таким не сталкивался.

А в Project Workspace -> Source Group не забыли эти файлы с функциями добавить??
Попробуйте без оптимизатора - возможно слишком короткая функция и оптимизатор решил сделать ее inline, т.е. заменить вызов кодом самой функции.

Симулятор не видит таких файлов #include func_def.c но в итоге после компиляции программа работает корректно.

Для того что-бы симулятор корректно работал с *.с файлом его необходимо подключить к проекту (например как в присоединненном файле). Для каждого *.с создается файл *.h (в вашем случае это будет func_def.h) в котором описываюдтся все прототипы функций и переменные используемые в теле main другого *.с файла.
Например -> Файл *.h

char func(char b );

-> Файл *.c

char func(char b )
{
b<<=1;
if( b )return b;else return 1;
}

Файл *.h вписывается в файл main.c с помощью #include func_def.h

Все достаточно просто

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

Было лень искать пост Ytrnj @ Mar 20 2007, 16:11 вот я его и подделал.