Fórum témák

» Több friss téma
Fórum » CPLD, FPGA - Miértek, hogyanok
 
Témaindító: Tomee, idő: Dec 2, 2006
Lapozás: OK   42 / 42
(#) slimcolt válasza sdrlab hozzászólására (») Jan 10, 2017 /
 
Én is remélem, hogy jó lesz. Elvileg a Quartus II-vel kompatibilis.
Milyen egyéb meg gondolásokból tértél át Alterára ha megkérdezhetem?
(#) sdrlab válasza slimcolt hozzászólására (») Jan 10, 2017 /
 
Én azzal használtam, gond nélkül elsőre beröffent alatta...! )
Nagyon egyszerű indokok voltak..., TQFP tokozás mellett itt nagyobb mennyiségű blokk érhető el, olcsóbb, a JTAG hozzá(klón) filléres..., kell ennél több ?
(#) killbill válasza sdrlab hozzászólására (») Jan 10, 2017 /
 
Aki CPLD-t, FPGA-t programoz, annak problema egy JTAG programozo?
(#) sdrlab válasza killbill hozzászólására (») Jan 10, 2017 /
 
Miért, te mindenből a drágábbat választod..., csak mert megengedheted magadnak ??!
Ez is egy hozzáállás...
(#) killbill válasza sdrlab hozzászólására (») Jan 10, 2017 /
 
Nem árban értem, hanem feladatban.
(#) sdrlab válasza killbill hozzászólására (») Jan 10, 2017 / 1
 
Nekem fontos, hogy kompatibilis legyen a fejlesztő környezetével..., semmi kedvem bohóckodni valami FTDI-s JTAG konverterrel, vagy hasonlóval, amivel ugyan felprogramozható lenne, de nem kényelmesen, "gyári" módon! Főleg nem párszáz pénzért, mikor utánam dobják a kínaiak... )
(#) icserny válasza sdrlab hozzászólására (») Sze, 18:33 /
 
Idézet:
„Miről beszélsz ?! 1,2-5V között minden Altera cucchoz jó!”

Én a 700 Ft-os USB Blasterről (ami nem V2).
(#) slimcolt válasza pajti2 hozzászólására (») Pé, 20:10 /
 
Szia,

öööhmm tényleg most azon töröm a fejem, hogy több cuccot pakolok a CPLD-be, de inkább választok akkor egy Cyclone II-t
Szóval igen, igazad volt!
Mondjuk van néhány dolog, amit még nem tudom hogyan oldjak meg, lehetséges hogy zaklatlak még titeket.
(#) sdrlab válasza icserny hozzászólására (») Szo, 12:09 /
 
Én is arról az árkategóriáról beszélek..., bár azt nem tudom, hogy létezik e több verzió is ebből, s hogy valamelyik ezekből lényegesen kevesebbet tudna, mint amik egy jó ideje kaphatóak. Azok mindent tudnak..., ki az a hülye, aki ugyanannyiért valami ősrégi verziót hajtana fel(kemény keresési munka árán, valljuk be ) ??!
(#) pajti2 válasza slimcolt hozzászólására (») Vas, 1:06 /
 
"Nem tudom, hogyan oldjam meg" -> "Pontosan tudom, mit kellene tenni, csak nagyon fáj a hócipőm miatta, mert annyira iszonyat drága lesz, jahahahahaaaj nem akaroooom"
(#) icserny válasza sdrlab hozzászólására (») Vas, 6:46 /
 
"nem tudom, hogy létezik e több verzió is ebből"
Feltételezem, hogy mindegyik 700 Ft-os árkategóriájú, Rev C jelzésű USB Blaster klón ugyanolyan gagyi, mint amilyet felbontottam (lásd a mellékelt képet). A kapcsolás és a firmware valószínűleg erről az oldalról származik. Amint látható, a kimenőjelet a 3,3 V-ra méretezett osztón kívül csak a target áramkör védődiódái korlátozzák... Lehet, hogy működik 1,8 V-os cuccokkal is, de jó szívvel csak 3,3 V-ra lehet ajánlani.

Az USB Blaster V2, amit Slimcolt fórumtársunk rendelt, az kinézetre is egészen más, meg árfekvésben is ( $19 - $24).
A hozzászólás módosítva: Vas, 6:48
(#) pajti2 válasza icserny hozzászólására (») Vas, 11:11 /
 
Még lehetne rajta javítani. Az adatlap szerint az rb4,5 digital io-ként ttl, amin a Vih szintje 0.25*vdd + 0.8v -> 3.3v esetén 1.625v. Ha beraknának egy 3.3v stabot is, és a két megmaradt kivezetésre open collector vezérlést külön set-nyi jtag kimeneti lehúzó ellenállásokat vezérelni, működhetne a cucc 3.3v, 2.5v, és 1.8v-ra is. Szóval ebben a formájában tényleg nem éri meg a 700 hufot
(#) sdrlab válasza icserny hozzászólására (») Vas, 11:23 /
 
Hát ez tényleg egyszerű belső Mondjuk ennyiért sokkal többet nem is vártam!
Azonban az, hogy minimalizált az alkatrészköltsége(s így 700 pénzért is dobozolva kaphatod), nem jelenti azt, hogy rossz lenne! A CMOS IC-k a lehető legritkább esetben nem tartlamaznak védő diódákat a lábaikon, főleg bemenet esetén. Hogy itt kihasználják ezt ??! Na és ?! Jól teszik! Én is így oldanám meg, ha költséghatékony megoldás lenne a cél...és semmivel sem inkorrektebb, mint bármilyen másik megoldás.

Csak nem álltam ellen, szétszedtem én is az én verziómat! Nos, abban van még egy LVC244 illesztő is, aminek gondolom a tápja a céláramkörből jön, így már minden kényes igényt kielégítve
(#) sdrlab válasza icserny hozzászólására (») Vas, 11:55 /
 
Egyébként az a lényegesen drágább verzió annyival tud többet, hogy Full speed sebesség helyett High speed-et tud..., amivel 1..3 szoros letöltési sebességet lehet elérni! Hát..., én kibírom azt a pár másodpercet, amivel a lassúbb, ám jóval olcsóbb verzió kevesebbet tud ))
A hozzászólás módosítva: Vas, 11:55
(#) slimcolt válasza pajti2 hozzászólására (») Vas, 18:59 /
 
Nem nem tényleg nem tudom hogyan kellene megoldanom
Igazából lehet még elmondani sem tudom érthetően (sajna még csak most ismerkedek a digitális technikával)

pl:

Van 32db D tárolóm (32bit) amiket sorosan vezérlek, de a példa kedvéért legyen csak 4 flop.
A data bemenetük össze van kötve, ami egy lm2903 komparátor kimenetére csatlakozik. Az órajel (nagyon nagyon lassú: 200Hz) felfutó élére az egyes floppok tárolják a komparátor állapotát.
De, én szeretnék olyat, hogy pl egy nyomógombbal kitudjak választani egy előre eltárolt bit értéket ami függvényében a floppok állapota független a data lábtól (mondjuk egyes floppokat asszinkron clear állapotba állítok).
Pl:

Legyen alapesetben a kimenet : 0111
De ha én beállítok egy értéket pl: 1101 (amik végülis a floppok clear bemenete)
Akkor a kimenet 0101 legyen...

De az sem tudom hogyan tároljak el ilyen információkat, hogyan hívjak elő, hogyan válasszam ki?
Szóval nem tudom...

Ötlet? Azon kívül hogya hagyjam a francba.. D

Egyébként barátkozom a VHDL-el! De ez még magas nekem
(#) pajti2 válasza slimcolt hozzászólására (») Vas, 20:35 / 1
 
Talán jeleztem már neked azt is, hogy ha csak az extrém szinkron sebesség nem követelmény, akkor nem cpld / fpga-t használunk, hanem valami mikrovezérlőt. Sokkal gyorsabban és sokkal egyszerűbben lehet vele lassú információs folyamot kezelni. Példának okáért a pic topic elég pörgős. Ugyan fogalmam sincs, mi értelme és célja tud lenni a D flopok olyan használatának, de nem szükséges ahhoz értenem, hogy a vélhető teljesítmény korlátok függvényében valami megoldást javasoljak. Csak aztán tényleg ne hagyj ki - "juj azt még elfelejtettem, hogy.." - valami nagyon fontosat megemlíteni.

A nyomógomb használatod még magyarázatra szorul, hogyan szándékozol beállítani, hogy mi legyen a nyomógomb hatása? Például fix kódolnád? Működés közben szeretnéd átállítani?

Hasznát tudod venni annak, ha az eszközöd kommunikálni tud valami intelligensebb eszközzel? Például nem dolgozni fel semmi információt helyben és nyomban, csak logolni, és továbbítani, mert fejlettebb platformon kényelmesebben tudod kezelni, és egyébként is szükséged lehet az időbeli eredményekre a későbbiekben - van olyan igény?

Egyik hdl nyelv sem ördöngösség, csak hozzá kell szokni, hogy mind az információt, mind a változásait nagyon aprólékos formájában kezeled. Például nem egy marék homokot fogsz meg, hanem 3 719 467 darab homokszemet, és mindegyiket egyesével. Ha elfogy a türelmed, és egyben akarsz egy problémát megoldani ahelyett, hogy bitenként és ütemjelenként boldogulnál el vele, akkor a hdl "egy kezelhetetlen sza*"-rá változik. Az informatika fogalma ma nagyon sok helyütt a web programozást jelenti, és ott hozzá vannak szokva az adatok logikai szintű kezeléséhez egészben. Leginkább, mert a mai világnak se esze, se türelme (se pénze ). A hdl-ek világában nem létezik az "egészben". Csak a bitenként, és az ütemjelenként. Szóval elsőként azt gondold végig teljesen a legkisebb időegységre lebontva, milyen ütemezéssel érkezik az adatod, és milyen időbeli lefolyással, milyen feltételek szerint milyen kimenetet akarsz abból gyártani. Mindent bitenként, és ütemjelenként. Például ha van 30 bemenő bited, a feldolgozásukhoz fel kell használnod másik 300-at, hogy legyen belőle további 20 kimenet, és a maximális ciklusod akár 100 ütemjel hosszú lehet, akkor van összesen 35000 bited a teljes időskálán, amit mind egyesével meg kell értened, és le kell írnod. Nem nehéz, csak sok. Az első lépés, hogy fogadd el, hogy azt mind egyesével végig fogod gondolni, és döntést fogsz hozni róla. 35000 darab döntést fogsz meghozni. Egyesével. Ugyan sok esetben lehet csoportosítani a biteket regiszterekbe, és lehet csoportosítani az ütemjeleket ciklusokba, szóval nem kell majd ténylegesen 35000 darab döntést meghoznod a fenti példában, de ha elkezdenéd a munka könnyebbik végét megfogni kezdésnek, akkor már elindultál azon az úton, aminek nem lesz jó vége. A gyakorláshoz mindig lassú mozdulatok kellenek. Csak úgy tudsz olyasmit megtanulni, ami később hirtelen mozdulatokkal is menni fog. Később majd menni fog úgy is, de kezdetben még nem. Ha már kezdetben is olyat akarsz, akkor nem tanulni fogsz, csak irigykedni mindenki másra, aki már rászánta az időt és a türelmet. Első lépésként törődj abba bele, hogy az a tanulópénz, és ne küzdj ellene, hanem fizesd ki. Akkor a hdl elkezd barátságosabb lenni. A többi meg csak idő és gyakorlás kérdése. Konkrétan maga a hdl (vhdl? verilog? systemc? a roseb tudja még hány van összesen, who care?) semmi egyéb, csak egy szintaktika, ami leírja a meghozott döntéseidet. Nem a hdl a lényeg. Nagyon eltéveszted a "szarva közt a tőgyit", ha azt hiszed róla.

Ha azt inkább mégsem küzdenéd végig, arra vannak a mikrovezérlők, hogy könnyebb utat kínáljanak. Azokat programozni lehet. Sokkal kevesebb adat (eleve csoportosítva vannak), sokkal kevesebb állapot, amit direkt sorfolytonossá tettek időben (az a program), összességében sokkal kevesebb állapot, amire figyelned kell, és a végeredmény úgy is megalkotható. Egy pic-et felprogramozni c-ben pihepuha lágyság a hdl-ekhez képest. Amennyivel kevesebb lesz az eredmény, hogy az adatfeldolgozási sebességed felső korlátja sokkal alacsonyabb. Viszont az alacsonyt is értsd úgy, hogy egy 80 mhz-es pic még mindig fényévekre van attól, hogy egy 200 hz-es információs folyamot ne tudjon feldolgozni. 200 khz-en is düböröghetne az az adatfolyam, és még mindig elboldogulhatna vele. Ha csak a végeredmény kell, egy mikrovezérlővel könnyebb "szót érteni". Ha a példa kedvéért választottad, és az a fontos, hogy a hdl-ekkel ismerkednél, csak akkor menj tovább a cpld / fpga úton.

Válassz kedved szerint.

És ha tényleg segítség kell, próbáld meg értelmesen megfogalmazni, mit is kezdenél azokkal a bitekkel, mert tényleg sötét folt az egész, ami eddig a topicon lejött. Már amikor erőltetted a quartus-t, hogy kapcsrajzon egy pillanat alatt összeteszed, már akkor sejtettem, hogy dehogy fogod összetenni. Úgyis messzebb fog menni az a történet, mert mindig alábecsüli a problémát az, aki siet. Aztán úgy jár, hogy az elején még halad, aztán meg falnak szalad. Azt hiszed talán, én meg itt mindenki más is még sosem járt úgy? Hehe
A hozzászólás módosítva: Vas, 20:36
(#) slimcolt válasza pajti2 hozzászólására (») Vas, 21:00 /
 
Szia,

Köszönöm a sok tanácsot. Egyrészt azért gondoltam a cpld / fpga-ra mert a későbbiekben úgysem fogom megúszni őket. Kitudja 5 év múlva miket fogok művelni.
Sajnos mikrovezérlőt mégannyira sem tudok programozni mint cpld-t
De szép lassan sorjában elkezdek mindent. A schematic editorral való szerkesztéssel elboldogulok ezzel a kis tudásommal is.
A korábban említett 60db floppos megoldást már elkészítettem és leszimuláltam, elméletileg tökéletesen működik a dolog, de jött az ötlet, hogy akkor a többi cuccot is belepakolom + még néhány extra elgondolást, csak akkor kell egy 208 lábú fpga
Az fpga előtt egy precíziós feszültségmérő van, és azt vezérlem. A sebesség nem nagy igény. Az analóg részével sokkal jobban boldogulok
Holnap összedobok egy demó kapcsolást, hogy érthetőbb legyen, tudom elég kusza...

Most azon agyalok, hogy tudok egy nyomógombbal csak 1bit-et kapcsolni, attól függetlenül, hogy mennyi ideig nyomom a gombot..
(#) pajti2 válasza slimcolt hozzászólására (») Hé, 1:01 /
 
Az fpga-k csak nagyon speciális területen tudnak tényleg labdába rúgni. A legtöbb hétköznapi feladatra vannak célirányos asic-ok. Általában katonai célú elektronikák, vagy az immáron kifutott hft-k, és a nagyon cutting edge prototípusok használnak fpga-t, másutt nem igazán fordulnak elő.

Maga a 208 láb még nem olyan nagy ügy. 1000 lábas fpga-k is vannak. Nagyobb problémád lesz azzal, hogy olyan bga tokot felforrasztani 6-8 rétegű nyák fog kelleni, robot a beültetéshez, meg forrasztó kemence a felforrasztáshoz. Arról nem is beszélve, hogy 208 vezetékre az analóg telefonközpontokon megedződött kábel korbács mesterek is elkezdik csóválni a fejüket. Amikor annyi vezetéket kell kezelni, általában külön kártyákat szerveznek rack szekrénybe, és valamilyen nagy sebességű soros kommunikáción küldik tovább a mérési adatokat / fogadják a vezérlési parancsokat. Kicsit tisztább kép kellene arról, hogy ami jel érkezik, mennyi érkezik, biztos külön vezetékeken tud-e csak érkezni, és hogy helyben muszáj felhasználni, vagy el is szállíthatod?

A nyomógomb idővezérelt funkciójához általában kell pár állapotgép (mint mindenhez). Kezdetben prellmentesíteni is kell egy gombot, mondjuk 1 millisec olvasási ciklussal 20 millisec időre reseteled alacsonyba is meg magasba is. A logikai jelet viszed tovább és további állapot gépekkel mondjuk tized másodperces időközökkel számolsz maximum 5-öt az egyik funkcióhoz, aztán 5 és 15 között a másikhoz, és úgy tovább. Ne felejtsd el kinullázni a funkciót ha felengedik a gombot. Egyébként remek jó gyakorlás egy kapcsoló időfüggő funkcionalitását lekódolni, törd csak rajta a buksit, nem fog megártani

Az fpga-k is, meg minden egyéb is általában egy áramköri környezet, amit meg kell szokni. Ha magasabb szintű logikai funkciókat kell teljesíteni, gyakorlatilag muszáj lesz legalább mikrovezérlőt előszedned, vagy akár tovább küldeni a jelet számítógépre. Előbb vagy utóbb azt is meg kell majd tanulnod. Az fpga-k nagyobb logikai erőforrások esetén nagyon durván kezdenek el drágulni, nem biztos, hogy azokat használni a költséghatékony megoldás.
Következő: »»   42 / 42
Bejelentkezés

Belépés

Hirdetés
Frissek
2017. Jan, 17. Kedd
9:49:34
Jelenleg 456 fő olvassa az oldalt
Online tagok:
Lapoda.hu     XDT.hu     HEStore.hu