Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Wolf 27. 09. 2017, 09:09:02
-
Ahoj
Začínál jsem na 8 bitových x51 a AVR8, pak jsem přešel k Armovským STM32 a SoC na hradlových polích.
Vyzkoušel jsem několik vývojových prostředí od "staromodního" shell + lepší notepad + Makefile po různé lehčí IDE (Codeblocks a jeho forky) až po mastodontní odnože Eclipsu.
V práci momentálně jedeme na forku Eclipsu pro C/C++ a není to ono. Je to prostě nenažraný bloatware, kde s každou aktualizací se podělá konfigurace pluginů nutných pro embedded vývoj, věčně blbne analýza kódu s indexerem atd.
Budu mít teď čas na vyzkoušení potenciálních alternativ, tak bych poprosil zkušenější programátory o doporučení, co bych měl vyzkoušet. Co takový Sublime text, různé forky Atomu?
Jde mi o
-snadnou integraci programátoru cílové platformy, debuggeru, deassembleru, vidět stack a registry...
-taková ta klasika jako code completion, indexování v projektu...
-nějaká interpretace výstupu buildu z externího toolchainu (Codeblocks a Eclipse tohle umí)
-nějaká integrace nebo pluginy pro GIT/SVN jsou plus
-
Ještě jsi zapoměl napsat, že to musí být zdarama a běžet pod Linuxem.
Problém je, že zdarma to optimalizovat nikdo nebude. Komerční IDE existují.
Eclipse je otesánek, ale je zdarma a jsou pro něj pluginy.
Já používám TortoiseSVN samostatně, kompilátory z commandline, debugger z commandline, a Notepad++ s pluginem NppExec, kterým občas pouštím kompilátor.
-
Jde mi o
-snadnou integraci programátoru cílové platformy, debuggeru, deassembleru, vidět stack a registry...
-taková ta klasika jako code completion, indexování v projektu...
-nějaká interpretace výstupu buildu z externího toolchainu (Codeblocks a Eclipse tohle umí)
-nějaká integrace nebo pluginy pro GIT/SVN jsou plus
Tohle můžete řešit do nekonečna. Prostě si zvolte co vám vyhovuje a naučte se jak daný toolchain funguje. Pak si můžete pro projekt napsat ručně relativně jednoduchý makefile, který vám to bude celé řídit a na všechny ty divné pluginy se můžete vykašlat a přejít na jiné IDE je sranda. Já osobně používám kdevelop, asi bych ho uměl nastavit i pro debug ARM přímo v IDE, ale už jsem to léta nepoužil, raději si pustím gdb z příkazové řádky. Berte to tak, že gdb použijete jen když máte problém, a přidávat si tam další integrací do IDE moc nepomůže. Pomocí gdb si odladíte vrstvu, která přímo leze na hardware, vrstvy nad tím jsem se naučil ladit spíš tak, že si udělám nativní aplikaci s tímto kusem kódu a používám ladící výpisy. Při dodržování určité disciplíny to pak přeložíte pomocí stejného gcc / clang (cross) pro cílovou platformu a chová se to stejně. Většinou je tahle metoda efektivnější než se s tím párat přímo v cílovém zařízení, hlavně pokud je to složitější. Prostě pokud nevíte, jak to uvnitř funguje, pak vám sebelepší IDE nepomůže, když narazíte na nějakou vypečenou chybu. A že se jich tam může vyskytnout mnoho je dáno už tím, že je to celé dost složité. Ze zkušenosti můžu říct, že se pak jen člověk diví, jak takovou pitomost mohl přehlédnout. A přitom to můžete hledat několik hodin. On vám to třeba někdo do toho IDE nastaví, jemu to chodí, tak co. Ale nastavil to podle svého způsobu uvažování a vy pak použijete nějakou vychytávku se kterou on nepočítal a jste vedle. Pokud toochain znáte, poradíte si s tím, pokud ne, můžete si v lepším případě dopisovat s autorem, v horším to zabalit.
-
Když to vezmu kolem a kolem, tak GDB + GCC + make je základ. Řeší se jenom to, co je nad tím. Stylem co komu vyhovuje.
Za sebe, Eclipse. Sice někdy opruz, ale navigace v kódu a ve výpisech je luxusní, pluginy pro všechno,... A podpora makefile projektů.
A z druhýho konce IAR EW. Kompilátor OK, ale za to IDE a za dokumentaci bych dal vývojářům takovou facku, že by se týden točili na židlích.
-
vscode + ms c++plugin (je tam intellisense) + tasky co len spustaju externy build system + gdb je integrovane, aj remote sa da pripojit.
-
Na debugger šahám taky jenom v nejnutnějších případech jinak aplikaci ladím přes systém logování chyb, warningů nebo info zpráv. Ale zrovna když jsem zkoušel gdb pro GCCčko, tak mi to konzolové ovládání přišlo neskutečně ubíjející oproti klikačkám v IDE, kde jsem hnedl viděl naklikané sledované proměnné, oblasti paměti, registry...
V kompilování ale zas upřednostňuju vlastní Makefile než nějaký vygenerovaný paskvil, ale to jsou věci, které se jednou napíšou a jedeš a pak mírně upravují.
-
Pro pripad, ze mas Mac (jak ostatne kazdy druhy na rootu) tak:
- navod jak nastavit kompilator a debuger https://www.davidyamnitsky.com/blog/2013/11/14/stm32-mac/
Atom editor ma par pluginu
- treba pro STlink https://atom.io/packages/stlink
- podpora ARM assembleru https://atom.io/packages/language-armasm
- prepojeni na GDB https://atom.io/packages/dbg-arm-none-eabi-gdb
-
Jo jeste jsem zapomnel https://atom.io/packages/platformio-ide . podporuje:
Atmel AVR & SAM, Espressif 8266 & 32, Freescale Kinetis, Intel ARC32, Lattice iCE40, Maxim Integrated MAX32, Microchip PIC32, Nordic nRF51 & nRF52, NXP LPC, Silicon Labs EFM32, ST STM32, TI MSP430 & Tiva, WIZNet W7500, Teensy, Arduino, ARM mbed, libOpenCM3, ESP8266, etc.
-
Ak IDE pre ARM, tak:
http://www.rowley.co.uk/arm/index.htm
Windows, Linux aj MAC.
Ale nie je zadarmo.
-
Divím se, že tu nikdo nezmínil EmBitz (dříve EmBlock). Nějakou chvíli už není zadarmo, ale 49€/rok není tak hrozné na to, kolik toho umí. Lepší je už jen šíleně drahý ARM Keil (který je tedy zadarmo pro celou řadu F0 a L0).
-
Embitz jsem právě používal než ho právě autor zpoplatnil. Keil zas není rozšířitelnej jako forky Atomu, codeblocksu, eclipsu....
-
Vcelku běžná věc, že něco na postavené nad Eclipse nebude fungovat. Svého času existovala i stranka IHateEclipse.com
Ten soft je strasny a jen by mi nekde rekli, ze v tom delaji, nesel bych tam pracovat. Cas od casu se najde clovek s poruchou z autistickeho spektra, ktery neda na Eclipse dopustit. Uz jsem slysel i o takovemto exemplari navic strizenem s psychopatem.
Co CLion? Multiplatformni nebot je v udelan v Jave, pohodli srovnatelne s IntelliJ, cesky produkt, velice kvalitní IDE. Jako bonus je komercni - beru to jako plus. Delal jsem v tom jen na zkousku, nejsem Ceckar.
-
http://platformio.org
-
Vim
-
Vim
Nechtěl jsem zbytečně provokovat, ale také Vim.
-
Vim
Nechtěl jsem zbytečně provokovat, ale také Vim.
Autor threadu nikde nenapsal, že trpí poruchou osobnosti tak proč mu to nabízíte ?
-
Vim
Nechtěl jsem zbytečně provokovat, ale také Vim.
Autor threadu nikde nenapsal, že trpí poruchou osobnosti tak proč mu to nabízíte ?
Jako vývojové prostředí je Vim mnohem lepší, než co navrhuješ ty.
-
Ve Vimu jsem dělal vývoj na STM32 a šlo to. Obecně Vim je velmi dobrý na programování v C. Chce to ale strávit nad tím chvíli času, najít si pár pluginů apod. Jak to člověk dostane do krve, je práce s Vimem velice rychlá, člověk už ani nepřemýšlí a ruce píšou příkazy automaticky (prostě muscle memory), přirovnal bych to ke hře na klavír. Chce to ale doplnit správcem oken, který lze ovládat čistě přes klávesnici, aby člověk nemusel vůbec sahat na myš.
-
Vimovský editování klidně přes nějaký emulátor/plugin do vybranýho editoru, ale samotný vim radši ne :D
-
Ve Vimu ... Chce to ale doplnit správcem oken, který lze ovládat čistě přes klávesnici, aby člověk nemusel vůbec sahat na myš.
Ten správce oken (resp. tabů) ve Vimu je, ovládá se čistě přes klávesnici.
Raději si na téma Vim založíme nové vlákno, ať to tady neplevelíme.
-
Ve Vimu ... Chce to ale doplnit správcem oken, který lze ovládat čistě přes klávesnici, aby člověk nemusel vůbec sahat na myš.
Ten správce oken (resp. tabů) ve Vimu je, ovládá se čistě přes klávesnici.
Raději si na téma Vim založíme nové vlákno, ať to tady neplevelíme.
To ano, ale já měl na mysli spíš situaci kdy mám několik terminálů (např. s výpisem komunikace přes CAN, RS232 apod.) popř. další aplikace.
-
Vimovský editování klidně přes nějaký emulátor/plugin do vybranýho editoru, ale samotný vim radši ne :D
Tohle se mi nikdy moc neosvědčilo, protože to ovládání nebylo naimplementované celé, jen základní věci.
-
..., ale já měl na mysli spíš situaci kdy mám několik terminálů (např. s výpisem komunikace přes CAN, RS232 apod.) popř. další aplikace.
Vyzkoušej si GNU Screen, na tohle se bude docela dobře hodit.
-
..., ale já měl na mysli spíš situaci kdy mám několik terminálů (např. s výpisem komunikace přes CAN, RS232 apod.) popř. další aplikace.
Vyzkoušej si GNU Screen, na tohle se bude docela dobře hodit.
Případně terminál jako Tilix :)
-
..., ale já měl na mysli spíš situaci kdy mám několik terminálů (např. s výpisem komunikace přes CAN, RS232 apod.) popř. další aplikace.
Vyzkoušej si GNU Screen, na tohle se bude docela dobře hodit.
Znám tmux, myslím že vychází z GNU screen. Můj WM (i3) ale zvládá podobné funkce, takže to tolik nevyužiju. Navíc nejsem omezen pouze terminálovými aplikacemi.
-
Co CLion? Multiplatformni nebot je v udelan v Jave, pohodli srovnatelne s IntelliJ, cesky produkt, velice kvalitní IDE. Jako bonus je komercni - beru to jako plus. Delal jsem v tom jen na zkousku, nejsem Ceckar.
Nějaký komerční software také používám, ale proč by to mělo být plus? Český produkt to není. Pokud vím, tak tu mají jen sídlo firmy. Žádný vývoj tu nedělají.
"Delal jsem v tom jen na zkousku, nejsem Ceckar." - to je dobré vědět. Raději si nechám poradit od někoho jiného.
-
Začínám se přiklánět ke kombinaci Sublime Text a externího GUI debugger.
https://www.segger.com/products/development-tools/ozone-j-link-debugger/
Akorát je třeba mít J-Link - pro softprocesory/SoC v FPGAčkách budu stejně muset spouštět tooly výrobce.