Arduino pendant

pepiho
Příspěvky: 39
Registrován: 19. 8. 2011, 10:41
Bydliště: Liberecko

1. 2. 2015, 4:03

Nezkoušel jste někdo ovládat EMC pomocí arduina přes USB ?
Chci si vyrobit jednoduchej ovladač s LCD, přepínáním os,.....
našel jsem tyto linky: https://ckcnc.wordpress.com/2011/02/13/ ... r/#more-88 https://emc2arduino.wordpress.com/

Jsem z toho nějakej zmatenej (s arduinem nemám problém).
Díky.
Uživatelský avatar
filla
Příspěvky: 3536
Registrován: 1. 12. 2013, 12:55
Bydliště: Brno
Kontaktovat uživatele:

1. 2. 2015, 4:14

hotovy se to jmenuje XHC HB04
"do řiti se řítíme, ani o tom nevíme.."
pepiho
Příspěvky: 39
Registrován: 19. 8. 2011, 10:41
Bydliště: Liberecko

1. 2. 2015, 7:16

Díky, za 1800 kč vč poštovnýho (drátová verze http://www.aliexpress.com/item/Free-shi ... 42356.html ) se to nevyplatí bastlit.
Máte někdo tuto drátovou LHB04 ?
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

1. 2. 2015, 11:15

Díval jsem se na ten projekt EMC2Arduino.
Je to udělné tak, že napsali HAL modul do LinuxCNC a firmware pro Arduino, takže je možné připojit motory a čidla pomocí toho Arduina přes USB k PC.
Jako myšlenka dobré, ale realizace nic moc. Je to pomalé, a navíc to neřeší problém jitteru, protože to visí na base-thread.

Už jsem tady ten dotaz jednou psal, ale zůstal bez odpovědi. Tak zkusím štěstí ještě jednou:
Uměl a byl by prosím někdo ochotný pro nás ostatní-neznalé popsat, jaké informace běhají mezi LinuxCNC a Mesa kartama? Tyhle Mesy se snad věší na servo-thread, takže jsou obsluhované jen každou milisekundu. To už mi přijde dost pomalu na to, aby bylo možné v rámci té milisekundy jen rovnoměrně rozložit generování požadovaného počtu pulzů STEP. Takže to zřejmě bude udělané nějak chytřeji a bude tam běhat nějaký sofistikovanější protokol. A ten by se možná dal využít k napojení jiného HW, než je zrovna Mesa.
Jestli to máte někdo v ruce, prosím podělte se.
Díky.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

2. 2. 2015, 7:43

uz tu na to tema byla debata

vymenuji se tam informace z registru treba do stepgenu se posle tusim 11 bit registr ktery urcuje kmitocet vystupnich kroku (programovatelna delicka zakladniho kmitoctu krystalu)
a vystupni kroky se treba citaji aby byla znama poloha ktera byla vyslana na motor (tento registr se zase cte do linuxcnc)
kdyz to je vic nebo min tak se upravi kmitocet vystupnich kroku
pak tam jsou nejake registry ktere odpovidaji obecnym IO
nebo hardwarovym citacum z encoderu
nebo PWM na analogove vystupy

zalezi presne co za firmware je zrovna nahrany do mesy a kde teda ty registry jsou
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

2. 2. 2015, 6:50

robokop píše:uz tu na to tema byla debata
vymenuji se tam informace z registru treba do stepgenu se posle tusim 11 bit registr ...
Díky za informace.
Tu debatu se mi (zatím) nepovedlo najít.

Ty informace jsou zajímavé. Takže je to ten nejjednodušší princip, že v rámci jedné milisekundy Mesa rozloží pulzy rovnoměrně. Jestli to chápu správně, tak zpoždění mezi odeslanými pulzy (odeslanými LinuxCNC) a reálně odeslanými Mesou se kompezuje tím, že se zpětně čte počet reálně odeslaných pulzů.
Docela by mě zajímalo, jak se řeší případ, kdy se čtením GPIO zjistí nějaká událost (třeba najetí na spínač). To čtení GPIO je myslím dělané v base-threadu, tedy mnohem častěji než se načte aktualizovaný stav čítače reálně odeslaných pulzů (který se čte předpokládám v servo-thread). Takže tam bude posun v nejhorším případě až o počet pulzů za 1ms.

Každopádně taková logika, jakou dělá ta Mesa, by se asi dala celkem snadno realizovat nějakým slušnějším MCU.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

2. 2. 2015, 7:06

cekal bych ze to cte soucasne v servo threadu jako nejaky registr
ale jedna se o obecne IO piny

na procaku by to slo
ale to hradlove pole bud emnohem vykonejsi
bezi v nem mnoho navzajem nezavislych procesu jako treba ty stepgeny a citace pulzu
na procesoru by jsi musel resit ruzne spozdeni u jednotlivych uloh toho procesoru, ruzna preruseni atd... takze by to ve finale bylo pomale viz nektere z pokusu tohle resit na MCU ve svete

co tim zamyslis vylepsit?
Vsechna prava na chyby vyhrazena (E)
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

2. 2. 2015, 8:39

Veskerou komunikaci s MESOU obstarava HostMot2 "driver" ktery nahrava mimo jine i firmware do MESY a obstarava veskerou komunikaci.
Po nahrani "Firmware" se registruji jednotlive moduly a pemotovy komunikacni bufer ktery se cely aktualizuje v ramci ServoThreadu. Tato komunikace tedy pri jedinem cyklu (ktery muze byt klidne vice jak 1kHz) vymneni s MESOU veskere informace jakou jsou pozadovane rychlosti vsech stepgenu. Vsechny vstupni/vystupni piny, precte pozice enkoderu, nastavi PWM a spoustu dalsiho. VŠECHNO tohle se stihne v jedinem ServoThread cyklu.

Pro rizeni polohy se nezadava pocet pulzu ktere ma karta udelat ale presna rychlost kterou se maji jednotlive osy pohybovat. Tato rychost je "pouze" 11 bitova hodnota (ale ono to více než brutálně stačí) která v MESE běží na rychlosti podstatně vyšší než je rychlost krokování (tedy jednotlivých kroků pro krokáč, nebo vstup serva). V MESE je 16.16 (tedy fixed point celkem 32 bitů) registr polohy (tedy s přesností brutálně vyší než je přesnost krokování) který je aktualizovaný pro všechny "StepGeny" paralelně. Tato pozice se potom v každém cyklu čte a pomocí kvazi-PID regulátoru (ten je součístí HostMot2 na straně PC) je dopočítána nová "požadovaná" rychlost na základě rozdílu mezi "skutečno polohou" a "teoretickou polohou". Toto všechno s přesností o několik řádů jinde než potom "leze" na výstupu každého ze "StepGenů".
Dále se nepočítá pouze s časovým údajem 1ms (tedy pro ServoThread na 1kHz) mezi jednotlivými kroky, ale je znám opravdový "přesný" čas kdy k výpočtu dochází (rozlišení v řádu nanosekund podle přesného časovače procesoru).

Ono když se na to člověk koukne trochu "pod pokličku" tak to až zase tak primitivní není. A to co MCU nikdy nezvládne je onen opravdový PARALELNÍ chod všech těch "modulů" co se na to FPGA vlezou.

StepGenama počínaje, přes PWM Generátory, Encodery (a pozor i ty encodery nejsou pouze stupidní čítače jak by se mohlo zdát), až po řadiče dalších jednodušších sběrnic typu RS485, SmartSerial atd..... Vše běží paralelně zároveň a VŠE s možností "obsluhy" a kompletní "výměny" dat v rámci jediného cyklu.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

2. 2. 2015, 9:26

robokop píše:co tim zamyslis vylepsit?
Moderní MCU mají spoustu čítačů (např. ARMy STM32), často víc než 10. A navíc ty čítače jsou docela chytré, umí např. samy obsluhovat inkrementální kodéry. Takže není žádné velké scifi použít 3 čítače na HW generování STEP a další 3 čítače na čtení enkodérů nebo pravítek. A s takovou podporou HW by se dalo dosáhnout hodně zajímavých výkonů.

Líbilo by se mi, kdyby se stepgeny daly rozjet na nějakém široce dostupném HW. A to Mesa určitě není. Třeba kartu 5i25 Duzi teď zrovna má. Ale ještě před nedávnem ji měl rok "dočasně" vyprodanou.
Navíc by se to dalo celkem elegantně udělat připojitelné přes USB. Je mi jasné, že padne spousta názorů jak USB není real-time atd. Ale při obsluze, zavěšené na 1ms servo-thread má USB takovou rezervu výkonu, že se klidně dá za real-time považovat (pokud teda na stejném root-hubu současně nepustím kopírování nekolika gigabyte dat z jednoho USB disku na druhý USB disk ;-) ). Navíc při zpracování pomocí MCU není problém bufferovat komunikaci, a zajistit tak hodně velkou toleranci k latenci, resp. k jitteru.

Napsat tu část obsluhy na straně MCU bych si troufal a bavilo by mě to. Ale do vnitřností LinuxCNC nevidím, a kupodivu mě to ani neláká. Nevím proč, protože programovaním na Linuxu jsem se dost dlouho živil.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

2. 2. 2015, 9:53

CZ_Pascal píše:Veskerou komunikaci s MESOU obstarava HostMot2 "driver" ktery nahrava mimo jine i firmware do MESY a obstarava veskerou komunikaci.
Po nahrani "Firmware" se registruji jednotlive moduly a pemotovy komunikacni bufer ktery se cely aktualizuje v ramci ServoThreadu. Tato komunikace tedy pri jedinem cyklu (ktery muze byt klidne vice jak 1kHz) vymneni s MESOU veskere informace jakou jsou pozadovane rychlosti vsech stepgenu. Vsechny vstupni/vystupni piny, precte pozice enkoderu, nastavi PWM a spoustu dalsiho. VŠECHNO tohle se stihne v jedinem ServoThread cyklu.

Pro rizeni polohy se nezadava pocet pulzu ktere ma karta udelat ale presna rychlost kterou se maji jednotlive osy pohybovat. Tato rychost je "pouze" 11 bitova hodnota (ale ono to více než brutálně stačí) která v MESE běží na rychlosti podstatně vyšší než je rychlost krokování (tedy jednotlivých kroků pro krokáč, nebo vstup serva). V MESE je 16.16 (tedy fixed point celkem 32 bitů) registr polohy (tedy s přesností brutálně vyší než je přesnost krokování) který je aktualizovaný pro všechny "StepGeny" paralelně. Tato pozice se potom v každém cyklu čte a pomocí kvazi-PID regulátoru (ten je součístí HostMot2 na straně PC) je dopočítána nová "požadovaná" rychlost na základě rozdílu mezi "skutečno polohou" a "teoretickou polohou". Toto všechno s přesností o několik řádů jinde než potom "leze" na výstupu každého ze "StepGenů".
Dále se nepočítá pouze s časovým údajem 1ms (tedy pro ServoThread na 1kHz) mezi jednotlivými kroky, ale je znám opravdový "přesný" čas kdy k výpočtu dochází (rozlišení v řádu nanosekund podle přesného časovače procesoru).

Ono když se na to člověk koukne trochu "pod pokličku" tak to až zase tak primitivní není. A to co MCU nikdy nezvládne je onen opravdový PARALELNÍ chod všech těch "modulů" co se na to FPGA vlezou.

StepGenama počínaje, přes PWM Generátory, Encodery (a pozor i ty encodery nejsou pouze stupidní čítače jak by se mohlo zdát), až po řadiče dalších jednodušších sběrnic typu RS485, SmartSerial atd..... Vše běží paralelně zároveň a VŠE s možností "obsluhy" a kompletní "výměny" dat v rámci jediného cyklu.
Samozřejmě nic z toho, co píšeš, nezpochybňuju. Jen se na to dívám z pohledu, jak by se to dalo dělat pomocí MCU.

Dělat přenos všeho v jediném ceyklu servo-threadu je snažší, než něco dělat přes servo-thread a něco přes base-thread. Takže by to bylo ještě jednodušší, já jsem si totiž myslel, že GPIO se obsluhují přes base-thread.

Paralelismus by nebyl až takový problém, viz můj předchozí příspěvek o spoustě čítačů. Takže s plnou HW podporou a naprosto stejně paralelně se dají dělat stepgeny, PWM i čtení enkodérů. SmartSerial by se neřešil, není proč.

S poznámkou, že pod pokličkou je to složitejší samozřejmě souhlasím. Proto se tak stupidně ptám, jak ta Mesa komunikuje, protože pod pokličku LinuxCNC nevidím. Mimochodem kolik těch informací se celkem přenáší? Těch 11 bitů je předpokládám pro každý stepgen. Kolik informací tam leze z čítačů (těch 32 bitů z každého čítače?) a z GPIO?
Kdybys věděl o nějaké přehledné souhrné informaci co se tam pohybuje, tak by to bylo fajn.
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

3. 2. 2015, 7:06

delat to na hradlovem poli je daleko jednodussi
je uplne paralelni narozdil od mcu
dostupnost u duziho je katastrofalni
nic ti nebrani to koupit primo, nebo cncshopu aby to zacal prodavat nejak seriozneji

usb na cnc masine je slepa ulicka
nikdy to nemuze bezet spolehlive kvuli ruseni
vyzkouseno

na mcu nikdy nemuzes mit stejny vykon jaky budes mit na hradlovym poli

stejne jako jsou dostupny ruzny arduina tak jsou dostupny kity na hradlova pole nicmene je to slepa ulicka jako to usb
chce to trosku seriozneji delany hardware jako je napriklad ta mesa
jinak ta mesa je vcelku lacina, uz jsem par tech svabu na mesach lidem tady vymenoval a to fpga stoji asi 800,- + posta + tistak + dalsi bizuterie a nemas sanci byt levnejsi
Vsechna prava na chyby vyhrazena (E)
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

3. 2. 2015, 7:14

USB má svoje limity, ale když se jim člověk přizpůsobí, tak určitě použitelné je.
Základním limitem je délka kabeláže. Takže rozhodně to s délkou nepřehánět, ale udělat to tak akorát (1-2 metry).
No a hlavně použít slušný stíněný kabel.
Pak se i USB rozhodně použít dá, už jsem toho i v průmyslu viděl na USB docela dost (a dokonce i něco dělal).

Kromě toho pokud by se to přeportovalo na MCU, tak není problém to honit třeba po RS485/RS422. Zrovna nedávno jsem dělal nějaké řízení technologie v průmyslu na Profibusu, konkrétně na RS485 na 1.5 Mbit/s. Jede to na dlouhé kabeláži v pěkně zahnuseném prostředí (rušení jako prase od velké haly, plné měničů v hodně mocných motorů), a jede to jako víno.

Já jsem bohužel v oblasti hradlových polí lama (a stydím se za to). Takže neumím moc kvalifikovaně odhadnout, jak reálné by bylo přeportovat funkčnost Mesy na jiný HW (jiné hradlové pole). Ale vzhledem k slušné abstraktnosti popisu pomocí VHLD bych řekl/doufal, že by to mělo být realizovatelné.
S tím kvalitním ošetření FPGA na kartách Mesa bych si tak úplně jistý nebyl. Minimálně na holé Mese. Samozřejmě s pomocnými oddělovacími kartami už jo, ale ty taky nejsou z úplně laciného kraje.
Problém vidím v oblasti licence, předpokládám, že to má Mesa nějak ošéfované (případný přenos na jiný HW).

Pro změnu v oblasti MCU lama nejsem. Takže jsem si celkem jistý, že by se velmi slušných parametrů (steprate generované pomocí HW klidně na 500 ksteps/sec, vstup od enkodéru zpracovávaný pomocí HW na frekvenci klidně v řádu Mpuls/sec) dalo dosáhnout i s procesorem v hodně zajímavé cenové kategorii (do 100 Kč za kus).

Nezpochybňuji, že FPGA umí danou činnost udělat rychleji než MCU. Ale MCU ji zase umí udělat chytřeji.
Dovolím si přirovnání k lidem: mladý člověk (třeba dítě) má rychlejší reakce než starší člověk. Ale starší člověk zase většinou umí líp vymyslet, co by se mělo dělat, takže nepotřebuje mít tak rychlé reakce.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

3. 2. 2015, 9:29

Přeportovat tu MESU na cokoliv jineho "není problém", pokud si myslíš že zvládneš řadič PCI sběrnice levněji a dostupněji než to dává ta MESA.

Jak říkáš VHDL je velice abstraktní a o konkrétní "vydrátování" pro dané hradlové pole se musí postarat "překladač" výrobce příslušného švába, takže nic nebrání přeložení FIrmware pro jiný šváb než pro XILINX, ale zcela určitě se bude bránit jiné vývojové prostředí stylu v jakém je Firmware napsaný, takže bez dokonalé znalosti VHDL a práce s FPGA to rozhodně nepujde.

Přirovnal bych to jako když píšeš v C-čku pro mikrokontrolery a to co přeložíš s AVR-Studiem už nepřekousne KEIL nebo CodeBlocks nebo další jiná udělátka bez "doladění" na příslušné "zvyklosti" daného překladače (a to samé platí samozřejmě naopak, projekt z ECLIPSE atd... nepřeložíš jen tak bez znalostí toho co děláš v AVR-Studiu)

Pokud bys chtěl jít cestou vlastního HW tak rovnou zapomeň na to že někde navážeš na to co do MESY leze. Výpočtově je to právě velice šikovně rozdělené na to co se počítá v MESE a co v RealTime "procesu" HostMot2 "driveru" na straně PC. Na obou stranách je toho požehnaně a rozhodně rychlost a odezvu PCI sběrnice nějakým USB nebo nedej bože dalším převodníkem USB na RS485/RS422 nenahradíš. Buferování nepřipadá v úvahu protože výpočty počítají s tím že mají AKTUÁLNÍ data.

To už raději zapoměň že nějaká MESA existuje a udělej si vlastní "STEPGEN" HardWare který bude mít modul v HALu (tak jako to má softwarový stepgen, stejně tak jako to má ta MESA a stejně tak jako to mají jiné komponenty které můžeš v HALu "nadrátovat" ať už na ServoThread nebo BaseThread) A s tímto modulem může komunikovat tvoje "udělátko" na bázi MCU. A část toho modulu pojede v RealTime "procesu" a druhá část v "UserSpace" tedy ne Realtime - tedy stoprocentně nepoběří v tom RealTime procesu komunikace s USB - to budeě muse ošéfovat "buferem" ve sdílené paměti jako rozhraním mezi "RealTime" a "UserSpace".

Přes HAL do svého modulu dostaneš pravidelně údaj o potřebné poloze a je na tobě jak se popereš s tím že ho s potřebnou pravidelností nedokážeš nakrmit do toho MCU.
Nezbyde ti tedy než nějaké buferování (= problém už z principu protože už běžíš pozadu oproti LinuxCNC a jakoukoliv synchronizaci s čímkoliv dalším řešíš s tímto spožděním) a s tím že USB si klidně zdřímne na několik MS (například v rámci čekání na zaplnění vysílacího buferu a teprve když se dlouho nic neděje -tedy oněch pár milisekund tak pošle data i když není paket transferu využit "naplno" a začne se nudit) tak rovnou k posílaným datů připojit i "TimeStamp" nebo něco čím eliminuješ nepravidelnost dat z USB.

Stejně tak by se dal využít "spešl" režim USB přenosu kdy se data odesílají konstantní rychlostí (tedy nejsou "shromažďována" do efektivnějších paketů) ale i v tomto případě je potřeba mít předchystaný "bufer" na straně PC = opět zdržení.

Dokud budeš jezdit "naslepo" bez zpětné vazby (nemálo strojů je takto provozováno) tak je to v pohodě. Ve chvíli kdy budeš chtít uzavřít regulační smyčku přes PC tak jsi v pasti. Jediné řešení je zpracovat smyšku už na straně MCU a PC s tím neobtěžovat, ale to už se zase komplikuje SW na straně MCU a přidává nemalé zatížení a složitost na straně MCU.

Jinak nevím jak jsou na tom cenově v současné době nějaké trochu chytřejší procesory, ale rozhodně by to chtělo už nějaký ARM a ne "ušmudlané AVR-ko na 20MHz" (které se pohybuje zhruba kolem těch 100,-kč). A to ne že bych proti těm AVRkum něco měl - dá se s nima za málo peněz udělat překvapivě hodně a jsou moje oblíbené.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

3. 2. 2015, 10:09

CZ_Pascal píše:Přeportovat tu MESU na cokoliv jineho "není problém", pokud si myslíš že zvládneš řadič PCI sběrnice levněji a dostupněji než to dává ta MESA.
Do emulace PCI bych se netlačil. Je pár karet, které komunikují po LPT nebo SPI (nepř. 7i34, 7i90).
CZ_Pascal píše:Jak říkáš VHDL je velice abstraktní a o konkrétní "vydrátování" pro dané hradlové pole se musí postarat "překladač" výrobce příslušného švába, takže nic nebrání přeložení FIrmware pro jiný šváb než pro XILINX, ale zcela určitě se bude bránit jiné vývojové prostředí stylu v jakém je Firmware napsaný, takže bez dokonalé znalosti VHDL a práce s FPGA to rozhodně nepujde.
Souhlasím. A tuto dovednost (minimálně zatím) nemám. Proto taky píšu, že jsem z tom lama, a ptám se, co by na to řekli praktici, kteří toho už udělali dost.
CZ_Pascal píše:Přirovnal bych to jako když píšeš v C-čku pro mikrokontrolery a to co přeložíš s AVR-Studiem už nepřekousne KEIL nebo CodeBlocks nebo další jiná udělátka bez "doladění" na příslušné "zvyklosti" daného překladače (a to samé platí samozřejmě naopak, projekt z ECLIPSE atd... nepřeložíš jen tak bez znalostí toho co děláš v AVR-Studiu)
Jak jsem psal - v tomhle lama nejsem. A dělal jsem to mnohokrát.
CZ_Pascal píše:Pokud bys chtěl jít cestou vlastního HW tak rovnou zapomeň na to že někde navážeš na to co do MESY leze. Výpočtově je to právě velice šikovně rozdělené na to co se počítá v MESE a co v RealTime "procesu" HostMot2 "driveru" na straně PC. Na obou stranách je toho požehnaně a rozhodně rychlost a odezvu PCI sběrnice nějakým USB nebo nedej bože dalším převodníkem USB na RS485/RS422 nenahradíš. Buferování nepřipadá v úvahu protože výpočty počítají s tím že mají AKTUÁLNÍ data.
Proto ten dotaz/přání, jestli není nějaká souhrná informace co a jak tam mezi tím PC a FPGA lítá. To bylo gró mého dotazu.
CZ_Pascal píše:To už raději zapoměň že nějaká MESA existuje a udělej si vlastní "STEPGEN" HardWare který bude mít modul v HALu (tak jako to má softwarový stepgen, stejně tak jako to má ta MESA a stejně tak jako to mají jiné komponenty které můžeš v HALu "nadrátovat" ať už na ServoThread nebo BaseThread) A s tímto modulem může komunikovat tvoje "udělátko" na bázi MCU. A část toho modulu pojede v RealTime "procesu" a druhá část v "UserSpace" tedy ne Realtime - tedy stoprocentně nepoběří v tom RealTime procesu komunikace s USB - to budeě muse ošéfovat "buferem" ve sdílené paměti jako rozhraním mezi "RealTime" a "UserSpace".
No to naráží na mou neznalost toho, jak je to konkrétně v LinuxCNC/HALu udělané. Proto to přání "poučit se od mistrů" a kouknout, jak to dělá ta Mesa.
CZ_Pascal píše:USB si klidně zdřímne na několik MS (například v rámci čekání na zaplnění vysílacího buferu a teprve když se dlouho nic neděje -tedy oněch pár milisekund tak pošle data i když není paket transferu využit "naplno" a začne se nudit) tak rovnou k posílaným datů připojit i "TimeStamp" nebo něco čím eliminuješ nepravidelnost dat z USB.
Netvrdím, že USB je super. Ale tyhle neřešitelné milisekundové výpadky jsou městská legenda.
CZ_Pascal píše:Jinak nevím jak jsou na tom cenově v současné době nějaké trochu chytřejší procesory, ale rozhodně by to chtělo už nějaký ARM a ne "ušmudlané AVR-ko na 20MHz" (které se pohybuje zhruba kolem těch 100,-kč). A to ne že bych proti těm AVRkum něco měl - dá se s nima za málo peněz udělat překvapivě hodně a jsou moje oblíbené.
Mluvím celou dobu samozřejmě o ARMech, jak jsem už psal v předchozích příspěvcích. Ty ARMy mají právě moc šikovné čítače/timery, které by se daly pěkně využít pro HW asistenci. A ty nejmenší začínají už nekde na 40 Kč (i když zrovna tyhle nejnižší řady bych na to asi nepoužíval).
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

4. 2. 2015, 6:32

Mex píše:Do emulace PCI bych se netlačil. Je pár karet, které komunikují po LPT nebo SPI (nepř. 7i34, 7i90).
OK muzes klidne pouzit to LPT jakozto opravdove realtime rozhrani. SPI je vzdy az jako komunikacni protokol hlavni karty (pripojene na LPT nebo PCI) s kartou rozsirujici a resi veci ktere nejsou rychlostne tak nachylne. Tedy standardne General purpose IO a jine seriove sbernice (RS485/RES422) atd.
Mex píše:Souhlasím. A tuto dovednost (minimálně zatím) nemám. Proto taky píšu, že jsem z tom lama, a ptám se, co by na to řekli praktici, kteří toho už udělali dost.
Praktici by nejspis rekli ze to je spuosta prace pro jednoho cloveka ktery jeste ani nema nastudovane zdrojaky. Jsou v tom stovky a vice hodin prace nez se zacne vysledek alespon blizit tomu co uz existuje.
Mex píše:Jak jsem psal - v tomhle lama nejsem. A dělal jsem to mnohokrát.
To je samozjreme fajn. Programatorske mysleni je zaklad vseho a da se na tom stavet kdyz uz clovek vi co ma k dispozici a napadaji ho cesty jak by se co dalo resit.
Mex píše:Proto ten dotaz/přání, jestli není nějaká souhrná informace co a jak tam mezi tím PC a FPGA lítá. To bylo gró mého dotazu.
Souhrna informace je rozlozena do stovek rádku zdrojoveho kodu LinuxCNC (a mirna znaost toho VHDL taky trochu pomuze v pochopeni toho co je psane v tom C-čku když muzes nakouknout na obe "strany zarizeni")
Jinymi slovy zas az tak souhrna neni :oops:
Mex píše:No to naráží na mou neznalost toho, jak je to konkrétně v LinuxCNC/HALu udělané. Proto to přání "poučit se od mistrů" a kouknout, jak to dělá ta Mesa.
Kouknout ja k to dela MESA se da pouze do tech zdrojaku. Je to uzitecne vedet jak to delaji, nicmene je to temer nenapodobitelne s jinou HW archytekturou narazejici na "nevhodnost" standardnich jednodussich rozhrani PC.
Mex píše:Netvrdím, že USB je super. Ale tyhle neřešitelné milisekundové výpadky jsou městská legenda.
Tato legendy vychazi ze zpusobu jakym je napsana vetsina ovladacu USB (tedy pro nas bastlice vsechndy HMI interface a FTDI Radice - at uz serove nebo paralelni). U ostatnich vyrobcu svabu pro komunikaci s USB ocekavam velice podobny pristup a nejsem sam vzhledem k tomu ze vetsina tvurcu LinuxCNC tento zpusob komunikace "zavrhuji", presto ze je to jeden z nejdostupnejsich a relativne jednoduchych rozhrani.
I to blby LPT tomu USB dava v ohledu Realtimeovosti na prdel :!:
Mex píše:Mluvím celou dobu samozřejmě o ARMech, jak jsem už psal v předchozích příspěvcích. Ty ARMy mají právě moc šikovné čítače/timery, které by se daly pěkně využít pro HW asistenci. A ty nejmenší začínají už nekde na 40 Kč (i když zrovna tyhle nejnižší řady bych na to asi nepoužíval).
V čase kdy jsem se "dožil věku ARMů" už jsem neměl dostatek času si s nimy pohrát. Mám rozchozený základy pro ARM7TDMI SAM7S, ale už jsem se k nějaké reálnější aplikaci nedostal :-(
Odpovědět

Zpět na „LinuxCNC - drive pod nazvem EMC2“