Börja med DSP ?

[4kTRB]

Hittade en, tydligen, bra bok om DSP https://www.amazon.se/Understanding-Dig ... 707&sr=8-1

Men sedan ska man ju ha hårdvara också och det har funnits starter kits ifrån Analog Devices och Texas och kanske ifrån Motorola också.
Men nu för tiden ska man kanske kika på annat?
Vad i så fall?

[4kTRB]

Här listas en hel del Starter Kits https://frontline-electronics.com/html/ ... rdPage.htm
men de där hittar man väl bara på ebay kan jag tro.

[4kTRB]

Den här går att plugga in en Arduino R3 på och sedan Eclipse IDE - CodeWarrior for MCUs. Kostar under 600kr.
Kanske vore något att börja med.
https://www.mouser.se/new/nxp-semicondu ... dev-board/

[rvl]

Som jag läser det så behövs ingen Arduino, men man kan använda "skjödar" med samma kontakt.

[4kTRB]

Ok. Ja det finns ju lite att välja på i så fall.
Jag tycker priset var intressant. Lite som att köpa en nybörjargitarr kanske fast
en sådan där MC56F83 räcker nog till en hel del kul applikationer och experiment.
Texas och Analog Devices starter kits kostar mångdubbelt mer. Fast de kanske
är mer mångsidiga.

[Nerre]

Ska man bara lära sig jobba med en DSP behöver man väl egentligen ingen DSP?

Jag menar, de beräkningar en DSP kan göra kan väl vilken dator som helst göra, DSPn är bara optimerad så den kan göra det mer effektiv/snabbare?

Testa koden kan man ju göra bara genom att stoppa in valfri genererad data och se vad som kommer ut.

När jag skrev ett digitalt filter en gång i tiden så vill jag minnas att jag t.o.m. skrev ett kort program i C för att räkna fram parametrarna som skulle in i assemblerkoden, istället för att behöva sitta och handräkna dem. Detta filter användes aldrig i realtid utan testades bara med färdiga data i en emulator (hade alltså inte ens tillgång till en fysisk DSP). Tror främst jag körde impulssvar eller stegsvar.

[4kTRB]

Jo tanken är ju att sedan kunna implementera en DSP i något projekt så jag ser
ingen nackdel med att ha lärt mig en DSP, exempelvis nu NXP:s DSP, är väl i princip samma som äldre Motorola.
Å sedan har jag implementerat regler-applikationer med 68HC11, assemblerprogrammerat, till ett andra ordningen system, var ett tag sedan dock,
höll på med Z-transform.

[Nerre]

Det jag gjorde var mitt examensarbete efter 80p elektroingenjör, och det som var svårast i mitt fall var att den DSP som jag skulle göra detta på var en TMS320 C80. Den kallades inte ens DSP utan multimediaprocessor tror jag.

Den hade en vanlig "master" RISC-processor och sen 4 stycken som jag tror kallades ADSP i samma kapsel. Dessutom hade kapseln en massa minne i sig uppdelat i banker. Så det var mer eller mindre en liten dator i en och samma kapsel. ADSP:erna var roliga, men för att kunna utnyttja dem fullt behövde man koda i assembler och ha ganska "statisk" kod. De hade en ALU som kunde jobba i split mode, en 32-bitars, två 16-bitars eller fyra 8-bitars operationer på en instruktionscykel (som jag tror var fyra klockcykler). Och ALU hanterade addition, subtraktion och multiplikation på en instruktionscykel. Men sen hade de dessutom en adress-ALU som man kunde utnyttja parallellt (om man inte behövde räkna adress kunde man använda den för addition eller subtraktion). De hade en "barrel rotator" så ett ord kunde roteras valfritt antal bitar under en och samma instruktion.

Så om man jobbade med bytes som data så kunde man med trixande räkna ut "kvadratsumma" av 4 bytes på en instruktionscykel (i genomsnitt, man behöver 4 instruktionscykler för att räkna ut det för 16 bytes har jag för mig).

Problemet jag fick var att läsning från externt RAM tog 15 instruktionscykler. Så även om jag kunde göra filterberäkningen snabbare så tog det alltså 30 instruktionscykler från att jag läste in ett värde tills jag kunde skriva ut det... Så det blev lite väl mycket fördröjning.

Sen när jag var klar så fick jag veta att de ville egentligen inte ta reda på hur snabbt filtret gick att göra utan hur många filter man kunde få in... Men jag hade ju inte gjort nån parallellisering alls för jag hade bara fått uppgiften att implementera ett filter.

Jag undrar var jag har rapporten...

[Glenn]

Undrar om inte jag räddade ett DSP devkit från förra jobbet när jag slutade, frågan är var det tog vägen.. I vilken låda det ligger :/

[4kTRB]

Ett annat sätt verkar vara att labba med audio-DSP. Texas har något utvecklingskort men väldigt dyrt.

Finns schema för att bygga eget: https://freedsp.github.io/
eller det här arduino-kompatibla för runt 500kr
https://www.ohmic.net/puca-dsp
Sedan finns en SDR pyton-dsp-kurs: https://pysdr.org/index.html
För java (och pyton) : https://www.g0kla.com/sdr/tutorials/sdr_tutorial2.php

[AndLi]

Sen är väl frågan om behovet är så stort för dedikerade dsp:er idag. Eller man hugger i med en lite kraftfullare uC istället som tillverkas i enorma kvantiteter...och mer generella så man kan pressa säljare mot varandra....

[DanielM]

Vad ska ni ha detta till?
Jag brukar använda frekvensanalys, men då kör jag FFTpack.
Eventuellt brukar jag utföra conv och conv2 för matriser.

[4kTRB]

Citerar https://www.analog.com/en/resources/ana ... art-2.html

The DSP’s high-speed arithmetic and logical hardware is programmed to rapidly execute algorithms modelling the filter transformation.
The combination of design elements­ arithmetic operators, memory handling, instruction set, parallelism, data addressing­ that provide this ability forms the key difference between DSPs and other kinds of processors.

Snabba uC klarar inte lika bra det som DSP kan, tydligen.

[4kTRB]

Här är en snabb Arduinokompatibel processor som ska duga för audio i vilket fall.
https://www.kickstarter.com/projects/pa ... -35-and-36
https://www.kb6nu.com/can-dsp-arduino/

[DanielM]

Ingen som har testat CMSIS-DSP?