ARM MCU gnu toolchain, getting started?

Elektronika, Elektromos eszközök

Sziasztok!

Tudtok jo leirast a fentebbi temakorben? Probalnank kicsit tovabblepni (teljesitmenyben) az AVR vonalrol igy mikrokontrollerek teruleten, es adja magat, hogy ARM-mel probalkozzunk. Pl ezzel: MK20DX256VLH7.

No, erre a feladatra keresnek egy jo kis getting-started jellegu leirast. Ugy latom, hogy az emdebian jo lenne, van vegigjatszas, bar ezutobbit azert meg nem sikerult teljesen abszolvalni (unmet dependencies, ilyesmik miatt). Ettol fuggetlenul ugy latom, hogy a szukseges csomagok (binutils-arm-linux-gnueabi, gcc-4.8-arm-linux-gnueabi, libc6-dev-armel-cross) ott vannak, amik az AVR-es megfelelo tooloknak (binutils-avr, gcc-avr, avr-libc) a parjai.

A netes keresgelest megneziti, hogy sok/legtobb talalat az ARM achitekturaju linux illetve azon futo programok (cross) compile-arol szol (mintha pl RPi-re fejlesztenenk). Itt azonban linuxos fejlesztokornyezet kellene ARM MCU target-hez. MCU, azaz ~128k-256k flash, 32-64k SRAM, GPIO-ok, UART/SPI/I2C/USB/CAN stb periferiak kezelese, nativ RT, stb.

Elore is koszonet minden otletert!

A

  • 12556 megtekintés

( sza2king v | 2014. 10. 23., cs – 16:23 )

A Silabs Gecko termekcsaladjahoz ( http://www.silabs.com/products/mcu/Pages/32-bit-microcontrollers.aspx ) Linux-os (meg persze Win / Mac) eclipse alapu fejlesztoi kornyezet van. Installalasa kb. next -> next -> finish jellegu, teljes erteku IDE / debug kornyezet, free of charge. Alapvetoen GCC-t tesz fel, de Keil, IAR is tamogatott.

A csalad eleg sok tagu, szeles palettabol lehet valogatni labszam, periferiak, Flash es RAM kiepites tekinteteben. Cortex M0 (Zero Gecko) es M3 (Tiny, Leopard, etc.) magokkal. Minden fo tipushoz van demo kit (a Farnell kinalataban mind a kit-ek, mind maguk az MCU-k megtalalhatok).

Minden MCU rendelkezik soros (vagy a nagyobban eseten soros es USB) bootloaderrel (csak letoltes, debug-ot nem tud), igy nem feltetlen kell programozot venni hozza (a demo kit-eken rajta van a programozo / debugger, csak egy USB port kell, arrol kap tapot is, illetve azon keresztul debug-olhato / programozhato).

2015Q1-ben ezek az IC-k subGHz radiokkal egybeepitve is jonnek.

Nem utolso szempont (de ez nem hivatalos:-), magyar nyelvu support is lehetseges.

Ha jol ertettem a kerdesed, es ilyen dolgokra gondoltal.

/sza2

Szerk: Ja, kicsit eltevedtem, atsiklottam afelett, hogy kifejezetten leirast keresel, nem magat az eszkozt. Mondjuk az IDE letoltheto es a dokumentacioban eleg sokminden van ami valamennyire altalanos a Cortex MCU-kat tekintve.

Én geany alá lőttem be, csináltam egy-két egyszerű makefájlt és fordulgat.
Viszont nagyon macerás ezeket a toolchaineket akár sourcery akár az armos gcc átültetni a disztród saját build rendszerére, és még nem sikerült használhatót gyártanom. Szóval ha nem 32-bites win32 vagy linux a target akkor szopó van. :S

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

"Viszont nagyon macerás ezeket a toolchaineket akár sourcery akár az armos gcc átültetni a disztród saját build rendszerére, és még nem sikerült használhatót gyártanom."

A Sourcery-vel nem is tudsz mit kezdeni, mert nem adják ki a fordító forrását. Tehát vagy fut úgy ahogy van, vagy nem. A gcc-arm-none-eabi-4_8-2014q3-20140805-src.tar.bz2 fordításával pedig nem kísérleteztem mert jól működik. Egyszerűen kibontottam a gcc-arm-none-eabi-4_8-2014q3-20140805-linux.tar.bz2 tömörítvényt a HOME könyvtáramba és onnan hívom.

Egyébként a leírás alapján nem sikerült lefordítanod?

Fordítottam, de igazándiból a disztró integrális részeként akartam megvalósítani... gyk csomagot..
Egyébként a sourcery forrása itt van: http://sourcery.mentor.com/public/gnu_toolchain/arm-none-eabi/arm-2014…

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

Nyilvan a forditas soran elhasznalt gepkapacitasert es emberi eroforrasert cserebe viszonzast varnak. Peldaul egy email cimet, amire hirlevelezhetnek. Egy GCC toolchain egy jobb gepen is olyan fel ora magassagaban fordul.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Koszi szepen igy utolag/megkesve is! Forditotnak ez lett a nyero", ez a gcc-arm-embedded (azon belul is a `arm-none-eabi-gcc`). Ez a toolchain ma'r tud olyan *.ihex-et gyartani amit egy ST-LINK/v2-vel fel tudtam to"lteni (openocd segitsegevel) egy STM32F4-discovery board-ra. Es szepen mukodik, villog a led pont ugy ahogy kell ;)

Ma'rcsak tenyleg ezeket a periferialis konyvtarakat kellene jobban atnezni. Az ST altal adott konyvtar jooo nagy, igy elsore inkabb nativan probaltam valamit osszerakni a referenciadoksi alapjan... de hosszutavon ez biztos nem olyan effektiv, foleg ha vmi komolyabb kellene (USB, Eth, ...)

Szívesen. :-)

"Az ST altal adott konyvtar jooo nagy, igy elsore inkabb nativan probaltam valamit osszerakni"

Érdemes lenne megnézned a libopencm3-at amit fentebb a figyelmedbe ajánlottam. Vannak hozzá példák is: https://github.com/libopencm3/libopencm3-examples
Én STM32F101CB-re fejlesztettem vele. A kezdetén el voltam vele mint a befőtt, mivel semmi segítségem sem volt. (Mástól vettem át a fejlesztést, de semmit sem tudtam arról hogy mit és hogyan csinált az illető, ha egyáltalán csinált valamit.) A program betöltésével is gondjaim akadtak, de végül az stm32flash lett a nyerő miután kijavítottam két hibáját:
1.) Képtelen volt kapcsolatot teremteni az MCU-ban ücsörgő boot-betöltővel.
2.) A lyukas (nem címfolytonos) hex-et rossz helyre töltötte be. A kihagyás méretét rosszul kezelte és emiatt a "lyuk" utáni részt rossz helyre került. (Emlékeim szerint a program egy értéket char típusú változóban kezelt int helyett.) A bin állománnyal nem volt ilyen gond mivel abban a "lyuk" is benne van.

Mindez kb. egy éve történt, nem tudom hogy azóta az eredeti forrásban kijavították-e a hibákat.

Koszi szepen, igen, kozben megneztem ezt a libopencm3-at is, leforditottam, ezzel minden oke. Megprobalok ezalapjan osszerakni majd egy relative egyszeru periferialis tesztet (sima ledvillogtatas, mondjuk PLL-szabalyzott belso oraval, egyelore dev-boardon), aztan meglatjuk.

Nalunk most az a szerencse hogy nem meglevo fejleszteseket kell atvenni/folytatni hanem nullarol kezdenenk egy-ket kisebb projektet. Ezeket mar prototipizalas szintjen AVR-alapokon osszeraktuk, szepen mukodik, csak teljesitmenyben nem epp' a legjobb.

A "netes keresgetessel" az a nehezites hogy nagyon sok olyan peldat talalni (vagyis a kereso" leginkabb olyan peldakat dob fel) amik kimondottan dev-boardokra keszultek, dev-boardokra (is) osszeallitott lib-ek alapjan. Viszont ha magunk csinaljuk a teljes fejlesztest (elektronikat, kapcs rajzot, nya'kot, mindent) akkor ez nem feltetlenul lehet jo kiindulasnak... vagyis kiindulasnak jo lehet, persze, de csak annak.

Ez a libopencm3 tenyleg jonak nez ki, megnezzuk. koszi meg1x!

"PLL-szabalyzott belso oraval"

Előfordulhat hogy neked egyik órajel beállító eljárás sem lesz igazán jó: Nem jó a választható órajel frekvencia és/vagy az alapul szolgáló kvarc nem stimmel. Ilyenkor saját eljárást kell írni, ehhez persze alaposan át kell tanulmányozni az MCU ide vonatkozó részeinek leírását. (Az induláskor sokat vadásztam fórum bejegyzésekre.) Később a lebegőpontos emulációval volt bajom (néha egy-egy osztáskor egyszerűen megfagyott az alkalmazás), de ez nem a periféria könyvtárhoz tartozik, hanem a gcc része. Az az MCU amit használnom kellett - mert a készüléket ezzel építették - elég gyöngécske és nincs benne FPU. Ráadásul csak soros porton tudtam kommunikálni a procival. Írtam egy kivétel kezelőt és ezzel tudtam kinyomozni hogy kb. mi baja lehet. Végül át kellett térnem egész számok használatára.

( hrgy84 | 2014. 11. 18., k – 09:52 )

IDE-nek probald ki a NetBeans-t. A toolchaineknel tamogatja a cross-compilinget is, te adhatod meg az egyes cuccok utvonalat, az include-okat meg felveheted a projekt fuggeseibe.

Sajnos a CLion (a JetBrains C/C++ cucca) egyelore ugy nez ki, nem tamogat cross-compilinget.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

-1. Általában teljesen jól bele van integrálva minden.
Nem tudom, beágyazott fejlesztéssel mennyire foglalkozol (ha jól sejtem, nem területed), azért ott más a történet.
Nézz egy kicsit körül a gyártók által adott fejlesztőkörnyezetek között. Pár nagyobb:
CodeWarrior (FreeScale MCU) - Eclipse alapú
Xilinx SDK - Eclipse alapú
CooCox CoIDE - Eclipse alapú
TI Code composer - Eclipse alapú
ARM DS-5 - Eclipse alapú

Elhiszem, hogy egybe van integralva, de az Eclipse kezelese onmagaban horror. Nehez ra egy konnyen kezelheto IDE-t epiteni. Lattam mar par kore epitett IDE-t (nem embedded devicekhez), es nem igazan volt meggyozo. Szazszor inkabb egy kevesbe integralt NetBeans pluginekkel, mint egy Eclipse, mert utobbinak borzalmas a kezelhetosege.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Akarat kerdese az egesz, nem hiszem, hogy barmelyik tool csak Eclipse alatt lenne eletkepes, valoszinuleg portolhato mind.

Az Eclipse azert nepszeru most az integralt IDE-k fejlesztoi kozott, mert korabban lett elterjedt, mint a NetBeans. Azonban minden erdeme (ohm..., na mindegy, ezt ne feszegessuk...) mellett az Eclipse felett egyszeruen elrepult az ido vasfoga. Az, hogy van benne egy csomo jo tool, attol meg borzalmasan rossz IDE. Egy lyukas kartondoboz akkor is rossz szerszamoslada, ha amugy kiraly szerszamok vannak benne.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

"És az Eclipse amúgy nem csak IDE."

Hanem?

"csak mert a hupon valaki megszakértette, hogy az Eclipse rossz."

Nem (csak) en allitom, hogy rossz. Tobb fejleszto ismerosom van, akik korabban Eclipse-t hasznaltak, mind valtott valamire. De biztos csak rosszul tartottak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

> Hanem?

Művelődj:
http://en.wikipedia.org/wiki/VIATRA
http://scholar.google.hu/scholar?q=eclipse+model+framework

> Nem (csak) en allitom, hogy rossz. Tobb fejleszto ismerosom van, akik korabban Eclipse-t hasznaltak, mind valtott valamire. De biztos csak rosszul tartottak.

Ízlés. Neked nem tetszik. De a főbb embedded gyártók közül sokan mégis erre építik a környezetüket...

"De a főbb embedded gyártók közül sokan mégis erre építik a környezetüket..."

En itt kisse tyuk vs tojas effektust erzek. Valamikor valamelyik nepszerubb embedded gyarto erre kezdett el epitkezni (gondolom, mert ehhez volt tudas hazon belul), az Eclipse nepszeru lett az embedded hasznalok kozott, majd a tobbi gyarto emiatt szinten az Eclipse-t valasztotta. Ennek kb. semmi koze ahhoz, hogy az Eclipse jo vagy sem. Pont ezert nem lehet pl. azt mondani, hogy az Eclipse jo, mert lam, az Androidosok is milyen jol megvannak vele. Igen, mert sokaig semmi mas nem volt, amivel Androidra lehetett volna fejleszteni, az NBAndroid joval kesobb jott csak ki, ma meg mar a Google is valtott Eclipse-rol IntelliJ IDEA alapokra, mert sokkal epeszubb irany.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

+1

Én java programozáshoz napi szinten használok eclipse-t, arm és beágyazott linux-os munkákhoz viszont soha!
Mivel java EE és android alá is dolgozom, az ehhez szükséges plugin-ek is éppen eleggé terhelik, hát még ha cdt is lenne.
Ezért két verziót kellene tartani, mivel a cdt egész más plugin-eket igényel és így még lassabb lenne az indulás, valamint láttunk már olyant, hogy plugin-ek összeakadnak,
másrészt elképesztően bonyolult és bugyuta a cdt. Ezalatt az ezer dialóguson eresztüli kattogtatást értem, az egyszerű make szabályok helyett.
Semmi extra szolgáltatást nem ad, amit egy C-hez kitalált IDE nem adna (syntax highlight, code completion). A refactoring C-ben nem napi gyakorlat.

A magam részéről következetesen ragaszkodom a megszokott make alapú fejlesztői modellhez. A Code::Blocks kiválóan alkalmazható IDE gyanánt, hajlandó külső Makefile-t használni és a gdb is megoldott.

Amit leírtam az kizárólag Linux-ról szól, winfütyi-ről nincs tapasztalatom.

( cd334 v | 2014. 11. 18., k – 11:51 )

Szia!

Én arm-gcc-vel (https://launchpad.net/gcc-arm-embedded) és make file segítségével csináltam IDE és platform független toolchaint magamnak. Windows-on(XP, 7) és linuxon(Mint 13 és 17) is kiválóan lefut.

Ennek a saját toolchainak egy régi verziója kinn van az egyik nyilvános svn repomban:
https://subversion.assembla.com/svn/cd334_free_stm32_repo/trunk/

Igaz a fordító meg minden egy kicsit régi benne, de szerintem egy jó kiindulási alap. Ez az ST egyik olcsó dev. boardjához készült LED villogtató és UART echo.

Remélem tudtam segíteni!

cd334

( Foltos | 2014. 11. 19., sze – 16:05 )

Megemlítenék még 1-2 érdekes szoftver könyvtárat:

  • ChibiRTOS: Real-time oprendszer. Több ARM csipre is van portja, és az ütemezőn és szinkronizációs eszközökön túl (event, mutex, stb) rendelkezik periféria támogatással is (UART, I2C, SPI, stb...).
  • FreeRTOS
  • LwIP TCP/IP network stack
  • FatFs FAT filesystem

( apal v | 2014. 12. 30., k – 10:11 )

Sziasztok!

Kerdes roviden: tud-e valaki jo leirast a linkerek melyebb mukodeserol? Szegmetalasok, szegmenseken beluli elosztasa a blokkoknak, stb. A manual (`man ld`, arm-none-eabi-ld leirasa, stb) elegge szukszavu, es pont abbol indul ki hogy az ember a dolgok mukodeset nagyjabol erti.

A kerdes hosszabban, vagyis a hattere: egyelore ugy hasznalgatom a toolchaint hogy teljesen 0-rol van felepitve minden (sajat vektortabla, sajat _start-jellegu fuggveny, mindenfele kulso libc nelkul). Igy szepen is megy minden, egy esetet leszamitva. Ha van egy ilyesmi, hogy 


for ( i=0 ; i<32 ; i++ )
 {    ...
      buff[i]=0xAA;
      ...
 }

akkor ebbol a fordito csinal egy memset() hivast, kvazi ertelemszeruen. Viszont a linkelesnel nincs semmi kulso lib(c), igy a memset-et hianyolni fogja a linker. A naiv megoldas az lenne, hogy egy 


void *memset(void *s, int c, size_t n)
{
 uint8_t *dest=(uint8_t *)s;

 while ( 0<n )
  {     *dest=c;
        dest++;
        n--;
  }

 return(s);
}

implementaciot gyorsan beszurunk - de ez meg lefagyasztja az MCU-t. Kis debuggolas (arm-none-eabi-objdump, disasm) utan kiderult hogy ez meg egy onmagara mutato tail call recursion-t csinal a dologbol ;) ugy meg nyilvan lefagy.

Egy relative egyszeru megoldast sikerult talalni: a -fno-tree-loop-distribute-patterns kapcsolo az -O3 utan (helyett). Mukodik ugy is hogy a teljes forrasfat ezzel forditjuk, ill ugy is hogy csak egy memset.c modult.

Kerdes az, hogy van-e erre valalmi mas jellegu megoldas is? Elobb-utobb elokerulhet a memcpy, vagy extrem esetben a memmove is, aztan nem biztos hogy ez igy pont a leghatekonyabb... ill maga az alapproblema nyilvan nem ARM, azon belul is arm-none-eabi-gcc specifikus, hanem minden architekturan es leginkabb cross-compile eseten elokerulhet, beagyazott rendszereknel (ahol nincs global _start, vagy ilyesmi) ott hatvanyozottan. Es ezert is lenne erdekes tudni, hogy a linkele's mint folyamat az hogysmint van absztrahalva.

koszi, A

Alulrol ugatom az egeszet, de valamikor regen hallottam egy -nostdlib nevu kapcsolorol (lehet, hogy tobbes szam es -nostdlibs?), azt mar probaltad?

Illetve egy tipp: nezd meg, hogy a kernel build rendszere hogy mukodik, libc ott is viszonylag kevesse van.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Csak a -nostartfiles opcioval probalkoztam (vagyis a linkernek az kvazi kotelezo" ha nem a crt1-et akarnank hasznalni hanem sajat vektortablat). Most megneztem ezt az -nostdlib dolgot, de igy is tail recursion-t csinal: 


00000000 <memset>:
   0:   b510            push    {r4, lr}
   2:   4604            mov     r4, r0
   4:   b112            cbz     r2, c <memset+0xc>
   6:   b2c9            uxtb    r1, r1
   8:   f7ff fffe       bl      0 <memset>
   c:   4620            mov     r0, r4
   e:   bd10            pop     {r4, pc}

Valoban, igy fogalmaz a manual vagyis azt mondja a -nostdlib-nel hogy ``The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.''. Szoval a -nostdlib hatasara a fordito ugyan beleteszi ezeket a fuggvenyeket viszont linkelesnel nem a libc-bol probalja feloldatni hanem sajat implementaciot kell prezentalni.

Kozvetlen hivatkozas csak ennel a -ftree-loop-distribute-patterns opcional van arra, hogy memset(), memcpy(), ... hivasokra cserelheti ki a ciklusokat.

Koszi, igen, ugy nez ki hogy ez a -fno-builtin, megoldotta!

Neztem ezt is, de a manual azt allitja elso"re, hogy ez azt kapcsolja ki ha valaki mondjuk egy memset()-et direkt leir, akkor azt biz esetekben lecserelheti mas kodokra, pl inline assemblyre (extrem esetben pl egy memset(b1,&x,1)-et egy sima ertekadasra, ami azert olcsobb mint a fuggvenyhivas). Konkreten ezt irja: ``GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to "alloca" may become single instructions which adjust the stack directly, and calls to "memcpy" may become inline copy loops'' Szoval emiatt ezzel nem is probalkoztam elso"re.

De ennek ellenere ez "forditva" is mukodik, tehat kevesse optimalis megoldasok helyett alkalmazott builtin-fuggvenyhivasokat is letiltja.

( zamek | 2014. 12. 31., sze – 19:00 )

Debian es leszarmazottai ala tobb peldanyban is uzembiztosan sikerult beloni.
Itt talalod a leirast es van hozza egy script keszlet is.

http://vili.pmmf.hu/portal/hu/web/zamek/blog/-/blogs/chibios-fejlesztok…
http://vili.pmmf.hu/portal/hu/web/zamek/blog/-/blogs/chibios-fejlesztok…
http://vili.pmmf.hu/portal/hu/web/zamek/blog/-/blogs/chibios-fejlesztok…

Alapvetoen make alapu, de ide-nek code::blocks-t hasznalunk, mivel nem olyan nagy boszme mint az eclipse es tamogatja a make-kel forditast.

ChibiOS van alatta es mi Stm32F sorozattal hasznaljuk.

A CodeSourcery-re gondoltam.
A mingw azert nem egy teljes erteku csomag, eleg sok hianyzik belole. Pl. ha sima C-vel akarsz forditani, akkor a MINFLOAT, MAXFLOAT, MINDOUBLE, MAXDOUBLE, LDBL_MIN, LDBL_MAX.

Ha normalis make alapu kornyezetet akarsz C forditashoz, kenytelen leszel virtual linux, vagy cygwin alatt dolgozni, akkor meg kukasauto/rallyeverseny.