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 ?

do góry

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.

do góry

W dniu 2018-01-07 o 04:50, sundayman pisze:
> 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.
>

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.

do góry

Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:p2s21v$1sji$1@gioia.aioe.org...
> Moje pierwsze podejście do tematu, więc proszę o wyrozumiałość.
> Co potrzeba;
>
Wez dspic'a ep33 wszystko w jednym a i cena nie powala
ale to oczywiscie zalezy jak szybko potrzebujesz liczyć.
michal

do góry

michal wrote:

> Wez dspic'a ep33 wszystko w jednym a i cena nie powala

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

do góry

W dniu 07.01.2018 o 03:52, sundayman pisze:

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

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).

do góry

> 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).

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...

do góry

W dniu 07.01.2018 o 17:55, Piotr Wyderski pisze:
> michal wrote:
>
>> Wez dspic'a ep33 wszystko w jednym a i cena nie powala
>
> 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.

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 :)

do góry

sundayman wrote:


> 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 :)

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

do góry

sundayman wrote:

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

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

do góry