Ebben az esetben nem elég a #define... , mert az is fontos, hogy a fordító ne tegyen semmit az adott tárhelyre, mert akkor felülíródhatnak az adatok. A te megoldásod nem foglal le helyet a változóknak.
Nálam ez működik:

Az pedig, hogy a linker file-hoz nem akartam hozzányúlni, az a saját elképzelésem volt, hogy könnyebben átültethető maradjon a kód más IDE-re.

Az en megoldasom valoban nem foglal le helyet, az igaz. De nyilvan egy olyan helyre allitom a cimet, amirol tudom, hogy ott nincs es nem is lesz mas. De teny, hogy korrektebb megoldas a C valtozo es __attribute__ ...
Az IDE kerdes nekem orok talany marad.. En csak DE-t hasznalok I nelkul. gentoo linux, jEdit, gcc, make, stb. Es ez jo AVR-hez, ARM-hez, mindenhez.

Azért gondoljatok már a kíváncsi kezdőkre is!

És írjátok le hogyan tovább?

Hogy írod és olvasod ezt a „flash_data[4096]” területet?
És az ".userdata" mire való?

Üdvözlet mindenkinek.
Azt szeretném megkérdezni, hogy tudna valaki írni néhány dolgot a Texas által gyártott CC2538 típusú ZigBee SoC lábkiosztásáról. Az adatlap nem tartalmazza az összes periféria csatlakozását, például I2C. Vagy az lehetséges, hogy bármelyik periféria bármelyik lábra multiplexelhető?

A segítséget előre is köszönöm.

Ez akkor most azt jelenti, hogy az "Integrated Development Environment" nálad i nélkül nem integrált, vagyis nincs egy programba gyúrva az összes funkció?
Én alapvetően lusta vagyok, szeretem, ha egyben van az egész: fellököm a Keilt vagy az Em::blocks-ot, és benne van a fordító, szerkesztő, debugger, nem kell állítgatni. A Linux-nak már nekifutottam párszor,de néhány órás állítgatás után eluntam, és visszatértem Windowsra. Mint írtam lusta vagyok.

Nem akartam az egészet beollózni, mert egyrészt nincs kitisztázva, abból meg csak a "mi a f*szért így csinálod?" kérdések lennének, másrészt ha valakit tényleg érdekel, akkor meg kérdez, addig meg nem dolgoznék feleslegesen.
A Flash olvasásban nincs semmi bonyolult, simán memóriacímről olvasunk, vagy mondjuk ha tömböt definiáltunk rá, akkor így:

A flash_data tömb létrehozása, ahogy korábban is írtam (GCC-ben):

Ez a sor lefoglal 16kB-ot (4096*4byte) a belső ROM-ban, vagyis a Flash-ben, amire a "userdata"cimkével kell hivatkozni a linker file-ban. A linker file neve IDE-től függően változik, nálam épp "stm32f407ve_flash.ld". Mindez megint csak GCC-re igaz, Keilben kicsit másabb, és nem kell a linker filet szerkeszteni (állítólag, én még nem próbáltam).
A linker file MEMORY szekciójába beszúrjuk, hogy

ez megadja, hogy milyen címen foglalja le a userdata-t.
Van még egy rész, amit beszúrtam a linker file SECTIONS részhez:

Bevallom, nem tudom, hogy ez mit jelent, de a netes forrásokban ez is ott volt.

Miért pont 4096 elemű a tömb?
A Flash-t csak szektoronként lehet írni, vagyis írás előtt törölni kell az adott szektort.
Ha jól gondolom, akkor törlés előtt a szektort ki kell olvasni egy átmeneti tárba, törlés után a szükséges byte-okat az átmeneti tárban átírni, és az egészet visszaírni a Flash-be. Így kerülhető el, hogy a szektor azon területe ne sérüljön, amit nem akarunk felülírni. Az STM32F4-ben a legkisebb szektor 16kB. Mivel a kontrolleremben 512kB Flash van, nem fáj, ha egy egész szektort lefoglalok. Így a fenti kiolvas-átír-visszaír procedúrát megúszom, mert nem gond, ha a kimenteni kívánt adatokon kívül a szektorban minden más törlődik.
Akkor itt az írás:

Ennyi. Az írásnál meghívott fv-ek az STM32 Standard Peripheral Library-ban találhatók.
Nem állítom, hogy a fenti módszer/kód tökéletes, pláne azt, hogy másképp nem lehet csinálni, de úgy tűnik, hogy legalábbis nálam működik.

Igen, ezt jelenti. A szovegszerkeszto kell, mert mindenre hasznalom. A gcc-t felteszem ARM-hez, AVR-hez, mindenhez, amihez kell. A nativ C fordito (linux-ra) eleve font van. Az osszes tobbi utility szinten adott. A UNIX-ot arra talaltak ki, hogy fejlesszenek rajta. Ez azt is jelenti, hogy elvarja a hasznaloitol, hogy ertsen a szamitastechnikahoz, tisztaban legyen a programozas alapjaival. A windowst arra talaltak ki, hogy a mikroszoft milliardokat keressen rajta. Mas volt a cel, ennek megfeleloen az eredmeny is mas lett...

Köszönöm a részletes ismertetést!

Nekem is van stm32f407v, és most bővült a repertoár SAM3X8E-assal.
Mind 2-ből nagyon hiányzik a EEPROM!

Mihelyst lesz, rá időm kipróbálom. Bár én meg pont Keilt használok, remélem össze fog jönni!

Keil-hez így lehet lefoglalni területet a Flash-ben:

és ez az "at" feleslegessé teszi a külön linker file szerkesztését. Szerintem elegáns, kár, hogy a GCC nem használja.

A linker file ugyanolyan resze kell legyen a projektnek, mint barmelyik C forras. Ennek kicsit ellentmod az IDE-kben talalhato kozponti linker script-ek. Ugyanis a linker script nem processzor fuggo dolog (kellene legyen), hanem projekt fuggo. Sokszor jo ugyanaz a linker file mas projektekhez, de ettol meg nem kell altalanositani. Az egesz leforditott cucc elhelyezkedeset a linker script hatarozza meg, ezert kell ott beallitani, hogy egy adott szegmens hova keruljon.

Itt a "10" Az Byte vagy KByte foglalás?

Jó lenne, ha a Gcc változatot az Arduino IDE ARM-os részébe is be lehetne illeszteni.
(Mert igény lenne rá.)

Egyik sem. A példában csak egy int konstansnak foglal helyet, amelynek értéket is ad(hat), ez a 10.
Ugye alap esetben egy const változó értékét nem írhatod át futásidőben, az a program futása alatt végig ugyanazzal az értékkel rendelkezik (ezért sem árt neki fordításkor értéket adni). Nem is igazi változó. Ezért is menti a fordító a ROM-ba, és nem a RAM területen találod. Jó példa erre mondjuk ha egy grafikus LCD-hez a pixelenként megrajzolt betűidet egy nagy const tömbbe pakolod, az a program memóriából fog területet elvenni, mert a fordító egybe fordítja a programmal.
Ahogy mondtam, alapesetben. Mert a fentebbi flash-írásos példában ezt a const változó számára foglalt területet írjuk át.

Rossz volt a Keil-es példám, így kellett volna, ha teljesen a GCC-snek akarom megfeleltetni:

ha pedig kezdő értéket is akarsz adni neki:

Ebben az esetben az első 4 int helyet feltölti egymás után 1-gyel, 2-vel, stb, a maradék 4092 helyet pedig 0xFFFFFFFF-fel. Igazából már a törlés után lesz minden FF a szektorban, utána írja át az első helyeket az általad megadott értékekre. Vagy ha épp úgy akarod, mind a 4096 db int tárolónak, vagy pl. 16384db byte méretű tároló helynek adhatsz kezdő értéket.

AzArduino a maga egyszerű nyelvén kevés dologra lenne használható, a fapados szerkesztőjével!

De éppen azért lett népszerű, mer Gcc libekkel fejleszthető.
És ugyanazt a „arm-none-eabi-gcc” használja, mint az összes többi IDE.
Már van STM32-es szekciója is, bár még nem próbáltam.

Most az Arduinu-due SAM3X8E-assal ismerkedem.

Dehogynem igazi valtozo. Csak az erteke nem valtoztathato. De attol meg az valtozo. Az, hogy hol lesz neki hely foglalva az architektura fuggo dolog. Pl. ha irsz egy programot PC-re, ott a const valtozok ugyanugy RAM-ban lesznek, mint a tobbi valtozo vagy a kod maga. De bizonyos Harvard architekturas processzorokon szinten RAM-ban lesznek a const valtozok, mert a flash-t nem tudja ugyanugy elerni a processzor, mint a RAM-ot. Ilyenkor a RAM-ban van helye a valtozonak, onnan is olvassa a program menet kozben, de a flash-ben van ektarolva a kezdoerteke. A program indulasa elott egy startup kod (altalaban a crt0) atmasolja az inicializalt const data-t a RAM-ba. Ugyanez a crt0 masolja szinten flash-bol a ram-ba az tobbi inicializalt valtozo erteket is, es inicializalja a .bss szegmenst nullara, ahol a nem inicializalt valtozok vannak. ARM-en a cost data flash-ben van, mert onnan is pont ugy tud olvasni a CPU, mint a RAM-bol.
Akkor regen baj van, ha nem nullaval tolti fel. A C definicio szerint a nem inicializalt valtozok (kivetel az auto valtozok) nulla erteket vesznek fel a program indulaskor. Ha ez nem igy van, na akkor tenyleg nem igazi valtozorol beszelunk, de nem is szabvanyos C-rol.

Mea culpa. Benéztem.
Helyesen: közvetlenül a Flash törlése után a törölt szektorban 0xFF értékek olvashatók ki, de utána a const változó kezdő értékének beírásakor a maradék helyek nullákkal töltődnek fel.
Köszi killbill.

Sziasztok!
Segítségre van szükségem. 64 lábú STM32F205-öt programoztam SWD-n keresztül, és az utolsó programmódosítás óta nem látja a programozó a kontrollert.
Megnéztem a programomat, és egy szerencsétlen elgépelés következtében, amikor is az SPI1-et inicializáltam, rossz AF regisztert írtam át, és így az SWDIO, SWCLK, valamint a JTDI lábakat szépen átállítottam AF5-be. Szerintem ezért nem látja a programozó a kontrollert.
Vissza lehet ezt még hozni valahogy az életbe, vagy végleg sikerült téglásítani a kontrollert?

Hoppá!
Beállítottam az ST-LINK Utility-ben a "Connect under reset"-et, és elkezdtem a mikrokontroller resetét nyomkodni, közben a programozó alkalmazásban a kapcsolódás gombot szintén nyomkodtam. Sokadjára újra kapcsolódott, így újra tudtam programozni a kontrollerem.
Most örömködöm, úgy látszik a tervezők gondoltak az olyan bénákra is, mint én.

Sziasztok!
Én is belevágtam az ARM világába, így beszereztem egy STM32F407 discovery kitet. Most ott tartok, hogy IDE-t válasszak, illetve olvasom az ST-s pdf-eket. Hosszú távra tervezek, és itthoni használatra csak ingyenes jöhet szóba, amiben lehetőleg nincsenek korlátok. Egyelőre Eclipse és CooCox között gondolkozok. Az Eclipse azért lenne jó, mert azt már picit ismerem, viszont a CooCox talán jobban "össze van rakva".
Nyelvnek egyértelműen a C, bár ha ASM hozzáférési lehetőség is van, az pozitívum.
Szóval ezügyben kérném a tapasztaltaktól a véleményeket.
Előre is köszönöm!

Ha visszaolvasol a fórumban, időről-időre felbukkannak hasonló kérdések.

Az Eclipse és a CooCox nem említhető egy szinten, mert a kettő nem ugyanarra való. Míg a CooCox egy komplett IDE (a háttérben egyébként itt is Eclipse-et használ), az Eclipse egy Java-ban írt keretrendszer, amit IDE-kben, fejlesztőrendszerekben szoktak használni. Vagyis ha az Eclipse-et akarod használni, ahhoz még telepíteni kell egy fordítót (pl. GCC, ami szintén ingyenes), pluginek kellenek, meg az egészet be kell állítanod.
A CooCox-ban minden megvan egyben, sőt még példaprogramok is vannak hozzá, ami azért nagy segítség az elinduláshoz. Tehát én inkább ezt javaslom.
Az Eclipse használata IDE-kben szerintem egy rossz divat. Mivel Java-ban íródott, ezért iszonyatosan lassú, és nagy tárhelyet is foglal. A CooCox-ban némileg optimalizáltan van jelen, de még az is elég lassúcska.
Ha Windows-t használsz, én inkább az Em::Blocks-ot javaslom. Szintén ingyenes, minden benne van, az elinduláshoz szükséges kódokat is létrehozza. Ráadásul gyorsabb, mint a CooCox.

Olvastam a topicot, de nem tudtam eldönteni, melyiket is kéne használni, ezért kérdeztem. Nade! Köszönöm hogy írtál.
Az Em::Blocks-al lehet programot is betölteni a discovery panelen lévő ST-LINK/V2-vel?

Erre az egyre tényleg nem lehet használni, de az eredeti ST-link Utility ezt remekül megoldja. A kettő rendben elfut egymás mellett, csupán két ablak között váltogatsz a fejlesztés/programletöltés során. Tehát szerintem ez nem lehet probléma.
Ráadásul az Em::Blocks-ban szépen lehet debugolni az ST-link V2-t használva. A CooCox is alkalmas lehet erre, én azt csak régebben próbáltam, akkor valami miatt a debug nem ment, de azóta pár verzió kijött, szóval lehet javították.

Szóval debuggolni lehet az ST-link V2-vel, de programozni nem? Ez kicsit furcsa.
Apropó debug. Akkor ez tud olyat, hogy a program futását az IDE-ből indítom, és mondjuk a C kódban egy sorhoz rakok töréspontot, ahol megáll a program, ha odaér az ARM?

Így van. A debug-hoz egy beépített plugint használ, az kezeli az ST-link V2-t.


Igen. Közben láthatod a változóid és a regiszterek pillanatnyi értékét is, valamint azt is mutatja, hogy hogyan néz ki a C kódod ASM-ben.

Viszont ahogy nézem, alig van hozzá leírás. Egy hello world (pl. LED bekapcs) programot se találtam.

Nincs sok leírás az igaz, de emlékeim szerint nekem nem hiányzott, mert jól átlátható IDE.
Azért itt van néhány dolog: Em::Blocks Wiki
Többek között a Hello World is ott van. http://www.emblocks.org/wiki/tutorials/f401_f429_disco/debugging_ideas
Van benne Coocox project-import, Coocox-hoz meg rengeteg példaprogramot tölthetsz a netről.

Az emblocks-ban is lehet programozni, igaz kell hozzá telepített stlink utility.

Tools -> Configure tools -> Add

Name: ST-Link
Executable: C:\Program Files\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
vagy
C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
Parameters: -c SWD UR -P "${TARGET_OUTPUT_DIR}${TARGET_OUTPUT_BASENAME}.hex" 0x08000000 -V "after_programming" -Rst -Run
Working directory: ${PROJECT_DIR}

Ezután a Tools/ST-Link-re kattintva tudod feltölteni a programot. Így egy kicsit kényelmesebb mint kintről.

Sejtettem, hogy valamiképp meg lehet oldani, de ezt én sem ismertem. Köszi.

Köszi!

toto:
Felraktam a CooCox-ot (a régit, mert az új bugos), az EmBlocks nekem egyelőre túl zavaros. Most sikerült CooCox-al már a procin kimenetet állítani. Csak a fordítót kellett megadni neki, és egy gombnyomásra már be is rakta a progit...
Egyébként akármelyik IDE-t használom, mindenhol szükség van ennyi header meg C fájlra?
Most egyébként ezt próbáltam ki: Bővebben: Link
Remélem csak az elején tűnik ilyen végtelenül zavarosnak és bonyolultnak ez az ARM fejlesztés.. Nem azt mondom hogy legyen PIC18F szintű, csak lehessen legalább a C részét átlátni.

A Coocox sem rossz IDE, kicsit másképp áll az ember kezére, mint az Em::Blocks.

A használt header és library file-ok - amikkel sokat fogsz még találkozni az STM32 programozása során - az ST Standard Peripherals Library részei. Az ST Microelectrinics pont azért készítette, hogy különböző perifériák használatához ne kelljen minden egyes regisztert külön állítgatni. Ezeket perifériánként, funkciónként külön file-ba rakták, hogy áttekinthető legyen. Használata az egyes kontrollerek közötti váltást is megkönnyíti.
Nem kötelező használni, én pl. nem igazán szeretem, inkább állítgatom a regisztereket egyenként. Persze így lassabb a fejlesztés.
Sőt, ennyi file-t sem kell használni, rakhatod az egész programod egy file-ba, de előbb-utóbb az válik áttekinthetetlenné.
Ahogy egyre bonyolultabb dolgokat fogsz megoldani ARM-mel, kitisztul ez a zavar.

Világos.
Most valami olyan leírást keresek, amivel átláthatóbb az ARM működése, főleg gyakorlati oldalról, mert eddig egy nagy katyvasz van a fejemben.