21 ...editoval Dohnalik (11. 9. 2014 18:03)

Re: Vývoj použitelného DSPčka

Ano, jak píšeš, UAC2 má přímo control pro EQ a podobně, což vypadá velice zajímavě, ale nepokryje to to, co my potřebujeme, takže HID bude bohatě stačit a není to nic složitého.

Navrhoval bych výstupy 2x 4 pásma + výstup pro stereo/mono sub zesík. Řetězec bych viděl na vstupní MUX+mixer, filtrace DC, vypinatelný subsonický filtr, několik parametrických EQ, jeden velký 40 pásmový EQ, pak výhybky (řád, strmost, typ filtru, lomící frekvence konfigurovatelné), pak další param EQ u každého pásma na doladění, za tím nějaký delay, fáze a nakonec regulace gainu jednotlivých pásem.

Pokud by se povedlo tohle, dá se uvažovat o rozšíření o nějaký room correction techniky, Linkwitzova transformace, noise reduction, možná i správně použitá DRC nemusí být na škodu...

Je to běh na velmi dlouhou trať, pod 3-4 roky to nevidím reálně, nicméně pak by z toho mohl být slušný komerční projekt.

22 ...editoval tubamusic (11. 9. 2014 18:20)

Re: Vývoj použitelného DSPčka

Je super, že jste se nad tím takto zamysleli. 80% toho co tu řešíte je pro mě naprosto cizí řeč, kterou neovládám. Já osobně mám celkem jasnou představu o tom, jak by to mělo ve výsledku vypadat a fungovat. Neříkám tím však, že moje představa je správná. Co se týče digitální části a softu nemohu nijak přispět. Kladu si pár otázek, které zatím netuším, jak by se v daném případě řešili. Začnu od konce. Regulace hlasitosi všech šesti výstupů se mi nějak nelíbí řešit digitálně. To že se bude muset úrověň výstupu regulovat je jasné, protože pak by před každý koncový stupeň musel být zařazen ovladač hlasitosti. Relátková regulace by byla sice pěkná věc, nic méně dost nákladná a zabrala by hodně místa. Nešlo by to tedy řešit šetinástobným motorovým Alpsem? Šestinásobným potem by to bylo zas možné pouze v případě, že by byly výstupy nesymetické. V případě symetrických výstupů by nejspíš bylo potřeba regulovat 12 potenciometrů. Zas je to trochu utopie. Další věc co mi vrtá hlavou, jak vyřešit ovládací prvky. Původně jsem myslel, že by to mělo být ovládané pouze přes USB, ale Když si uvědomím, že takovou věc převezu z jedné aparatury na jinou, v té chvíli třeba nemám z nějakého důvodu možnost počítače, je tu v tu chvíli docela problém. Možná by stačilo mít tam možnost několika editovatelných presetů ( samozřejmě přededitovaných v PC předem), které by šly přepínat na předním panelu. Zvolený preset by pak buď rozsvítil příslušnou LED na panelu, nebo se zobrazil jako číslo na LED segmentovém displeji. Přepínání presetů by mohlo být pomocí dvou tlačítek Up/Down nebo pro každý preset zvlašť tlačítko + příslušná led. Nebo to tedy pak celé řešit tak, že by na předním panelu byly dva otočné codery a jednoduchý display. Jedním ovladačem by se primárně volil vstup a druhým celková hlasitost. Otočné ovladače by fungovaly i jako tlačítka, které by vyvolaly daší funkce. Jako je přepínání presetů, změna výstupní úrovně pro jednotlivá pásma atp.. Teď mi napadá, že v tomto případě, by byl spřažený šestinásobný alps asi k ničemu, protože je třeba regulovat úroveň každého pásma zvlášť...
No raději zas budu chvíli nečině pozorovat, jak se tahle plodná a hodnotná diskuse vyvijí. Díky, že jste se nad tím zamysleli.

Vzdáleně se blíží mé představě něco jako toto, ale na domácí poslech to není. Zvukově je to bída. Uvádím, jen jako příklad řešení.

Web

23

Re: Vývoj použitelného DSPčka

Ovládání bych viděl na nějaký barevný dotykáč, který můžete vidět i na vývojových kitech od ST. Něco takového: goo.gl/LPmCKa
Tady můžete vidět co se s tím dá dělat: goo.gl/FDxrqN
MCU je velmi podobný tomu s kterým si teď hraji (STM32F407). Je to v podstatě taky STM32F4xx až na to, že má nějaké věci navíc. Co je dobré, že má 2MB Flash a 256 KB RAMky a s tím už se dají dělat dost velké kouzla. Hlavně pro věci jdoucí za display-em se to hodí. Dá se to rozšířit i o další paměť, ale problém je, že se pak blokují periferie, které se můžou hodit. Nicméně to i tak chce (asi z mé strany) testnout piny co budou potřeba. Kit mám doma takže to je to nejmenší a i kity na USB2 atd. mám. Vlastně mám vše co potřebuji k vývoji. smile

Co se týče mě a vývoje tak to vidím tak, že bych udělal USB, k tomu bych si domluvil interface jdoucí za PC a DSP a to je celé. Ostatní věci by šly mimo mně včetně celkového designu. Nicméně je i tak potřeba počítat, že se to bude muset z počátku rozflágat na moduly a s těmi pracovat. Proč? Už mě STMka párkrát vypekla špatnými označenými PINami a předělávat co chvíli celkový layout je cestou do pekla. smile

Nicméně natli jste mě pěkně. Nakonec bych měl to svoje heblo i dodělat, protože bez toho to půjde těžko big_smile

Web

24

Re: Vývoj použitelného DSPčka

Malé změny hlasitosti lze dělat digitálně a velký, kde by už digitální regulace znamenala ztrátu informace, by se dělalo analogově...alps asi nebude mít úplně úžasnej souběh, zvlášť ten 6 násobnej. Kdybychom použili hybrid analog-digitál, tak by regulace byla naprosto plynulá s tím, že by nebylo potřeba moc stupňů relátek.

Zbytek co říkáš (presety a spol) by byl bez problému proveditelnej.

25 ...editoval Dohnalik (11. 9. 2014 19:41)

Re: Vývoj použitelného DSPčka

//Já bych se asi s Hazysem pustil do DSP, pak bych udělal DAC. Dál by to chtělo nějakýho člověka co udělá analog za DAC, relátka. No a na ovladače pod winy + řidicí SW bych měl jednoho borce smile Máme ovladače zatím ve stadiu ladění feedbacku, ono ty endpointy jsou chytrý jako horákyně i na straně hosta...pak se naváže KS a ASIO a nejhorší je hotovo (USB část už šlape a komunikuje). Jenže muselo by se to uzavřít mezi náma a pak bysme vyšli s hotovým komerčním projektem, tohle zadarmo nedám a ostatní si myslím, že to budou vidět stejně.

26

Re: Vývoj použitelného DSPčka

@Dohnalík: To je to co jsem říkal už na začátku. Upřímně jestli někdo si myslí, že dám jako opensource projekt na kterým dělám pomalu 2 roky (nepočítám učení a věci, abych to vůbec mohl dělat) tak je hodně naivní. Prostě ta návratnost tam musí být. Jinak to nemá cenu. Neříkám, že se potřebuji topit v penězích, to ne. Ale chci, aby mi to minimálně zaplatilo vstupy a nějaké prachy na další vývoj by se taky šikly.

Já stejně dělám aktivity, které mě odprostí od peněz, ale to neznamená, že budu pak svým snažením dělat něco co chce jeden člověk (no offense). Určitě bych to chtělo i trošku zmapovat trh. Možná by se to dalo v určité fázi překlopit ku příkladu na startup. Nabízí to pak lepší model financování a i ku příkladu Dohnalíkovi by to dalo větší prostor pro vývoj. Pochopitelně, že lidé, kteří by v tom byli zainteresování by měli volný přístup ke zdrojům. Tím mám na mysli vzorky, věci v různých fázích vývoje, soft atd. To je, ale všechno trošku daleko.

Zatím bych na místě autora sbíral informace. Udělal nějaký koncept, ten tu nahodil a pak by jsem mohli pokračovat dál. Minimálně mě to dá prostor dodělat věci co musím dodělat. Tyto věci se dají řešit zadarmo. Jakmile by to mělo nějakou "realnou" představu tak by jsme se mohli domluvit na dalším postupu. Toto co tady popisuji jsou běžné fáze vývoje od "snu" až po realný výsledek.

Web

27

Re: Vývoj použitelného DSPčka

xmarek: Pokud chceš obsluhovat nějaké větší než miniaturní LCDčko, je vhodný použít třeba 427 nebo snad 439, kde je LTDC a DMA2D. Jinak je to o hovně a MCU to bude prostě vytěžovat víc, než málo. S LTDC si tu teďka hrám já. Koupil sem si naposled 4 pěkný levný QVGA TFT panýlky a teď, co sem více zaryl rypák do datasheetu zjišťuji, že ten interface jejich je nějakej zkurvenej a jsou tam nějaký pošahaný signály, který normální TFTčko vůbec nepotřebuje. Možná to byl jeden z důvodů, proč byly tak levné.
Jen prosím u těhle F4 majker dávejte bacha na revize, teď z hlavy si nevzpomenu, ale některé revize mají vadný FMC, který se nesnese současně na sběrnici se SDRAM a periferií typu SRAM - náhodně chybuje při přenosech dat.

Jakej konkrétně byl problém s I2S na externí clocky? Já s tímhle ještě neexperimentoval (nebyl důvod), ale domnívám se, že se jedná o poměrně snadný úkon.

dohnalik: To už nějak začíná vypadat, že snad se mnou počítáš? Hm.. však jsem říkal, že to asi nebude moc dobrý :-/ Účistnit se mohu spíš jako externí žvástal - mohu zjistit prakticky libovolnou věc okolo STM32, či vyřešit problém.  Ale podílet se aktivně na profesionálním výrobku, ku kterému bych teprve studoval jak vlastně funguje, vidím jako spíše nereálné.

Ono těch relátek zas moc potřeba není, stačí binární útlumák. 7 relátek už dá >100dB s krokem 1dB. Mimochodem, taky by šly využít multiplexery možná, např ADG řada. Aspoň to nebude cvakat, nebude to pomalý a nebude to kurvítko. A cenově to asi bude prašť jak uhoď s kvalitními relátky.
Elektronický potenciometry chápu, že se nemusí líbit díky svým nelinearitám. Ale u muxu neni s linearitou problém, nikdo nikoho nenutí skrz něj pouštět větší než téměř nulový proud (to ostatně dělá jen hlupák).

28

Re: Vývoj použitelného DSPčka

@Hanyz: ano je to docela jednoduché, ale pro mě pouze teoreticky. Prostě zjistím interrupt na I2S a pak vezmu vzorek z DMA, podle frequence na I2S_IN, a ten pošlu na I2S. Toť teorie. Jelikož pracuji s příkladem od ST tak to bylo horší. Oni jsou totiž neuvěřitelní kecálisti. Ten příklad není vůbec asynchronní. Je synchronní a to ještě blbě. O nějaké podpoře více frequencí, bitové hloubky apod. si může zájemce nechát pouze zdát. Oni to řeší tak, že vezmou interrupt z SOF a pak ten vzorek pošlou na I2S což je pochopitelně blbě. Všechno to jede vůči rychlosti USB sběrnice. Lupalo to jako hrom, nemluvě o tom, že ten původní příklad pomalu ani nejel. Možná tak na jejich originálním Kitu, ale neměl jsem to vyzkoušené a stejně by mi to bylo k ničemu. Moje představa byla, že vykradu jejich USB komunikaci a tom postavím svůj transport. Teď je to ve fázi, že potřebuji prokopnout 24 bit. Už to mám nastřelené a cca. tuším jak to řešit. Pak dořeším UAC1 na HS (High speed) a další fází už bude UAC2, který mám cca. nastudované. Je to dost podobné jak UAC1, výhody jsou známé. Cíl je stejně UAC2, protože UAC1 ani ve widlích nefunguje úplně ideálně.
Jestli to bude na té 400 nebo jinačí je mi celkem šuma fuk. Určitě bude k display-i dost výkonu a cenový rozdíl je stejně zanedbatelný. Jestli zaplatím za čip o kilo víc neřeším. Výsledná cena stejně bude ve finále dost velká, s tím je třeba počítat.
Co se týče konzultací od tebe tak to určitě uvítáme, tedy minimálně já. Přece jen když jsem v něčem zabořený tak trochu ztrácím náhled a "nezávislý" pohled mě může posunout dál. wink

Jinak můj vývoj na těch STMkách bývá kolikrát pokus omyl. Dohledat některé informace je jak hledat jehlu v kupce sena. big_smile Jediné co člověk najde jsou dotaz na to jak co řešit, ale odpovědi bývá poskromnu. sad

Web

29

Re: Vývoj použitelného DSPčka

Odpovědi na dotazy ke STM32 ti mohu zodpovědět já, stejnětak tak dotazy na nedokumentované nebo na blbě dokumentované funkce.

Exámplkódy ST často ani nejsou zkoušené, není mi moc jasný, jak to teda v té divizi píšou, ale je poměrně běžné, že něco nechodí a jsou tam chyby. Jestli si už dělal s Cubem, tak asi dobře  víš, o čem mluvím. Btw hoši, doufám, že to nechcete patlat v kjúbu...  Standard Peripheral library taky není žádný zázrak (co se některých periferií, jmenovitě třeba I2C týká - to zas řeší CPAL), ale je to mnohem lepší, než se s tím drbat registrama. S tím já osobně problém nemám, na CM0 jsem se lehce učil i assembler, ale tak trochu to zdržuje.  Co je ale fakt, tak docela dost zákazníků STčka, co používají STM32 si píšou vlastní knihovny - takže i to je třeba cesta.

"Dohledat některé informace je jak hledat jehlu v kupce sena" - přes webový vyhledávač na st.com nepochybně, já mám přístup na lepší místa.

30

Re: Vývoj použitelného DSPčka

Nevím co je Cube. Já dělám vše oproti jejich Standard Peripheral library. Co tam není si píši sám. Funguje to pro mě jako dobrý základ.  Psát to v asembleru by byla sebevražda. Prošel jsem si asemblerem, ale dnes už většinu věcí i pro jiné čipy pišu v C-čku. Co se týče chyb tak to je u ST kapitola sama pro sebe, ale zase na druhé straně vím, že pokud to překonám tak mě to krásně posune, takže i když kolikrát kur**ji tak mi STMka vyhovují. Minimálně pro to, že se dají ještě rozumně pájet. U ostatních firem je to bída co je použitelné to je BGA a na to se mi doma nevyplatí mít doma mašinu. To je taky důvod proč jsem si STMka vybral. smile

Web

31 ...editoval Hazys (11. 9. 2014 21:32)

Re: Vývoj použitelného DSPčka

No jen se nesměj, STčkovská BGAčka mají snad prý 0,5mm pitch kuliček, to když bys chtěl náhodou doma dělat, tak neuděláš. Milimetrový doma dělat jdou. Nemluvě o těch CSP pouzdrech, to je teprve řešeto.

Neřikám psát to celý v assembleru, ale je vhodný mít o tom HW nějaký lepší povědomí. Třeba tuhle jsem na 32F207 řešil interrupt, který se musel vykonávat 120 000x za sekundu a musel žrát co nejméně výpočetního výkonu. Znalost ASM výhodou, aspoň jsem mohl zrevidovat, co vyblil kompilátor.


kjúp je tohle: http://www.st.com/web/en/catalog/tools/ … pe=keyword
barevný naklikávátko napsaný v javě na nastavení periferií procesoru a na nablití inicializačních zdrojáků. Bohužel je to takový moloch, který by se dal přirovnat programovacím interfejsem k italskýmu zmrdujínu, i co se rychlosti běhu kódu týká. Však si to stáhni, připrav blicí kýbl a nainstaluj. Naklikávátko je pěkný, ale ty STM32Cube knihovny stojí za řiť. Nějaký blikátka na LEDky se v tom dělat nějak daji hezky, ale pak jde rychle do tuhýho. Ještě horší je, že na nové L0 a L4 řady už StdPeriph driver nebude. (teda, pořád se pořádají neuvěřitelné názorové války markeťáci vs inženýři, ale kdo má poslední slovo je vcelku jasné).
To co dřív člověk normálně dělal přes GPIOx->BSRR, na to musí použí HAL_GPIO_WritePin(GPIOx, GPIO_PIN_n, GPIO_PIN_SET) a podobně. Neuvěřitelná přítěž na výpočetní výkon. Interrupty si obsluhuje HAL sám, k uživatelskýmu kódu se to dohrabe tak přes tři i víc volání nějakých interních funkcí. Tedy velmi rychlé ISR.
Prostě filozofií Cube knihoven je udělat z procesoru blackbox, který bude schopen naprogramovat i totální imbecil. Bohužel s touhle ideologií poněkud nesouhlasím.

32

Re: Vývoj použitelného DSPčka

Nepočítám s nikým, sám jsem řekl, že dřív jak za rok do toho nejdu smile Teď nastupuju na školu a budu mít zhnusenej dobrej půlrok...no a pak mám taky svoje věci, co jsou potřeba dodělat. Jak řekl xmarek, pokud se zmapuje trh, najdou ochotný lidi a bude zájem, tak do toho můžeme jít, jinak tyhle chujoviny můžeme vymýšlet donekonečna. Já do té doby můžu slíbit, že udělám jednoduchý DSP korekce basy, středy, loudness...abyste viděl jak se to chová a jak to měří. Chci to stejně do svojeho malýho projektu.

33

Re: Vývoj použitelného DSPčka

Upřímně já jsem původně JEE vývojář (enterprise Java), ale dávat to do těch čipů nechci. Java je dobrá jako multiplatformní věc, ale na PC. I když byla původně Java určená pro embeded tak svoji sílu ukazuje na serverech (aplikacích na nich běžících) kde člověk potřebuje všechno možné, různé protokoly, parsery, databáze a milión dalších sraček. Tam není s výkonem problém, navíc se to dá rozložit na jednotlivé PC. Ale jak se jedná o něco takového tak to ne, tam se vracím zpět ke svému asembleru. Tedy částečně, přece jen psát něco složitějšího už v ASM prostě nejde. Prošel jsem si v automatizaci (moje původní profese) vše od robotů počínaje po PLC konče skoro vše a až někdo uvidí knihu kódu v asembleru co má upravovat tak ho odvezou. Jenom učení zabere např. půl roku. A USB je opravdu maso a psát to od základu je sebevražda. Budoucnost STM bych neřešil, to nikdo neví a už se x-krát ukázalo, že obchodníci něco vymysleli a realita byla pak jiná. Protože kdo to nakonec rozhodne jsou zákazníci. A já jako "zákazník" na Javu kašlu. Upřímně sice nejsem v situaci, že bych to dokázal ovlivnit, ale kdo ví. Třeba se jednoho dne i ve firmě ST chytí za palici a řekne si, že ten debil Quarda (mé jméno) měl pravdu. big_smile

Web

34

Re: Vývoj použitelného DSPčka

V javě je psaný jen to naklikávadlo, do procesoru putuje normální Cčkovský kód, ovšem plný nechutných věcí a sviňáren, takže rychlostí běhu se to vyrovná asi tak té Javě.

35 ...editoval Dohnalik (11. 9. 2014 21:45)

Re: Vývoj použitelného DSPčka

xmarek napsal:

Java je dobrá jako multiplatformní věc, ale na PC.

hmm, ne big_smile sorry
Když aplikace na PC, tak v C++, když multiplatformní aplikace, tak v Qt v C++. Mám problém překousnout i C#, kdy takový naklikávátko píčovin žere 70MB RAM ani nemrknu, nicméně narozdíl od javy to alespoň běží. Ale v dnešní době každej na optimalizovanost sere, prioritou je rychlost vývoje, proto ty naklikávátka pro hromadu MCU (freescale, STM...snad jedinej atmel to nemá tak pošahaný) a ohromný .net frameworky, který sežerou ram ještě ani nic nedělají.

36 ...editoval cestmir (11. 9. 2014 21:55)

Re: Vývoj použitelného DSPčka

Dohnalik napsal:

nicméně narozdíl od javy to alespoň běží

To je povera. Normálne napísaná Javácka aplikácia beží rovnako dobre ako normálne napísaná .NET-ovina. Oba frameworky majú detské muchy roky vychytané. Samozrejme, sila managed prostredia sa neprejaví pri jednooknových pičovinách na naklikávanie niečoho. Ale trebárs tvoriť nejakú komplexnejšiu SOA vtákovinu v podnikovom prostredí v C++ je asi ako riešiť zložitejší firmware v assembleri. Proste každý tool je na niečo.

37

Re: Vývoj použitelného DSPčka

@Dohnalík: Představa většiny lidí jsou klikací nesmysly, a toto firmy nezajímá. Swing už je, ale v podstatě mrtvý. Všechno chtějí jako tenký klient nebo bez interakce s uživatelem a tam je zapotřebí trochu něco jiného. Psát tyto věci v C++ je sebevražda, navíc je to nepřenositelné. Zákazníka nezajímá na čem to běží, jim je to u zádele. Stačí se podívat v čem jsou psané databáze (vesměs Java) např. Oracle, MySQL atd. Dělal jsem např. pro mobilní operátory nebo banky a tam je Java, Java, Java ... Ano občas se člověk setká i s jinými věcmi např. .NET. Ale upřímně co to je. Nic jiného než Wrapper na sračky od Mrkvosoftu nic víc. A to, že je to velmi podobné Javě není tajemstvím. Vždyť Sun s Mrkvostoftem spolupracovali než se kvůli Javy totálně rozhádali. Jinak já se učím psát ty svoje věci v C#. Výhoda, že můžu volat Ckové knihovny a mám to vokýnkové. big_smile
Upřímně kdysi jsem uvažoval podobně jako ty, ale dneska už to tak neřeším. Důležité je pro mě, aby to fungovalo dobře a abych se neupsal. Takže když je potřeba tak jdu do ASM, nebo do C/C++, C# a i s Javou nemám problém. Ale jak jsem napsal musí to mít pro mě nějaké rozumné opodstatnění. A co důležité abych věděl která páčka. Což je třeba v případě USB na STM nutnost. To samé platí i pro PICy, nebo Cypress FX2/3.

Web

38 ...editoval cestmir (11. 9. 2014 22:06)

Re: Vývoj použitelného DSPčka

xmarek napsal:

Ale upřímně co to je. Nic jiného než Wrapper na sračky od Mrkvosoftu nic víc.

Čo sa týka čisto syntaxe, C# je (vďaka Andersovi Hejlsbergovi) "Java done right"... smile Čo sa týka runtime a knižníc, je to veľmi podobné. Že sa .NET nestal viac multiplatformný je trochu škoda. Mono sice žije, ale enterprise segment má obrovskú zotrvačnosť a je už zvyknutý na Javu (ktorá bola k dispozícii skôr).

39

Re: Vývoj použitelného DSPčka

Napočítal bych víc java aplikací co mi nefungovaly korektně, než těch co fungovaly...pro mě to pověra není. Za ty roky jsem to měl na hromadě OS, 32 i 64, linux, mac, windows... Navíc se mi neskutečně hnusí ta představa interpretovanýho jazyka, radšej C# smile

40 ...editoval cestmir (12. 9. 2014 9:00)

Re: Vývoj použitelného DSPčka

Bajtkód sa dávno naivne neinterpretuje ani v jednom prípade. Viď JIT.

Okrem toho žiaden z dvojice Java/.NET nie je viac alebo menej interpretovaný ako druhý, oba sú implementáciou tej istej paradigmy. C# (alebo iný CLI jazyk) sa prekladá do zásobníkového medzikódu (ten je vnútri v .NET assemblies, hoci majú ich súbory prípony EXE/DLL), ktorý je potom vykonávaný vo VM.