Wybór DSP do analizy dźwięków w metalowej konstrukcji - jak dopasować?''

Sun Jan 07, 2018 3:52 am   

Moje pierwsze podejście do tematu, więc proszę o wyrozumiałość.
Co potrzeba;

Będzie sobie urządzenie pomiarowe, zasilanie np. z solarów (czyli moc
minimalizujemy generalnie).
Urządzenie ma za pomocą czujnika a'la "mikrofon" wykryć określone
dźwięki, które mogą powstać w pewnej metalowej konstrukcji.
Te dźwięki to coś w rodzaju "pisku" czy "gwizdu" - w przedziale
akustycznym. W tle sygnału mogą występować różne szumy, stuki etc.,
które oczywiście nie powinny rzutować na wykrywanie tego pisku.

Niemniej - jeżeli powstaje poszukiwany efekt dźwiękowy - jest on dość
dobrze słyszalny dla ludzkiego ucha. Oczywiście wysokość tego "pisku"
może być nieco zmienna - powiedzmy w przedziale 1-5 KHz czy coś koło
tego. Częstotliwość takiego pisku może się zmieniać w czasie - ale
generalnie jest to sygnał o wybijającej się jakiejś tam podstawowej
częstotliwości.

Na razie nie wiem,jakiego MCU użyję - samo urządzenie poza analizą
sygnału z czujnika (lub czujników) będzie miało jakiś wyświetlacz z
niezbyt wyrafinowanym GUI, do tego obsługa komunikacji via GPRS czy tam
WiFi.

Aha - sygnał z czujnika (lub kilku bo zakładam możliwość rozbudowy do
np. 2 czy 4 czujników) będzie cyfrowy, nie analogowy.
Najprawdopodobniej czujnikiem będzie jakiś mikrofon MEMS.
Czujnik jest mocowany do konstrukcji, nie zbiera dźwięku z powietrza,
tylko "z metalu".

No i teraz - pytanie podstawowe ; analiza w osobnym DSP czy w MCU ?
Wolałbym chyba, żeby osobny DSP - dodatkowe kilka USD nie robi tu
różnicy, a wolałbym mieć komfort użycia MCU tylko do obsługi samego
sterownika. Ale może przesadzam i do takiego celu nie warto używać
osobnego DSP ?

Jeżeli jednak osobny DSP - to jaki ? Na razie o DSP tylko czytałem,
interesowałem się układami w rodzaju ADAU (ale nie praktycznie).
Jak dobrać chip żeby "dał radę" ? Jak wspomniałem nie muszę oszczędzać
każdego centa - ale armata na muchy też nie ma sensu.

Co jeszcze ? Wolałbym uniknąć na razie obudów BGA, chyba że się nie da.
Pobór mocy - ma znaczenie. Dobrze by było, żeby całe urządzenie nie
pobierało więcej niż powiedzmy 3W.

A może "po pałam" - czyli MCU z wbudowanym DSP ? Ma to sens ?

Sun Jan 07, 2018 4:50 am   

Aha - no i pytanie; jeżeli DSP to Analog, Ti, jakiś inny ?

Nie mam żadnego doświadczenia, więc wszystko mi jedno niby, ale wolałbym
coś, co będzie w miarę łatwe do przyswojenia, do czego są przykłady,
biblioteki czy co tam potrzeba w praktyce.

Coś w miarę popularnego, żeby było kogo zapytać, dlaczego nie działa.
Dobrze, żeby były jakieś devkity na start.

Sun Jan 07, 2018 7:56 am   

W dniu 2018-01-07 o 04:50, sundayman pisze:

TI z rodziny TMS320F28... albo proste, F280x, albo już coś mocniejszego,
z FPU, np F28335.

Całkiem przyjemne, z flashem wewnątrz. bez problemu dostępne w LQFP i w
devkitach.

a.

Sun Jan 07, 2018 10:47 am   

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w wiadomości
news:p2s21v$1sji$1@gioia.aioe.org...

ale to oczywiscie zalezy jak szybko potrzebujesz liczyć.
michal

Sun Jan 07, 2018 5:55 pm   

michal wrote:


Za to do wykorzystania kostki potrzebna jest zgoda Wojewódzkiego
Konserwatora Zabytków i kompilator będzie miał wyłączoną optymalizację,
albo będziesz lżejszy o 800 dolców. To już lepiej wydać 1/3 tej kwoty na
jakąś płytkę z Zynq, gdzie będziesz miał dwa gigahercowe ARMy, a jeśli
i tego będzie mało, to sobie na FPGA dorzeźbisz brakujący akcelerator.

Pozdrawiam, Piotr

Sun Jan 07, 2018 9:05 pm   

W dniu 07.01.2018 o 03:52, sundayman pisze:


Wydaje mi się że zaczynasz od d... strony. Jeśli masz próbki sygnału,
który masz wykrywać to zacznij od prób z obróbką na PC, oszacuj
potrzebną moc obliczeniową i dopiero szukaj procka. Pewnie na tym etapie
nawet nie wiesz czy wystarczy ci stały przecinek, czy potrzebujesz floatów.
Może się okazać, że z obróbką poradzi sobie zwykły ARM (wyższe modele
też mają instrukcje charakterystyczne dla DSP).

Mon Jan 08, 2018 2:24 am   

fakt, nie wiem. Myślałem, że z opisu ktoś będzie miał pojęcie "na oko",
czego trzeba na to. Chciałbym mieć rozwiązanie z jakimś "zapasem", na
wypadek gdyby trzeba było coś zrobić inaczej...

Tue Jan 09, 2018 9:39 pm   

W dniu 07.01.2018 o 17:55, Piotr Wyderski pisze:

Hm...nie znam tego, na pierwszy rzut oka to mi wygląda na lekki
overkill, ale przyjrzę się jeszcze.

Chyba zrobię jak sugeruje Zbych - znaczy od sprawdzenia, jaka realnie mi
potrzebna moc. Co prawda na razie nie wiem, jak się do tego zabrać...
Kuśwa najgorsze są początki - zawsze jak się biorę za coś nowego to mam
wrażenie, że jestem kompletnym głąbem

Wed Jan 10, 2018 10:12 am   

sundayman wrote:



Przepuść te sugerowane próbki przez FFT (gotowce i żródła pewnie gdzieś są)
i powinny się Twoje dzwięki pojawić w widmie. I to wszystko.

jp

--

www.flowservice.pl
www.flowsystem.pl

Wed Jan 10, 2018 11:19 am   

sundayman wrote:


Co to jest overkill? Jeśli nie prowadzisz produkcji idącej w miliony
sztuk, to dominujące będą Twoje koszty NRE, a nie koszty części,
zwłaszcza w zakresie uczenia się nowej architektury. Więc sobie
weź najsilniejszy układ, na jaki Cię stać i się go naucz. Zynq
ma olbrzymią zaletę bycia ARMem, więc od razu masz dostęp do masy
darmowych narzędzi wysokiej jakości, a nie vendor-specific kompilatorów,
które nie radzą sobie z wspieraniem standardu C/C++ (Microchip)
albo w ogóle nie wspierają C++ (PSOC). Właśnie ta standardowość
jest w nich najfajniejsza: to jest zwykły ARM i zwykłe FPGA w jednym,
programowalne w Verilogu. Zdecydujesz się pójść gdzieś indziej, to
Ci cała wiedza i doświadczenie zostaje. Weźmiesz niszowe chipy,
to przy jakiejkolwiek próbie zmiany wszystko tracisz. Zaryzykuję
stwierdzenie, że procesor DSP to pojęcie z XX. wieku, które obecnie
nie ma większego sensu technicznego. Procesor ogólnego przeznaczenia
daje Ci 2 gigaflopy, a to jest znacznie więcej, niż miały specjalizowane
chipy wtedy. Nie masz potrzeby wchodzić w niszę, to w nią nie wchodź.

Poza tym nie przesadzajmy, mój Szajsung ma większą moc obliczeniową.

Pozdrawiam, Piotr

Wed Jan 10, 2018 11:39 am   

Zbych wrote:

Pewnie na tym etapie

Średnie modele ARMów wspierają floaty, więc nawet ten dylemat mu odpadnie.


Te "zwykłe ARMy" z NEONem rozgniatają układy DSP sprzed kilku lat,
bez całej tej niszowej otoczki związanej z programowaniem DSP.

Pozdrawiam, Piotr

Wed Jan 10, 2018 12:36 pm   

W dniu 10.01.2018 o 11:39, Piotr Wyderski pisze:

Popraw mnie jeśli się mylę, ale NEON to nie w Cortexach M-0...7, tylko
A-cośtam a to oznacza z kolei obudowy BGA, zewnętrzne flashe, RAM DDR2/3
itd. Zaraz się zaczną problemy, bo żre więcej prądu, bo mniej odporne na
drgania, cykle termiczne, wyciągnięte poza kość procka magistrale mogą
spowodować problemy z emisją, odpornością itp, a za dwa lata się okaże
że nie da się kupić już tego samego modułu z prockiem a dla kilku sztuk
nie będziesz robił swojej płytki pod BGA/DDR.

Wed Jan 10, 2018 11:06 pm   

Dla ciekawych - sobie przypomniałem, że już wcześniej wybrałem
(wstępnie) MCU do tego zastosowania
Nawet kupiłem devkita - STM32F746 Discovery. I będę na tym próbował.

Te SoC'e Xilinxa na pewno ciekawe są, tak czy owak dzięki za
podrzucenie, będę pamiętał o nich. Na razie jakoś chyba mnie to
przerasta, choćby z uwagi na BGA. Ale w przyszłości to na pewno dobry
kierunek.

Wed Jan 10, 2018 11:19 pm   

sundayman wrote:


To też jest ARM, więc kierunek dobry.
Podobały mi się kiedyś te procki, aż do momentu konieczności
rozegrania partii sudoku przy ustalaniu mappingu pinów i rzutu
oka na wynikową płytkę. Teraz nie ruszam niczego, co nie ma
routingu funkcji do wygodnych dla mnie pinów w krzemie (co ciekawe,
nawet najnowsze 8-bitowe PICe to już mają). Przerzuciłem się na
PSOC, a wkrótce będę migrował na Zynq.

Pozdrawiam, Piotr

Wed Jan 10, 2018 11:29 pm   

Zbych wrote:


Jasne, ale nie ma obowiązku używania SIMDów, to jest narzędzie
wymagające zarówno wsparcia sprzętowego, jak i, przede wszystkim,
odpowiednich umiejętności programistycznych. Rozmawialiśmy o floatach,
a to jest zaledwie Cortex M4. Proste SIMDy, nawiasem mówiąc, też. Więc
w kwestie stałoprzecinkowe można w ogóle nie wchodzić bez wyraźnej potrzeby.


Za dwa lata to możesz mieć problem z kupieniem sensownego chipu w wersji
nie-BGA. W przypadku FPGA już tak praktycznie się stało. Ja zostałem
"zmuszony" do polubienia QFN.

Pozdrawiam, Piotr