Página 1 de 1

Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 07 Abr 2021 22:46
por Guri
Os ARMs, creio que acima dos F4xx, possuem um core DSP além do CPU.

Pois bem, quando o usuário cria um cálculo, essa conta é feita automaticamente e diretamente no DSP? Ou tem algum caminho para chegar ao core DSP?

Eu tenho notado que a eficiência, se assim posso dizer com os cores F4 em diante são muito versáteis. Atualmente estou começando as brincadeiras com um core H7, acho que em overclock o carinha pega uns 500mhz...Interessante esses carinhas. :D

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 08 Abr 2021 19:53
por cfreund
O compilador deveria resolver isso pra você. Se este for muito antigo, ai tem de ser na unha,

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 09 Abr 2021 00:44
por sync
Colega

Você está testando as placas a venda no Aliexpress com Stm32h750vbt6 e stm32h743vit6 ?
Eu recebi uma propaganda do Ali com oferta delas e achei uma boa relação de custo/desempenho, mantenha-nos informado da sua avaliação.

Quanto à sua pergunta, imitando o STF eu sigo o voto do relator cfreund, com base no modelo de MCU definido no projeto, o compilador deve produzir um executável que utilize os recursos disponíveis

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 10 Abr 2021 23:20
por Guri
sync escreveu:Colega

Você está testando as placas a venda no Aliexpress com Stm32h750vbt6 e stm32h743vit6 ?
Eu recebi uma propaganda do Ali com oferta delas e achei uma boa relação de custo/desempenho, mantenha-nos informado da sua avaliação.

Quanto à sua pergunta, imitando o STF eu sigo o voto do relator cfreund, com base no modelo de MCU definido no projeto, o compilador deve produzir um executável que utilize os recursos disponíveis


:D Exatamente "sync", a plaquinha é um foguete turbinado da pirongueta espacial. É muito poderoso, no momento estou fazendo um teste de desempenho de processamento, quero ver até onde ele aguenta o "peso". Até o momento posso dizer que um F4 perto dele é babada. Não só pela velocidade que acredito que deva chegar em overclock a mais 500mhz (ainda não testei por falta de tempo), mas o desempenho é muito alto. O legal dessa plaquinha é que ela vem com uma RAM salvo engano de 8mega word e 2 mega de flash...

Postarei sim, mais detalhes...obrigado :lol:

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 11 Abr 2021 16:35
por dreher
No que eu achei quando precisei, o GCC tem as bibliotecas de matematica para as linhas dos microcontroladores, e tem algumas que justamente fazem os calculos puxando para a FPU ou DSP.

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 11 Abr 2021 16:47
por tcpipchip
eu tenho testado (mas em BASIC COMPILER) alguns turbinados da NXP, 600Mhz sem Overclocking...
São muito muito rápidos!

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 11 Abr 2021 21:13
por sync
Amigos
Olhando o manual em:

https://gcc.gnu.org/onlinedocs/gcc-9.3. ... RM-Options

o gcc se comporta como no tempo dos 386 com ou sem 387,
Código: Selecionar todos
-mfloat-abi=name
Specifies which floating-point ABI to use. Permissible values are: ‘soft’, ‘softfp’ and ‘hard’.

Specifying ‘soft’ causes GCC to generate output containing library calls for floating-point operations. ‘softfp’ allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. ‘hard’ allows generation of floating-point instructions and uses FPU-specific calling conventions.

The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries.

além disso, na definição da arquitetura (-march=) pode-se adicionar mais opções para ativar SIMD,DSP, FP de níveis diferentes de precisão dupla (16, 32 bits), etc. No link acima tem a coleção completa de arquiteturas e opções. E ainda por cima tem a opção de otimização -mtune

O colega Guri podia uma olhada o que o CubeMX IDE define para STM32F103 e para o STM32F7xx durante a compilação.

Uma caractterística que aumenta o desempenho dos F7/H7 além da frequência do clock são os caches L1 de instrução e de dados.

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 12 Abr 2021 09:31
por tcpipchip
sim

Pois é tudo reutilização de código, grande parte da Intel.

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 12 Abr 2021 10:33
por eletroinf
No Keil me parece que é necessário habilitar a FPU, pois é considerada um periférico.

https://www.keil.com/support/man/docs/a ... 958654.htm

Mas eu não tenho muita experiência nesses modelos com FPU.

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 12 Abr 2021 12:22
por vtrx
Sim,no Keil voce escolhe float point single ou outro disponível.

https://www.programmersought.com/article/31747390931/

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 19 Abr 2021 16:21
por Guri
sync escreveu:Amigos
Olhando o manual em:

https://gcc.gnu.org/onlinedocs/gcc-9.3. ... RM-Options

o gcc se comporta como no tempo dos 386 com ou sem 387,
Código: Selecionar todos
-mfloat-abi=name
Specifies which floating-point ABI to use. Permissible values are: ‘soft’, ‘softfp’ and ‘hard’.

Specifying ‘soft’ causes GCC to generate output containing library calls for floating-point operations. ‘softfp’ allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. ‘hard’ allows generation of floating-point instructions and uses FPU-specific calling conventions.

The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries.

além disso, na definição da arquitetura (-march=) pode-se adicionar mais opções para ativar SIMD,DSP, FP de níveis diferentes de precisão dupla (16, 32 bits), etc. No link acima tem a coleção completa de arquiteturas e opções. E ainda por cima tem a opção de otimização -mtune

O colega Guri podia uma olhada o que o CubeMX IDE define para STM32F103 e para o STM32F7xx durante a compilação.

Uma caractterística que aumenta o desempenho dos F7/H7 além da frequência do clock são os caches L1 de instrução e de dados.


Ótima análize, eu reparei mesmo que a linha F7 ou H7 tem caches, esse detalhe acredito eu aumentar o desempenho que já é grande pacas. Eu Graças a DEUS, terminei um trabalho complexo com F4 (o meu novo synth rodando tabelas de ondas senoidais) aguentou chutar 70 canais de polifonia, esse faz parte de um produto comercial, depois postarei algumas informações a respeito. Então quero e DEUS me dando saúde e paz, vou começar os estudos com o F7, que acredito dar pelo menos umas 4 x mas de carga de processamento, tenho sonhos mais altos. Como por exemplo a área de aúdio, to pensando em fazer uma mesa de som um mixer com todos os recursos embutidos, equalização, canais, reverber e eco, compressão....mas estou a estudar sobre microfonia, alguém tem alguma dica de literatura a esse respeito, quero aprender sobre isso!

Re: Uma questão de entendimento sobre o DSP no arm

MensagemEnviado: 19 Abr 2021 16:27
por Guri
Justamente, o fato de eu abrir esse post, foi tentar entender de fato como funcionam essas plataformas de gerenciamento para o DSP. Muito tenho visto falar sobre o assunto DSP e sobre a enorme capacidade de fazer cálculos e todos nós sabemos que cálculos são o x da questão e seus segredos, para quem entendeu né, :lol:

Eu sinceramente estou fascinado com este core, realmente é incrível a carga de processamento que ele aguenta. Um DSPIC, meia boca de 16bits já faz um arraso danado em termos de processamento, fico imaginando um DSP da texas ou da analóg....
Ainda bem que tiveram a ótima ideia de colocar esses cores nos chips ARM. NXP, até tentei iniciar estudos com eles, mas não se foi impressão minha, mas parece que essa empresa não é mais a mesma de quando começou, seus ideais, suportes, etc...e também quanto a disponibilidade do produto em sí de forma geral...