Zbych wrote:

Pewnie na tym etapie
> nawet nie wiesz czy wystarczy ci stały przecinek, czy potrzebujesz floatów.

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

> Może się okazać, że z obróbką poradzi sobie zwykły ARM (wyższe modele
> też mają instrukcje charakterystyczne dla DSP).

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

do góry

W dniu 10.01.2018 o 11:39, Piotr Wyderski pisze:
> Zbych wrote:
>
>  Pewnie na tym etapie
>> nawet nie wiesz czy wystarczy ci stały przecinek, czy potrzebujesz
>> floatów.
>
> Średnie modele ARMów wspierają floaty, więc nawet ten dylemat mu odpadnie.
>
> > Może się okazać, że z obróbką poradzi sobie zwykły ARM (wyższe modele
> > też mają instrukcje charakterystyczne dla DSP).
>
> Te "zwykłe ARMy" z NEONem rozgniatają układy DSP sprzed kilku lat,
> bez całej tej niszowej otoczki związanej z programowaniem DSP.

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.

do góry

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.

do góry

sundayman wrote:

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

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

do góry

Zbych wrote:

> Popraw mnie jeśli się mylę, ale NEON to nie w Cortexach M-0...7, tylko
> A-cośtam

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.

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

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

do góry

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

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

do góry

W dniu 10.01.2018 o 23:29, Piotr Wyderski pisze:
> Zbych wrote:
>
>> Popraw mnie jeśli się mylę, ale NEON to nie w Cortexach M-0...7, tylko
>> A-cośtam
>
> 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.
>
>> 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.
>
> 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.

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.

do góry

Zbych wrote:

> Zależy co zdefiniujesz jako sensowne. Z twoim podejściem typu "włóżmy
> procesor 10GHz+64GB RAM na wszelki wypadek"

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.

> faktycznie już teraz byłby problem bez BGA.

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

do góry

sundayman wrote:

> Z QFN problemu nie mam , już stosowałem. Ale BGA na razie się boję :)

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:

https://www.enclustra.com/en/products/system-on-chip
-modules/mars-zx3/

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

https://shop.trenz-electronic.de/en/TE0722-02-07S-1C
-DIPFORTy1-Soft-Propeller-mit-Xilinx-Z-7007S-Single-
core-16-MByte-Flash?c=348

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

Pozdrawiam, Piotr

do góry

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

> 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

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

do góry