Fórum témák
» Több friss téma |
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.
Még próbáld ezt a megoldást:
Még próbáld ezt a megoldást:
Itt találsz komplet megoldást rá: EEPROM emulation in STM32F40x/ A hozzászólás módosítva: 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.
É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...
Azért linkeltem, hogy Cimopata olvassa el!
Ebből rájön, hogy másképpen kel ezt csinálni.
É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.:
Ezután a kódodhoz add hozzá pl. ezeket:
Majd a változókat így deklaráld pl.:
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
Ez van benne. De ide nem fogadja el a fenti sorokat. Ezt nem ismeri fel: > ROM
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.
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:
Most kellene ötlet, hogyan használjam ezt a ER_IROM2 területet? Köszi minden segítséget!
Próbálkoztam fix cím megadásával:
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 ” ???
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.
Én is megvoltam eddig nélküle. Csak a kíváncsiságból próbálkoztam megoldani.
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 ).
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.
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.
Aludtam a problémára egyet.
És felhagytam a linker babrálásával! Csináltam egyszerűen ezt: (STM32F407VGT)
És feltöltés után lás csodát, a megadot címen helyén voltak az értékeim. A hozzászólás módosítva: Júl 12, 2017
üdv.
Az új 1.8 as F030 as driver-ben eléggé megválzotztak a dolgok és csomószor nem tudom értelmezni mi hogy van amit még korábban az 1.4 es driverrel egyértelmű volt számomra. Bemásolnék 1 példát a TIMER3 egyik regisztere ami beállítja milyen polarítással billenjen a bemeneti impulzusnál. 1.4 driver:
Ez egyértelmű nincs mit hozzáfűzni csak megszámolom hogy melyik bitre esik az adott hexa de itt van az új 1.8-as driver aminél teljesen másképp van:
Esetemben ezt a 3-at használom de nem vagyok biztos hogy a régi és az új driverrel ugyan azt álítja e be. TIM3->CCER |= TIM_CCER_CC1E | TIM_CCER_CC2E | TIM_CCER_CC1P; Mik ezek az (1U) (0x1U) stb a kódban hogy kell ezt értelmezni? A hozzászólás módosítva: Júl 23, 2017
Természetesen ugyanazt állítja be. Nem hülyék, hogy elrontsák a visszafelé kompatibilitást, ha nem muszáj.
Az új Pos és Msk pedig hasznos lehet olvashatóbb kód írásakor (hasonlóan néz ki az Atmelnél is az ATXMega család kódja).
Értem és hogyan értelmezzem ezeket az 1U 0x1U dolgokat?
Az U-val tipizálja a konstanst unsigned int-ként, így egyértelmű lesz a műveletek végeredménye.
Üdv!
Egy rövid leírást kérhetnék valakitől a DMA ping-pong mód működéséről? Nem regiszter szinten, csak a lényegét illetően. Utána olvastam, de kifog rajtam, a manual pedig pár mondatos ez ügyben.(LPC)
Kezdőként én is mindenáron bootloader-t akartam az ARM-ra rakni, azóta nem akarok.
Van 4 tüsid, arra simán rákötheted az OpenOCD-t és tudsz vele debuggolni is. Még a legegyszerűbb kínai utángyártott klón is tudja 700 HUF-ért. Igen, két USB kábel fog lógni a cuccról egy helyett (táp és programozó), de inkább két kábel lógjon, mint hogy Serial.println-nel szórakozzak 256KB-os kódban. Elvileg az AVR-t is lehet debuggolni, de messze nem annyira pofon egyszerű és magától értetődő, mint ARM-on. Egy eset lehet, ha mondjuk Wifi-n akarod az ARM chipjeidet webszerverrel felprogramozni, de igazából ehhez sem kell bootloader, mert a megfelelő pinek állításával UART segítségével a legtöbb ARM programozható bootloader nélkül is. A bootloader AVR alatt megkerülhetetlen, de ST alatt simán megvagy nélküle is. Legalábbis szerintem. A hozzászólás módosítva: Aug 8, 2017
Nincs mindenben igazad. Én pl. arra használom a bootloadert a fejlesztői kártyáimon, hogy átirányíthassam a programom kezdő címét és így kíméljem a flasht.
A debuggolás pont ugyanolyan jól megoldható AVR-nél is mint az ARM-oknál, csak normális programozóra van szükség, nem ilyen USBASP féle borzalmakra. Rendes programozóval látszanak a regiszter állapotok, a live értéke a változóknak stb., pont úgy mint mondjuk egy STMicro-nál, lásd képen. Annyi nehezítés valóban van, hogy nem ugyanoda tették minden chipnél a debug-ot, illetve nincs mindig debugWire (ATMega esetén, ATXmega-nál már más van, az jobb).
Csatti2 ajánlotta az STM32F103-at, ehhez fogok venni egy fejlesztői panelt és kiprobálom, hogy mit tud.
Majd a kész projektre, (ami kb. 1 éve készül, de még a tervek sincsenek meg), egy USB3-as dugaszt terveztem tenni, a sima USB felébe (ahova talál a sima microUSB is) bekötném az USB lábait(+5V, D+,D-, GND, így megoldódna a töltés+a memókártyáról a fájlok átmásolása gépre), míg a másik felébe tennék két UART-ot (RX1, TX1, RST, RX2, TX2), az egyik UART-ra rákötném a külső wifi/ 433mhz/ RFID modult míg a másikkal használnám az UART bootlodert. Vagy tegyek még egy dugaszt a debuggolásra és ne legyen bootloader?
Kérésre az AVR topikból áthelyeztük ide azt a pár OFF hozzászólást.
Ha majd megnézed az STM32-es fejlesztői kártyádat, észre fogod venni hogy van rajta két állítható kapcsoló vagy jumper BOOT0 és BOOT1 néven. Az eszköz ugyanis gyárilag tartalmaz egy kitörölhetetlen bootloader-t, amely a használt mikrokontrollertől függően lehetővé teszi a firmware update-t USART-on, USB-n illetve CAN buszon keresztül és neked ehhez nem kell külön szoftvert írnod.
Éppen ezért használhatod az USART1-et mind debug üzenetek írására (vagy fogadására), mind pedig a BOOT lábak beállításával bootloaderes firmware frissítésre. |
Bejelentkezés
Hirdetés |