No, hned v úvodu jsem psal, na co to potřebuji. Co nejjednodušším způsobem ukládat a číst krátké zvukové soubory (wav) do nějaké RAM paměti a to pomocí PIC, protože nic jiného neumím. Je fakt, že pokud budu chtít přehrát určitý soubor odněkud někam, tak opravdu potřebuji něco na způsob FAT tabulky, protože minimálně musím vědět, kde ten soubor začíná a kde končí (nebo jak je dlouhý). Ale tabulku s těmito údaji si bez problému mohu vložit do programu a mělo by to fungovat stejně. Kdybych chtěl použít klasickou SRAM paměť (jak jsem původně uvažoval), tak to snad ani jinak udělat nejde. Takže nač se budu smolit s klasickou FAT a formátovaným mediem, když to jde i jinak a (pro mne) jednodušeji. Kdyby byly k dispopzici SRAM paměti s větší kapacitou, tak to udělám s nimi, ale nejsou. A navíc je tam problém se šířkou sběrnice. Leda že by existovaly sériové SRAM? 
.Teď mne zaujala zmínka o tom, že některé procesory přímo podporují práci s DRAM pamětmi. Platí to i pro mikrořadiče? A nevíte někdo, zda to umí i některý typ PIC?
Vl.
neee. V SRAM se ti data po odpojeni napajeni smazou.
CF karta, ne¨bo MMC, nebo jakakoliv jina formatovana neni. Kdo rika ze musi. Formatuje se to jenom kvuli tomu, ze se to strka do kompu, kde sou wokna. 
Příde mi naprosto zbytečný, dělat se s FAT, pokud to neni nutný. Tabulka může být “dynamicky nahrána” na začátku paměťovky. Bude tam tabulka, začátků a konců datových úseků. Stačit to bude. Kvůli pár souborům to nemá cenu, se s FAT zabývat.
Ale nevím jak je to s rychlostmi u PICů,má paměť dost velkou na to, aby si dovnitř přetáhnul celej soubor, a pak ho přehrával. Budeš ho muset postupně načítat, ale tady tě omezuje odezva paměťovky. Tj doba,. za kterou ti je schopna dodat data po jejich vyžádání. To lze jednoduše vyřešit pomocí “pseudo DMA”, to znaená, že data se průběžně ládují z pamětovky do procíku, který si vevnitř vytvoří FIFO paměť, ze který za pomoci přerušení bude posílat data pryč, do DAC.
Vim o jedný stránce, kde je DMA dobře popsaný. Můžu ti to najít, zdali budeš chtít.
Mozno by bolo aj dobre, keby si trochu popisal, k comu to ma sluzit.
Ak chces nacitat zvukovy signal do SDRAM, RAM, DDR znamea to, ze tie data po vypnuti napajania nepotrebujes. Zalohovanie baterkou vopred vylucujem, lebo ak chcas nahrat nejake spravy, ktore potom vysielas na zaklade nejakych pokynov, ryziko ze sa zmazu je velmi velke a preto prakticky nepouzitelne. Okrem toho, koho by neustale bavilo tie spravy nahravat na novo? Ak nie, ako ich dalej spracovavas?
FFT, zvukove efekty a na podobne veci nepotrebujes take kvantum pamate, okrem toho je PIC pre tieto pripady uplny zobrak co sa rychlosti spracovania tyka.
Dalsia moznost, ktora ma napada je, ze chces urobit nieco ako pamatovy osciloskop a data potom prenasas cez UART do PC. Tam mi ale tiez nesedi to kvantum pamate.
Tak k comu vlastne take mnozstvo pamate? A najhlavnejsi parameter pre vyber pamate - ako casto sa budu jednotlive pamatove oblasti prepisovat? Mozno by vzhladom na velku hustotu zapisu MMC a ani SD nevyhovovali.
Ak potrebujes iba prenasat data z AD do RAM a potom z RAM do DA, data vobec nemusia chodit cez procesor, ale procesor moze iba urcovat adresy z/do ktorych sa bude citat/zapisovat.
Obsluhovat SDRAM bude z PICa asi take komplikovane, ako obsluhovat nejaku SPI Flash pamat, ci uz MMC, alebo SD. Raz si naprogramujes funkciu, ktorej parametre budu:
fn_zapis( uint32_t adresa vo Flash, uint8_t pocet prenasanych bajtov, uint8_t od ktorej adresy v RAM procesora, uint8_t zapis/citanie) {}
/* zapis v konvenciach GCC */
Kazdy tvoj subor nemusi zacinat na nejakej predom dohodnutej adrese a nemusi mat pevnu dlzku. Staci ti do EEPROM procesora zapisat, kde sa subor nachadza (32b cislo) a aky je dlhy(32b cislo). Nasledujuci zaznam zacina tam, kde sa predchadzajuci skoncil. Takto zabezpecis dobre vyuzitie pamate. Ak predpokladas vymazavanie suborov “medzi” inymi nahravkami, mozes im otom pridelit bud pevnu dlzku pamate, napriklad kazdemu pre 4minuty zaznamu bez ohladu ci ju naplnia alebo nie, alebo potom musis pouzit suborovy system, kde kazdy subor bude pozozstavat zo sektorov a to uz zavana FATkou. To co som v predchadzajucom napisal sa tyka ako SPI Flash tak aj SDRAM.
Obsluha SPI pamati ma tu vyhodu, ze ak sa “nic” nedeje, logicky sa o pamat nemusis starat. SDRAM budes musiet venovat cas neustale a este k tomu asi pod prerusenim a ak sa ti program nejak pozdrzi a nestihnes ju vcas refresovat (aspon predpokladam z otazky, ze SDRAM sa navonok sprava ako DRAM) - pri DRAM boli tie casy radovo v ms, o data bezpecne prides, minimalne o niektore z nich. Bude ti dlho trvat kym to rozchodis odladis, najdes casove diery, atd., chce to urcite dobru pristrojovu vybavu. Na rozdiel od toho je praca s SPI Flash (MMC, SD) staticka, t.j. komuikaciu si mozes odkrokovat lubovolne pomaly a spravnost signalu tak namerat aj obycajnym voltmetrom. Mozno zozenies specializovany svab pre SDRAM, okrem toho SDRAM chce pre plne vyuziie strasne vela noziciek = velky procesor + velky plosak = mozne presluchy a chyby medzi spojmi = problemy. Ako tu jeden expert napisal ani pouzitie DDR nie je vylucene. Ale to je asi jednoduchsie pouzit nejaky LINUXovy modul, napr s AVR32, napriklad ATNGW100, ktory soji do 2000,-Sk a tam je okrem samotneho procesora aj sietove pripojenie, citacka kariet, USB i Ethernet rozhranie, 32MB Flash, 32MB SDRAM a predinstalovany Linux.
Ak pises, ze okrem PIC nic ine nevies, mozno je prave toto ten spravny cas prejst na nieco ine.
2 MArtin, tady asi někdo nečte: CO si pamatuji, tak chtěl vytvořit přehrávač zvukových záznamů. Takže nač kvanto poaměti je jasný. Nejhorší použitelná kvalita je 8 bitů mono, 11025kHz vzorkovačka. z toho vyplývá tok cca 10.7kB/s, což by ten PIC mohl zvládat bez problémů.
NEvím, jakou paměť SPI si měl na mysli, ale pokud něco stylu 24C128 a podobných jako jsou tyto na iic, tak měl bych pochybnosti, jaké rychlosti načítání dat z nich to zvládá. 11kB/s by to ale mělo dát vpohodě snad.
Do 64kB paměti se vejde “pouze” necelých 6 sekund záznamu.
Nic to ale nemění na tom, že něco jako FIFO, nebo Pseudo DMA je nutností. Ze sériových pamětí totiž není zrovna moc zaručené dostat dsouvislý datový tok. Souvíslý datový tok, celkem velkých rychlostí je možné získat použitím již zmiňované SRAM.
Například je také možné data z jakkoliv pomalého média přehrát do SRAM, a odtut (třeba i bez FIFO) pouštět do DAC rovnou.
Plánuju vyrobit něco podobného, tak uvidím, jak daleko se s tím dostanu, a jaké bude konečné zapojení.
Takze k uplne prvemu prispevku - hlasenia typu “nadrazni hlaseni”,
poziadavka na 16MB pamate.
24C128 NIE JE SPI komunkacia. Je to I2C komunikacia a je relativne velmi pomala.
Riesit sa to da roznymi sposobmi, ale pri pri pouziti DRAM treba vzdy osetrit problem pri vypnuti a zapnuti zariadenia, aby nedoslo k strate dat. Preto je dobre mat tie data niekde “na pevno” ulozene. Ja by som doporucil 4x AT45DB321 [4MB Flash v puzdre SO8, komunikacia SPI 66MHz, cena cca 60,-Sk].
Pri pouzitit takychto pamati je zbytocne realizovat medzi krok s DRAM, lebo hned ako sa data z Flash nacitaju, hned sa mozu poslat do DA (rovnako by sa pouzila MMC alebo SD karta, v kombinacii s FAT by sa dali nahravky elegantne spracovavat a nahravat cez citacku kariet priamo v PC, ale znacne by sa spomalovalo nacitanie dat pre streamovanie udajov do DA). Konstrukcne je AT45DBxxx omnoho jednoduchsia a velmi velmi mala. Ale suhlasim, ze akekolvek ine tu spomynane riesenie okrem SDRAM a DDR je rovnako dobre a pouzitelne.
Inak 8 bit je dost nekvalitnych i na stanicny rozhlas. Je tam uz dost pocut kvantizacny sum, ktory ma odstup od uzitocneho signalu iba nieco vyse 40dB. Robil som s kvalitou zvuku svojho casu experimenty a signal je uz dobre pouzitelny od 12bitov. Aj ked pri trocha snahe sa da rozumiet i 1bitovemu (slovom jedno) prevodu. Pre DA vystup doporucujem TDA1543, co je maly lacny stereo DA presne na audio ucely. Tu sa vyuzije len jeden kanal. Ak ratam 16b vzorku pri 11kBSp, potom na 1 sekundu treba 22kB. 4MB (ak sa pouzije iba jeden cip AT45DB321) vystacia na 182 sekund zaznamu, co je viac ako 3 minuty. A tri minuty je mrte zaznamu. Okrem toho sa daju hlasenia kombinovat tak, ze niektore slova/frazy su nahrate iba raz. Napriklad “Vlak odchadza z nastupista cislo” + “styri”.
Zvuky sa do AT45 mozu nahrat tak, ze z PC sa cez UART posielaju vzorky do PIC a ten si ich uklada primo do AT45.
AT45 maju interne dva RAM bufre po 512B. Pri citani je to prakticky jedno, noda sa to s vyhodou pouzit, ak treba do Flash kontinualne zapisovat. Zapis bufera do cistej Flash trva max 6ms. Pocas doby zapisu sa moze plnit druhy bufer a takto sa mozu navzajom oba bufre striedat. Da sa tak zvysit kontinualny zapis az na 85kB/sec. Citanie je vsak obmedzene iba hodinami a tie mozu ist az do 66MHz + nejake servisne bajty na urcenie adresy. A to by malo stacit i na kvalitne strereo na 44kHz.
Signalom CS_Flash a CS_DA by som urcoval, s ktorym obvodom sa bude hw SPI bavit. Na nacitanie jednej vzorky potrebujem preniest 2B dnu + 2B von + 4servisne bajty + 2B rezerva (kvalifikovany odhad) = 10bajtov*8bitov = 80bitov. Bilancia sa da zvysit nacitanim napr 32B zaznamu z Flash do interneho bufra.
Ak treba preniest 11000 vzoriek za sekundu, treba vediet dosiahnut SPI rychlost (pri jednom SPI )aspon 880kHz. S HW SPI urcite lavou zadnou.
Atmega na 14MHz moze vykonat vyse 100 instrukcii do najblizsieho prerusenia od SPI. ako je to s PIC - to vedia najlepsie jeho uzivatelia
Pri prenose stereo signalu na 44kHz by to uz bolo dost narocne, lebo by ostaval cas len na priblizne 12 instrukcii medzi preruseniami. A to je mozno akurat na zistenie, ci nebolo stlacene tlacitko stop prehravania.
Ale kedze som v uvahach pouzil hw SPI , obdobna situacia s casovanim by bola pri pouziti paralelneho prenosu z SRAM (mozno o 15-25% lepsia, ale nie zasadne). Lebo tam sa tiez manipuluje s bajtami, ako v pripade hw SPI. Takze to vyzera, ze limit konstrukcie nie je v tom, ci pouzit Flash (AT45,MMC,SD) alebo DRAM, ale v pouzitom procesore. Kedze vsak autor pisal, ze experimenty so SRAM boli uspesne, len bolo malo pamate, vyzera to, ze pouzitie SPI Flash by malo byt uspesne tiez, pricom sa zda, ze je to konstrukcne jednoduchsie ako pouzit SDRAM.
Ale vela ciast vedie k vytuzenemu cielu, tak som sam zvedavy, ako sa autor rozhodne a ake bude mat vysledky.
Martin
Precejenom neumime cist 
“24C128 a podobných jako jsou tyto na iic,”
pouzdro SO8 - kdyz to dokaze pripajet… ja ne.
Otazka je, zdali pic bude stihat davat data z karty pres SPI rovnou do DA.
ad qalita: 8bit 11kHz je na staniční rozhlas řek bych dost. to, cim to reprodukuji, tak tomu vetsi kvalita zaznamu moc nepomuze.
Zvyseni vzorkkovacky 8b 44100Hz zlepsi kvalitu o mnoho, ovsem o chudak pic, rozdejcha to vubec? (AVRko sto%, na AVRmega32 bezi pohodove prehravac MODu, stereo, 16bit, 44100Hz). Picum nerozumim, ale neco mi rika, ze AVR jsou rychlejsi.
S decibelama na me nechodte, nechapu vubec co to znamena.
TDA1543 je sice hezky, ale ma to cenu na stanicni rozhlas? (mono nevalne qality?)
To že to AT45 stíhá, neznamená že to bude stíhat PIC.
ATmega na 14MHz (jak si na takle blbou frekvenci prisel? 
) - jasny, ze AVR bude stihat. PIC ale nejspis ne.
“moze vykonat vyse 100 instrukcii do najblizsieho prerusenia od SPI” em nepochopil. To mam chapat jako ze pote co pridou data, ma stoo instrukcí, než přídou další? Tohle je řek bych velice blbá metoda, která plně nevyužívá výkon procesoru.
Trochu si to rozebereme:
Prijdou data z SPI. Procesor je zacne hnedka ládovat do DAC. pozada o dalsi data. MUSI CEKAT. Mist oaby delal neco smysluplneho.
Prijdou dalsi data, strci je zas do DAC.
Pozada oo dalsi. DAta neprichazi vcas, a je průser na světě.
DAleko lépe, to lze řešit takto:
(bereme kvalitu 11025Hz, 16bitů, mono)
Vyhradí se kus paměti jako FIFO buffer. (uvnitř procíku)
spustí se přerušení, které bude ve vhodných chvílích/časových intervalech ládovat data do DAC.
Mezitím poběží hlavní program (smyčka programu), která bude neustále ládovat data do FIFO bufferu, dokud se nezaplni. Az se trochu vyprazdni, hned se zacne do nej ladovat znova.
Pokud bude mit buffer 1kB, a dejme tomu, ze procikovi bude trvat prumerne naladovat do bafru 1 bajt cca 30 instrukcí (možná i o dost míň)
to nám zaplní bafr po 102430 instrukcí, což je 30720 instrukcí.
Dejme tomu, že to bude AVR s taktem 16MHz (takt/instrukce).
Buffer se bude vyprazdňovat rychlostí 110252 bajtu za sekundu (22050B/s) To znamena, ze je traba buffer naplnit 22050/1024 krat za sekundu. 21.53x. 21.53*30720 bude celkem potreba 661401 (přibližně) instrukcí na 1 sekundu přehrávání. (nepočítám s tim co sežere přerušení).
avr na 16MHz zvládne 16000000 instrukc za sekundu. Odečteš li těch 662000, zůstane ti 15338000 instrukcí, který můžeš nějak využít.
AVRko bude vytížené na směšných 4.5%. (s přerušením, které jsem zanedbal, no přes deset % to opravdu nebude).
U toho pice to bude podobné, pokud má instrukci na tak, a zvládne 16MHz, sice nám vyjde vytížení taky asi max. 10%, al s tim rozdílem, že volných instrukcí, kde může dělat něco podobného (když vezmu způsob přímého ládování do DAC) že bude možnost dělat za sebou něco jiného jen pár desítek istrukcí. U toho avr, které naplní buffer za 30700 instrukcí, a neš se buffer vyprázdní, tak má volno přibližně 740000 instrukcí. ZA sebou, bez přestání (nepočítám li zase přerušení)
Což 100 a 700000 instrukcí je lehce rozdíl.
Je to jen prostá středoškolská matematika.
Vy neviete citat 
Nikde predsa netvrdim, ze tvrdite opak. Ved sam pisete, ze sa jedna o iic, len som chcel Vasu informaciu podtrhnut.
Je to 1.27mm, to sa celkom da, len trocha praxe.
Otazka je, zdali pic bude stihat davat data z karty pres SPI rovnou do DA.
Podla mojich skusenosti je 11kHz celkom OK, len ten maly odstup signal sum zanechava na konci hlaseni taky kratky sumovy “zavoj” a ten je dost pocut. Ak to vsak objednavatelovi vadit nebude - OK. Na tej stanici totizto vznika efekt zvysenej citlivosti pri hlaseni na zvuky, ktore sa rynu z miestneho rozhlasu. Preto si taketo - za inych okolnosti nepodstatne- ruchy clovek lahko vsimne. A ten sum je zosilneny miestnym rozhlasom, neupada preto do uzadia v porovnani so sumom na nastupisti, lebo hlasenie ma tieto ruchy prekricat. Urcite vsak treba konkretne nahravky prehrat v konkretnom prostredi a podla toho sa rozhodnut. Na konecnu upravu som pouzival Audacity k velkej spokojnosti. Mozno by sa ta nahravka v konecnej faze dala pouzit k spokojnosti i ako 8 bitova.
to iste
Ludske uch vnima hlasitost nie linearne, ale logaritmicky. To znamena, ze dvojnasobny hluk nevnima ako dvojnasobny hluk.
Na napatovej urovni zodpoveda dvojnasobny hluk 6dB. Dalsi dvojnasobny hluk 6dB, takze 4 nasobny hluk je v logaritmickej miere rozdiel 12dB.
Z toho vyplyva, ze 10x vacsi hluk je rozdiel 20dB, 100x vacsi hluk 40dB
200x vacsi hluk 46dB. kedze pri 8 bitoch je rozdiel jednotlivych dvoch susednych signalov 1/256 a na tejto urovni sa do signalu vmiesava kvantizacny sum (ak sa dve susediace vzodky lisia o 1/512, prevodnik tam vlozi bud 0, alebo az 1, cim vznikne chyba 1/2LSB, prejavujuca sa vo vyslednom zvuku ako sum, najviac patrny v tichych pasazach). pri 12bitoch je kvantizacny sum na urovni 72dB, na 16bitoch 96dB. To je ten udaj ktory sa uvadza na CD prehravacoch. Takze tak velmi v kratkosti k decibelom.
TDA1543 stoji v DIL8 puzdre 43,-Sk. Co tam chcete dat lacnejsieho?
Ak je Atmega do 16MHz, tak najblizsi Xtal pre spravne generovanie UARTovych frekvencii je 14.7456MHz. Pre nove ATmega do 20MHz je to 18.432MHz. Obe hodnoty su bezne k dostaniu, omluvam sa ze som v rychlosti vynechal desatiny
Jasne ze sa tam nema co flakat. Vlozim 1B do SPI registra pre odvysielanie dolnej casti adresy z Flash. Pri takte 1MHz sa tento bajt odvysiela za 8us. za tuto dobu moze procesor spravit pri Xtale 14.7456MHz 117.9 jednotaktovych instrukcii. Na co ma procesor cakat? Nech zatial obsluhuje display alebo tlacitka, alebo co. Potom sa to este 1x zopakuje (priklad pre nacitanie dat z bufera AT45). Potom zapisem do SPI regislta 0xff a pri najblizsom preruseni mi pride prvy bajt, ktory mam poslat do DA. To zopakujem znovu a mam druhy bajt z Flash. Vypnem CS pre Flash, zapnem CS pre DA a poslem na zbernicu prvy bajt do DA. Po preruseni od odvysielanie zapisem do SPI druhy bajt do DA. Po dalsom preruseni viem, ze som nacital jednu 16b vzorku z Flash a poslal som ju do DA. Spolu 6 bajtov a teoreticky 117x6 = 702 volnych jednotaktovych instrukcii procesora. treba odratat instrukcie spojene s vybavenim prerusenia PUSH , POP a zvysok sa co ma co flakat. Na to som tu ja, on je na robotu.
Nacitanie a zapis jednej vzorky trva 861us = 48us. Treba pripocitat este nejaky cas na zmenu CS a na nastavenie nacitania dalsej sranky vo Flash.
I tak sa da, moje riesenie nepotrebuje nejaky speci bufer - prihliadal som na “moznosti” PIC.
Samozrejme, ako som pisal, je viac dobrych ciest k tomu istemu a toto je jedna znich.
Vo Vasich vypoctoch predpokladate 30 instrukcii na nacitanie bajtu. Ja ich nepotrebujem, lebo bajt sa nacita z Flash a zapisuje do DA cez hw SPI.
Jedina uvaha je, ci instrukcie spojene s vybavenim prerusenia su vacsie ako 30 instrukcii na sw nacitanie bajtu. Myslim, ze sa sw da napisat tak, aby vybavenie prerusenia trvalo menej instrukcii.
V mojom pripade tak isto. Procesor ma pred sebou miliony instrukcii ZA sebou bez prestani (nepočítám li zase přerušení)
Inak neviem ako ste prisli na porovnanie cisel 100 a 700000?
Ale obe riesenia su podla mna rovnocenne, moje akurat nepotrebuje ziadny bufer (2B nepovazujem za bufer), menej instrukcii na nacitanie bajtu a potrebuje vybavit viac preruseni (co by malo byt menej ako tych instrukcii na vybavenie preusenia). Okrem toho, nech sa deje v hlavnej slucke hocico casovo narocne, toto riesenie je casovo deterministickejsie, aj ked si myslim, ze by sa bufer vo Vasom pripade stacil vzdy naplnit.
No netřeba podtrhovat, pak to vypada… no divne, nemyslite
Jestli je SO8 to co myslim, tak 1.27mm zvladnu s trafopajkou, s upravenym hrotem. Cekal sem horsi veci. SMD bezne nedelam.
“na konci hlaseni taky kratky sumovy “zavoj”” rozved to trochu do detajlu, to me zajma, nejak si momentálně nedokážu představit co to je…
No, kdby mu stačilo 8 bitů, tak by jednoduše posloužila odporová kaskáda R2R mysli mse tomu řiká. Když budou mít odpory přesnost 0.1%, tak celkova chyba by nemela byt vetsi nez 2%. (tj mam na mysli nelinearitu DACu z odporu) 0.1% odpory se daji bezne kouopit ne? (otazka je , zdali to vyjde levneji nez to TDAcko)
no, i 2B se daji pokladat za buffer 
Ale podle mě to s tim bufferem je výhodnější, procesor má pak “více souvislého času na nudění” - kde může dělat něco dalšího, a zvuk by se neměl vůbec trhat. De taky o to, ze kdyz budes delat ladovani dat do DAC pomoci preruseni, muze hlavni smycka pracovat kontinuálně na něčem úplně jiném, navíc mě napadla ještě jedna super věc… CO takle, když dojde buffer, tak ho rovnou naplnit ještě během probíhajícího přerušení? Hlavní smyčka procíku bude pak úplně volná, což si myslím je ideální stav , a vytížení procíku klesne minimálně na polovinu. (ze 4% budou 2% 
)
Jasne ze lze napsat to na min instrukci, dava l jsem ale rezervu, a rtek byhc velkou, i tak to zatížení pak vychází směšně malé.
Pokud by byl program opravdu takhle jednoduchý, jen by se ještě obsluhoval v hlavní smyčce uart, a vybíraly by se záznamy, tak v přerušení nebude ani třeba zbytečností jako pop, push a podobně, obejde se to opravdu lehce i bez toho.
číslo 100 jsme jentak plácnul, odhaduju, kolik může mít ten pic asi tak času, použijeli se metoda bez bufferu, a data se budou přesouvat v hlavní smyčce, ne pomocí přerušení.
Navíc mě napadá, že přerušení vzniká i při příjmu dat a uartu i na SPI, takže program půjde lehce napsat tak, aby pak v hlavní smyčce bylo pouhé:
sem: rjmp sem
řešení rovnoceená jsou, můj názor je takový, že vzhledem ke stavbě programu pro případná rozšiřování je použití bufferu jednodušší.
Asi lepsie raz pocut ako 100x citat.
Samotna nahravka nie je studiova a je zanesena ruchmi. Rozdiely su myslim jasne. O aku konverziu sa jedna je uvedene v nazve suborov.
Nech si kazdy vyberie podla moznosti a potrieb
P.S. Odpory s 0.1% presnostou stoja cca 27,-Sk. Ale to by bolo lepsie kupit jeden typ, 2R vyskladat ako dvojicu a R vybrat tak, aby tolerancia nebola vacsia ako 0.4%.
hhh.zip (2.92 MB)