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

КРАМ

[uquote="eleks",url="/forum/viewtopic.php?p=4712006#p4712006"]Так и есть. С фиксированной точкой и двойное использование FIR на общий сумматор для получения рекурсии.
Ни кто не говорил, что будет просто.[/uquote]
Поэтому DSP ядро и не используется.
dsPIC33 - это типичный VLIW Гарвард. А это означает, что быстродействие математики обработки сигналов достигается длинными инструкциями, которые за 1 машинный цикл выполняют до семи разных математических операций.
Возьмем к примеру mac в максимально длинной версии:

Код: Выделить всё

mac   W4*W5, A, [W8]+=2, W4, [W10]+=2, W5, [W13]

1. W4 умножается на W5
2. результат п.1 суммируется с содержимым аккумулятора А
3. по указателю в W8 загружается W4
4. по указателю в W10 загружается W5
5. инкрементируется указатель в W8
6. инкрементируется указатель в W10
7. содержимое аккумулятора с округлением загружается по указателю в W13
То есть наблюдается типичная обработка в FIR, где всего одна инструкция будет повторена на всю длину массива посредством помещения ее под инструкциями повтора do или repeat. При включении модульной адресации можно применять оконную функцию произвольной формы для кольцевого массива накопления.
IIR тут ни ухом, ни рылом.
Так же есть DSP инструкции, позволяющие без повторов максимально компактно реализовать комплексную "бабочку" БПФ за 22 машинных цикла с учетом загрузки-выгрузки.

eleks

[uquote="КРАМ",url="/forum/viewtopic.php?p=4712014#p4712014"]IIR тут ни ухом, ни рылом.[/uquote]
Честно сказать, не вижу каких-то принципиальных ограничений, не позволяющих реализовать IIR на dsPIC.
Для простоты можно считать, что я просто ничего не понимаю и поэтому не вижу проблемы.
Цель состоит в том, чтобы интересно провести время.

Картинка из интернета:

КРАМ

[uquote="eleks",url="/forum/viewtopic.php?p=4712020#p4712020"]Честно сказать, не вижу каких-то принципиальных ограничений, не позволяющих реализовать IIR на dsPIC.[/uquote]
Реализовать можно. В этом никто не сомневался. Выигрыша никакого не будет против НЕиспользования DSP ядра. Еще раз, дело не в умножении-сложении одной инструкцией. Такая mac - это не DSP. Накладные расходы связанные с ненативностью 40-разрядного аккумулятора в 16-разрядной архитектуре приведут к бессмысленности ее использования.
Но если вы желаете просто поиграть в DSP - это можно, конечно.
Основной расход времени придется на многократные загрузки/выгрузки тела фильтра в/из аккумулятора. Потому что в отличии от FIR, в IIR аккумулятор подлежит сохранению между выборками. А аккумуляторов всего два.

eleks

[uquote="КРАМ",url="/forum/viewtopic.php?p=4712023#p4712023"]Но если вы желаете просто поиграть в DSP - это можно, конечно.[/uquote]
Да, просто хочу разобраться. Функция ведь есть. Кстати, под XC16 подобная функция тоже есть. В библиотеке smps_control_library есть похожие функции реализации регуляторов 2p2z, 3p3z, 4p4z. Значит не все так плохо. Возможно многое зависит от порядка фильтра. Для первого порядка можно обойтись без DSP, а для порядков >=2 лучше DSP (это пока догадки).

КРАМ

[uquote="eleks",url="/forum/viewtopic.php?p=4712029#p4712029"]для порядков >=2 лучше DSP (это пока догадки).[/uquote]
Я посмотрел библиотеку. Сложно сказать про выигрыш. Линейный неповторяемый код.
Попробуйте - расскажете. Может я и не прав. Нужно сравнить FIR и IIR c примерно одинаковой крутизной спада АЧХ в части скорости вычисления одной выходной точки сигнала.

eleks

Да, разумеется. Как разберусь с функцией то отчитаюсь о результатах.

Добавлено after 3 hours 33 minutes 53 seconds:
Re: Тем, кто боится перейти с 8 на 16 разрядов (PIC24/dsPIC33)
1. Как выделить место для массива переменных?
Например, мне нужно организовать два буфера длиной по 16 байт (8 слов по 2 байта). Один для ввода - input, другой для вывода - output.
2. Как вышеуказанные массивы разместить по определенному адресу?
3. Как разместить константу по определенному адресу?

КРАМ

1. Синтаксис ниже. Указывается количество байт. В данном случае - 128.

Код: Выделить всё

arrayData:			.space 128

2. Не нужно ничего размещать "по определенному адресу" за крайне редкими и очень специфическими исключениями. Адрес выделенного пространства в ОЗУ - имя этого пространства. Линкер все за вас сделает.
Однако вы сами должны определить требуемый сегмент памяти. Для чего в секции выделения памяти есть определение сегмента:

Код: Выделить всё

    .section buf1,near
var1:    .space 2
var2:    .space 2
var3:    .space 4
var4:    .space 2
.......
    .section buf2, address (0x2000) ; X-memory
var5:    .space 64
var6:    .space 2
var7:    .space 4
var8:    .space 8
.......
    .section buf3, address (0x3000) ; Y-memory
var9:    .space 1024
.......

Напомню, что только сегмент near может содержать переменные, которые доступны в прямой адресации, когда адрес операнда в ОЗУ находится в самой инструкции. Например dec2 var.

3. Константы во флеше так же размещаются в произвольном месте и доступ к ним производится по имени. Размер и формат константы вы указываете в начале каждой строки: .pbyte .pword .fixed .float .double и так далее...
Пример:

Код: Выделить всё

tabCRC:
.pword	0x00, 0x31, 0x62, 0x53, 0xC4, 0xF5, 0xA6, 0x97
.pword	0xB9, 0x88, 0xDB, 0xEA, 0x7D, 0x4C, 0x1F, 0x2E
.pword	0x43, 0x72, 0x21, 0x10, 0x87, 0xB6, 0xE5, 0xD4
.pword	0xFA, 0xCB, 0x98, 0xA9, 0x3E, 0x0F, 0x5C, 0x6D
.pword	0x86, 0xB7, 0xE4, 0xD5, 0x42, 0x73, 0x20, 0x11
.pword	0x3F, 0x0E, 0x5D, 0x6C, 0xFB, 0xCA, 0x99, 0xA8
.pword	0xC5, 0xF4, 0xA7, 0x96, 0x01, 0x30, 0x63, 0x52
.pword	0x7C, 0x4D, 0x1E, 0x2F, 0xB8, 0x89, 0xDA, 0xEB
.pword	0x3D, 0x0C, 0x5F, 0x6E, 0xF9, 0xC8, 0x9B, 0xAA
.pword	0x84, 0xB5, 0xE6, 0xD7, 0x40, 0x71, 0x22, 0x13
.pword	0x7E, 0x4F, 0x1C, 0x2D, 0xBA, 0x8B, 0xD8, 0xE9
.pword	0xC7, 0xF6, 0xA5, 0x94, 0x03, 0x32, 0x61, 0x50
.pword	0xBB, 0x8A, 0xD9, 0xE8, 0x7F, 0x4E, 0x1D, 0x2C
.pword	0x02, 0x33, 0x60, 0x51, 0xC6, 0xF7, 0xA4, 0x95
.pword	0xF8, 0xC9, 0x9A, 0xAB, 0x3C, 0x0D, 0x5E, 0x6F
.pword	0x41, 0x70, 0x23, 0x12, 0x85, 0xB4, 0xE7, 0xD6
.pword	0x7A, 0x4B, 0x18, 0x29, 0xBE, 0x8F, 0xDC, 0xED
.pword	0xC3, 0xF2, 0xA1, 0x90, 0x07, 0x36, 0x65, 0x54
.pword	0x39, 0x08, 0x5B, 0x6A, 0xFD, 0xCC, 0x9F, 0xAE
.pword	0x80, 0xB1, 0xE2, 0xD3, 0x44, 0x75, 0x26, 0x17
.pword	0xFC, 0xCD, 0x9E, 0xAF, 0x38, 0x09, 0x5A, 0x6B
.pword	0x45, 0x74, 0x27, 0x16, 0x81, 0xB0, 0xE3, 0xD2
.pword	0xBF, 0x8E, 0xDD, 0xEC, 0x7B, 0x4A, 0x19, 0x28
.pword	0x06, 0x37, 0x64, 0x55, 0xC2, 0xF3, 0xA0, 0x91
.pword	0x47, 0x76, 0x25, 0x14, 0x83, 0xB2, 0xE1, 0xD0
.pword	0xFE, 0xCF, 0x9C, 0xAD, 0x3A, 0x0B, 0x58, 0x69
.pword	0x04, 0x35, 0x66, 0x57, 0xC0, 0xF1, 0xA2, 0x93
.pword	0xBD, 0x8C, 0xDF, 0xEE, 0x79, 0x48, 0x1B, 0x2A
.pword	0xC1, 0xF0, 0xA3, 0x92, 0x05, 0x34, 0x67, 0x56
.pword	0x78, 0x49, 0x1A, 0x2B, 0xBC, 0x8D, 0xDE, 0xEF
.pword	0x82, 0xB3, 0xE0, 0xD1, 0x46, 0x77, 0x24, 0x15
.pword	0x3B, 0x0A, 0x59, 0x68, 0xFF, 0xCE, 0x9D, 0xAC

Использовать выделенные константы можно в любом месте кода - до и после выделения. Линкер вставит константы в той последовательности кода, в котором эти константы размещены в тексте исходника. Применять директиву .org для фиксации положения кода во флеше конечно можно, но очень не рекомендуется из-за особенностей работы линкера.
Синтаксис использования констант зависит от способа доступа к флешу как к данным.
Тут могут быть специфические нюансы семейств МК.
Типичный PSV доступ выглядит так (копирование таблицы во флеше в буфер таблицы в ОЗУ для ускорения доступа):

Код: Выделить всё

  mov		#psvpage(tabCRC), W0
  mov		W0, DSRPAG
  mov		#psvoffset(tabCRC), W0
  mov		#bufTabCRC, W1
  repeat		#255
	mov		[W0++], [W1++]

Время доступа к флешу как к данным зависит от семейства и чем быстрее МК, тем больше латентность этого доступа. Поэтому и было сделано копирование в примере.
Напомню, что самые супер-пупер технологии флеша обеспечивают скорость доступа не выше 40 MIPS, поэтому инструкции прозрачно кэшируются, а доступ к данным во флеше
приводит к "пузырькам" в конвейере.

eleks

КРАМ, огромное спасибо за очень подробное разъяснение и примеры кода!

Ferro83

Добрый день! Можете объяснить насчет бага в моделях dsPIC33CH? Пока не могу понять в каких случаях у меня могут возникнуть проблемы (решаемые или вовсе не решаемые).
Errata для моделей МК с размером программной памяти более 128 кБ короче.

1. The FLIM instruction may incorrectly limit the data range when operating on signed operands of different sign values. If the operands are either all negative or all positive, the limit is correct.
2. The ECCSTATH/L registers cannot be read when an ECC error happens. The ECC Double-Bit Error (ECCDBE) trap and ECC Single Bit Error (ECCSBE) interrupt will work correctly, but the ECCSTATH/ECCSTATL registers will always read as zero.
3. In the ECCSTATH register, the SECSYNDx bits cannot be read when an ECC error happens.
4. When operating on signed operands of different sign values, the output for MAXAB, MINAB and MINZAB instructions may be incorrect. If the operands are either all negative or all positive, the output is correct.
5. When using the signed 32-by-16-bit division instruction, div.sd, the Overflow bit is not getting set when an overflow occurs.

КРАМ

[uquote="Ferro83",url="/forum/viewtopic.php?p=4725822#p4725822"]Пока не могу понять в каких случаях у меня могут возникнуть проблемы[/uquote]
Чрезвычайно странный вопрос.

1. Никто кроме вас не знает характер решаемых вами задач.
2. Не известно никому кроме вас на каком языке вы пишите код.
3 Практически все выпускаемые в настоящее время МК такого уровня сложности имеют достаточно обширные эрраты, в которых имеются и баги ядра. Все перечисленные пункты эрраты обсуждаемого семейства МК не имеют фатального характера и не мешают использовать чипы с учетом этих багов.