Mesa 7i90
Myslíš tyhle?
http://www.cncmonster.eu/?lang=en" onclick="window.open(this.href);return false;
Tam se mi snaží prodat jenom nějaký SW.
Neumím hledat nebo je nějaká jiná firma s podobným jménem?
Díky.
http://www.cncmonster.eu/?lang=en" onclick="window.open(this.href);return false;
Tam se mi snaží prodat jenom nějaký SW.
Neumím hledat nebo je nějaká jiná firma s podobným jménem?
Díky.
-
OompaLoompa
- Příspěvky: 459
- Registrován: 28. 6. 2017, 1:45
- Bydliště: Západný Slovakistan
Aha, díky.
Tak 7i93 bohužel nemají ani tady.
Asi už se preventivně připravili na zavedení vysokých cel při dovozech z Ameriky a rovnou už je tam dopředu připočítali. Ty ceny jsou teda o slušný kus výš než přímo u Mesy.
U jedné karty by se to ještě nevyplatilo, ale u 2 nebo určitě u 3 by se už asi vyplatilo to koupit přímo u Mesy.
Tak 7i93 bohužel nemají ani tady.
Asi už se preventivně připravili na zavedení vysokých cel při dovozech z Ameriky a rovnou už je tam dopředu připočítali. Ty ceny jsou teda o slušný kus výš než přímo u Mesy.
U jedné karty by se to ještě nevyplatilo, ale u 2 nebo určitě u 3 by se už asi vyplatilo to koupit přímo u Mesy.
-
OompaLoompa
- Příspěvky: 459
- Registrován: 28. 6. 2017, 1:45
- Bydliště: Západný Slovakistan
Áno, ceny sú samozrejme vyššie 
No keď si k tomu pripočítaš DPH + clo + prípadne aj poplatok za colného deklaranta (či čas + nervy + cestovné náklady v prípade, že si to budeš riešiť sám), tak to nie je zas až taká katastrofa..
a o prípadných reklamáciách radšej ani nezačnem
No keď si k tomu pripočítaš DPH + clo + prípadne aj poplatok za colného deklaranta (či čas + nervy + cestovné náklady v prípade, že si to budeš riešiť sám), tak to nie je zas až taká katastrofa..
a o prípadných reklamáciách radšej ani nezačnem
Ahoj MEXi,
zajímavé téma. Průběžně ho sleduju a čekám na každý další přízpěvěk.
Můžeš mi/nám osvětlit pár otázek. Určitě nebudu jedinej koho to zajímá.
Tak prvně by mě zajímalo, jak hluboko se musí člověk ponořit do protokolu a všeho okolo, aby byl schopnej hledat chyby ve zdrojacích a opravovat je. Z vlastní zkušenosti vím, že poměrně hluboko.V podstatě až na úroveň jednotivých bitu/bytu. Vycházel jsi z nejakého popisu standartu EPP?
Co obnáší uprava driveru? Alespon ve zkratce. Predpokladam, ze EPP komunikaci moc zarizeni nepouziva a tak tomu nikdo pred tebou nevenoval prilis pozornosti. Čínani to chrlej po milionech, ale normalni clovek pouzije rozsirujici kartu s LPT tak maximalne na starou tiskarnu.
Kolik drátů je použito na komunikaci? LPT ma standartně 8 bitu plus nejaky rizeni okolo. EPP jeste o neco malo navic. Pouziva vsechny? Je na zacatku komunikace nejaké dohadovani co kdo komu bude posilat jako je tomu u sserialu?
Mohl by jsi sem prihodit kus komunikace z analyzatoru s nejakym velmi hrubym popisem. Idelane nahranou komunikaci aby se do toho clovek mohl podivat.
Dalsí vec co me zajima je to, co chces zkoumat na ethernetovej kartach? Obsah jednotlivych paketu? Porovnat zpusob komunikace?
Jinak, kdyby jsi chtel pujčit PCI kartu, tak tu mam jednu nevyuzitou testovaci 5i22 1.5M, klidne ti ji zapujcim na prozkoumani.
Martin
zajímavé téma. Průběžně ho sleduju a čekám na každý další přízpěvěk.
Můžeš mi/nám osvětlit pár otázek. Určitě nebudu jedinej koho to zajímá.
Tak prvně by mě zajímalo, jak hluboko se musí člověk ponořit do protokolu a všeho okolo, aby byl schopnej hledat chyby ve zdrojacích a opravovat je. Z vlastní zkušenosti vím, že poměrně hluboko.V podstatě až na úroveň jednotivých bitu/bytu. Vycházel jsi z nejakého popisu standartu EPP?
Co obnáší uprava driveru? Alespon ve zkratce. Predpokladam, ze EPP komunikaci moc zarizeni nepouziva a tak tomu nikdo pred tebou nevenoval prilis pozornosti. Čínani to chrlej po milionech, ale normalni clovek pouzije rozsirujici kartu s LPT tak maximalne na starou tiskarnu.
Kolik drátů je použito na komunikaci? LPT ma standartně 8 bitu plus nejaky rizeni okolo. EPP jeste o neco malo navic. Pouziva vsechny? Je na zacatku komunikace nejaké dohadovani co kdo komu bude posilat jako je tomu u sserialu?
Mohl by jsi sem prihodit kus komunikace z analyzatoru s nejakym velmi hrubym popisem. Idelane nahranou komunikaci aby se do toho clovek mohl podivat.
Dalsí vec co me zajima je to, co chces zkoumat na ethernetovej kartach? Obsah jednotlivych paketu? Porovnat zpusob komunikace?
Jinak, kdyby jsi chtel pujčit PCI kartu, tak tu mam jednu nevyuzitou testovaci 5i22 1.5M, klidne ti ji zapujcim na prozkoumani.
Martin
-
OompaLoompa
- Příspěvky: 459
- Registrován: 28. 6. 2017, 1:45
- Bydliště: Západný Slovakistan
Neviem, možno som len natvrdlý a uniká mi dáka hlbšia pointa, ale:
Zdrojáky ku všetkému ohladom MESA sú voľne dostupné priamo od výrobcu, a vy tu riešite skúmanie komunikácie medzi Mesou a PC prostredníctvom analyzátora, za účelom dekódovania protokolu?
Nebolo by podstatne jednoduchšie si dané info dohladať priamo v dokumentácii/zdrojákoch, namiesto veštenia?
PS: Ak sa jedná o prípad "cesta je cieľ", či len akúsi novú formu masochizmu, tak se omlouvám a beru zpět
Zdrojáky ku všetkému ohladom MESA sú voľne dostupné priamo od výrobcu, a vy tu riešite skúmanie komunikácie medzi Mesou a PC prostredníctvom analyzátora, za účelom dekódovania protokolu?
Nebolo by podstatne jednoduchšie si dané info dohladať priamo v dokumentácii/zdrojákoch, namiesto veštenia?
PS: Ak sa jedná o prípad "cesta je cieľ", či len akúsi novú formu masochizmu, tak se omlouvám a beru zpět
Ahoj.fupe píše:Ahoj MEXi,
zajímavé téma. Průběžně ho sleduju a čekám na každý další přízpěvěk.
Můžeš mi/nám osvětlit pár otázek. Určitě nebudu jedinej koho to zajímá.
Tak prvně by mě zajímalo, jak hluboko se musí člověk ponořit do protokolu a všeho okolo, aby byl schopnej hledat chyby ve zdrojacích a opravovat je. Z vlastní zkušenosti vím, že poměrně hluboko.V podstatě až na úroveň jednotivých bitu/bytu. Vycházel jsi z nejakého popisu standartu EPP?
Co obnáší uprava driveru? Alespon ve zkratce. Predpokladam, ze EPP komunikaci moc zarizeni nepouziva a tak tomu nikdo pred tebou nevenoval prilis pozornosti. Čínani to chrlej po milionech, ale normalni clovek pouzije rozsirujici kartu s LPT tak maximalne na starou tiskarnu.
Kolik drátů je použito na komunikaci? LPT ma standartně 8 bitu plus nejaky rizeni okolo. EPP jeste o neco malo navic. Pouziva vsechny? Je na zacatku komunikace nejaké dohadovani co kdo komu bude posilat jako je tomu u sserialu?
Mohl by jsi sem prihodit kus komunikace z analyzatoru s nejakym velmi hrubym popisem. Idelane nahranou komunikaci aby se do toho clovek mohl podivat.
Dalsí vec co me zajima je to, co chces zkoumat na ethernetovej kartach? Obsah jednotlivych paketu? Porovnat zpusob komunikace?
Jinak, kdyby jsi chtel pujčit PCI kartu, tak tu mam jednu nevyuzitou testovaci 5i22 1.5M, klidne ti ji zapujcim na prozkoumani.
Martin
Jsem na cestách, tak odpovídám trochu se zpožděním a asi Ti nebudu hned schopný poslat nějaká záznamy komunikace, to až po návratu domů, tj. asi tak za týden.
Malá vsuvka: aby ten život nebyl tak jednoduchý, tak mi hned první den cesty zdechl mobil. Ne HW, ale SW. Řekl, že se mu nepovedlo rozcryptovat něco v systému, tak jediná možnost je totální tovární reset mobilu. Tudíž všecka data v prdeli, kurva!
Proč to píšu - připomínám 2 zlatá pravidla: zálohovat, zálohovat, zálohovat a nevěřit v neomylnost techniky.
Teď věcně k EPP. EPP je docela chytrý režim komunikace přes LPT, který je do jisté míry podporován HW a ulehčuje tak procesoru práci a zrychluje komunikaci.
Používá samozřejmě 8 datových linek D0-D7, které jsou zde používány obousměrně. Kromě nich používá ještě 3 signály z PC do periferie a jednu zpět z periferie do PC.
Ty 3 linky z PC jsou:
- Write - tady je to jasné, 0 znamená přenos z PC do periferie, 1 znamená naopak požadavek čtení
- Address Strobe - když jde signál dolů, začíná komunikace, tj. přenos 1 byte po EPP. Je-li současně aktivní Write, znamená to zápis 8bit adresy do periferie. Existuje i pro čtení, ale to se asi moc nepoužívá (Mesa to pro svou práci nepoužívá). Signál Strobe je aktivní po celou dobu přenosu jednoho byte, trvá max. 10us (je tam HW watch-dog), minimálně do doby než převzetí dat potvrdí periferie tím svým výstupním drátem. Ten time-out 10us zavedl standard EPP 1.9, ve starší verzi EPP 1.7 nebyl, a tak se při chybě komunikace teoreticky mohlo stát, že by se PC zaseklo, protože by trvale čekalo na potvrzení. Možná si uvědomuješ, že při nastavení LPT v BIOSu do režimu EPP se Tě to většinou ptá jestli 1.7 nebo 1.9, a nikdo neví, co tam má nastavit a proč. Tak teď už je to jasné, a rozhodně nastavit 1.9.
- Data Strobe - signál se stejnou funkčností jako Address Strobe, ale znamená, že se přenáší datový byte. Ten se už na rozdíl od Address Strobe používá velmi často i v režimu čtení.
Zpět vede drát Wait, kterým periferie potvrzuje převzetí dat (v režimu PC->periferie) nebo připravenost dat pro PC (v režimu periferie->PC).
Celý přenos provede na straně PC hardware, procesor jen vyšle nebo přečte data, o celý ten kolotoč s hand-shakingem se postará HW (neplatí tak zcela u PCI karet, viz dále).
Takže shrnuto: přenos adresy nebo dat probíhá prakticky stejně, jen v jednom případě to signalizuje linka Address Strobe a ve druhém případě Data Strobe.
Mesa to docela elegantně využívá pro svou komunikaci. Obecně se karta Mesa (asi všechny druhy, tedy i ty přes PCI a Ethernet) vůči systému tváří jako pole registrů, ty registry jsou seskupeny do sekcí.
Takže driver Mesy (tj. v tomto případě hm2_7i90.ko) komunikuje tak, že vyšle 16-bit adresu (tj. 2 přenosy po 1 byte), kde do Mesy pošle adresu začátku nějaké sekce registrů (např. sekci registrů s I/O vstupy), a pak cyklickým voláním čtení vytahá obsah celého bloku. Adresa těch registrů umí nastavit příznak, že se má automaticky zvyšovat čítač registrů, takže přenos adresy proběhne vždy jen na začátku bloku.
Po zpracování v driveru (v tomto případě už ve vyšší vrstvě, tj. v hostmot2.ko), kdy jsou spočteny požadované náplně stepgenů pro další periodu a jsou určeny stavy I/O linek pro výstup, to zase naadresuje pole výstupních registrů a datovými přenosy to zase nasype to Mesy.
Teď k problémům: standard EPP byl stanoven nějakým volným sdružením tuším 3 firem, a je v tom bordel. Docela slušně je nadefinováno chování na vlastní sběrnici, tj. co běhá po drátech. Ale blbě bylo nadefinováno chování toho, jak se má celý ten blok EPP chovat coby periferie v tom PC. Intel někdy v době uvedení procesoru 386SL udělal chipset, kde jako první zaintegroval HW podporu tohoto standardu. No a protože ten standard blbě nebo spíš vůbec nedefinoval, jak se to má chovat v systému, tak to ti ostatní pojali tak, že vzali tohle konkrétní implementaci řekli "a takhle je to správně, tak to má být".
Takže to defacto není žádný oficiálně definovaný standard, a podle toho to vypadá.
EPP se na většině základních desek chová stejně, jako to kdysi vymyslel ten Intel, proto to většinou funguje. Ale různí výrobci rozšiřujících desek (tedy ty PCI nebo PCIexpress I/O karty) to prostě pojali trochu jinak, neudělali to jako přesnou kopii, ale různě to "vylepšili".
No a to je to, oč zde běží. Mesa ve svém driveru implementovala komunikaci podle toho původního návrhu Intelu, takže to na LPT portech na základních deskách chodí (protože ti dodrželi/okopírovali ten původní Intel design). Kdežto na těch "vylepšených" to nechodí.
Návrháři ty PCI karty s chipem MCS9865 to vyřešili dost podobně, jako je to na těch základních deskách. Jen tam nedali automatické otáčení směru komunikace, a musí se to řešit programově v driveru. To ti Číňani byli se svým návrhem mnohem "kreativnější", a udělali to totálně jinak, pojali to koncepčně odlišně. Proto pokud se mi to povede dostat do oficiálních zdrojáků LinuxCNC, tak varianta pro karty MCS9865 se bude konfigurovat jen parametrem, kdežto varianta pro ty čínské desky bude prakticky jiný driver (ten ještě nemám napsaný).
Za zmínku ještě stojí, že drivery dle EPP 1.9 by měly umět i vícebytovou komunikaci, umí na jeden pokyn procesoru poslat 1, 2 nebo 4 byte. Na sběrnici se to stále tváří jako 4 nezávislé přenosy, ale pro PC to znamená tam jen jednou poslat 32 bitů. Tohle bohužel ty čínské desky neumí. Nicméně driver Mesa s tím už z dřívějška počítá, takže umí jet jak po bytech (parametr EPP_WIDE=0) nebo 32-bitech (EPP_WIDE=1).
Samozřejmě k těm PCI I/O kartám není žádná pořádná, případně vůbec žádná dokumentace. Takže tyhle hrátky znamenaly nekonečné série iterací pokus/omyl. Musel jsem k tomu napsat testovací SW pro Linux, a na druhé straně simulátor EPP s procesorem. Přímo s Mesou se pokusy moc dělat nedají, ta Ti jen prostě řekne "nefunguje to" a hotovo.
Ale to zrovna Tobě jistě nemusím říkat, sám si podobných radovánek s nezdokumentovaným chováním jistě užíváš dost a dost ve svém projektu SSerial.
Jinak to, co jsem popisoval, je rutinní chování v 1ms servocyklech. Po startu to stejně jako u Tvého SSerialu má dohadovací fázi, kdy si PC a Mesou vyříkají, co všechno Mesa poskytuje.
Rád Ti všechno naloguju a pošlu, ale teď jsem prostě týdne mimo.
K tomu Ethernetu: chci si udělat "odposlechové pracoviště", abych mohl sledovat provoz v obou směrech (podobně, jako to používám teď u EPP).
Protože u toho Eth řešení se dost blbě dostává na konkrétní signály (má to integráče v pouzdrech, kde se prakticky nedá rozumně měřit), tak chci vytvořit speciální firmware pro tuhle Mesu, která bude ty signály duplikovat na nějaké měřitelné piny. Tady ale zatím plavu, nicméně jsem si vzal na cesty knížku a nějaká skripta o VHDL.
Poznámka: už od pohledu je mi VHDL nesympatický. Verilog mi přijde výrazně bližší. Ale Mesa bohužel vsadila na VHDL.
V tomhle bych s Tebou (případně samozřejmě i někým jiným, VHDL-potentním) rád zaspolupracoval.
No a pak s tím mám další docela velké plány, ale o těch se zatím nebudu šířit. Budou samozřejmě poté veřejné, ale až (a pokud) se mi je povede realizovat.
Ahoj,
díky za cenné informace.
Třeba se budou jednou hodit.
Jenom k tomu ethernetovymu reseni.... není jednodussi nez poslouchat na dratech si mezi mesu a pc strcit nejaky ethernetovy analyzator? takovej wireshark primo na pc s linuxcnc by podle me dodal všechny potrebne informace.
Podobne sem to delal, když sem zkoumal ethercat. Tam jsem to nastrkam do switche a na druhem pc jsem mel pusteny odposlouchavani. Výhoda u ethercatu je ta, ze wireshark uz ma filtry pro ethercat a vi co ma poslouchat. To u tohohle asi nebude umet, ale i tak si myslim, že koukat do paketu na ethernetu by mělo postacit. Ty, jestli tomu dobře rozumim chces jit ještě hloubeji a na uroven signalu.
Co se týče VHDL, tak já moc potentní nejsem, ale zkusím se na to podívat co to obnáší. Nezapomen, ze nejsem ani programator, ani elektronik a do dané problematiky jsem naskočil za pochodu samostudiem před realtivne nedavnou dobou.
Každopádně mě toto téma zajima, tak si budu muset rozsirit obzory. Jen ten cas se nejak nedostava.
Takže diky za info a drzim palce at se plany podari. Az budes u stroje posli prosim ty snapy.
DIK
Martin
díky za cenné informace.
Třeba se budou jednou hodit.
Jenom k tomu ethernetovymu reseni.... není jednodussi nez poslouchat na dratech si mezi mesu a pc strcit nejaky ethernetovy analyzator? takovej wireshark primo na pc s linuxcnc by podle me dodal všechny potrebne informace.
Podobne sem to delal, když sem zkoumal ethercat. Tam jsem to nastrkam do switche a na druhem pc jsem mel pusteny odposlouchavani. Výhoda u ethercatu je ta, ze wireshark uz ma filtry pro ethercat a vi co ma poslouchat. To u tohohle asi nebude umet, ale i tak si myslim, že koukat do paketu na ethernetu by mělo postacit. Ty, jestli tomu dobře rozumim chces jit ještě hloubeji a na uroven signalu.
Co se týče VHDL, tak já moc potentní nejsem, ale zkusím se na to podívat co to obnáší. Nezapomen, ze nejsem ani programator, ani elektronik a do dané problematiky jsem naskočil za pochodu samostudiem před realtivne nedavnou dobou.
Každopádně mě toto téma zajima, tak si budu muset rozsirit obzory. Jen ten cas se nejak nedostava.
Takže diky za info a drzim palce at se plany podari. Az budes u stroje posli prosim ty snapy.
DIK
Martin
Mým záměrem je mít Ethernetové Tx i Rx synchronně, a to vše synchronně s činností Mesy.
Určitě chci využít Wireshark. Ale nevím, jestli Wireshark umí explicitně zaměnit Tx a Rx pár, tj. přeprogramovat PHY ethernetové karty a využít MDI-X. Proto si chci udělat redukci a použít 2 síťové karty, kde jedna bude číst Tx a druhá Rx té komunikace.
A k tomu bych rád přidal nějaký synchronizační vstup z Mesy, ale nemám to zatím promyšlené, jak to udělat. Já jsem zatím vždycky používal Wireshark jenom tím nejjednodušším způsobem, takže jsem neměl potřebu zkoumat jeho vyšší možnosti.
Jistě by se to dalo poslouchat i přímo na tom LinuxCNC, nebo to udělat na externím PC i jen jednou síťovkou a použít inteligentní switch s mirroringem portů. Ale já bych to chtěl a potřeboval pokud možno mít nezávislé na komunikujících zařízeních (proto to nechci poslouchat na tom LinuxCNC ale chci to dělat na dalším nezávislém PC) a neovlivněno časově (proto to nechci dělat nějakým chytrým switchem, který to zřejmě časově zkreslí).
Možná to půjde udělat nějak snadněji, musím si tom Wiresharku něco načíst.
K tomu VHDL: cílem je využít 20 pinů na tom FPGA a na nich zařídit mirroring:
- 8 linek, co přijdou na datovou vstupní sběrnici, poslat na 8 výstupních linek toho FPGA
- zápisy, které naopak pošle FPGA na těch stejných 8 datových linek poslat na dalších 8 výstupních linek FPGA
- 3 vstupní linky do FPGA poslat na další 3 výstupní linky
- 1 výstupní linku poslat souběžně na další výstupní linku
Tedy jinými slovy mirrorovat stav daných linek toho FPGA na dalších linkách. Přičemž 8 z nich je obousměrných, takže jejich obsah mirrorovat zvlášt ve vstupním a zvlášť ve výstupním režimu.
Umět VHDL, tak by to bylo asi na chvilku. Ale právě je tam ten podmiňovací způsob, se zatím nesplněnou podmínkou.
Určitě chci využít Wireshark. Ale nevím, jestli Wireshark umí explicitně zaměnit Tx a Rx pár, tj. přeprogramovat PHY ethernetové karty a využít MDI-X. Proto si chci udělat redukci a použít 2 síťové karty, kde jedna bude číst Tx a druhá Rx té komunikace.
A k tomu bych rád přidal nějaký synchronizační vstup z Mesy, ale nemám to zatím promyšlené, jak to udělat. Já jsem zatím vždycky používal Wireshark jenom tím nejjednodušším způsobem, takže jsem neměl potřebu zkoumat jeho vyšší možnosti.
Jistě by se to dalo poslouchat i přímo na tom LinuxCNC, nebo to udělat na externím PC i jen jednou síťovkou a použít inteligentní switch s mirroringem portů. Ale já bych to chtěl a potřeboval pokud možno mít nezávislé na komunikujících zařízeních (proto to nechci poslouchat na tom LinuxCNC ale chci to dělat na dalším nezávislém PC) a neovlivněno časově (proto to nechci dělat nějakým chytrým switchem, který to zřejmě časově zkreslí).
Možná to půjde udělat nějak snadněji, musím si tom Wiresharku něco načíst.
K tomu VHDL: cílem je využít 20 pinů na tom FPGA a na nich zařídit mirroring:
- 8 linek, co přijdou na datovou vstupní sběrnici, poslat na 8 výstupních linek toho FPGA
- zápisy, které naopak pošle FPGA na těch stejných 8 datových linek poslat na dalších 8 výstupních linek FPGA
- 3 vstupní linky do FPGA poslat na další 3 výstupní linky
- 1 výstupní linku poslat souběžně na další výstupní linku
Tedy jinými slovy mirrorovat stav daných linek toho FPGA na dalších linkách. Přičemž 8 z nich je obousměrných, takže jejich obsah mirrorovat zvlášt ve vstupním a zvlášť ve výstupním režimu.
Umět VHDL, tak by to bylo asi na chvilku. Ale právě je tam ten podmiňovací způsob, se zatím nesplněnou podmínkou.
Povedlo se vám prosím někomu s touto nebo aspoň nějakou jinou kartou se Spartanem 6 natáhnout firmware on-line?
Tedy něco jako:
loadrt hm2_7i90 ioaddr=0x378 config="firmware=hm2/7i90/7i90_epp_svst4_8.bit"
Původní driver karty 7i90 to neumožňuje, protože je v něm chyba, daná tím, že ho někdo vytvořil jen modifikací driveru pro 7i43. To jsem spravil, ale stejně tam on-line firmware neumím dostat, nejde zresetovat to FPGA.
On je ale u této karty ve FPGA řešen i komunikační interface (EPP nebo SPI), takže to přeprogramování firmwaru za chodu zřejmě nepůjde. To programování určitě začne výmazem původní konfigurace, že jo.
Případně jak jinak dostat rychle nový firmware do karty? Standardní postup přes zápis do EEPROM pomocí Mesaflash je děsně pomalý.
JTAG zatím nemám, ale předpokládám, že tam je nahrání firmware ještě mnohem pomalejší.
Chtělo by to něco jako simulátor té sériové EEPROM, který by byl tvořený RAMkou. Do té by to z jedné strany nasypalo PC třeba po USB, z druhé strany by se to pak vůči FPGA tvářilo jako běžná EEPROM.
Tedy něco jako:
loadrt hm2_7i90 ioaddr=0x378 config="firmware=hm2/7i90/7i90_epp_svst4_8.bit"
Původní driver karty 7i90 to neumožňuje, protože je v něm chyba, daná tím, že ho někdo vytvořil jen modifikací driveru pro 7i43. To jsem spravil, ale stejně tam on-line firmware neumím dostat, nejde zresetovat to FPGA.
On je ale u této karty ve FPGA řešen i komunikační interface (EPP nebo SPI), takže to přeprogramování firmwaru za chodu zřejmě nepůjde. To programování určitě začne výmazem původní konfigurace, že jo.
Případně jak jinak dostat rychle nový firmware do karty? Standardní postup přes zápis do EEPROM pomocí Mesaflash je děsně pomalý.
JTAG zatím nemám, ale předpokládám, že tam je nahrání firmware ještě mnohem pomalejší.
Chtělo by to něco jako simulátor té sériové EEPROM, který by byl tvořený RAMkou. Do té by to z jedné strany nasypalo PC třeba po USB, z druhé strany by se to pak vůči FPGA tvářilo jako běžná EEPROM.
Ahoj,
7i90 jsem zatím netestoval, tak nemam realne zkusenosti. hral sem si pouze s 7i43 kde nahrat firmware při startu pomoci lpt dratu rovnou nekam do fpga není problém, dokonce je to standartni postup, samozrejme muzes natáhnout firmware i z eeprom ale to jsem nikdy netestoval.
loadrt hm2_7i43 config="firmware=hm2/7i43-4/SVST4_12.BIT num_encoders=0 num_pwmgens=0 num_3pwmgens=0 num_stepgens=4 "
Ale není to spartan 6 nýbrž spartan 3.
A blba otázka nakonec. Proc chces nahrazovat eeprom za ram a cely to simulovat. Ze ty chces metodou pokusu omylu hrnout do karty hromadu verzi a ladit? Nebo sem uplne vedle?
M
7i90 jsem zatím netestoval, tak nemam realne zkusenosti. hral sem si pouze s 7i43 kde nahrat firmware při startu pomoci lpt dratu rovnou nekam do fpga není problém, dokonce je to standartni postup, samozrejme muzes natáhnout firmware i z eeprom ale to jsem nikdy netestoval.
loadrt hm2_7i43 config="firmware=hm2/7i43-4/SVST4_12.BIT num_encoders=0 num_pwmgens=0 num_3pwmgens=0 num_stepgens=4 "
Ale není to spartan 6 nýbrž spartan 3.
A blba otázka nakonec. Proc chces nahrazovat eeprom za ram a cely to simulovat. Ze ty chces metodou pokusu omylu hrnout do karty hromadu verzi a ladit? Nebo sem uplne vedle?
M
Mesa 7i43 na to je dělaná, ta má interface pro komunikaci po EPP dělanou externím HW. Takže komunikace žije i když je FPGA mrtvé.fupe píše:Ahoj,
7i90 jsem zatím netestoval, tak nemam realne zkusenosti. hral sem si pouze s 7i43 kde nahrat firmware při startu pomoci lpt dratu rovnou nekam do fpga není problém, dokonce je to standartni postup, samozrejme muzes natáhnout firmware i z eeprom ale to jsem nikdy netestoval.
loadrt hm2_7i43 config="firmware=hm2/7i43-4/SVST4_12.BIT num_encoders=0 num_pwmgens=0 num_3pwmgens=0 num_stepgens=4 "
Ale není to spartan 6 nýbrž spartan 3.
A blba otázka nakonec. Proc chces nahrazovat eeprom za ram a cely to simulovat. Ze ty chces metodou pokusu omylu hrnout do karty hromadu verzi a ladit? Nebo sem uplne vedle?
M
U 7i90 je to jinak. Tam je interface pro EPP přímo součástí obsahu toho FPGA, takže když FPGA nežije, nejede ani komunikace.
Výhodou je nízká cena (míň HW na desce) a větší pružnost. Snadno je možné zaměnit EPP třeba za SPI nebo jiný komunikační kanál.
Nevýhodou je, že mě to štve. Při pokusech stále ojíždět Flash a navíc čekat věčnost na naprogramování, to na náladě nepřidá.
Ano, chci metodou pokus/omyl programovat to FPGA. Já obecně rád programuju malými kroky, takže třeba u jednochipů zásadně ladím v RAM a ne ve Flash. Mám zvyk, že kolečko překlad-naprogramování chipu-spuštění by nemělo trvat víc než 5 sekund, v limitních případech u složitých věcí max. 10 sekund.
Takže něco podobného bych rád i u toho FPGA (samozřejmě tady mimo ten překlad, který bude bohužel dlouhý). Už mě napadlo, jak ten simulátor udělat. Ale asi to pak budu ladit na dev-kitu se stejným FPGA, přece jen je to tam líp dostupné a z Číny stojí to čtvrtinu, takže kdybych něco oddělal, nemusím se jít hned věšet.
Mám tuhle úchylku už od mládí, už na vejšce (začátek 80-tých let) jsem vyráběl různé simulátory (např. simulátor děrné pásky) a tajně je na nočních směnách připojoval k drahým sálovým počítačům, kolem kterých se jinak muselo chodit jen po špičkách. Vědět to tehdy zodpovědní pracovníci, tak bych určitě nedostudoval.
Pánové, mohl by prosím někdo napsat něco o PID, která se používá pro výpočet kroků pro Mesu na další servoperiodu?
PNCConf tem vygeneruje tyhle defaultní parametry:
FERROR = 10.0
MIN_FERROR = 1.0
...
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
Ty parametry P, I, D fungují nějak záhadně, rozhodně ne jako u běžné PID. Pokud se sáhne na některý parametr FF, tak to přestane fungovat úplně. Takže mi to připadá, že to s běžnou PID má dost málo společného.
Ale budiž. Když jsem změnil P na 520 (optimum, které jsem našel metodou pokus-omyl) a na zbytek nesahal, tak to funguje celkem slušně (i když ne optimálně).
Co ale nechápu vůbec jsou parametry FEROR a MIN_FERROR. Když jezdím s Mesou dost rychle (víc než cca F5000 s vysokou akcelerací a vysokou frekvencí STEP), tak to občas padalo na "Joint X following error". Měnil jsem ledacos, nakonec pomohlo nastaveni MIN_FERROR na nějakou vyšší hodnotu, konkrétně jsem nastavil 10.
Zní to nelogicky, že změna parametru, který se jmenuje MIN_xxx potlačí generování chyb.
Pokud v tom máte někdo jasno, prosím napište kolem toho nějaké moudro.
Jistě je zde ta nejpracnější varianta začít louskat zdrojáky driveru Mesy. Kdyby to ale někdo znal a byl ochotný k tomu něco napsat, bylo by to moc fajn.
Díky.
PNCConf tem vygeneruje tyhle defaultní parametry:
FERROR = 10.0
MIN_FERROR = 1.0
...
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
Ty parametry P, I, D fungují nějak záhadně, rozhodně ne jako u běžné PID. Pokud se sáhne na některý parametr FF, tak to přestane fungovat úplně. Takže mi to připadá, že to s běžnou PID má dost málo společného.
Ale budiž. Když jsem změnil P na 520 (optimum, které jsem našel metodou pokus-omyl) a na zbytek nesahal, tak to funguje celkem slušně (i když ne optimálně).
Co ale nechápu vůbec jsou parametry FEROR a MIN_FERROR. Když jezdím s Mesou dost rychle (víc než cca F5000 s vysokou akcelerací a vysokou frekvencí STEP), tak to občas padalo na "Joint X following error". Měnil jsem ledacos, nakonec pomohlo nastaveni MIN_FERROR na nějakou vyšší hodnotu, konkrétně jsem nastavil 10.
Zní to nelogicky, že změna parametru, který se jmenuje MIN_xxx potlačí generování chyb.
Pokud v tom máte někdo jasno, prosím napište kolem toho nějaké moudro.
Jistě je zde ta nejpracnější varianta začít louskat zdrojáky driveru Mesy. Kdyby to ale někdo znal a byl ochotný k tomu něco napsat, bylo by to moc fajn.
Díky.
