Антинародный генератор с ультранизкими искажениями
#61

Дядку, збавте обороты :)

Если взять хороший быстрый контроллер, с кучей памяти с подходящим наобором команд, билиотеками и т.д., то да, скорее всего разницы либо небудет, либо будет но непринципиальная. Если взять что-то что досталось по наследсту от продуктов из которых уже труха сыпится, но то что приходится пользовать по ряду причин, разница может оказатся и решающей. Что будет в том или ином случае - хз, поэтому в среднем - "может быть". Да, у меня нет компетенции что-бы вести этот спор, но я доверяю компетенции людей с которыми работаю, реализующими это все в коде. И уж извините, но доверяю больше чем вам :)

"Найкраще сало то ковбаса." (с)
Ответ
#62

Гы Гы.
Я уже себе представил, "тех людей"...
Видимо, они до сих пор считают себя умнее компилятора.
Ответ
#63

БендеровецЪ Написал:Дядку, збавте обороты
Это что, была попытка мне что-то указывать?! Lol

Впрочем, бандерштадт щас у власти....
Ответ
#64

БендеровецЪ Написал:Если взять хороший быстрый контроллер,
Вообще-то, речь шла конкретно про Cortex-M4 (STM32F4xx).
Хотя, это касается что их, что 8-битных PIC'ов, для которых я лет 5-6 писал на асме, и чего уже лет 15-16 не делаю - все это не проблема процессоров, это проблема качества компилятора.
БендеровецЪ Написал:с подходящим наобором команд, билиотеками
Интереса ради, можешь посмотреть исходники STM33 DSP Library, и найти там "ассемблерные вставки".
Ответ
#65


Off-topic:
Altor Audio Написал:Не пиши того, в чем ты ничего не понимаешь, ибо:
Алекс, не груби плиз. Некоторые "аналоговые инжинеры" понимают больше чем "специализированнвые программисты".
Как программист, а не как аналоговый инжинер, я могу сказать что этот разговор не несёт никакого смысла без знания какой компилятор будет использоваться (даже для одного и того же процессора) и какой конкретно алгоритм и как будет имплементирован. Тот факт что есть ассемблер в библиотеках или нет ровным счётом ни о чём не говорит. Во многих случаях ручная оптимизация критических кусков всё равно может дать значимый выигрышь. Нужен ли он или будет или нет это другой разговор.
Как человек занимающийся разработками новых продуктов в компании, я бы пытался избегать использования ассемблера по причине более сложной отладки, сложности внесения изменений, не переносимости кода. Если не хватает быстродействия и нет ограничения по потребляемой мощности, практически всегда можно взять более быстрый процессор. Это будет дешевле и менее рискованно для компании. Но ежели у тебя что-то работает на батарейках то возможно у тебя не будет особо выбора...
The following 1 user says Thank You to Nick for this post:
  • s3t (05-08-2015)
Ответ
#66

Nick Написал:Некоторые "аналоговые инжинеры" понимают больше чем "специализированнвые программисты".
Вполне возможно, но я не только "специализированный программист, но и "аналоговый инженер" тоже :)

Nick Написал:без знания какой компилятор будет использоваться (даже для одного и того же процессора)

Для означенного выше, варианта всего два - IAR & KEIL, я предпочитаю Keil. Остальные даже не рассматриваются.

Nick Написал:Во многих случаях ручная оптимизация критических кусков всё равно может дать значимый выигрышь.

Разумеется, если криво написано, то без разницы на каком языке. Но если написано корректно, то я сколько ни раз пытался это делать - в лучшем случае мало что менялось. Компиляторы нынче достаточно умные. Достаточно только им кое-де подсказывать, а переходить на асм в 99.99% случаев нет смысла, лучше не будет.
Подсказки могут быть,например, когда в switch несколько case'ов заканчиваются одинаковой последовательностью вызовов других функция или каких действий, то если это не противоречит алгоритму, располагать их надо в одинаковой последовательности, тогда компилятор их вставит только один раз а с остальных будут просто джампы.
Или другой пример, который почти никогда не используют "РС программисты", но который часто весьма существенен для МК - если опять-же, это не противоречит алгоритму, делать цикл не for(i=0; i0;i--), ибо даже еще в Z80 была отличная команда DJNZ (decrement and jump if no zero), хотя опять-же - если i не используется внутри цикла, то умный компилятор сам превратит первый цикл во второй.

Nick Написал:Но ежели у тебя что-то работает на батарейках то возможно у тебя не будет особо выбора...
У меня в основном на батарейках и работает.
Ответ
#67


Off-topic:
По поводу DSP библиотеки для STM32 - например http://users.ece.utexas.edu/~valvano/EE345M/UM0585.pdf . Смотрим http://users.ece.utexas.edu/~valvano/EE345M/PID_stm32.s Function Name : DoPID
;* Description : PID in ASM, Error computed outside the routine
Ответ
#68


Off-topic:
Или вот http://users.ece.utexas.edu/~valvano/EE3...24_stm32.s FFT в DSP библиотеке для STM32 вполне себе на ассемблере...
Ответ
#69

Nick Написал:По поводу DSP библиотеки для STM32 - например http://users.ece.utexas.edu/~valvano/EE345M/UM0585.pdf . Смотрим

Так то для STMF1xxx, который Cortex-M3 а речь шла про STM32F4xx, который Cortex-M4.
В 3-м нет DSP-модуля и ДСП команд, естественно. Там такое может быть оправданно.
Ответ
#70


Off-topic:
Это с DSP для STM32F4 (CMSIS-DSP library)
Код:
;/* ----------------------------------------------------------------------
;* Copyright (C) 2010-2014 ARM Limited. All rights reserved.
;*
;* $Date:       12. March 2014
;* $Revision:     V1.4.4
;*
;* Project:     CMSIS DSP Library
;* Title:        arm_bitreversal2.S
;*
;* Description:    This is the arm_bitreversal_32 function done in
;*              assembly for maximum speed.  This function is called
;*              after doing an fft to reorder the output.  The function
;*              is loop unrolled by 2. arm_bitreversal_16 as well.
;*
;* Target Processor: Cortex-M4/Cortex-M3/Cortex-M0
;*
;* Redistribution and use in source and binary forms, with or without
;* modification, are permitted provided that the following conditions
;* are met:
;*   - Redistributions of source code must retain the above copyright
;*     notice, this list of conditions and the following disclaimer.
;*   - Redistributions in binary form must reproduce the above copyright
;*     notice, this list of conditions and the following disclaimer in
;*     the documentation and/or other materials provided with the
;*     distribution.
;*   - Neither the name of ARM LIMITED nor the names of its contributors
;*     may be used to endorse or promote products derived from this
;*     software without specific prior written permission.
;*
;* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
;* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
;* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
;* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
;* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
;* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
;* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
;* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
;* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
;* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
;* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
;* POSSIBILITY OF SUCH DAMAGE.
;* -------------------------------------------------------------------- */
#if defined(__CC_ARM)       // Keil
    #define CODESECT AREA     ||.text||, CODE, READONLY, ALIGN=2
    #define LABEL
#elif defined(__IASMARM__)  // IAR
    #define CODESECT SECTION `.text`:CODE
    #define PROC
    #define LABEL
    #define ENDP
    #define EXPORT PUBLIC
#elif defined(__CSMC__)        /* Cosmic */
    #define    CODESECT    switch .text
    #define THUMB
    #define EXPORT    xdef
    #define PROC    :
    #define LABEL    :
    #define ENDP
    #define arm_bitreversal_32 _arm_bitreversal_32
#elif defined (__GNUC__)    // GCC
    #define THUMB .thumb
    #define CODESECT .section .text
    #define EXPORT .global
    #define PROC :
    #define LABEL :
    #define ENDP
    #define END

    .syntax unified
#endif

    CODESECT
    THUMB

;/*
;* @brief  In-place bit reversal function.
;* @param[in, out] *pSrc        points to the in-place buffer of unknown 32-bit data type.
;* @param[in]      bitRevLen    bit reversal table length
;* @param[in]      *pBitRevTab  points to bit reversal table.
;* @return none.
;*/
    EXPORT arm_bitreversal_32
    EXPORT arm_bitreversal_16

#if defined(ARM_MATH_CM0) || defined(ARM_MATH_CM0PLUS)

arm_bitreversal_32 PROC
    ADDS     r3,r1,#1
    PUSH     {r4-r6}
    ADDS     r1,r2,#0
    LSRS     r3,r3,#1
arm_bitreversal_32_0 LABEL
    LDRH     r2,[r1,#2]
    LDRH     r6,[r1,#0]
    ADD      r2,r0,r2
    ADD      r6,r0,r6
    LDR      r5,[r2,#0]
    LDR      r4,[r6,#0]
    STR      r5,[r6,#0]
    STR      r4,[r2,#0]
    LDR      r5,[r2,#4]
    LDR      r4,[r6,#4]
    STR      r5,[r6,#4]
    STR      r4,[r2,#4]
    ADDS     r1,r1,#4
    SUBS     r3,r3,#1
    BNE      arm_bitreversal_32_0
    POP      {r4-r6}
    BX       lr
    ENDP

arm_bitreversal_16 PROC
    ADDS     r3,r1,#1
    PUSH     {r4-r6}
    ADDS     r1,r2,#0
    LSRS     r3,r3,#1
arm_bitreversal_16_0 LABEL
    LDRH     r2,[r1,#2]
    LDRH     r6,[r1,#0]
    LSRS     r2,r2,#1
    LSRS     r6,r6,#1
    ADD      r2,r0,r2
    ADD      r6,r0,r6
    LDR      r5,[r2,#0]
    LDR      r4,[r6,#0]
    STR      r5,[r6,#0]
    STR      r4,[r2,#0]
    ADDS     r1,r1,#4
    SUBS     r3,r3,#1
    BNE      arm_bitreversal_16_0
    POP      {r4-r6}
    BX       lr
    ENDP

#else

arm_bitreversal_32 PROC
    ADDS     r3,r1,#1
    CMP      r3,#1
    IT       LS
    BXLS     lr
    PUSH     {r4-r9}
    ADDS     r1,r2,#2
    LSRS     r3,r3,#2
arm_bitreversal_32_0 LABEL       ;/* loop unrolled by 2 */
    LDRH     r8,[r1,#4]
    LDRH     r9,[r1,#2]
    LDRH     r2,[r1,#0]
    LDRH     r12,[r1,#-2]
    ADD      r8,r0,r8
    ADD      r9,r0,r9
    ADD      r2,r0,r2
    ADD      r12,r0,r12
    LDR      r7,[r9,#0]
    LDR      r6,[r8,#0]
    LDR      r5,[r2,#0]
    LDR      r4,[r12,#0]
    STR      r6,[r9,#0]
    STR      r7,[r8,#0]
    STR      r5,[r12,#0]
    STR      r4,[r2,#0]
    LDR      r7,[r9,#4]
    LDR      r6,[r8,#4]
    LDR      r5,[r2,#4]
    LDR      r4,[r12,#4]
    STR      r6,[r9,#4]
    STR      r7,[r8,#4]
    STR      r5,[r12,#4]
    STR      r4,[r2,#4]
    ADDS     r1,r1,#8
    SUBS     r3,r3,#1
    BNE      arm_bitreversal_32_0
    POP      {r4-r9}
    BX       lr
    ENDP

arm_bitreversal_16 PROC
    ADDS     r3,r1,#1
    CMP      r3,#1
    IT       LS
    BXLS     lr
    PUSH     {r4-r9}
    ADDS     r1,r2,#2
    LSRS     r3,r3,#2
arm_bitreversal_16_0 LABEL       ;/* loop unrolled by 2 */
    LDRH     r8,[r1,#4]
    LDRH     r9,[r1,#2]
    LDRH     r2,[r1,#0]
    LDRH     r12,[r1,#-2]
    ADD      r8,r0,r8,LSR #1
    ADD      r9,r0,r9,LSR #1
    ADD      r2,r0,r2,LSR #1
    ADD      r12,r0,r12,LSR #1
    LDR      r7,[r9,#0]
    LDR      r6,[r8,#0]
    LDR      r5,[r2,#0]
    LDR      r4,[r12,#0]
    STR      r6,[r9,#0]
    STR      r7,[r8,#0]
    STR      r5,[r12,#0]
    STR      r4,[r2,#0]
    ADDS     r1,r1,#8
    SUBS     r3,r3,#1
    BNE      arm_bitreversal_16_0
    POP      {r4-r9}
    BX       lr
    ENDP

#endif

    END
Ответ
#71

Хм, значит добавили, у меня более старая библиотека, 2012г, там нет ни одного *.s файла!
И есть arm_bitreversal.c:
Код:
/* ----------------------------------------------------------------------    
* Copyright (C) 2010 ARM Limited. All rights reserved.    
*    
* $Date:        15. February 2012  
* $Revision:     V1.1.0  
*    
* Project:         CMSIS DSP Library    
* Title:        arm_bitreversal.c    
*    
* Description:    This file has common tables like Bitreverse, reciprocal etc which are used across different functions    
*    
* Target Processor: Cortex-M4/Cortex-M3/Cortex-M0
*  
* Version 1.1.0 2012/02/15
*    Updated with more optimizations, bug fixes and minor API changes.

Но в общем - и то и то полная глупость. т.к. эти перестановки битов делаются прямо из Си командами типа _REV16(), _REVSH(), _RBIT() и т.п. интрисинками.
( можно конечно это считать использованием ассемблерных вставок в неявном виде :))
Ответ
#72

Altor Audio Написал:Вообще-то, речь шла конкретно про Cortex-M4 (STM32F4xx).
Хотя, это касается что их, что 8-битных PIC'ов, для которых я лет 5-6 писал на асме, и чего уже лет 15-16 не делаю - все это не проблема процессоров, это проблема качества компилятора.

Речь шла вобщем, вы почему-то решили что это именно STM32F4xxx. Делать утверждения подобные "этого не может быть потому что не может быть никогда" без привязки к апаратной платформе, компилятору и собственно процессингу который надо реализовать, выглядят как минимум несерьезно.
Да, это скорее всего полностью либо частично зависит от качества компиляторов. Каким образом это противоречит тому что я сказал изначально?

"Найкраще сало то ковбаса." (с)
Ответ
#73

shkal Написал:1) Как сделать детектор огибающей\пиковый детектор с ошибкой 1%? Либо надо очень быстрый АЦП (100*верхняя частота генерации), либо как-то интерполировать пики между отсчётами, что требует много реалтаймовых вычислений.
2) Фактически такая система АРУ никогда не устанавливается, а дрейфует между двумя соседними "ступеньками" ЦАПа, т.е. амплитуда колебаний будет промодулирована некоторым напряжением треугольной формы. Каков будет спектр этого напряжения, какая нужна разрядность ЦАПа-АЦП, чтобы этот эффект не вылезал за -140дб - я не знаю.
3) "Сильно фильтровать" тоже не очень получается - набег фазы в петле
1) Например использовать 2 АЦП (синхронно чтобы работали). Снимать sin и cos. Всё остальное в цифре делать.
2) Конечно будет "дрейфовать", но если разрядность достаточно большая это думаю не будет проблемой.
3) Но возможностей больше. Например частоту фильрации и ед. усиления в петле можно сделать переменной, снижать по мере установления. Делать разной для разных частот генератора. Хитрить в общем есть больше возможностей.
Я не утверждаю что в этом вообще есть смысл, это просто была идея у меня такая. Возможно будут какие то трудности в её вопрлощении и потеряется всякий смысл это делать.
Вообще прощу прощения за "захват" твоей темы. Не думал что мой пост вызовет столько разговоров совсем не по теме. Если хочешь я думаю можно всё про "процессорный детектор" перенести в другую ветку.
Ответ
#74

БендеровецЪ Написал:Речь шла вобщем, вы почему-то решили что это именно STM32F4xxx.

Т.е. ты уже от собственных слов уже отказываешься?

БендеровецЪ Написал:Мне кажется что может хватить и микроконтроллера, тем более что STM32 есть с DSP блоками.

Под то что ты тут написал, подходит только три семейства Cortex-M4, наиболее распространенное из них - это именно STM32F4xx, остальные - F3xx и L4xx, что в данном случае тоже самое. ( ядро то-же).
Ответ
#75

То что одно и другое упомянуто в одном обзаце, вовсе не означает что эти вещи однозначно связаные. И нигде я не писал что это относится ко всем случаям. Так же как и "надо быть готовым" ну никак не трактуется как "100% приниприменно". Вот, даже специально для вас процетирую:

БендеровецЪ Написал:Мне кажется что может хватить и микроконтроллера, темболее что STM32 есть с DSP блоками. Но надо быть готовым писать асемблерные вставки, т.к. если фильтры писать на С то уходит гораздо больше ресурсов.

И могли бы занятся чем-то более конструктивным чем копание в чужих постах и написание опровежений с пафосным видом. И да - я опять говорю вам что делать :)

"Найкраще сало то ковбаса." (с)
Ответ
#76

БендеровецЪ Написал:И да - я опять говорю вам что делать Smile
И вторая попытка, также не удалась, как и первая.
Ответ
#77

БендеровецЪ Написал:И могли бы занятся чем-то более конструктивным
Мне есть чем заниматься.
БендеровецЪ Написал:м копание в чужих постах и написание опровежений с пафосным видом.
А вдруг кто прочитает, и в самом деле поверит что:
БендеровецЪ Написал:Но надо быть готовым писать асемблерные вставки, т.к. если фильтры писать на С то уходит гораздо больше ресурсов.
Ответ
#78

Altor Audio Написал:Мне есть чем заниматься.

Не заметно.

Altor Audio Написал:А вдруг кто прочитает, и в самом деле поверит что:
БендеровецЪ писал(а):
Но надо быть готовым писать асемблерные вставки, т.к. если фильтры писать на С то уходит гораздо больше ресурсов.

И? Вы так и остались несогласным с тем что в ряде случаев так и происходит?

"Найкраще сало то ковбаса." (с)
Ответ
#79

БендеровецЪ Написал:Вы так и остались несогласным с тем что в ряде случаев так и происходит?
В 0.01% случаев.
Ответ
#80

Процентность будет сильно зависить от того с чем приходится работать.
Вон и под СТМ ассемблерная библиотека откопалась. Тоже ж наверное человекочасы были не зря потрачены.

"Найкраще сало то ковбаса." (с)
Ответ


Возможно похожие темы ...
Тема / Автор Ответы Просмотры Последний пост
Последний пост от Zebra
01-18-2020, 11:08 PM

Перейти к форуму:


Пользователи, просматривающие эту тему: 1 Гость(ей)