Nie nie czytalem tego PDF-u... po prostu RS znam z innych zastosowan. Jak mowilem siedze w DSP dosc dlugo - pisalem dekodowanie GSM/UMTS/LTE itp. glownie w profesjonalnych (komercyjnych) zastosowaniach (z tym ze na wyspecjalizowane uklady Picochip sporo wspomagajace sprzetowo)...
Natomiast co do testow to wlasnie polecam albo trial matlaba, albo octave - nie traci sie czasu na implementacje FFT, FIR czy co tam jeszcze - tylko uzywa gotowych funkcji czy tam narzedzi w stylu filter design itp.. Zaladowanie pliku wav to jedna funkcja [y,Fs] = audioread(filename), a FFT to Y = fft(X,n,dim)
Mozna w ten sposob szybko przetestowac dowolne algorytmy i zobaczyc jak sobie radza. Jak juz wszystko fajnie dziala to wtedy mozna sie brac za implementacje w jakims procesorku... a jak ktos nie chce sie bawic to w sporej czesci wypadkow mozna z tego nawet kod w C wygenerowac czy VHDL na FPGA - ale ja akurat tego nie uzywam bo czytelnosc kodu pozostawia wiele do zyczenia
Praktycznie w firmie wszystko tak robie bo inaczej to czas przygotowania projektu/produktu trwal by wieki - testujac to wszstko w C/C++
Zwlaszcza ze w firmie uzywamy na prawde cholernie skomplikowanych algorytmow... przykladowo radar 24GHz potrafiacy sledzic wiele obiektow w 3D - podajac ich predkosc, polozenie, rozmiar itp.
(niedlugo sie to moze kierowca nie spodobac, bo niedlugo wejdzie na polski rynek)
Natomiast co do malych prockow - to ja wlasnie dlatego jestem przeciwnikiem wszelkich nakladek w stylu Arduino czy standard peripheral library dla STM32... teoretycznie to ulatwia (choc w przypadku bibliotek od STM wrecz przeciwnie bo ich jakosc jest tragiczna), ale niestety kosztem pochlaniania cykli procesora i zasobow. Potem wychodzi ze nagle trzeba dawac coraz wieksze procki
I tak troche odbiegajac od tematu tutaj mozna zobaczyc co mozna z AVR-a wycisnac jak sie pisze kod z glowa
https://www.youtube.com/watch?v=sNCqrylNY-0
