É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?

É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 ?

Aki CPLD-t, FPGA-t programoz, annak problema egy JTAG programozo?

Miért, te mindenből a drágábbat választod..., csak mert megengedheted magadnak ??!
Ez is egy hozzáállás...

Nem árban értem, hanem feladatban.

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

Én a 700 Ft-os USB Blasterről (ami nem V2).

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.

É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 ) ??!

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

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

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

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

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

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

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

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

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.

Sziasztok!

Olvasgattam ezt a topicot, láttam másnak is feljött ez a kérdés, mégpedig a programozó kérdése. Még annó bontottam pár XILINX CPLD-t, és ki szeretném próbálni őket. Néztem gyári programozót, de az ára miatt letettem róla. Néztem kínai klót, de az ára még ennek is sok számomra, hogy csak kipróbáljak 1-2 dolgot rajtuk Keresgéltem a neten, és a legszimpatikusabb (egyszerűnek tűnik) ez volt számomra. Párhuzamos port van a gépen, innentől ez már minimális alkatrészköltség, és egy egyszerű panel lenne. Kérdésem, hogy a XILINX ISE WebPACK Design szoftverével ez vajon működne-e ? Esetleg én nem bánom ha a szoftver fordít nekem egy kódot és azt mással kell betöltenem, csak működjön. Illetve alapból mennyire használható ez a programozó?
Nem ragaszkodok ehhez, tényleg csak próbaképpen lenne rá szükségem, esetleg ha más tud ajánlani valami olcsón építhető vagy beszerezhető programozót, akkor várom a véleményeket.

Tetszik a CPLD/FPGA-k működése, ezért lehet kísérletezgetnék rajta ha tudok

Köszönöm!

Szia!

Nekem ISE WP 14.9 van fent, és Digilentes LPT JTAG3 kábellel használom, vagyis inkább nem használom mostanában. CPLD-t is ezzel használtam. A kábel rajza benne volt a board manuáljában:Bővebben: Link A doksi vége felé.

Üdv. Zoli

Nekem is volt pár CPLD-m a XILINX-től, ami miatt hasonlóan hozzád, szerettem volna kicsit kísérletezgetni velük. A gyári USB-s JTAG ilyen célból igen drága volt, de kiderült, hogy van az az LPT portos rém egyszerű kábel is. Meg is terveztem hozzá egy kis nyákot, ami belefért az LPT csatlakozó házába, el is készült..., de kipróbálásig már nem jutott el a dolog..., mivel utána konstatáltam, hogy a konkurens ALTERA CPLD-k mennyivel olcsóbbak, és főleg a gyári kompatibilis USB-s JTAG fillérekért van hozzá. Így laza csuklómozdulattal nyugdíjba küldtem a meglévő, és vásárolt CPLD-ket is a XILIX-től, helyette vettem pár ALTERÁS cuccot(CPLD, FPGA), amivel teljesen meg vagyok elégedve.

Sziasztok!

Köszönöm a válaszokat Ki fogom próbálni ezt a LPT-s megoldást, ha működik maradnak, ha nem akkor ezt én is félreteszem. Én is nézegettem az ALTERA-s cuccokat, ebayen 1000Ft a programozó , ami már jóval barátságosabb ár.

Megnéztem a manualt, kb ugyanaz mint az LPT-s megoldás, csak USB-ről illeszt, lehet a kettőből össze lehetne hozni egy normális megoldást, de nekem az LPT jó lenne, csak működésre lehessen bírni, relatív kevés energiából.

A XILINX csak azért lenne hasznosabb számomra, mert az egyetemi oktatásban is XILINX-et (Basys 2) panelt használnak, ezért gondoltam hogy előveszem és ismerkedek vele.

Ha ezt a linket megnézitek, akkor a 3. oldalon van egy gyári párhuzamos/jtag programozó, kérdés hogy a bolti példa ilyen átalakítók használhatók e a célra (megmondom miért, nem feltétlen szeretnék az alaplapba ilyeneket csatlakoztatni, ha nem muszáj, és akkor inkább 1000Ft-ért "leválasztom" a dolgot).

Ezek a bolti átalakítók direkt nyomtatókhoz vannak kitalálva, nem egyenértékűek az alaplapi LPT csatlakozóval! A JTAG programozó viszont nem valószínű, hogy nyomtató protokollokat használna működéséhez, így a valószínűsége a jó működésnek a 0-hoz konvergál...

Igen, én is ettől féltem, akkor viszont már árban kb ott vagyok hogy megveszek egy kínai programozót, vagy akkor marad az alaplapi LPT port.

Sziasztok!

Megérkezett az ebayről a programozó (Blaster V2), egy 1.8V-os CPLD-n próbáltam ki. Tökéletesen működik!! Gyors. Durva hogy a gyári Altera Blaster driverével megy

FPGA-kból a MAX10-el szemezgettem. Nagyon szimpatikusnak tűnnek. Próbálta már valaki?
Integrált config flash, és lehet csak 1 feszültségről működtetni (3.3V) (Ebből ő regulál magának 1.2V-ot).

Üdvözlet! Csináltam egy "Parallel Cable 3"-at. Letöltöttem egy Webpack4.1-et. Egy XC9572-t szeretnék kiolvasni. Mi úton módon lehet? Egy leírás jól jönne. Köszönöm!

Megoldódott!

Sziasztok!

Jártas itt valaki FPGA-ban megvalósított SoC-hoz történő Linux fejlesztésben? Egyszerű, memory-mapped eszközökhöz kellene platform drivereket írnom. Simán a /dev/mem fájlba írással működik, egyszerű kernel modulként fix címekre írással szintén oké. De a fixen bekódolt címek helyett illene platform drivereket írni, és hiába töltöm ki az of_device_id struktúra compatible tagját a device tree-nek megfelelően, sosem hívódik meg a probe függvényem. Biztos, hogy én rontok el valamit, mert ugyanez van akár Spartan6+MicroBlaze, akár Zynq alatt dolgozom.

Sziasztok,

Ha már mindenki szétszedte a Blasterjét, én is szétkaptam ezt a valamivel drágább verziót.
Ez van benne