TI nem postáz, hanem futároz (FedEx)

A Stellaris LaunchPad-hez tartozó oktató videókat itt találjátok meg:
Youtube videók

Sajnos nekem is van bőven időm megnézni a videókat, átrágni magam a kontroller dokumentációján, mert november 29. a tervezett kézbesítés időpontja...

Pontosabban: itt

25-én este (magyar idő szerint tegnap hajnalban) elindult a Stellaris Launchpad szállítmány azoknak, akik még augusztusban regisztrálták magukat. Az a szállítmány, amelyikben az én kártyám is utazik, a DHL Global Forwarding információja szerint ma délelőtt érkezett Hollandiába (a szállítmány 572.9 KG, s közel fél köbméter). Remélhetőleg néhány napon belül eljutnak a címzettekhez.

Üdv!

Van kialakulóban egy ötlet, első nekifutásból arra gondoltunk, hogy egy kamera képét feldolgozva kellene a kütyünek működnie, ezért felvetődött a gondolat, hogy valamilyen ARM-es platformot kellene talán bevetni. Nézegettem developement boardokat, és alapvetően kétfélével találkoztam: az egyikben nincs külső memória az ARM CPU mellett, programtárolásra használható a saját (jellemzően 256k) flash-e, illetve van belső 20-64k SRAM a chipben; a második verzió 128M-1G külső flash-sel és 64-128M RAM-mal rendelkezik. Persze ez utóbbiak sebességre is sokkal többet tudnak, a csupaszok általában 60-100MHz képességgel, a nagyok 400-600MHz órajellel. A nagyokon viszont már Linux vagy WinCE is futhat.

A kamerakép-feldolgozás miatt a maximum 64k belső RAM nekem nagyon soványnak tűnik, ebbe egy 640x480-as kép maximum gybitesen fér el, valamint ezeknek a CPU-knak a maximum 100MHz-es órajele is lehet, hogy kevés lesz a feldolgozáshoz. Tehát inkább hajlanék egy, akár Linuxot is futtatni tudó boardban.

Igazából a JTAG-nél akadtam meg. Ilyet még sosem használtam, és ahogy körülnéztem, van jópár megoldás erre, de nem tudom, melyik lenne az, amit szoftveresen mindenhol jól tudnék használni. Printerportosat semmiképp nem akarok, már nincs egyik gépünkben sem printerport.

Ha valaki pár szóval, tömören leírná azt, hogy mivel kellene felkészülnöm, ha belevágok ebbe a témába, azt nagyon megköszönném. Tehát:
- milyen fejlesztőkörnyezetet használhatok, lehetőleg ingyenest, lehetőleg linuxon?
- milyen nyelvet érdemes megcélozni (nincs ellenemre az assembly sem, ha az a jó)?
- a Linux-képes "nagy vasak"-ra ugyanúgy tudok akár egy ledvillogtató assembly progit írni, mint a csupaszokra?
- milyen JTAG-csatlakozást keressek/szerezzek be, amivel programozni fogom tudni a cuccokat, és ehhez milyen szoftverek kellhetnek (nyomkövetés nem annyira szempont)?
- bootloaderek vannak-e, mit kell róluk tudni?

Hirtelen ennyi kérdés merült fel bennem, jó lenne, ha el tudnék indulni valamerre, legalább annyira, hogy miket rendeljek meg...

Köszönettel!

Csillió féle ARM van.
Egyrészt core szerint (kissé leegyszerűsítve a dolgokat, mert volt régebbek még sok más is) mostanában van:
- ARM7 alapú, ezek kissé kiöregedtek, inkább olyan max. 50MHz körül
- ARM9 alapú, ezek sem mai darabok, de 150-400MHz-ig elérhetőek,
- ARM11 alapú, ezek modernek, nagyrészt csak BGA-s verzióban elérhetőek, 400-500MHz-től felfele
- Cortex M0 alapú, ezek kicsi, egyszerű, olcsó cuccok szoktak lenni, olyan 50MHz környékén (300 Ft körül már létezik ilyen pl. a chipcadnél)
- Cortex M3 alapú, ezek elég korrekt dolgok, 50-200MHz között
- Cortex M4 alapú, ez még elég új, jellemzően 150MHz-200MHz
- Cortex A8/A9 alapú, ezek nagyon jó és modern cuccok, 500-600MHz-től felfele, mindenféle érdekes HW támogatással (pl. videófeldolgozáshoz is)

A core egyik alapvető jellemzője, hogy van-e benne MMU. Ha van, akkor tudsz rajta Linuxot futtatni - már persze ha raksz rá több MB memóriát. Ha nincs benne MMU, akkor valami embedded op.rendszert, vagy ucLinux-ot tudsz csak rárakni, vagy op.rendszer nélkül mikrokontrollernek használhatod. Cortex CPU-ban még nem láttam MMU-s verziót, az ARM11-ek mind, az ARM9-ek pedig nagyrészt rendelkeznek MMU-val.

A CPU-ban belül vagy van flash a programnak, vagy nincs, de általában nagyon könnyen illeszthető hozzájuk külső SPI-s flash chip. Bent RAM általában 4-128-256KB szokott lenni.

A CPU-k másik fontos paramétere, hogy van-e rajta (és milyen) külső busz:
- nincs rajta külső busz, nem tudsz rá külső memóriát rakni, csak a belső SRAM van
- van rajta külső busz, de csak SRAM-ot (meg egyéb statikus dolgokat, pl. párhuzamos flash-t, külső regisztereket) tudsz rápakolni, ami ~1MB felett nem igazán költséghatékony, annyiban meg Linux nemigen fut el
- van rajta külső busz, amire akár DRAM-ot is rá tudsz rakni, ebből is van több verzió(SDRAM, DDR, DDR2+)

Szerintem Neked csak a külső DRAM-os modellek jöhetnek szóba, ha képet szeretnél feldolgozni.
Az egyik opció, hogy keresel valami 100-200MHz-es Cortex M3 vagy M4 alapú CPU-t, (pl. STM32F2xx/4xx, LPC177x/8x/185x/435x) raksz mellé külső DRAM-ot - ez otthon összerakható tud lenni, vannak belőlük QFP tokozású modellek, bár normális DRAM sebességhez azért oda kell figyelni a panel kialakítására.
A másik opció ugyanez ARM9-es alapú CPU-val, aminek az előnye, hogy könnyen találsz MMU-s modelleket (pl. AT91SAM9260, AT91SAM9XExxx, TI AM1705), és tudsz rá Linuxot rakni. A hátránya, hogy a modern ARM9-esek lassan már csak BGA-val érhetőek el, a régebbiek meg inkább 150-200MHz-et tudnak csak, vagy egyéb módon korlátozott a tudásuk (kis lábszámú tok).
A harmadik opció, hogy veszel készen egy modult/fejlesztőpanelt, amin rajta van a CPU és DRAM. Ennek az az előnye, hogy tudsz venni erős, gyors (pl. 500MHz-1GHz-es Cortex A8/A9 vagy ARM11-es) CPU-t, gyors és sok DDR2/3 memóriával, mégsem kell BGA-zgatnod. A hátránya, hogy picit drágább lesz, ill. számíthatsz rá, hogy csak Linuxon keresztül fogod akarni használni (pl. nincs teljes mélységében a HW-ről doksi). Ez persze nem biztos, hogy annyira hátrány.

Ez kicsit félreérthető lehet, ezért javítanám: Cortex M CPU-ban még nem láttam MMU-s verzió.

Fél köbméternyi cucc, az nem is sok Európának

Még egy kis kiegészítés.
A prociba épített FLASH programmemoriák sebessége igen alacsony 50-60 Mhz
Ha ezt cache-elik és duál vagy több csatornán kezelik, akkor lehet ennek többszöröse az utasításbeolvasás így érnek el mostanában nagyobb sebességet. Ilyen az ARM7 M3 M4
Az ARM9 ARM11... -ben már nem belső FLASHben van a program, hanem külső nagysebességű "tárolókban", amit neked kell a proci sebességhez igazítanod.
Azért írtam idézőjelbe, mert nagy sebbességeknél NAND-ból RAM-ba másoló "tárólókat" használnak, amiknek RAM sebessége van.
A hardvered nagyban meghatározza a cél. A kamerafeldolgozás elég tág cél
Csináltam már atmegával BB kameráról (2mp) direktbe képet BB LCD-re 320x240.
Minden RAM és egyéb egység nélkül 20Mhz-en ment kb 20Frame/sec
Persze a másik véglet pl arcfelismerés na erre már karcsú lenne bármelyik ARM is.

Köszönöm a hozzászólásokat!

Én is úgy gondoltam, hogy külső memóriás cuccal kellene kezdeni mindenképp, és persze nem ártana a nyers erő sem a képfeldolgozás miatt, bár azért nem arcfelismerésről lenne szó, hanem tárgy megjelenésének érzékeléséről. Van nég pár ötletem, hogy hogyan lehetne rásegíteni erre, de az majd később lesz aktuális.

Próbálom tisztázni a dolgokat magamban, és nézegettem, hogy mivel indulhatnék. Cortex M3/STM32 boardokat láttam elég sokat, de ezeken általában nem voltak külső memóriák. A leginkább használhatókon volt a CPU mellett 512k SRAM és 64-128MB flash. Ezek a cuccok ráadásul maximum 100MHz-esnek voltak írva. Amik már közelebb állnak ránézésre az igényekhez, azok az S3C2440-es alapú cuccok, ezekben van külső RAM és flash is. Ilyenből van már egészen kompakt (például), egybepakolt platform is, de ez valamiért szimpatikusabb: Bővebben: Link
Még nem teljesen világos, hogy a különböző memóriák elérése hogyan is történik, pl. mi a NOR és a NAND flash funkciója közt a különbség, valamint hogy viszonyul ezekhez a CPU-ban lévő flash. Még sokmindennek utána kell néznem, sokat meg kell tanulnom erről a világról, de nyitott vagyok teljes mértékben.

Szerintetek jó irány a fenti cucc az elinduláshoz? Mi fog kelleni szoftver oldalról nekem, hogy tudjak dolgozni vele? Egy ilyen vason tudok programot írni MCU-ként használva az ARM-et? Fog kelleni még a csomagon kívül valamilyen JTAG illesztő? Ha igen, milyet érdemes megcélozni?

Nekem van pár JTAG programozóm, de ULINK2-t használok mostanában.
Nem volt drága.
De lehet nem lesz rá szükséged, mert ha kész boardot veszel, azokon vagy van ICD vagy Bootloader. Ha meg komolyabb cuccot veszel, akkor azon van linux és SD kártyáról futtathatod a C-ben lefordított projected.
Elég jól támogatják mostanság a boardokat. Help + examples.
Ha mélyebben akarod programozni, akkor egy komolyabb programkörnyezet is kellhet. IAR KEIL CS, de ezek pénzbe is kerülnek. Van pár eclipse megoldás is.
Az Open2442 egész jó lehet, még a $100 se tűnik soknak érte, bár LCD, kamera nincs benne.
persze nem $5-os csupasz TI

A NOR flash SRAM-szerű külső interfésszel rendelkezik. Olvasásra kb. hasonló módon is reagál, ennek megfelelően az SRAM-ot meghajtani képes külső busz jellemzően NOR flasht is szokott tudni kezelni, továbbá használni közvetlen kód futtatására (byte/word szinten olvasható, emberi válaszidővel). Cserébe picit drágább, az SRAM-szerű interfész miatt sok vezeték kell neki, törlés/írás picit lassabb, és mérsékelt kapacitásban szerezhető csak be (128-256MB körül vannak a nagyobbak).
A NAND flash teljesen blokk/szektor szintű kezelésre van kitalálva, az interfészén az adat/cím multiplexált. Hasonlóan működik, mint egy wincheszter: kiadod az olvasás parancsot, megmondod a szektorcímet, majd elkezded az egész szektort kiolvasni. Emiatt nem igazán alkalmas közvetlen kódfuttatásra (új szektor választása mondjuk 25us, utána kezdenek csak kijönni belőle a byte-ok), tipikusan háttértárként szokás kezelni, hiába memory-mapped (mint egy pen-drive-ot, vagy egy SD kártyát), azaz komplett blokk be a DRAM-ba. Előnye, hogy olcsóbb, jóval nagyobb kapacitásban is elérhető (16-64GB), mint a NOR flash, valamint sokkal kevesebb vezetéket foglal.
Jellemző hátránya még a NAND flashnek az is, hogy a hibakezelést a CPU-ra bízzák. Azaz egy 2KB-os szektorra van mondjuk +64 byte, és a CPU meg oldja meg valami ECC-vel, hogy a meghibásodó bitek ne okozzanak adatvesztést. A CPU-ban levő NAND vezérlőnek ezt is kezelnie kell tudni.

A belinkelt cucc elég jól néz ki, és még az ára is tűrhető, plusz ha van kedved pár ezresért szüttyögni alá egy interfész panelt, akkor megveheted külön csak a középső CPU-modult a DRAM-mal meg a flashekkel (nem néztem, de gondolom 50-70 USD körül az is biztos megszerezhető).

Ehhez külön JTAG illesztőre akkor lesz szükséged, ha debuggolni szeretnéd az oprendszert, vagy oprendszer nélkül akarod használni és debuggolni szeretnéd "Az" alkalmazást. Nem tudom, hogy mi a cél, de ez van olyan erős CPU-ban is és memóriában is, hogy elbírjon az alkalmazás alatt egy Linuxot (pl. openwrt). Linux alatt viszont simán lehet pl. gdb-vel meg strace-szel debuggolni user szintű programot. Ha az oprendszert elrontod, a benne levő boot loader szokott tudni SD kártyáról vagy egyéb interfészről bootolni, ha a boot loadert is elrontod, akkor szokott lenni boot loader fallback (pl. ROM-ban valami buta boot loader, amit nem tudsz elrontani).

Az openwrt pl. tömörített fájlrendszerben lakik alapból. Pl. egy openwrt-s wifi routerben van mondjuk 8MB flash, ezen van a komplett Linux, igaz, csak mérsékelten sok csomag fér fel, de mondjuk egy átlag routerben a kétharmada is elég. Ha van 1GB NAND flashed, az ehhez képest durva sok.
A NOR flash nélkül amúgy pl. teljesen meg lehet élni, ill. ha nem annyira nagy a NAND flash, az se baj (van SD kártya slot). Viszont a RAM nem igazán bővíthető utólag. Azaz azt kell végiggondolni, hogy mennyi a minimum, amivel meg tudsz lenni. Openwrt-s tapasztalatok azt mutatják, hogy egy üres oprendszer (pár futó daemonnal) mondjuk 8-16MB-ot megeszik, tehát praktikus okokból 32MB alá semmiképpen nem mennék. Nyilván ha oprendszer nélkül használod, akkor az egész memória a tied.

Én úgy látom, hogy a linkelt, $100 árú cucc tartalmazza az alapcsomagot és a kiegészítő csomagot is, amivel az ember többek között kap egy kamerát és egy 4.3"-es touch paneles LCD-t is. A kiegészítő csomag nélkül olyan $60 körül láttam ugyanezt.

Vagy van nagyjából ugyanennyiért (szállítással) ilyesmi, amihez $10 körül lehet kamerát szerezni (egyébként egy ilyen kameramodul már úton van, azt már korábban megrendeltük, mivel úgyis biztos kell, akármivel is dolgozzuk fel a jelét).

A kérdés az, hogy vajon a gyárilag mindennel felszerelt, egybeépített, vagy a modulárisan dugdosható lenne-e a jobb megoldás.

Tegnap este utánaolvastam ezeknek a flash-eknek, és bár az nem vált teljesen világossá, hogy a technológia (NOR vagy NAND) miért is határozza meg azt, hogy hogyan lesz elérhető az adat, az letisztult, hogy melyiket hogyan lehet használni.

Ezek szerint a NAND flasheket inkább felfoghatjuk valamiféle HDD-ként, ahol jó eséllyel filerendszerben tároljuk az adatainkat illetve kódrészleteinket. Ezeket majd olyan memóriaterületekre olvasunk be, ahonnan a CPU már közvetlenül képes natív módon futtatni a kódot, illetve feldolgozni az adatot. Ez a terület - gondolom - lehet a belső vagy külső RAM (esetleg a NOR flash, de azt valószínűleg nem szokás ilyen célra befogni).

Apropó flashek: ezekre a flash memóriákra szoktak megadni olyan adatot, hogy hányszor újraírhatók?

A memóriaméretekről azt látom, hogy ezekben a $100 körüli cuccokban 64MByte DRAM a jellemző, és emelett van általában 2MByte NOR flash és 128 vagy 256MByte NAND flash (ennek méretét sokszor GBit-ben adják meg, de ha jól számolok, akkor 2GBit az 256MByte). Néztem az S3C2440A adatlapját, abból nekem úgy tűnik, hogy belső flash-e vagy SRAM-ja egyáltalán nincs, jól látom (persze a chache-eken kívül)?

Pár helyen úgy írják, hogy jumperrel lehet a NOR vagy NAND flash-ből bootolást választani, jól gondolom, hogy ez a jumper valamilyen címdekódolást változtathat meg (adatlap szerint a Reset vector a 0 címen van)?

Máshol olvastam olyan megfogalmazást, hogy a 2MByte NOR flash BIOS-t tartalmaz. Jól gondolom, hogy ez a BIOS lenne tulajdonképpen az a bootloader, amibe a flashelési funkciók is be vannak építve? Ha ennek a tartalmát akarnám felülírni, akkor kellene nekem a JTAG?

Esetleg Raspberry PI board-ot is érdemes lenne megnézni! Mindössze 35 $ az ára, nagyon sokféle OS-t támogat, a támogatói fórum is elég aktív.

Ahogy előbb írtam, a gyorsabb prociknak nincs belső nagyméretű RAMjuk és programtároló FLASH memoriájuk. Külsőt alkalmaznak, ami gyorsabb a technológiájuk miatt.
Egy ilyen procinak kell egy nemfelejtő gyorselérésű program tároló: "2MByte NOR flash"
Külső ram is használatos: "64MByte DRAM"
És egy nagyobb adattároló képeknek, audiónak: "64MByte DRAM"
Plusz a proci "csupaszon".
Futhat rajta oprendszer, ami a NOR-ból jön, de betöltheti a RAM-ba is, pl a NAND-ból.
Pl Android fut NOR-ból, és a kiválasztott APP-ot betölti a RAM-ba és onnan futtatja.

"jól gondolom, hogy ez a jumper valamilyen címdekódolást változtathat meg"
nem
A NOR tárolók közvetlen címzésűek. Egy ilyen 64Mx32 Flash tárolónak 26 címlába van (A0-A25) és 32 adatlába (Q0-Q31) (persze nem lába van, hanem már golyója)
Tehát bazi sok vezeték kell hozzá (persze lehet multiplexelni, de lassabb lesz)
Tároló méretével nő a lábak száma is!

A NAND-oknál pedig "programozni" kell a címzést/feladatot.
Itt van 8 vagy 16 IO adatláb, amin lekommunikálja a címzést és az adatokat. (+ vezérlő lábak)
A tároló méretével nem nő a lábak száma. Tehát nem gond a több GB adatterület megcímzése sem.
Egy adat kinyerése több bemenő utasítást igényel, tehát nem közvetlen elérésű. De kitalálták a burst technikát. Tehát streem olvasáskor egy címzésre 8 byte olvasása jön közvetlen, és közben lehet megadni a következő címet is. Így tud gyors maradni.

Általában 100.000 törlés/írás-t garantálnak és 10 év adattárolást. (persze ha nem tologatják sűrűn a reptéri szkennereken át)

Olvasgattam a Mini2440 doksijait (Bővebben: Link), ebből nekem úgy tűnik, hogy a NOR/NAND jumper állása szerint két memóriatérkép van: az elsőnél a NOR flash látszik 0-tól; a másodiknál a NAND flash 4k-s buffere látszik 0-tól, és majd csak 0x08000000 (128MB)-tól lép be a NOR flash. Valahol mintha azt láttam volna, hogy NAND-os bootoláskor a NAND flash 0-s címétől az első 4k beolvasódik ebbe a bufferbe (ezt ki intézi, az MMU?), és úgy indul a boot. Egyébként egyre jobban tetszik ez az összegyúrt cucc, elsőre elég jónak tűnnek a dokumentációi, és talán az sem utolsó szempont, hogy ha "terepre" kell majd vinni próbálni, akkor eléggé egyben van, nem lógnak rajta a modulok csatlakozókkal (csak a kamera).

Fejlesztéshez talán azt a módszert tudnám elképzelni, hogy a PC-n összeállított image-et soros porton vagy USB-n keresztül közvetlenül megbootoltatni, így nem kell "fárasztani" a flash memóriákat. Ez szerintetek járható út?

Raspberry PI-n is gondolkodtam, de az LCD kijelző nagyon megtetszett ezeken a 2440-es cuccokon, mert lehet, hogy a képfeldolgozás miatt nem baj (legalább a fejlesztés alatt), hogy van lokális kijelző is. Raspberry PI-hez csak monitort láttam csatlakoztatva, de az már nehezebben hordozható (itt megint a terepre kitelepült p-etróbákra gondolok). Persze a vas erősebb, és ha jól gondolom, a fejlesztés módja, a rendszer felépítése nagyban hasonlít a 2440-esekhez. (Amit látok különbséget elsőre, hogy ott kizárólag SD kártyára tudom tenni a bootolandó image-et, nem csinálhatok olyan csupasz gépet belőle, ami a kártyán lévő flashből indul és dolgozik, akár opsys nélkül. Jól látom?)

Nekem van komplett mini2440 7es kijelzővel és mindenféle +kivezető kábellel eladó Talán ott van még a hirdetések között

Látom még mindig ragaszkodsz az egy jumperrel NOR ból NAND protokol lesz
Kerestem az adatlapot, de nem találtam, de 1 jumperrel csak a bootloadernek "mondod" meg, hogy honnan akarsz bootolni. Ö meg teszi a dolgát és a protokolt ő oldja meg.

Image a RAM-ba, járható út, de nem kellene féltened a FLASH-t. 100.000 -szer soha nem tólsz rá program verziót. Ennyiszer változtatni és feltölteni irrentábilis a fejlesztés.
Ha meg kész a szoftver, akkor csak egyszer írod rá, vagy új firmware update-nél.
Változó adatokat meg ugye nem itt tároljuk.

LCD-t meg mindenhez lehet ragasztani. De ha van rajta az már előny.

Akkor hogy értelmezzem ebben a fileban az 1.2.1 pontban lévő memóriatérképeket?

Itt pedig a CPU doksi 6. fejezetének overview-jában írják azt, amit én is próbáltam lejjebb megfogalmazni: "Auto boot: The boot code is transferred into 4-kbytes Steppingstone during reset. After the transfer, the boot
code will be executed on the Steppingstone."

Vagy valamit félreértelmezek?

Na, megjött a LM4F120?

Nem tudom követni, hogy Hollandiából hogy jut el Debrecenbe. Reményeim szerint a hét első felében fog megérkezni.

1.2.1 a jumper a bootolás helyét adja meg. Nem címeltolást, mivel vagy a NAND van vagy a NOR van azokon a címeken (fedik egymást)

Igen, a kiválasztott boot kódot 4k-ba másolja és onnan futtatja.
Ez amit írtam neked, hogy a NAND-ból macerás kiolvasni a tartalmat, programozni kell a memoriát. Ezért van egy harveres megoldás ami a NAND-ból az első 4K automatikusan beolvassa a belső RAM-ba és futtatja.

Van egy ilyen FriendlyARM-om, most WinCE van rajta. Kölcsönadhatom.

Hogy pontosan hogyan történik az indulás bootkor, az azért érdekes lehet, az adatlap alapján én azt gondolnám, hogy ezt valami belső logika intézi a jumper állása szerint. Nem címeltolásról írtam, hanem arról, hogy a memóriatérkép máshogy néz ki a két esetben, más terület látszik nullán, ahonnan a végrehajtás reset után kezdődik.

A hétvégén olvasgattam valamelyik AT91S doksiját, és ott egészen világosan le van írva, hogy a chipben van egy ROM, ami reset után indul, és kinéz ide-oda (SPI flashek, és talán NAND flash is), hogy ott van-e bootolható kód, és ha talál, akkor beolvassa RAM-ba, megcsinálja a remap-elést és ráadja a vezérlést. Szóval ott nagyon szépen látszik, hogy nincs itt semmi extra logika (mert minek is, ha már ott a CPU core), hanem egy gyárilag megírt, megváltoztathatatlan kód intézi ezt a startup-ot. Lehet, hogy a Samsung-ban is valami ilyesmi van, csak ők ezt nem fejtik ki ilyen szinten. Ha a jumper ott áll, akkor beolvassa a NAND elejét a RAM-ba és azt map-eli nullára, máskülönben pedig a NOR-t map-eli nullára és ráugrik. Ugye valami ilyesmiről lehet szó?

Ha minden jól megy, akkor már a hétvégére lesz egy saját FriendlyARM-om. Majd biztos lesz még kérdésem, most egyelőre csak olvasgatok mindenfélét, mindenhol.

Már megkapta.
/Kb. 10 perccel előttem./

Igen ezt írtam én is
"de 1 jumperrel csak a bootloadernek "mondod" meg, hogy honnan akarsz bootolni. Ö meg teszi a dolgát és a protokolt ő oldja meg."

Bootloader (ROMban) körbenéz (jumper,SD...) és saját protokollal betölt (nem harveres)

A bootloader vagy beégetett ROM, vagy te írhatod meg, mint kisebb MCU-kban.
Jobb MCU-kban egy halom rutint beleraknak...

Na akkor marad nálam a FriendlyARM

Megyek befejezem végre az LM4F120-hoz az expandert, hogy mehessen gyártásba.

Milyen expandert csinálsz hozzá?

Most kaptam készhez a kártyáimat. Egyelőre csak az RGB LED villog, majd este otthon kipróbálom a kommunikációt is. (szoftvertelepítés nélkül nem ismeri fel a Windows)
Mivel a kártyán két USB csatlakozó is van, felraktak egy kapcsolót, amivel választható, hogy melyikről vegye a tápellátás.

Alapértelmezetten a cél áramkör csatlakoztatásához van beállítva a kapcsoló, gondolom, a gyári demó miatt. Tehát Launchpados reflexből ne a debuggert csatlakoztassuk a géphez!

Nekem még egy hónapot kell rá várnom, mire kézhez kaphatom.

Érmes most hozzáfogni, mert lehet, hogy az egy hónap is kevés lesz a szoftver és a dokumentáció összeszedéséhez, letöltéséhez, telepítéséhez és áttanulmányozásához.

Vannak furcsaságok, például az erről az oldalról letöltött Stellarisware és CCS 5 nem egyezik meg múlt héten egy másik oldalról letöltött, de azonos nevű csomagokkal.

A www.ti.com/stellaris-launchpad címről érdemes kiindulni. Itt kínálják a Stellaris PinMux Utility programot, azt is érdemes letölteni (a portlábak és periféria kivezetések engedélyezéséhez nyújt segítséget).

A Stellarisware csomag azért kell, mert ebben van néhány mintaprogram és a perifériakönyvtár, meg a dokumentáció.