Тем, кто боится перейти с 8 на 16 разрядов (PIC24/dsPIC33)

[khach]

КРАМ, вы тут похоже самый большой специалист по dspic. Посоветуйте, возникла необходимость поковыряться в импульсном блоке питания, который управляется dspic33. Что то по мотивам
https://www.microchip.com/en-us/develop ... nce-design который 750W AC/DC REFERENCE DESIGN AN-2388 но на сайте так не находится.
Подскажите, как лучше отлаживать такое устройство, чтобы не устроить большой бабадум при остановке управления инвертором дебаггером? Это все таки резонансник, там частота должна меняться в цикле управления, нельзя оставить просто таймер шимить транзисторы.

[КРАМ]

[uquote="khach",url="/forum/viewtopic.php?p=4593938#p4593938"]Подскажите, как[/uquote]
С этим имеются некоторые проблемы.
К сожалению, ни PICkit4, ни ICD4 не сканируют контроллер на лету, в отличии от JTAG. Подключение JTAG в dsPIC33 возможно не всегда (значительная часть эррат не дает такой возможности вообще, а даже если это возможно, не факт, что ноги под JTAG будут свободны в конкретной схеме и эти ноги никогда не ремапируются, в отличии от ног ICSP.
Но в настройках периферии можно указать, чтобы периферия не останавливалась во время останова при отладке. Однако, как правило, алгоритмы управления периферией таковы, что проку от продолжения работы периферии нет никакой. Например, остановка кода приводит к остановке DMA, который грузит PWM.
Из всего этого следует, что такие как у вас критические ко времени приложения нужно отлаживать через UART и ногодрыг. Впрочем, JTAG тоже частенько не позволяет получать данные в реальном времени, поскольку сканирование происходит достаточно медленно и асинхронно исполняемому коду.

[khach]

Спасибо за инфо, хотя и не очень радостное. Хотелось для набора опыта поковыряться с серверными блоками питания от HP. Вот на гитхабе есть собрание прошивок для таких блоков
https://github.com/darwinbeing/HPServerPSUHack и частично схемы модернизации обратной связи для настройки напряжений. Но есть желание именно в алгоритмах управления на живом железе потренироваться. Большинство конструкций на DSPIC33FJ64GS608
Может кому будет полезно.

[eleks]

КРАМ, до этого сообщения изложение было просто отличное. Однако дальше обсуждение ушло в сторону. Но данная тема очень нужная и интересная. Не многие в неё пишут, но многие читают. Поэтому хотелось бы чтобы тема вернулась на первоначальные рельсы и стала помощницей тем, кто боится перейти с 8 на 16 разрядов (PIC24/dsPIC33).
Заранее прошу извинение за возможно глупые вопросы с моей стороны, т.к. я не являюсь специалистом по микроконтроллерам и программированию. Но эта тема мне глубоко интересна.
И так, в указанном выше ссылкой сообщении мы добрались до отладки демонстрационного фрагмента программы. К сожалению, в моем случае, кнопки отладки остались неактивными. Бегунок в нижней части окна бегает, а кнопочки серенькие.

screenshot1.jpg

(6.57 КБ) 133 скачивания

В качестве Connected Hardware Tool (правый клик по названию проекта во вкладке Projects -> Properties) выбран Simulator. Полагаю, что это программный симулятор контроллера.
Подскажите, как можно запустить программную отладку

[КРАМ]

Для начала скиньте мне весь проект as is - просто заархивированной папкой.
Скинуть можно сюда или мне на почту my504@mail.ru

[eleks]

Скинул тестовый проект на почту

[КРАМ]

Принял. Разберусь - напишу.

Добавлено after 20 minutes 57 seconds:
Re: Тем, кто боится перейти с 8 на 16 разрядов (PIC24/dsPIC33)
Не увидел проблем.
За исключением выбора версии компилятора и соответствующей версии pack.
Для XC16 v2.00 валиден dsPIC33E-GM-GP-MC-GU-MU_DFP v 1.5.258

[eleks]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4711771#p4711771"]Не увидел проблем.
За исключением выбора версии компилятора и соответствующей версии pack.
Для XC16 v2.00 валиден dsPIC33E-GM-GP-MC-GU-MU_DFP v 1.5.258[/uquote]
У меня установлены последние версии, представленные на сайте MicroChip на данный момент.

После запуска отладки проекта

Не возможно перейти в режим пошаговой отладки

[КРАМ]

Сверяем опции настройки среды - они с проектом не переносятся:

[eleks]

Различия были

Все привел в соответствие.

Однако лучше от этого не стало

[КРАМ]

Есть предложение откатить среду и компилятор на мои версии.
Я пока подумаю.

[eleks]

Да, уже занимаюсь этим.
Только не вижу, где взять старые версии компилятора.

[КРАМ]

на сайте микрочипа есть раздел архив.
Сейчас включу впн и найду

https://www.microchip.com/en-us/tools-r ... -ecosystem

[eleks]

Благодарю за потраченное на меня время. К сожалению, ничего не получилось. После переустановки имею такую же картину
Завтра попробую повторить все под Linux на другой машине.

[КРАМ]

Внезапно вопрос.
А нет ли в путях к проекту и исходникам кириллицы?
Это харам.

[eleks]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4711873#p4711873"]Внезапно вопрос.
А нет ли в путях к проекту и исходникам кириллицы?
Это харам. [/uquote]
И, о чудо!
Всё заработало!

Добавлено after 22 minutes 28 seconds:
Re: Тем, кто боится перейти с 8 на 16 разрядов (PIC24/dsPIC33)
[uquote="КРАМ",url="/forum/viewtopic.php?p=3542816#p3542816"]Речь будет идти для тех, кто желает разобраться в архитектуре 16-разрядной платформы и начать писать простые программы на АСМе этой платформы.[/uquote]
Было бы прекрасно, если бы Вы продолжили речь в данном направлении. Думаю, что ассемблер очень полезен, по крайней мере, для написания отдельных процедур, если к ним предъявляются высокие требования по быстродействию. Это особенно актуально для источников питания. И вообще на ассемблере, после некоторой тренировки, не очень трудно писать .
dsPIC33F имеет относительно сложную структуру памяти и поэтому хотелось бы начать с объявления констант и переменных для различных областей памяти. Получения адресов этих констант и переменных для использования в программном коде. Использование стека для передачи данных и констант, использование адресации по модулю, бит-реверсивной адресации...

[КРАМ]

Не, у dsPIC-ов как раз очень простая в понимании архитектура. Именно поэтому на них целесообразно писать на АСМе, в отличии от АРМов, например.
Но вы лучше объясните свою конкретную цель и тогда на ее примере я расскажу, в том числе, и о работе двухканальной памяти с AGU.
ЗЫ. Бит-реверсивная адресация - это для БПФ. Тут как раз все очень однозначно. Особо рассказывать не о чем. Скорее вам нужно прочитать про БПФ. Просто с нуля можно рассказать, но тема разбухнет.

[eleks]

Не уверен, является ли моя задача типовой.
До этого, для программирования PIC-ов, всегда использовал компилятор MikroC. В принципе хороший и не сложный компилятор. Как раз для тех, кто занимается программированием эпизодически. В последнее время больше для самообразования. В основном вожусь с источниками питания. Раньше использовал в них контроллеры, но в основном для сервисных функций. Однако всегда хотелось сделать полностью дискретное управление. На сайте MicroChip есть, казалось бы, подходящие аппноты, но для меня они не подходят. И DSP ядро там практически не используется. Поэтому решил идти по классике - разрабатываю корректор (регулятор) в линейной области, затем создаю дискретную форму и переношу её на dsPIC. Покопался в DSP библиотеке MikroC for dsPIC и выбрал там наиболее подходящую, как мне кажется, функцию реализации фильтра IIR_Radix. В примерах имеется демонстрационный код использования этой функции. Однако, существует несколько не понятных параметров функции, а также существуют некоторые сомнения по её пригодности. Поэтому решил заглянуть внутрь. И вот тут понадобился отладчик на уровне ассемблера, чтобы точно отслеживать поведение кода. Решил создать проект в MPLAB X IDE, обнаружил там отсутствие возможности создавать проект на ассемблере и вот теперь мы здесь.
Сейчас стоит задача адаптировать листинг от MikroC под XC16 ассемблер и приступить к изучению.
Архив с соответствующими файлами от MikroC прилагаю.
К сожалению, для полноценной отладки эти файлы не подходят. Необходимо довести их до полноценной программы. Причем надо использовать именно lst файл, т.к. asm версию компилятор почему-то укоротил и она не совсем соответствует прототипу на Си.

Бит-реверсивной адресации тут конечно нет, но адресация по модулю и использование стека для передачи данных имеют место.

[КРАМ]

Я ничего не говорил про типичность вашей задачи. Я имел ввиду типичную математику применяемую в ваших задачах.
Но ваш ответ уже позволяет мне его прокомментировать.
Дело в том, что архитектура DSP ядра подразумевает реализацию КИХ (FIR) фильтров, а не БИХ (IIR). Проблема в том, что все IIR принципиально требуют либо float-ов, либо фикспойнтов и всегда рекурсивной топологии. Рекурсивность противоречит архитектуре DSP в этом семействе. А флоаты аппаратно вообще не реализованы.
Поэтому для конструктивного решения этой проблемы вам нужно переделать проект на FIR, прежде всего.

Добавлено after 4 minutes 18 seconds:
[uquote="eleks",url="/forum/viewtopic.php?p=4711973#p4711973"]адресация по модулю и использование стека для передачи данных имеют место.[/uquote]
Адресация по модулю применяется для обработки массивов. Причем тут IIR?
Передача данных через стек - это тупо реализация локальных переменных с помощью аппаратного механизма выделения фрейма в стеке для локальных переменных. Дело тут не в самой передаче, а именно в использовании стека для локальных переменных. Передача тут вторична.

[eleks]

[uquote="КРАМ",url="/forum/viewtopic.php?p=4711983#p4711983"]Дело в том, что архитектура DSP ядра подразумевает реализацию КИХ (FIR) фильтров, а не БИХ (IIR). Проблема в том, что все IIR принципиально требуют либо float-ов, либо фикспойнтов и всегда рекурсивной топологии. Рекурсивность противоречит архитектуре DSP в этом семействе. А флоаты аппаратно вообще не реализованы.
Поэтому для конструктивного решения этой проблемы вам нужно переделать проект на FIR, прежде всего.[/uquote]
Так и есть. С фиксированной точкой и двойное использование FIR на общий сумматор для получения рекурсии.
Ни кто не говорил, что будет просто.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4711983#p4711983"]Адресация по модулю применяется для обработки массивов. Причем тут IIR?[/uquote]
Разумеется, к IIR адресация не имеет прямого отношения, но в данном случае имеет место.