jaki wybrać DSP ?

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.

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.

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

Wez dspic'a ep33 wszystko w jednym a i cena nie powala ale to oczywiscie zalezy jak szybko potrzebujesz liczyć. michal

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

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

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

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

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

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

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

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.

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.

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

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

Z QFN problemu nie mam , już stosowałem. Ale BGA na razie się boję :) Oczywiście - nie ma innej drogi, z czasem się trzeba będzie dostosować. Nie tyle jest to problemem przy serii, bo idzie zlecić, ale boję się bardziej o prototypowanie.

No ale kwestia narzędzi i doświadczenia. W naszej branży pozostaje tylko ucieczka do przodu :)

Zależy co zdefiniujesz jako sensowne. Z twoim podejściem typu "włóżmy procesor 10GHz+64GB RAM na wszelki wypadek" faktycznie już teraz byłby problem bez BGA.

Nie "na wszelki wypadek", tylko "bo bez większych narzutów mogę". Dla mnie zasobem krytycznym jest czas, a nie oszczędność na częściach, więc muszę tym czasem gospodarować rozsądnie. Zwłaszcza z tego powodu, że lwią część budżetu czasowego pochłania mi uczenie się nowej architektury, jej środowiska narzędziowego i erraty. Często kończyło się na debugowaniu oscyloskopem i znajdowaniu błędów w datasheetach zarówno Microchipa, jak i Cypressa. Co ciekawe, głównie dotyczy to timingów ADC, ludzie sprawiają wrażenie, że nie rozumieją, jak działa ich własna konstrukcja. Takie przejścia wykonywałem już kilka razy w życiu i mi się znudziło. Dlatego jeśli coś nie jest ARMem (standard) i nie rozumie Verilogu w przypadku posiadania zasobów programowalnych, to dla mnie nie istnieje. Rozumiem jednak, że może istnieć dla innych, uzasadniam tylko swój punkt widzenia i to, z czym się wiąże przyjęcie innego.

Budowałem ostatnio coś w oparciu o kostki LTC, nawet nowe wzmacniacze operacyjne są w tej śmiesznej dwurzędowej obudowie BGA. Też nie znoszę tej obudowy, ale w tę stronę zmierza świat, więc albo się dostosujemy, albo nas przysypią warstwy geologiczne.

Pozdrawiam, Piotr

Z BGA problem jest z płytkarnią. QFN w większości przypadków obskoczysz płytką dwustronną, a to Ci zrobi każdy. Czterowarstwowe robi chyba tylko Technoservice (ale prototypy wychodzą słono, bo traktują je jako zamówienia produkcyjne), a w BGA osiem warstw nie jest niczym dziwnym. Cała nadzieja w Chińczykach, bo na polskie firmy tej sprawie nie liczę. W małych seriach rozsądnie wychodzi więc użyć modułów, np. takich:

Reszta płytki może być dwuwarstwowa. Trenz też ma sporo ciekawych konstrukcji, m.in. to:

Tu już na upartego zmieścisz się na jednej warstwie, więc widmo BGA się odsuwa.

Pozdrawiam, Piotr

W dniu 11.01.2018 o 10:36, Piotr Wyderski pisze:

Możesz mi wyjaśnić jak rdzeń ARM cię uratuje przed błędami w peryferiach, dokumentacji (np. ADC)?

Przy takim podejściu tym bardziej nie rozumiem polecania dużych ARMów (np. Cortexów-A) tam gdzie ich moc obliczeniowa nie jest potrzebna. Zaraz się zacznie ból głowy z Linuksem (jak zrobić hard real-time, jak się dobrać do np. przerwań, timerów bez pisania sterowników do jądra, jakieś binarne sterowniki które blokują aktualizację jądra, porzucanie wsparcia przez producentów itp.)