Я с этим вопросом три недели промучился полтора года назад. 1. Конфигурацию в АСМ проекте лучше делать отдельным С-файлом. Во первых, читабельнее. Во вторых, исчезнут варнинги. В третьих, генерация этого файла легко делается в окне Configuration bits - там есть кнопка. 2. Применение AIVT делает использование Loadables-проекта для загрузчика кривым. Поэтому лучше загрузчик и основной код размещать в едином проекте, выделяя их в отдельные секции. 3. Для генерации AIVT в общем случае нужно правильно рассчитать лимитер адреса бут-сегмента кода в конфиге. Ну и включить бут сегмент и альтернативную таблицу:
Код:
// FSEC ........ #pragma config BSEN = ON ........ #pragma config AIVTDIS = ON
// FBSLIM #pragma config BSLIM = 0x1FFA ........
В данном примере размер Boot-сегмента будет 5 страниц стирания (длина одной - 0x800) - то есть IVT и Boot-код займут адреса 0x00000...0x01FFE, а AIVT разместится с адреса 0x02000. Основной код будет с адреса 0x02800. В этой ситуации, как вы понимаете, IVT работает в загрузчике, а AIVT обслуживает основной код. Лимитер расчитывается как 0x1FFF минус количество страниц бут-сегмента (0x1FFF-0x5=0x1FFA) Компоновка кода выглядит при этом так:
ЗЫ. В догон. Код старта, стопа и загрузки Slave-ядра размещайте сразу после Application: bra Main то есть до остального кода основной программы. Иначе возникают странности с длиной имиджа слейв-кода и слейв ядро потом не стартует. У меня в проекте используется три перезагружаемых имиджа слейва и после сборки кода карта памяти выглядит так:
Исходник требуется. Хотя бы ASM. Получить его можно из хекса с помощью дизассемблера. Нужно понимать, что дебаг во всех ПИКах происходит через управление битом отладки в конфиге и иногда с перемещением кода и данных, когда в конкретном чипе задействуются ресурсы памяти самого чипа.
Исходник требуется. Хотя бы ASM. Получить его можно из хекса с помощью дизассемблера.
любым или каким-то конкретным дизассемблером? в каком виде должен быть этот исходник (он обязательно должен ассемблироваться или нужен только для отображения)?
Нужно понимать, что дебаг во всех ПИКах происходит через управление битом отладки в конфиге и иногда с перемещением кода и данных, когда в конкретном чипе задействуются ресурсы памяти самого чипа.
правильно ли я понял, что так, как у АРМ-ов можно отладчиком подключиться к микроконтроллеру и шагать/останавливать с ПИК24 не получится? существует ли для ПИК24 gdb или какое-то подобие?
как у АРМ-ов можно отладчиком подключиться к микроконтроллеру и шагать/останавливать с ПИК24 не получится? существует ли для ПИК24 gdb или какое-то подобие?
Отладчик через ICSP-интерфейс не совместим с JTAG. Но часть 16-разрядных МК Микрочипа имеют и JTAG. Однако я никогда его не использовал. ICSP-отладчик позволяет шагать по коду, останавливаться на брейкпойнтах или по требованию и т.д. Наблюдать значения регистров и переменных во время исполнения в этом отладчике невозможно. Только после останова. Выход из этого отладчика потребует для штатной работы кода перепрошить МК. В отличии от JTAG, где после выхода код запускается в обычном режиме. Возможно есть какой то режим работы дебага, при котором исходник не требуется, но штатный вход в отладку в MPLABX транслирует исходник, перепрошивает МК и только после этого входит в дебаг.
Отладчик через ICSP-интерфейс не совместим с JTAG. Но часть 16-разрядных МК Микрочипа имеют и JTAG. Однако я никогда его не использовал. ICSP-отладчик позволяет шагать по коду, останавливаться на брейкпойнтах или по требованию и т.д. Наблюдать значения регистров и переменных во время исполнения в этом отладчике невозможно. Только после останова. Выход из этого отладчика потребует для штатной работы кода перепрошить МК. В отличии от JTAG, где после выхода код запускается в обычном режиме.
правильно ли я понимаю, что для отладки по JTAG не годится Pickit3 и потребуется ICD3 ?
Нет, не правильно. Для отладки по JTAG нужен минимум PICkit4. Ну и необходимо, чтобы сам чип имел такую возможность не исключенную в эррате, довольно много 16-битных МК Микрочипа имеют такое исключение. По поводу С30/ASM30/MPLAB 8. Я не помню, чтобы в восьмерке поддерживались инструменты JTAG.
9. Локальный стек (фрейм) позволяет при входе в вызов (call или прерывание) открывать указатели на локальные переменные. Эти указатели размещены сразу за вершиной стека. Указатель локального стека размещен в W14. При входе в вызов локальный стек объявляется командой lnk #N . При выходе из вызова локальный стек закрывается командой ulnk . Это Си ориентированный механизм определения локальных переменных.
можете ли для лучшего понимания привести реальный пример такого использования с вашими комментариями (с учетом предыдущего п.8 )?
MainInit: lnk #4 mov #15936, W0 mov W0, [W14] ; первая локальная переменная равна 15936 clr [W14+2] ; вторая локальная переменная равна 0 blah-blah-blah....
ulnk return
Предположим, что указатель стека изначально инициализирован значением 0x1000 (это определяется линкером), то есть W15=0x1000 (#__SP_init это #0x1000). Тогда при вызове MainInit указатель стека получит значение W15=0x1004, а в ОЗУ по адресу 0x1000:0x1002 будет адрес возврата из MainInit. После выполнения инструкции lnk #4 указатель стека станет равен W15=0x1008, а указатель локального стека W14=0x1004. Таким образом, открылся фрейм на две локальных 16-битных переменных в стеке к которым можно получить доступ через указатель [W14] и [W14+2], то есть по адресам 0x1004 и 0x1006. Перед выходом из MainInit фрейм закрывается инструкцией ulnk и W15 получает значение 0x1004 как было перед инструкцией lnk #4, а после возврата в основное тело программы W15=0x1000.
Последний раз редактировалось КРАМ Вс дек 17, 2023 18:47:48, всего редактировалось 1 раз.
пытаюсь разобраться с подпрограммой программной задержки и пока не совсем понял как правильно вычислить в мксек длительность одного цикла (применительно к исполнению инструкций, приведенных в даташите) в зависимости от частоты кварца основного генератора (например, 6МГц) -- подскажите, пожалуйста, применительно к PIC24FJ
как правильно вычислить в мксек длительность одного цикла
Длительность одного машинного цикла в любом МК 16-битной платформы Микрочипа равна двум периодам частоты осциллятора. То есть если у вас частота равна 6МГц, то длительность одноцикловой инструкции (например nop или mov W0, W1) составит 0,333(3) мкс. Но если включен PLL, то частота осциллятора не равна частоте кварца. Максимальная частота осциллятора для PIC24FJ составляет 32МГц, что соответствует производительности 16MIPS или циклу 62,5 нс.
Длительность одного машинного цикла в любом МК 16-битной платформы Микрочипа равна двум периодам частоты осциллятора. Но если включен PLL, то частота осциллятора не равна частоте кварца. Максимальная частота осциллятора для PIC24FJ составляет 32МГц
насколько я понял из даташита для ПИК24 умножитель только 4, т.е. при максимальной частоте 32МГц получается кварц должен быть на 8МГц хотя по даташиту допускается 10МГц (в моем случае получается при 6МГц-ом кварце частота будет 24МГц и ее нужно разделить на 2 для получения одного цикла исполнения инструкций)
Частота кварца при выборе типа осциллятора HS составляет 10...32МГц. Читайте даташит. То есть вы можете и без PLL получить максимальную частоту тактирования. Естественно, что и с PLL вы не можете ее превысить.
...инсталлировать ПОСЛЕ установки среды текущую версию компилятора XC16 (1.36). При инсталляции заявляем о желании free версии...
подскажите, пожалуйста, по каким критериям Вы выбрали ХС16 при наличии нескольких альтернативных компиляторов Си? можно ли где-то найти описание всех библиотечных функций компилятора?
А я и не использую Си компилятор на этой платформе. ХС16 мне нужен лишь для того, чтобы использовать ASM16. На Си я пишу только для ARM и есть один серийный проект для PIC18Q43 на ХС8. Поскольку 16-битные Микрочипы имеют очень приятную архитектуру и систему команд, а я не программист, а радиоинженер, то нахожу бессмысленным и неэффективным использовать в проектах с этими МК Си-компилятор. Ну а библиотеки я не использую вообще. Даже на ARM.
подскажите, пожалуйста, структуру выходного файла: после ассемблирования получается hex-файл. Конвертирую его в bin и вместо ожидаемых 24-битных слов наблюдаю 32-битные с одним 00-м байтом -- так и должно быть? например, пытаюсь понять порядок следования байтов и битов для анализа Конфигурационных слов (CW1, CW2, CW3): 0 1 2 3 4 5 6 7 8 9 A B C D E F 000557А0: 00 00 FF 00 FF FF FF 00 7E F2 FF 00 F9 3E FF 00
В хексе тоже самое. Стандартный хекс имеет 32-битную упаковку. Поэтому каждый четвертый байт будет нулевым. Вы вообще в курсе относительно формата хекса? Вы знаете какие строки являются адресным смещением, а какие собственно код?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Я с этим вопросом три недели промучился полтора года назад.
