MESA karty a vlastní firmware

[CZ_Pascal]

Takže tohle by hladce zvládal můj oblíbenec STM32F103, deska s procesorem na eBay už za nějaké 3 USD. Pak jsou možnosti rozšiřování I/O téměř nekonečné a za málo peněz.

Ahojky. Prozradíš prosím jaké používáš vývojové prostředí pro STM obvody ?
Když jsem před několika (no už asi víc jak 8-mi) lety hledal nějaký rozumný "free" prostředí tak jsem skončil na YAGARTO + Eclipse a bylo to víc laborování jak vlastní programování pro MCU. Věčně neco fungovalo jen tak napůl a na několikátý pokus o rozchození z mnoha popisů co a jak by mělo fungovat (kdyby to ovšem fungovalo).
Snad se situace trochu ustabilizovala ? Nebo je to pořád o tom laborování ?

Tohle se mi líbí na Atmelech, kteří mají Atmel Studio které prostě funguje (až na sem tam pár Bugů, které se nevyhnou žádnému "rostoucímu" SW, a které mi nikdy nijako neznesnadňovali programování)

Předem dík za info.

Jinak těch 2,5Mbps na hraně zvládne i AVRko na 20MHz (otázka je jestli by dávalo i to zpracování těch přijatých dat + odesílání, ale myslím že by mohlo)

[yaqwsx]

Otázka nebyla na mě, ale už rok používám plugin VisualGDB do Visual Studia nejen pro programování STM, ale pro programování linuxových věcí pod Windows. Funguje v tom velmi komfortně nastavení toolchainu i debugging přes ST-Link - na stránkách mají ukázky použití. Nemůžu si ho vynachválit a už dlouho jsem nenarazil na tak praktickou věc, která by mi ušetřila tolik práce a času. Bohužel není zadarmo, ale investice do jeho nákupu se skutečně vyplatila.

[robokop]

dobre vedet
nejsem tazatel ale asi taky vyuziju

[yaqwsx]

A ještě k STM32 - můžu vřele doporučit knihovnu STM32Plus (https://github.com/andysworkshop/stm32plus" onclick="window.open(this.href);return false;). Je pěkně napsaná, dobře zdokumentovaná a umožňuje se abstrahovat od jakéhokoliv nastavování registrů nebo zdlouhavého čtení datasheetu.

[Mex]

Ahojky. Prozradíš prosím jaké používáš vývojové prostředí pro STM obvody ?

Ahoj.
Nepoužívám žádné integrované prostředí. Popravdě řečeno všechna ta barevná a blejskavá IDE, která mají "usnadňovat práci" poměrně silně z hloubi duše nenávidím.
Takže používám oblíbený editor, pro překlad toolchain z https://launchpad.net/gcc-arm-embedded" onclick="window.open(this.href);return false;. A samozřejmě dobře napsaný Makefile.
Pro programování a ladění buď OpenOCD a levné ST-link programátory z eBay (cena kolem 3-4 USD), ale v poslední době jsem se zamiloval do BlackMagic probe, ten už nepotřebuje to OpenOCD, ale komunikuje se s tím už jenom přes sériový port. Mimochodem ty levné ST-linky se daji předělat na ten BlackMagic probe. Všechny nástroje jsou zdarma a open-source, všechny existují ve verzi Windows i Linux. Já většinou jedu pod Linuxem, ale třeba na cestách to používám pod Windows, protože na noťasu mám jenom Widle.

Mám rád rychlé nástroje. Ladím prakticky zásadně v RAM a ne ve Flash. Mám snahu vždy dostat jedno kolo pokusu do max. 10 sekund (v praxi to vychází většinou tak kolem 5 sec). Tedy překlad, spuštění debuggeru, naprogramování do jednochipu a spuštení aplikace v tom jednochipu, ukončení debuggeru.

Snažím se prakticky vůbec nepoužívat knihovny, resp. používám jen ty, které si sám napíšu. Je to podobné jako u těch přechytralých IDE - vadí mi, že většinu času bych pak strávil zkoumáním, jak to vlastně má fungovat. Místo toho si raději pořádně nastuduju datasheet a napíšu si to sám.
Takže jsem pravý opak celkem častého úkazu na různých fórech, s dotazy typu "... jaké IDE a jakou knihovnu mám použít na rozblikání žluté LED na Arduinu, všude nacházím jen návody na rozblikání červené LED ..."

Protože dělám pro různé zákazníky, a někdy si zákazník nadiktuje v čem to chce mít, tak se občas různým IDE bohužel nevyhnu. Naposled jsem trávil (zabíjel) čas s TIA portálem od Siemense, a s jejich úžasným programovacím jazykem SCL pro jejich PLCcéčka.
Mně se pak o tom i zdálo, a budil jsem se celý zpocený. Za ten prodrbaný čas, strávený zjišťováním jak udělat i docela triviální věci bych to už dávno měl vyvinuté třeba na tom STM32 úplně od základů. A ještě by to měli za zlomek ceny (výrobky Siemens jsou všechno, jen ne levné), a já bych neměl nervy v háji.

Jinak těch 2,5Mbps na hraně zvládne i AVRko na 20MHz (otázka je jestli by dávalo i to zpracování těch přijatých dat + odesílání, ale myslím že by mohlo)

No to už by byl slušný hard-core, jet na téhle rychlosti s AVR. Já jsem dřív byl taky zastáncem cpát všude AVR, ale když se dneska dá koupit STM32 už za nějakého 0.5 USD (nějaké základní STM32F0) nebo 1.5 USD (slušně vybavené STM32F1 na 72 MHz), tak už naopak celkem všude cpu ty STM32.
Přece jen za tyhle srandovní prachy dostaneš mnohem víc RAM, mnohem vyšší výkon a výrazně výkonnější periferie.

[CZ_Pascal]

Děkuji oběma za rady/odpovědi.

Já se nacházím tak nějak na půl. Taky nemám rád všechny ty rádoby univerzální knohovny které jsou skrze svou univerzálnost tak zašmodrchané a zabalené do všech možnách #Ifdef a prolinkované do 80-ti souborů abych získal banální blbost. Výsledkem je že pak někde chybí jediné blbé zadefinování nějaké konstanty a překladač vyhodí dve stránky chybových hlášek na úplně jiných místech něž kde k chybě došlo.

Taky si raději napíšu knihovnu vlastní s datasheetem v ruce, ale když je dobře napsaná jednoduchá a přímočará knihovna, kde pro projití zdrojáků a datasheetu vidím že bych to psal obdobně tak takové se naopak vůbec nebráním. Ne vždy je výhodné vynalézat kolo. Jen je potřeba najít to správné kolo a ne to nabalené do blata a všeho možného svinstva. Ano velká část je právě takových. Kolikrát je nastudování knihovny složitější než nastudování vlastního HW a napsání vlastního kódu....

Nadruhou stranu kvalitní IDE které funguje jak má je myslím velký pomocník a výhoda, pokud člověk není zvyklý hrabat se pouze s příkazovým řádkem.
Zvýraznění syntaxe a automatické doplňování nadefinovaných projměnných. Odskoky na místa volaných funkcí abych nehledal kde je její implmentace když pozapomenu jake parametry a jakým způsobem potřebuje. Skomplování + nahrání do "švába" a spuštění ladění jediným kliknutím, kde přehledně vidím co se kde děje. Sromová struktura použitých souborů s vizualizací jejich závislostí. Automatické vytvoření Makefile, kde např jen skontoluju nějaký konkrétní parametr překladu pokud očekávám něco jinak než obvykle atd...

Je potřeba si vybrat z každého to lepší a co komu vyhovuje.

[Mex]

Ještě krátce k tématu používání cizích knihoven nebo studium datasheetu: obě metody stojí úsilí. Buď to úsilí vrhnu do studia daného procesoru, nebo do studia toho, jak autor knihovny pojal problém. Razím zásadu, že z každé práce by mělo něco zbýt. Nemyslím peníze, ale každou prací bych se měl něco nového naučit, v něčem se obohatit. Naštěstí nedělám někde u pásu, kde by to asi nešlo, ale naopak mám přebytek nabídek, takže si můžu vybírat práci, která mi přináší nové informace a podněty.
No a přijde mi hodnotnější se raději naučit něco nového o tom procesoru, než o tom, jak někdo splácal nějakou knihovnu. Jistě už jsem taky narazil na kusy SW, kde jsem čuměl jak jsou napsané, a kde jsem se mimoděk autorovi poklonil. Ale moc jich není.

K použití IDE: zkoušel jsem jich spoustu, ale nic mi nepadlo do ruky tak, abych si řekl, že to stojí zato.
Zvýraznění syntaxe dneska umí snad každý lepší editor. Ale třeba doplňování jmen proměnných nebo nabídka parametru funkcí mi zatím nikdy nepřišla tak dobře udělaná, abych měl pocit, že mi to skutečně pomáhá. Když něco píšu, tak mám stejně problém v hlavě, takže to ani nepotřebuju. A navíc je to tak trochu brzda proti blbosti - snažím se navrhovat jména proměnných a strukturu volání procedur tak, aby byla logická, takže je pak snadno sázím z hlavy.
Ale nejsem nějak principiálně zabejčenej. Vždycky čas od času mě popadne touha zkusit prozkoumat, jestli by nějaké to IDE přece jen nebylo přinosem. Ale zatím jsem se vždy zase pokorně vrátil k osvědčenému editoru.

K psaní Makefile: určitě nikdy napoužiju žádný automaticky vygenerovaný. Proč taky? Třeba pro práci s ARMy jsem si s tím pohrál a napsal jsem si celkem vymazlený Makefile, takže pro všechny projekty používám jen ten jediný. Takže vytvoření nového "projektu" znamená vytvořit jen prázdný adresář se jménem projektu a nakopírovat (na Linuxu jen nalinkovat) tam tento standardní Makefile. A to je vše.

Jak správně píšeš, každý si vybere to, co mu vyhovuje. Třeba k nějaké automatizaci taky někdy dospěju, ale zatím jsem IDE svého srdce nenašel.

[robokop]

tak ty IDEcka jsou fajn kdyz to potrebujes pro jeden ucel a pak zas dlouho ne
je to nazorne a doplnuje to

ale pro castou praci je lepsi vlastni hlava

stejne jako windows linux
windows primarne klikaci ale pro zacatecnika dobrej OS
profik casto presedla na linux

linux primarne commandline, hodne si musis pamatovat
pro zacatek tezkej ale profik v nem udela celou operaci rychleji jednim prikazem a driv nez bys v exploreru nasel pozadovany soubor
kdyz ale neco delas prvne musis daleko vic studovat a hledat nez ve windows

[fupe]

Díky za zajímavé vlákno. Nemáš odhad, kolik se toho vejde do 5i25? Jsem do ní schopen nacpat 6 × enkodér + 6 × PWM pro servo + 3 stepgeny?

Záleží jaky použiješ rozšiřující karty. Když tam dáš 7i77 a 7i76 tak je to hotovy. Jestli to chceš použít bez dalších karet, tak se to tam taky vejde, ale nevim jestli to dava smyl.
Zkus to trochu rozvest.
M

[yaqwsx]

Zkouším si teď hrát s vlastním firmwarem pro Mesu 5i24/6i24. Konkrétně chci vytvořit firmware, který bude mít 1 enkodér, 1 PWM, 5 stepgenů a zbytek budou GPIO. Zkompilovat předpřipravené firmwary se mi povedlo snadno, a tak jsem vytvořil vlastní PIN_*.vhdl soubor a zkompiloval nový firmware. Všechno proběhlo v pořádku a PnCConf firmware uviděl, ukázal korektní layout. Jenže když jsem se pokusil vygenerovanou konfiguraci spustit, dostal jsem chybu HALu - konkrétně některé piny nešly nastavit jako výstupy. Z logu bylo vidět, že Mesa karta má ale jiný pinout, než jsem specifikoval - jednak jsou konektory 4 a 2 prohozené, zároveň jsou mezi piny nastrkané IO porty, které tam vůbec být nemají. Správně má být: encA, encB, encI, pwmO1, pwmO2, pwm3 a zbytek konektoru GPIO, následně na dalším konektoru mají být 2 piny stepgenu následované 2 GPIO, ale to se také neděje.

Co bych mohl dělat špatně? Nesetkali jste s podobným problémem? Níže přikládám můj PIN soubor a log skutečného pinoutu:
PIN soubor: http://pastebin.com/93axsrXV" onclick="window.open(this.href);return false;
Skutečný pinout: http://pastebin.com/jkhSt3t6" onclick="window.open(this.href);return false;

[RaS]

ono ten pnconfig není žádná výhra.. já se mu uplně vyhejbám a píšu všechno ručně.. pak ti je jedno co kde je .. nějaká základní konfigurace v tom pnconfigu lze ale nějaké speciálky na to to prostě není..

[yaqwsx]

V PnCConfu problém není - ten funguje správně. Problém je v tom, že nesedí *.PIN soubor s tím, co reportuje karta zpátky. O ruční psaní mi nejde - ale mám už nachystané konektory na konkrétní pinout.

[CZ_Pascal]

Problém je v tom, že nesedí *.PIN soubor s tím, co reportuje karta zpátky.

No on ten *.PIN soubor pro nic snad ani užitečnej není (respektive nevím co na něm závisí).
To je snad už jen nějaký přehled pro člověka ? (shrnutí v čitelnější podobě)

Důležitý je ten PIN_SVST1_5_72.VHD podle kterého probíhá "překlad" toho firmware. (v XILINX ISE Studiu)
- výsledkem "překladu" je soubor SVST1_5_72.BIT který se jakžto firmware nahrává do FPGA obvodu.
Toto by si měl číst i driver hostmot2 z IDROM obsaženém ve firmware (v FPGA) na základě kterého pak "tvoří/mapuje" jednotlivé HAL-piny.
(soubor PIN_SVST1_5_72.VHD je "mapován" do určité části struktury IDROM)

Co jsem tak koukal na ten tvůj PIN_SVST1_5_72.VHD tak jsem tam nenarazil na nějakou chybu, ale popravdě řečeno jsem si ještě nenašel čas abych si s tím pohrál nějako reálně. Spíše jsem vždy spíše jen tak okukoval jak to tam funguje, abych (až nadejde ta "svatá chvíle" a dostanu se k tomu) věděl co kde hledat a upravovat.

Spíše mě hodně překvapuje že funguje ten PnCConf
(respektive vidíš v něm porty/piny tak jak jsi je definoval v tom xxxxx.VHD souboru )
Dívalses odkud PnCConf bere údaje o tom jak je karta nakonfigurovaná ?
- pokud totiž funguje (jak tvrdíš), tak už by ve chvíli kdy provádí konfiguraci musela probíhat komunikace (což neříkám že by nemohla, ale zdá se mi že to bychom po tom PnCConf chtěli už trochu moc ?)

[packa]

ano když spustíšpncconf tak už komunikuje s kartou bez komunikace s ní tě dál nepustí

[yaqwsx]

CZ_Pascal: *.PIN je užitečný skutečně jenom pro člověka. PnCConf funguje na základě *.XML souboru. Oba dva soubory jsou mezi sebou konzistentní a jsou vygenerované originálním build procesem. Problém je v tom, že očividně samotný firmware (*.BIT) soubor obsahuje jiné mapování pinů, jelikož jej karta po nahraní reportuje zpět. A je mi záhadou, jak se to může stát.