MPLAB X IDE проблемы с симуляцией

[Maddocrus]

Начал осваивать pic на Си. Установил MPLAB X но заметил неприятную особенность очень долго считает задержку по __dalay_ms(1000) в низу полосочка крутится секунд 8.

Тестил в MPLAB X ver 5.10 и 4.20

#include ‹xc.h›
#define _XTAL_FREQ 4000000
void main(void) {
    while (1){
    PORTBbits.RB1 = 0;
    __delay_ms(100);
    PORTBbits.RB1 = 1;  
    __delay_ms(1000);
    }   
    return;
}

__delay_ms(100); обрабатывается еще терпимо но вот __delay_ms(1000); уже долго ждать при том что частота стоит 4МГц а если в настройках симуляции и в _XTAL_FREQ поставить реальные 16 МГц то конца симуляции не дождатся.
Код из дизасемблера:

!    __delay_ms(1000);
0x7EE: MOVLW 0x6
0x7EF: MOVWF 0x72
0x7F0: MOVLW 0x13
0x7F1: MOVWF 0x71
0x7F2: MOVLW 0xAD
0x7F3: MOVWF __pcstackCOMMON
0x7F4: DECFSZ __pcstackCOMMON, F
0x7F5: GOTO 0x7F4
0x7F6: DECFSZ 0x71, F
0x7F7: GOTO 0x7F4
0x7F8: DECFSZ 0x72, F
0x7F9: GOTO 0x7F4
0x7FA: GOTO 0x7FB
0x7FB: GOTO 0x7DF

Хотя, запуская то же самое в ASM MPLAB 8.92, никаких проблем нет, STOPWATCH показывает результаты мгновенно.

Мне вот интересно у всех так, или только я, не могу что-то, понять, включить? Как бороться с медленной симуляцией?

[my504]

А зачем вообще симулировать задержки, тем более, такие большие?
Вы отдаете себе отчет в том, что симулятору болт положить на реальное время и он тупо симулирует машинные циклы. То есть, увеличивая частоту осциллятора, Вы набиваете кучу никчемных циклов задержки...
Симулятор в МПЛАБе нужен для проверки фрагментов кода, а не для того, чтобы достоверно развернуть временную диаграмму на миллиарды циклов.
К слову, логический анализатор при этом симуляторе вообще ограничен буфером всего на 10000 крайних машинных циклов, остальное он выбрасывает.

[Maddocrus]

Ладно так как никто ничего не предлагает, пришлось продолжить поиски ответа :(

Эксперимент №1:
Для того что бы симуляторы MPLAB 8.92 b MPLAB X IDE 5.15 были в равных условиях, выбираю одинаковые компиляторы mpasm v5.83 и пишу код задержки равный 3 вложенным циклам.

Результат: MPLAB 8.92 - время обработки 4.5 сек на 16 МГц

Нажмите, чтобы открыть спойлер

Результат: MPLAB X IDE 5.15 - время обработки 14.5 сек на 16 МГц

Нажмите, чтобы открыть спойлер

Далее потыкал, покрутил, получалось что больше 2,2 секунд не показывает и цикл больше 35,4 M не крутит. Стал уменьшать в настройках симулятора частоту Fcyc и понял что частота как будто умножается на 4, так как количество циклов не совпадает.

Эксперимент №2:

Результат: MPLAB 8.92 - время обработки 0.01 сек на 16 МГц

Нажмите, чтобы открыть спойлер

Результат: MPLAB X IDE 5.15 - время обработки 4 сек на 4 МГц

Нажмите, чтобы открыть спойлер

Настройки Симулятора MPLAB X IDE 5.15:

Нажмите, чтобы открыть спойлер

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

Но все равно не понятно, вроде новая программа, должна быстрее работать... или наоборот получается, новая навороченная медленная?

Покрутил на Си __delay_ms(1000) на 16 МГц время эмуляции шага(F8) 45 сек. (мда печаль...) 4000000 циклов, однако если пройти по циклу зеленой кнопкой (F5) то нормально 1.5 секунды. Это понятно что применяются более сложные вычисления, по этому так долго. Но я хотел бы, как то настраивать сложность обработки циклов для увеличения скорости.

Вот еще перевод хелапа по симулятору:

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

Так хорошо где конкретный пример КАК УДАЛИТЬ?

[mike-y-k]

Maddocrus, тут ведь не реальное исполнение кода на реальном железе, а эмуляция этого железа.
Как оно внутри работает известно только разработчикам пакета и модели МК.
Эти вопросы стоит задавать их поддержке и на форуме сообщества программы.
Конечно на серии экспериментов удасться определить какие-то эмпирики для поведения виртуального МК, но в них таки немного смысла - смена версии пакета и содержимого эмулятора дадут новые результаты (99% вероятность).
Тут сильно продуктивнее обычная отладка на реальном железе - минимум задержки будут как положено отрабатывать