... pánové ani se mi už nechtělo reagovat, ale nějako mi to nedalo, protože se to tu zase zvrhává v polemiky, které rozhodně neslouží ke správnému pochopení toho jak jsou StepGeny v MESA Firmware a HostMot2 driveru implementovány a jak to tam vlastně funguje.
Nakonec se mi zdá že MEX z pozice tazatele dané téma chápe lépe (i když s jistými rezervami) než Fupe a OompaLoompa dohromady.
Přičemž když se podívám na zkušenosti obou (Fupeho i OmpaLoompa) tak by tomu tak býti myslím nemělo
Problém je (tedy alespoň se domnívám že tomu tak je) že vedete obecnou polemiku za použití určitých tezí (které jsou většinou i správně), které však nejsou přímo aplikovatelné a jednoznačně určující jak by to mělo nebo němělo fungovat.
J
ediným možným přínosným postupem je opravdu se podívat do těch zdrojáků (a to na obou stranách - tedy jak Firmware FPGA, tak HostMot2 "driveru" na straně PC). Jejich funkcionalita je natolik prorostlá, že jsou bez sebe nepoužitelné a nepochopitelné.
Dělba práce je (ani ne moc překvapivě) dle toho co které zařízení (né moc realtimeové PC versus dedikované FPGA) zvládá lépe.
FPGA se (bavím se teď konkrétně o případě StepGenů) stará opravdu čiste o "prosté čítače", které jsou:
- na jedné straně řízeny z driveru HostMot2, tedy posílány
směrem z PC do FPGA
- nastavení základích parametrů při inicializaci, jakou jsou:
- Délka pauzy po zmněně směru,
- Vlastní mód výstupu (Step+Dir, StepLeft+StepRight, QuadratureStepping atd)
- průběžná aktualizace rychlostního registru v rámci Servo-Threadu
- na druhé straně čtením stavových registrů, tedy
směrem z FPGA do PC
- čtení aktuální "pozice" StepGenu pro zpětnou vazbu regulátoru v rámci Servo-Threadu
Na jednu stranu to není mnoho, na druhou strau to je něco co procesor PC nikdy v takové kvalitě jako to FPGA nezvládne vzhledem k tomu že řeší zároveň "milion" všech možnách a nemožných úkolů.
V tom FPGA běží opravdu PARALELNĚ (souběžně) několik nezávislých hardwarových jednotek StepGenů
(které na sebe nijak nevidí, ale nijak se vzájemně v práci neruší / neovlivňují)
Mimojiné i GPIO porty jsou nastavovány a čteny v rámci Servo-Threadu.
FPGA a HostMot2 maji (v rámci nějakého enumeračního procesu, kdy se čte co je vlastně v kartě za Firmware a jaké komponenty obsahuje) zaregistrované určité množství registrů, které jsou "nastavovací" a které jsou "Datové" (bez ohledu na směr toku dat).
Nastavovací se přenáší pouze v době nastavování nějakých parametrů, nebo čtou v rámci nějakého enumeračního procesu.
Naopak
"Datové" registry (bez ohledu na to jestli se zmněnily nebo ne)
jsou KOMPLETNĚ přeneseny v rámci DMA přenosu v KAŽDÉM "ServoCyklu" tedy v rámci obsluhy Servo-Threadu.
Datový přenos PCI sběrnice je na to více než předimenzován, tak proč se trápits tím co přenášet, když se levou zadní zvládnou přenášet všechny data (bez ohledu na to jestli se změnily nebo ne)
To jestli běží StepGen v Rychlostním nebo Polohovém režimu FPGA skutečně nijak nepozná. Rozdíl je pouze v implementaci HostMot2 driveru, kdy v rychlostním režimu musím zajistit já správnou příkazovou rychlost abych byl tam kde mám být (a musím pro to využít nějaký regulační algoritmus tedy PID + FeedForward atd) nebo použiji Polohový režim, kde optimalizovaný regulační algoritmus psaný přímo na míru konkrétně matematicky jednoznačnĚ daného pohybu s omezením Rychlosti a Akcelerace zajistí vlastní HostMot2.
PID ZAČNE (z principu své funkce "automaticky" ZPOMALOVAT a polevovat když se blíží cíli)
- Jak se zmenšuje odchylka klesá vliv Proporcionální složky.
- tím že se nějakou rychlostí přibližuji k cíli, klesá vliv Derivační složky (čím rychleji se blížím tím je slabší její vliv)
- nakonec je cíli skoro tak blízko že je jeho "korekční síla" zanedbatelná a "courá" se za požadovanou polohou. Integrační složka to sice poopraví pokud se pohybuju stále jedním směrem, ale při změně směru pak spíše chvilku škodí než se znovu "NaIntegruje" do požadované polarity aby dorovnávala "courání" - překmitává (pokud není např. algoritmus nějako uměle upraven aby nuloval integrační složku při přesném dosažení cíle).
Naopak regulační algoritmus psaný na míru polohovému režimu VALÍ NAPLNO teoretickou maximální rychlostí danou limity maximální akcelerace a maximální rychlosti DOKUD NENÍ opravdu PŘESNĚ V CÍLI.
pro úplnost nakonec dodávám že popisuju MESA kartu píchlou přímo na PCI sběrnici. Je možné že při LPT implementaci je něco trochu jinak, ale myslím (tedy prd vím), že by to mělo být na stejném principu pouze s jiným médiem (LPT místo PCI) přenostu těch samých dat. Vzhledem k tomu že se předpokládá nulová chybovost při přenosu skrže PCI, tak asi moc nehrotili dodělávat CRC a podobné srandy pro zajištění přenosu skrze LPT - asi předpokládají že je na HW úrovni zajištěn kvalitní přenost (dokonalé sťínění proti vnějšímu rušení / omezená délka LPT kabelu / dostatečné odstínění respektive dostatečné vzdálenosti a uspořdání jednotlivých žil uvnitř LPT kabelu, impedanční přizpůsobení veení pro potlačení odrazů atd)