ARM - Miértek hogyanok - Hobbielektronika.hu - online elektronikai magazin és fórum

Hobbivasút | HESTORE | Receptoldal | Kislexikon

Fórum témák

Fórum » ARM - Miértek hogyanok

Témaindító: gtk, idő: Jún 26, 2007

(#)	cimopata válasza kapu48 hozzászólására (»)	Júl 9, 2017		/

Azért mert utána azokra a címekre mentem az adatot,de nem feltétlenül van lementve adat az FFFF érték pedig problémát okoz.

(#)	kapu48 válasza cimopata hozzászólására (»)	Júl 10, 2017		/

Még próbáld ezt a megoldást:

uint32_t Address = 0x08007C00; 
uint16_t Data = 0x1234;
        
*(__IO uint16_t*)Address = Data;

(#)	kapu48 válasza cimopata hozzászólására (»)	Júl 10, 2017		/

Még próbáld ezt a megoldást:

uint32_t Address = 0x08007C00; 
uint16_t Data = 0x1234;
        
*(__IO uint16_t*)Address = Data;

Itt találsz komplet megoldást rá:
EEPROM emulation in STM32F40x/

A hozzászólás módosítva: Júl 10, 2017

(#)	SBahadurD válasza cimopata hozzászólására (»)	Júl 10, 2017		/

Sima C nyelvi elemekkel való trükközéssel ez nem fog menni. Vagy támogat a fordító valamilyen direktívát, amivel egyből adott címre tudsz fordíttatni változót, vagy a linker fájlban kell megmondani a linkernek.

(#)	kapu48 válasza SBahadurD hozzászólására (»)	Júl 10, 2017		/

Olvasni való a témában: EEPROM emulation in STM32F40x.pdf
Bővebben: Link

(#)	SBahadurD válasza kapu48 hozzászólására (»)	Júl 10, 2017		/

Én ezt értem. De ez nem arról szól, hogy fordításkor a linkert utasítsuk egy adott változó adott területen való elhelyezésére.

Egyébként a Keil fordítónál elvileg az "at" módosító kulcsszóval lehet fix területre tenni változót de akkor nem lehet neki kezdőértéket adni. (Ez érthető is, eléggé elbonyolíthatná és kódfüggő startup kódot kéne generálni hozzá.) Tudom, ez így kezdőérték nélkül nem megoldás...

(#)	kapu48 válasza SBahadurD hozzászólására (»)	Júl 10, 2017		/

Azért linkeltem, hogy Cimopata olvassa el!

Ebből rájön, hogy másképpen kel ezt csinálni.

(#)	csatti2 hozzászólása	Júl 10, 2017		/

Én nem használok uVision-t, de valahogy így fog működni.

Ezt nézd át.
Majd módosítsd úgy az átmásolt linker scriptet, hogy a .data szekció elé beszúrod a kivánt fix címeket.
pl.:

.image 0x08060000:
        {
        } > ROM
 
        .font 0x0806B000:
        {
        } > ROM
 
        .patch 0x08074000:
        {
        } > ROM
 
        .str 0x0807B000:
        {
        } > ROM

Ezután a kódodhoz add hozzá pl. ezeket:

#define FONT                              __attribute__((section(".font")))
#define IMAGE                             __attribute__((section(".image")))
#define PATCH                             __attribute__((section(".patch")))

Majd a változókat így deklaráld pl.:

static const unsigned char seriffont[] FONT = {
  0x00, 0x20, 0xFF, 0x08, 0x10, // Data mode, min char, max char, width, height
  0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // Code for char
  0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF0, 0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // Code for char !
.
.
.

(#)	kapu48 válasza csatti2 hozzászólására (»)	Júl 10, 2017		/

Sajnos ilyenkor derül ki, hogy milyen keveset tudok!

Az Keil-be nem tudom hova rakjam a linker részt?

Ezt találtam, amit ír linkernek:
STM324xG_EVAL.sct

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
 
LR_IROM1 0x08000000 0x00080000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00080000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   }
                                  
  RW_IRAM1 0x20000000 0x00020000  {  ; RW data
   .ANY (+RW +ZI)
  }
}

Ez van benne. De ide nem fogadja el a fenti sorokat.
Ezt nem ismeri fel: > ROM

(#)	csatti2 válasza kapu48 hozzászólására (»)	Júl 10, 2017		/

Mert ez egy scatter file és nem egy linker script. Mint mondtam én nem használok uVision-t, de ha jól értettem, amit olvastam a GNU-ARM fordítója linker scriptet használ, az MDK-ARM pedig scatter file-t. Keress példát a scatter file-ra.

(#)	kapu48 válasza csatti2 hozzászólására (»)	Júl 11, 2017		/

Próbálkoztam, kerestem útmutatást.

GNU ARM Linker

De csak RAM foglalásra találtam megoldást, a fix ROM terület foglalásba mindenkinek beletört a bicskája.
CODE Linker Directive
Az a baj, hogy mintát nem találok, ezt meg nem igazán értem!

Configuring Linker Options
Itt próbálkoztam. Felosztottam a FLASHT, a végéből levágtam 2*64KBytet.
Ez lett az IROM2. Így automatikusan generálta a linkert:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
 
LR_IROM1 0x08000000 0x000F8000  {    ; load region size_region
  ER_IROM1 0x08000000 0x000F8000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  RW_IRAM1 0x20000000 0x00020000  {  ; RW data
   .ANY (+RW +ZI)
  }
}
 
LR_IROM2 0x080F8000 0x00008000  {
  ER_IROM2 0x080F8000 0x00008000  {  ; load address = execution address
   .ANY (+RO)
  }
}

Most kellene ötlet, hogyan használjam ezt a ER_IROM2 területet?

Köszi minden segítséget!

(#)	kapu48 válasza kapu48 hozzászólására (»)	Júl 11, 2017		/

Próbálkoztam fix cím megadásával:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
 
LR_IROM1 0x08000000 0x000F8000  {    ; load region size_region
  ER_IROM1 0x08000000 0x000F8000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  RW_IRAM1 0x20000000 0x00020000  {  ; RW data
   .ANY (+RW +ZI)
  }
}
 
LR_IROM2 0x080F8000 0x00008000  {
  ER_IROM2 0x080F8000 0x00008000  {  ; load address = execution address
  *.data    (0x080F8000) 
 
   .ANY (+RO)
  }
}

De valamit hiányol még!:

Idézet:
„*** Using Compiler 'V5.06 update 3 (build 300)', folder: 'C:\Keil_v5\ARM\ARMCC\Bin'
Build target 'Discover-More'
linking...
.\Discover-More\Project.sct(18): warning: L6314W: No section matches pattern *.data(0x080F8000).
Program Size: Code=51964 RO-data=14432 RW-data=2924 ZI-data=37532
Finished: 0 information, 1 warning and 0 error messages.
FromELF: creating hex file...
".\Discover-More\Project.axf" - 0 Error(s), 1 Warning(s).
Build Time Elapsed: 00:00:02
”

???

(#)	cimopata válasza kapu48 hozzászólására (»)	Júl 11, 2017		/

Egyenlőre ezzel a megoldással feladom én is használom azt amit írtam az elején aztán ha ha élet úgy hozza kísérletezem ezzel is. Köszönöm azért a segítséget.

(#)	kapu48 válasza cimopata hozzászólására (»)	Júl 11, 2017		/

Én is megvoltam eddig nélküle. Csak a kíváncsiságból próbálkoztam megoldani.

(#)	SBahadurD válasza cimopata hozzászólására (»)	Júl 12, 2017		/

Tudom, hogy ez nem Keil fordító, hanem GCC, de nekem működött.
Bővebben: Link

Kipróbáltam és a Flash végébe szépen beletettem egy konkrét értéket egy konkrét címre. Arra figyelni kell, hogy más szekcióba ne lógjon bele, különben hibát fog dobni a program (ami teljesen érthető és jogos felháborodás részéről

(#)	kapu48 válasza SBahadurD hozzászólására (»)	Júl 12, 2017		/

Ez RAM-ban foglal területet. Ez működik nekünk is.

Mi viszont a ROM-ban akartunk fix címre rakni adatokat.
Mert akkor szektor határra tudnánk igazítani, hogy később manipulálni tudjuk.

(#)	kapu48 válasza SBahadurD hozzászólására (»)	Júl 12, 2017		/

Ez is hasonlóan nézki:
Bővebben: Link

Csak nem tudom lefordítani, mert mindig hibát jelez.

(#)	SBahadurD válasza kapu48 hozzászólására (»)	Júl 12, 2017		/

Igen, bocsi. Ez alapján indultam el, de a címet és a memóriablokkot átírtam úgy benne, hogy a Flash-be foglaljon területet. A generált bináris fájlban a várt helyen ott is volt az érték.

(#)	kapu48 válasza kapu48 hozzászólására (»)	Júl 12, 2017		/

Aludtam a problémára egyet.

És felhagytam a linker babrálásával!
Csináltam egyszerűen ezt: (STM32F407VGT)

static __I unsigned int variable2[] __attribute__((section(".ARM.__at_0x08078000"))) = {0x11111111, 0x22222222, 0x33333333, 0x44444444, 0x55555555, 0x66666666, 0x77777777, 0x88888888, 0x99999999, 0x00000000};