Beágyzott (embedded) ARM fejlesztés

Fejlesztés

Ki, milyen/melyik ARM platformon fejleszt, beágyazott alkalmazásokat?

Most épp úgy látom, hogy a kedvenc forrásomnál számtalan minimalista fejlesztő panel van az STM processzorokhoz. Viszont még nem látom a járulékos költségeket - fejlesztői környezet a szövegszerkesztőtől az égetésen át a speciális hiba kereső eszközökig.

OFF - háttér gondolatok:
Miközben vadul próbálom behozni a lemaradásomat a 8 bites AVR processzoros fejlesztésben (nekem úgy tűnik ezt támogatja a legjobban a Linux), nem hagy nyugodni a gondolat, hogy ez kicsit "lefutott" dolog. Az ARM processzorok a uralják a piac 70% -át (olvastam valahol). Az alkalmazásuk a szinte PLCC szintektől a kézi számítógépekig terjed. Szinte "bármi" megvalósítható vele.
A piacon rengeteg gyártó ajánl különféle kiépítettségű fejlesztő paneleket onnan, hogy rajta van egy ARM chip és néhány alap alkatrész (majdnem egy 40 lábú DIP tok méretű nyákon) odáig, hogy "kulcsra kész" SBC (Rashpberry, Beagle bone stb.).
Viszont a fejlesztéshez szükséges eszközök árában, a szoftver támogatásban már nem ilyen egyszerű a választás. JTAG/ISP égetők, "in-circuit" hibakereső megoldások. Használatra kész, lehetőleg nyílt forráskódú szoftver könyvtárak (pl. az AVR -ek esetében szinte általános periféria - UART, SPI, ADC, LCD stb.) kész, jól kitesztelt szoftverek vannak, nem a kódolással, hanem a kód megértésével kell/lehet foglalkozni
A "kulcsra kész" SBC -k esetében - pl. Raspberry GPU - számos dologba nem látunk bele. A GPIO és egyéb perifériák már le vannak foglalva, alig marad szabadon felhasználható pin - jöhetnek a különféle bővítők ADC és DAC, SPI vagy I2C eszközök - lassú és nehézkes a CPU 0,7-1 GHz sebességéhez képest.

  • 4700 megtekintés

( bbandi | 2015. 04. 17., p – 12:13 )

Sub.
Régebben gondolkoztam én is ezen, de egyszerűen nem volt rá energiám, hogy otthon is ugyan azt csináljam, mint munkában.
Az STM kicsit gyanús volt, lévén a legolcsóbb, mégse találkoztam vele nagyon csak boltban.
Akkor a TI tűnt legszimpatikusabbnak, van egy msp430-as launchpad-em, elvileg ugyan az a környezet kell az arm verziókhoz is (eclipse+gcc), gyártótól vagy forgalmazótól is fillérekért lehet venni.
Felmerült még az atmel, mert nagyszerű dokumentációt adnak, de nagyon drága.
Iparban nagyon szeretik használni a Freescale-t ahogy látom.
A leendő munkahelyemen pedig silabsot fogok használni.

A silabs emlékeim szerint nagyon jópofa, de a fejlesztők elég költségesek.
A TI cuccok nagyon jól dokumentáltnak tűnnek, de a fejlesztő környezet kicsit borsos.
Érdekes lehet még az NXP is - pont a napokban nézegettem vele egy "launchpad" szerűséget és Linux/windows fejlesztő csomagot is láttam hozzá - de akkor nem néztem utána milyen JTAG kell is hozzá.
(Sajnos így ez eléggé összetett kérdés és még az is lehetséges, hogy érdemes egy "nagyobb" beruházást meglépni, mint most egy ocó valamivel zsákutcába jutni)

* Én egy indián vagyok. Minden indián hazudik.

( zman | 2015. 04. 17., p – 13:16 )

Amit én eddig használtam:
- Freescale i.MX25 (ARM9 @ 400MHz), valami drága JTAG-ot használtam hozzá, de egy kollégám simán OpenOCD-vel használta. Fordító: GCC-EABI, ingyenes.
- Freescale Kinetis K20 család (Cortex M4), Code Warrior (ingyen), JTAG: J-Link EDU (~20k Ft)
- Texas F28M35 (Cortex M3 + DSP), Code Composer Studio (ingyen) + Blackhawk USB100v2 (~40k Ft)

( cd334 v | 2015. 04. 17., p – 13:24 )

É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.
Dev.Board: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1848/PF252419

STM32 esetében a olcsó DISCOVERY boardokat programozónak és debuggernek is tudod használni.

(: Most már igazán uppolni kéne lassan a példa repómat, lehet hétvégén megteszem :)

Na ezt nagyon köszönöm! - nem véletlen, hogy sokfelől halottam az STM chipjeiről. Az említett libopencm3 már rengeteg hasznos dolgot tartalmaz.
Más 3,2K van elérhető kártya (Farnell).
Nagyon úgy tűnik ez lesz a befutó.

* Én egy indián vagyok. Minden indián hazudik.

STM32-es családnál arra kell figyelni, hogy ne a csilli-villi új HAL periféria library-t használd, hanem a Standard Peripherals Library-t az még jól össze van rakva. STM32 a hozzáadott driverek tekintetében most eléggé kihúzta a gyufát a közösség szemében a HAL libraryval, mert az egy... (: nem mondom mi, mert bannolnak innen :) De jól lehet dolgozni velük.
STM32-nek jó a közösségi támogatása, de a hivatalos támaogatás csak akkor jó, ha nagy vevő vagy.

Volt korábban is a periféria library. Más gyártók is adnak hasonlót. Nem kell regisztereket turkálni, makrókkal és függvényekkel tudod konfigurálni a cuccokat. Mondjuk rz a CubeMX HAL többet tud, elvileg a freertos-t is belekenték..

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

Sajnos a HAL nem jó, nézzétek meg a ST fórumán a HAL-lal kapcsolatos dolgokat, szinte minden nap jön egy-két új bug, full bloatware az egész. Egyszerűen nem mernék eldani olyan rendszert, ami HAL-lal készült. SPL megbízható évek óta használjuk. Én nagyon nem ajánlom a használatát!

Ezt a fórumot érdemes elolvasni ezzel kapcsolatban:
[url=http://www.eevblog.com/forum/microcontrollers/st's-(stm32cube)-software…]

Mindenféle gyártók által a chip -jeikhez adott kódokat fenntartásokkal kell kezelni.
Lehet őket használni, működtetnek, de komoly fejlesztésre nem valók. A probléma abból az ellentétből fakad, hogy a gyártó nem nyírhatja ki a fizetős szoftverpiacot a saját cuccaival, azaz túl sok figyelmet a minőségre nem fordít, ugyanakkor ma már csak evvel tud versenyezni. Gyakorlatilag mindenki ugyan azokat a magokat (ARM), ugyan avval a gyártástechnológiával gyártja. Azaz fogyasztásban, utasításkészlet hatékonyságában nincs jelentős különbség. Adnak tehát egy kupac ingyenes cuccot, firmware -t, fejlesztői eszközöket, stb... Ugyanakkor nem tudják és nem is akarják a te felhasználásodhoz optimalizálni a kódot. Azaz a vége úgyis az lesz, hogy kivágod az egészet a francba.

Szóval ezek a kódok prototípust készíteni jók, de igényes termékben nincs helyük.

Sokan elhiszik, hogy van "ingyen firmware", pedig fejlesztési időben rejtve úgyis megfizeted az árát.

A gyártói támogatás tud jó lenni, de engem (is?) inkább az opensource dolgok érdekelnek. Nem mintha valami nagy harcosa lennék ennek a témának, viszont az ilyen kódok, példa programok amit a többiek készítenek mutatja, hogy mivel érdemes foglalkozni - vagy épp nem.

* Én egy indián vagyok. Minden indián hazudik.

( cd334 v | 2015. 04. 17., p – 14:00 )

Egyébként érdekesen alakult ez a szegmens(Cortex-M beágyazott uC-k), munkámból adódóan folyamatosan követem a dolgokat.

ST és ATMEL: saját családot fejlesztettek és egyenlőre jól elvannak velük.

Silabs: volt saját családja, de egy idő után megvette az energymicro ezzel foglalkozó részlegét.

TI: nem volt jelen ezen a piacon megvette a Luminary micro-t, majd egy csúnya flash hiba miatt leírták a már megvett sorozatot(NRND) és teljesen újjat csináktak.

NXP: nemrégen megvette a Freescale-t érdekes dolgok várhatóak ezen a téren, még nem tudni pontosan hogyan alakul ez a szegmens az összeolvadás után.

Talán azért az STM32 család a legnépszerűbb, mert ők jöttek ki előszőr a piacra ezekkel a procikkal tömeggyártásban(NXP-vel kb. együtt(de nekik nem volt akkor portfóliójuk)), illetve az agresszív politikájuk a kicsi és olcsó dev. boardok terén. Most már mindenki követi a dev. boardokban őket, szinte minden gyártónak van egy ilyen "filléres" dev. boardja, amin mindenki el tud indulni.

Köszönöm ezt a tömör áttekintést.
A TI dolgait mindig szerettem - precíz, jól kidolgozott rendszerű leírásai miatt. De a micro kontrollerek terén többször szaladt zsákutcába.
Az NXP - neki vannak a legszimpatikusabb demo boardjai - nem is túl drága - proci + valamilyen interfész a PC felé, amit aztán akár le is törhetsz. Viszont amikor utoljára nézegettem, a fejlesztő eszközök már borsosak és nem tudom mivel tudom égetni, meddig lehet eljutni a gcc -vel és mi a helyzet a támogatottsággal.

* Én egy indián vagyok. Minden indián hazudik.

A TI MSP430 mikrokontrollereit nagyon szeretem, de az ARM-osokban sok ordas hiba van. Pl. a TM4C1294-ben legalább 2 olyan hiba van az USB hostban, ami miatt én végtermékben nem használnám. Az egyik olyan, hogy ha kis zaj jön be a VBUS-on akkor a processzoron belül rövidzár keletkezik és csak pirítja a magot (forró lesz a tok), amíg le nem húzod a tápot. Ja, és a demo board-ot szoftverből tönkre lehet tenni, ha egy GPIO-t kimenetnek konfigurálsz.
Az NXP-nek is vannak hibái, de szerintem elég jók (LPC1768, LPC1788). Pl. ha a PLL beállításait elrontod, nem lehet JTAG-en többé hozzáférni a CPU-hoz. UART-on kell betuszkolni egy működő firmware-t.
Nálunk a cégnél (HCC Embedded) az STM32F4xxx-kel és az LPC17xx-kel van a legtöbb projekt.

Más: Az Eclipse alapú IDE-k debugolláskor néha használhatatlanul lassúak ("step" 2-3 másodpercig is eltarthat). A PCB-re integrált debuggerek is néha csak demózásra jók, mert csak egy-két töréspontot lehet betenni és még lassabban lehet őket vezérelni, mint mondjuk egy különálló debugger-t.

A gyakorlati tapasztalatokat értékelem a legtöbbre - köszönöm!
Sajnos semmi sem tökéletes. Az Eclipse számomra túl zavaros, sok infót akar egyszerre kinyomni a képernyőre, de én ezt nem látom át. Szerintem a "kevesebb néha több" elv jobb.
A TI azért lenne még értelmes alternatíva, mivel van egy Beaglebone is a kezem ügyében.
A JTAG -ek körül úgy tűnik súlyos gondok vannak. A többszöri protokoll konverzió miatt (gondolom én), megreked, elakad vagy akadozik az infó.
Az ATMEL 8-bites AVR procikhoz láttam hivatalos (az ATMEL által kiadott) protokoll leírást, ennek dacára mindenki fanyalog, sok a rossz tapasztalat. Még nem néztem utána, az ARM procik JTAG -hez van "hivatalos" protokoll leírás?
Úgy látom, az egyik legelterjedtebb JTAG az FTDI 2232 USB konverter chipjére alapul, ami két csatornás (az egyik csatorna tulajdonképpen nincs kihasználva) aminek 4K puffere van. Azért nem ajánlják az egy csatornás 232 -es chipet mert csak 1K puffere van!? Miért is kell a nagyobb puffer? Mekkora sebességgel zajlik itt a kommunikáció és milyen csomagokban, hogy a PC csak így tudja lekezelni? Így bizony előfordulhat, hogy valahol útközben megreked és másodpercekig leáll vagy akár el is vész. Gondoskodni kellene, hogy a kommunikáció fennakadás mentesen menjen, ne a konverter vagy a driver pufferébe gyűljön az infó. Tartok tőle, hogy az USB alrendszer is beleszól ebbe, hiszen úgy tűnik még mindig versenyben vannak a párhuzamos portra épülő, bit bang JTAg -ek.

* Én egy indián vagyok. Minden indián hazudik.

Szerintem felreertetted, ep azt irta, hogy valoszinuleg nem talalsz egyseges J-TAG kezelest, mert mindenkinel mas.

Bar nem foglalkoztam sokat J-TAG-gel, de maga a J-TAG szerintem kb. olyan szinten egyseges mint az I2C vagy a SPI. tehat sorosan tolod be a biteket, a masik oldalon meg jonnek ki, vannak alapveto dolgok amik egysegesek, mint pl. az I2C eseten a cimzes, de hogy a gyarto milyen regisztereket es hogyan implementalt az eszkozrol-eszkozre valozik, ha ezt nem tudod, hiaba van J-TAG hardware interface-ed.

/sza2

( hardhead | 2015. 04. 17., p – 15:18 )

"Ki, milyen/melyik ARM platformon fejleszt, beágyazott alkalmazásokat?"

RPi-re portolgatom a C-s dolgaim cross (arm-gcc) fordítóval. Linux alatt Code::Blocks-ból kényelmesen lehet dolgozni.

( answ | 2015. 04. 17., p – 16:13 )

Most ZedBoard-ot használok (Zynq SoC: dual core Cortex-A9 + FPGA)
Az ARM cpu-n fut egy Linux és AMBA AXI interfészen lehet kommunikálni az FPGA-val. Akár menet közben is át lehet konfigurálni a beágyazott Linux alatt a logikát.
Sajnos befejezték az ISE fejlesztését, így Vivado Design Suite-ot használok..

Vannak STM32 boardjaim is, de csak a kihívás miatt (STM32-re fejleszteni szörnyű, nem hiába olcsó :) )

STM32cubeMX és a HAL. Persze ha van pénzed (Keil, IAR, ..), akkor biztosan jól működnének a dolgok, de én megszoktam hogy ma már a fejlesztő segge alá nyomják az ingyenes fejlesztőkörnyezetet.

off:
Például AVR Studio (ma már Atmel Studio) nagyon jól használható! Igaz én csak AVR programozásra használom, de elvileg ARM-ra is jó.

1.) nem kell feltétlen a cubemx-et használni http://hup.hu/node/140045#comment-1859876
2.) teljesen jól lehet rá fejleszteni. Mondjuk én nem vagyok az eclipse szerelmese, úgyhogy én más toolchaint raktam össze (crossdev --target arm-none-eabi egy kis newlib mókolással) egy minimális IDE-vel.

Az stm-es devboardok nagyon barátságosak, olcsók.

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

CooCOx még nem halottam róla. Nézem.
Elég komplexnek tűnik. Az Eclips nem a kedvencem. Most ez akkor free?
Sok gyártót kezel, van saját jtag (nem olcsó de talán belefér).
Hol a csapda?
Ha ez ilyen sokat tud akkor miért nem hallani róla sokat?

* Én egy indián vagyok. Minden indián hazudik.

J-TAG: mi leginkább Segger-t használunk, ami elég stabil. (Persze semmi sem hibátlan. Épp most futottunk bele egy SPIFI letöltés hibába...)
Free: mostanában egy pontig szinte minen az. Aztán jön a szívj vagy fizess.
Csapda: a feladathoz kell eszközt választani, másképp drága vagy bukó lesz a projekt. Pl. ld.: LPCXpresso árazását.
Mostanság inkább az a kérdés, hogy a kényelem/pénz görbén hova akarod (vagy tudod) beállítani a munkapontot.

Nem kötelező használni az stm lib-eket!

Van több jól használható op. rendszer embedded fejlesztéshez, van ami ingyenes is.
pl.
- ChibiOS ugyan nem ingyenes, de elég intenzíven fejlesztik és az stm sok board-ját támogatja.
- FreeRTOS ingyenes, kisebb munkákhoz jó, egyszerű
- ECOS azt hiszem ingyenes, de a config-ja egy rémálom, a tcl-tk felület miatt
- CooCox nem rossz, de egyelőre csak windows alá láttam

Mindegyik fenti oprendszer multitaszkos környezetet biztosít, vannak kész építőelemek (queue,semaphore és egyébb kifinomult nyalánkságok)
Nekem a ChibiOS nagyon bejött, stm32 alá nagyon kényelmes.

( sza2king v | 2015. 04. 17., p – 16:34 )

Mostansag Silabs Gecko. Az egyik volt munkatarsam Cypress PSoC-ra eskuszik.

/sza2

( zeerocool v | 2015. 04. 18., szo – 00:54 )

stm32-vel dolgozok az utobbi idoben, nekem jo tapasztalatom van vele, mi is a Standard Peripherals Library-t hasznaljuk. Van hozza egy stlink nevu jtag debugger, ez openocd-vel szepen mukodik, es gdb-el lehet debuggolni a programot rajta. Most pedig egy nordic nrf51-et probalgatok, eddig jonak tunik, ehhez is van openocd support, ahogy utanaolvastam, ez is mukodik stlink-el es segger jlink-el is. Egy par ora erejeig volt szerencsem egy toshiba tz1000-hez, elvileg ez is ment volna a segger jlink-el, es eleg jo a specifikacioja is a procinak, beepitett btle illetve szenzorok. Linuxon fejlesztek, openocd + gdb a debuggolashoz, arm-nore-eabi-gcc a forditashoz, illetve egy tarolos oszcilloszkop igen jol tud jonni neha, vagy akar egy usb-s logic analyzer :)

( meditor | 2015. 04. 18., szo – 09:25 )

szerk: hülyeség volt, amit írtam.

> Sol omnibus lucet.

( tovis v | 2015. 04. 19., v – 12:57 )

Kár hogy az NXP senkinek nem jön be.
A legszimpatikusabb olcsó boardok az övék - a mc minimális körítéssel, minden pin kivezetve úgyhogy könnyű legyen breabord vagy kísérleti panelra biggyeszteni - majd fejlesztő interfészt le lehet vágni/törni. Remek ötlet. Mintha ATMEL chippel is láttam volna ilyet, pont megfelel a DIP 40 -es toknak. A lényeg hogy ha kell valamiből 4-5 darab, akkor nem rohanunk nyákot tervezni, gyártani hanem egy próba panelen hozzá huzalozzuk a szükséges dolgokat és mehet a helyére :)

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2015. 04. 19., v – 13:42 )

Van itt még egy játékos: Cypress
Az NXP -hez hasonló kis kártyákat ajánl már majdnem 1k -tól és van hozzá egy free(?) "PSoC Creator" nevű IDE minden finomsággal - kár hogy csak windows. Senki nem próbálkozott ezzel? Mi lehet a csapda?

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2015. 04. 20., h – 13:01 )

Az eddigiek alapján, nekem az openOCD tűnik a nyílt fejlesztő eszközök közt a legszimpatikusabbnak. Használhatom a megszokott szövegszerkesztőt és a gcc alapú eszközöket.
A JTAG táján még van mit spekulálni. Úgy látom, nincs univerzális darab, csak több vagy kevesebb típust támogató. Első lépésben érdemes lehet lehet, valami olyan proto kártyát választani, ami tartalmazza a szükséges eszközt. Itt megint visszatérek oda, melyik gyártóval is foglalkozzam.
Persze ezzel a koncepcióval az lehet a baj, hogy "main stream" és a versenytársak a gyártó által "ingyen" nyújtott eszközöket fogják hiányolni, a forráskód nem lesz kompatibilis.
Továbbra is az a véleményem, hogy a feladatok "alsó-széle közepe" - vagy inkább legyen túlméretezett az adott feladathoz, de ha gyorsan akarok eredményt a betanulási fázist így lehet rövidíteni és csak a specifikumra kell koncentrálni talán :)
Azokat a gyártók a szimpatikusabbak, akik a lehető legkevesebb egyéb alkatrésszel szerelt kártyákat forgalmazzák. Mindenféle nyomógomb, LCD kijelző és egyéb blikkfang csak zavarhat a prototípusnál, hiszen lehet sem arra, sem erre nem lesz szükség, ha kell inkább mellé teszem.

* Én egy indián vagyok. Minden indián hazudik.

Valoban, imadom amikor az egyik spi-ra egy touch sensor van rakotve az eval boardon, mikozben csak 2 spi van az mcu-ban. De forrasztopaka az ember baratja :) Most a nordic devboard-jan lattam egy olyan megoldast hogy a gombok/ledek kis atvaghato vezetekkel vannak a nyakon, es a doksi azt is leirja hogy melyiket kell "levakarni" ( :D:D ) hogy ha nem akarod gombnak vagy lednek hasznalni az adott gpio-t.