Fórum témák
» Több friss téma |
DMA van? Nem piszkíthat oda? linker fájlod hogy néz ki?
Sziasztok,
Adott egy STM32F103C8T6-al szerelt kinai nyák és egy fehér klón ST-link. Az STM32-t sikerült uart--ttl átalakítóval programoznom, sőt a demo USB-s példák is működnek. Tegnap összekötöttem az ST-Link-kel, ha tízszer nyomom meg az olvasás gombot, akkor mind a tízszer kiolvassa a tartalmát, de ha a verify gombot nyomom meg, akkor végigmegy a kiolvasáson majd a képen látható hibaüzenet jelenik meg. A kérdésem az lenne, hogy mit jelenthet az alábbi üzenet? Normális dolog, hogy megjelenik? A választ előre is köszönöm! A hozzászólás módosítva: Jún 4, 2019
Nem ismerem a Keil-t, de pl. GCC-nél van egy kis assembly kód, amit beszúr a program elejére a linker. Ez a kód állítja be a vektortáblát, a stack és program pointereket, illetve tölti fel a memóriaterületeket az induló értékekkel (nullázás, illetve kezdő értékek beírása). Azonban ezt a kódot nem mindig írják meg úgy, hogy több különböző memóriaterületet is kezeljen (pl. a CCM területre nem csinálja meg az F4-es sorozatnál az alapkód, át kellett írnom, hogy ott is működjön). Gyanítom, hogy a H7-esnél is több memóriaterület áll rendelkezésre (nem használtam még).
Sziasztok!
Ha valaki tudná a hiba okát? Légyszives segitsen!
Error:
Köszönöm! A hozzászólás módosítva: Jún 8, 2019
Mint abszolút hozzá nem értő, lőnék egyet a levegőbe. Az
A hozzászólás módosítva: Jún 9, 2019
Úgy emlékszem a Keil-ben static __inline van, GCC-ben static inline, de ezt a definiálást a core_xx.h elvileg megoldja. Esetleg próbáld meg így: __STATIC_INLINE.
SMULWB egy signed word és egy signed half word szorzása. int32-t lenne a helyes paraméter szerintem.
Köszi, a próbálkozást!
Sajnos csak annyit segített, hogy valami irányt mutattál merre induljak el. A javaslatod kipróbáltam. De a hiba maradt ugyan az. Az eredeti project itt van: Bővebben: Link CubeMX-ben IDE: SW4STM32! Ezt sajnos még hírből sem ismerem! Próbáltam, MDK_ARM V5-re fordítani. A két IDE között lehet valami szintaktikai különbség? De mi? A hozzászólás módosítva: Jún 9, 2019
Sajnos ez a megoldás nekem még magas!
Próbálom behelyettesíteni, mivel csak egyszer hívja az egész programban. Csak nem igazán értem. Össze szedtem az alkalmazásban szereplő változók definiálását egy oldalra, hogy legen valami rálátásom. Az utolsó sort kellene átalakítani, hogy kihagyjuk a __SMULWB() hívását.
Valami ötlet, vagy tanács, jól jönne. A hozzászólás módosítva: Jún 9, 2019
Végül egy szorzássá és típus módosítással megoldottam.
Kérdés, hogy eredménynek ugyanazt kapom e?
Nálam STM32F4-re Visual GDB GCC-vel fordult.
Te GCC-t használsz fordításthoz? Meg esetleg próbáld meg F4-re lefordul-e.
Az Atollic nem importálja SW4STM32 project-et? Még nem próbáltam, csak olvastam valahol, hogy igen.
Már megvan az Open746I-C Standard STM32F7 Development Boardom.
Még akarok rá TFT is pakolni, és a gyors sinus hullám számoláshoz kel ez a CPU. Nem akarok vissza menni F4xx-re. Remélem fog ez így is működni. Tulajdonképpen azt nem értem, miért kellet ennyire túlbonyolítani két érték összeszorzását? A hozzászólás módosítva: Jún 9, 2019
Kijavítanám az eddigi tévelygéseimet.
Mivel közben utána olvastam, és rájöttem, hogy a kritikus program részlet a memória bővítések használatához szükségesek. És hogy működjön ahhoz módosítani kel a linker-criptet: (STM32F765VITx_FLASH.ld). Mivel én módosítottam a környezetet: (STM32F746ZETx_FLASH.ld)-re és ezt elmulasztottam javítani. Még további ismeretek beszerzésére van szükségem! A hozzászólás módosítva: Jún 11, 2019
Sziasztok!
Tudja valaki, hogy mi történt az Embitz.org-gal? Én ezt az IDE-t használom STM32-höz, és nagyon sajnálnám, ha megszűnne a fejlesztése. Igaz, hogy már korábban sem volt túl aktív a fejlesztő, de időnként azért jelent meg új verzió, fórum is működött. Most pedig már hónapok óta elérhetetlen az oldal. Nézegettem, hogy esetleg mire lehetne váltani a jövőben. Az Atollic Truestudio ingyenessé vált, de aztán STM32-re specializálódott, mivel az ST felvásárolta. Ahogy nézem, összegyúrták az STM32CubeMX-szel, és most STM32CubeIDE néven fut. Eclipse alapú, amitől viszolygok. Van valamilyen másik ingyenes, jól használható, aktívan fejlesztett IDE? Most a Keil-t hagyjuk, az tudtommal csak 32k-ig free. (OK, az Embitz-et is lehet tovább használni, de nincs fórum, a kényelmes projekt generátor nem foglalkozik az új kontrollerekkel, HAL-lal, egy dark theme sem lenne rossz, stb )
Ha belefér némi befektetés én a VisaulGDB ajánlom 1 évig van update utána használhatod a licence időben elérhető legújabb verzióig örökké.
Én Microchipen nevelkedtem MPLAB X-el (Netbeans) majd elkezdtem Silabs-al foglalkozni (Simplicity, Eclipse) majd használtam valamilyen szinten a keil-t is valamint mostanság elkezdtem STM32-vel foglakozni így ránéztem a TrueStudio-ra is. Mindezek alatt winsoft fejlesztésre használtam a Visual Studio-t is. Az én véleményem ezekről: (ez csak összehasonlításnak) MPLAB X - valamivel szerintem jobb mint az eclipse, de 50 fáj kb 20-40 percenkét szidód azt aki kitalálta a javát Eclipse alapú (Simplicity, TrueStudio) - instabilabb volt nálam mint az MPLAB (32 GB RAM-al sem igazán békéltem meg egyikkel se) viszont nagyon sok mindent tudsz az IDE-ben configolni. (de úgy láttam te se kedveled) Keil - stabil, de nekem nem elég moderni az IDE, kicsit gyenge szerintem benne a CodeAssitance/CodeCompletin/InteliSense (ki melyik néven szokta emlegetni) Visual GDB - Visual Studio-ban tudsz ARM-re fejleszteni rengeteg example van náluk, hogy mit hogyan lehet csinálni. Szerintem az előző IDE-khez képest messze ez tudja a legtöbbet ez tudja valamint ebben van rendes dark theme is. Valamint ha Cube-ot használt cube-os projetből is tudsz projektet létrehozni. A Visual Studióban a legértelmesebb a dark theme itt csak egy click a többiben szenvedni kell. Ez viszont nem ingyenes itt (az embedded kell) meg tudod nézni megfelel-e ez az opció neked. Szerk.: Vagy esetleg a Visual Studio Code, de én csak a platformot ismerem sose használtam microcontroller-hez csak tudom, hogy lehet ahhoz is használni. A hozzászólás módosítva: Jún 14, 2019
EmBitz jó volt, megszűnt. Vége.
Keil drága, régies a felülete. Eclipse-t szintén utálom. Ha akarod, saját magad össze tudod legózni, hogy a kedvelt szövegszerkesztőd meghívja a make-t, aztán pedig a szükséges ARM uploadert. Ha mindezt készen szeretnéd, és még kiváló debug is kellene, akkor egyetértek az előttem szólóval: Visual Studio Community (free) + VisualGDB ($99)
Mivel itthon csak hobbi célra fejlesztek, így a közel 30e forintos ár kicsit soknak tűnik. Pedig egészen ígéretes a VisualGDB a honlapon látottak alapján.
Nézegetem a VisualStudio Code-ot is. Nem tudtam, hogy olyan kiegészítőket is készítenek hozzá, amikkel mikrokontrollerre is lehet fejleszteni: pl. STM32 for VSCode. A legózást el akartam kerülni, de lehet, hogy ezekkel nem olyan nehéz összerakni egy jó rendszert. Ha pedig mégsem sikerülne, akkor az a 99$ fog kevesebbnek tűnni. Köszönöm a javaslatokat.
Esetleg még ezzel lehet érdemes foglalkozni, de mikor ezt megtaláltam már volt visual gdb-m úgyhogy nem szenvedtem vele, így tapasztalatom sincs róla.
Még egy dolog ami a visual studio mellet szól és ezt egyik IDE se tudja. Ha véletlen C++ irányba terelődsz (lehet C-ben is segítség) ott ugye be jönnek a class-os és vegyünk egy C++-ban elég alap class-t a string-et ami egy (kb) komplex osztály és ezt debug közben nézni kényelmetlen viszont itt van Natvis amivel komplex osztájt úgy tudsz a watch-ban megjeleníteni ahogy akarsz. Valamint ha C string-et használsz és karaktertípusú a típusod akkor automatikusan tudja, hogy string és kiolvassa '\0'-ig (lehet lassítja a debugot, de nem hiszem, hogy ez lenne a fő lassító indok) ezt sem tudja más ide csak szenvedéssel. És ezt lehetne sokáig sorolni. De ha hobbi, ha munka bárkit kérdezel aki használta szerintem azt fogja mondani, hogy egy nagyon jó befektetés (és a VS2019-et is támogatja már + embed-ből is tudsz importálni). (erős vélemény, de) Szerintem ez az egyetlen használható ide a többi egy rakás ... Ja és azt elfejtettem említeni, hogy az embitz-t ránézésre láttam régen. Ha azt sokat használtad a visual studio kényelmes lesz mivel az embitz erősen hajaz/hajzott a VS-re Idézet: „egyetlen használható ide a többi egy rakás ...” Látod, ennyire dilettánsok az ST-nél. Fizettek egy rakás Atollic-ért, mikor már volt egy támogatott, ingyenes IDE (SW4STM32). Hobbi szint, nem kell rögtön a pénztárhoz rohanni. A VScode is sokat tud segíteni, ha nem tetszik és Linux is létezik, jóval kisebb hardver igénnyel az op. rendszer részéről.
Szerintem messze nem csak ST oldalon megfigyelhető a "diletancia".
A legtöbb gyártó valamiért erős prioritásnak érzi a cross platformot, de egy java-s binary sose lesz olyan effektív mint egy adott op rendszerre írt IDE. A VS sem natív kód, de szerintem rengeteg natív áthívást használt. Vagy csak van egy olyan hely ahol a Microsoft egy jó kódot tudott írni A cég ahol dolgozom onnan ismertem meg a Silbas-ot komoly fejlesztés nincs inkább csak support. A kollégám is mondta, hogy mindenki szidja a Simplicity-t - kérdés akkor miért nem csinál a gyártó egy használható IDE-t?? A Microchip magába olvasztotta az Atmel-t. Beszélgettem az egyetemen egy Atmel-t használó sráccal és mondta, hogy az Atmel Studio-hoz (VS alapú) képest az MPLAB X katasztrófa még is az MPLAB X-be adtak supportot az Atmel-hez. (jó mondjuk az M biztos szívén vette volna, hogy egy felvásárolt cég IDE-jbe viszi be a saját controller-eit) Kicsit az az érzésem, hogy ezt már hogy hogy néz ki az IDE/mi az IDE alapja nem a mérnökök döntik el, hanem a "pénzügy". És ha beszélsz egy software fejlesztővel és azt mondod a legjobb a VS - ááá dehogy mond egy Java-s IDE-t és "write once run everywhere" csak azt felejtik el, hogy sehol se fut igazán csak a RAM-ot "tornáztatja". Még ránéztem két "nagyra" Ti, NXP és ők is eclipse-t adnak... Én nagyon nagy Microchip fan vagyok/voltam, de már annyit számít a stabil IDE és elég komoly absztrakció van már a hardware-re (így a controllerek "kb" ugyanazok), így inkább VS + STM32 sokkal járhatóbb.
Egy kis irónia van ám az első mondatomban a megjegyzésedet illetően.
Létezik Segger Embedded Studio IDE is, ami nem kereskedelmi célra ingyenes. Régen néztem már, de akkor is csak futólag, nem használtam komolyabb projekthez. Bővebben: Link
Úgy emlékszem hogy a SES csak a saját jlink debuggerrel működik, ami nem éppen hobbi kategória. Esetleg vehetsz kínai klónt, de az meg illetlenség. Egyébként a Keil nem csak 32k-ig ingyenes, pl. az összes nuvoton m0 -al ingyen használható, amik között van 256k is. STM -et nem használok, de úgy rémlik ott is van valami hasonló.
Még nem próbáltam ki, de állítólag az on-board ST-Link programozók firmware cserével J-link kompatibilisek lesznek. A belinkelt lap alján van egy kompatibilitási lista. Bővebben: Link
Szia ! Kozben megoldodott de mar nem tudom hogy mi volt a problema pontosan, a linker file valtozott, ez biztos.
Egyeb: 32H7-hez hasonlo teljesitmenyu vagy nagyobb telj. ARM letezik, ami Linux nelkul relative konnyen hasznalhato ? Idézet: „Egyeb: 32H7-hez hasonlo teljesitmenyu vagy nagyobb telj. ARM letezik, ami Linux nelkul relative konnyen hasznalhato ?” Definiáld a könnyű fogalmát és a felhasználási területet . Előző cégnél Freescale/NXP i.MX6-ot használtunk "bare metal way" Hát a PCIe-vel voltak gondok. Az elején ha jól emlékszem akkor volt bare metal SDK a Freescale-től de később elhatárolódtak tőle mondván, hogy csak Ubootot meg Linuxot támogatnak
Ez így igaz, fel kell készülni arra, hogy az SWD órajele 4 MHz is lehet (az ST-s implementáció 2 MHz-je helyett) .
Mennyire poén már az, hogy megfelelő firmware-vel egy eszkö telejesítménye megduplázható. Az RTT-ről meg ne is beszéljünk.
DSP. Legyen benne FPU, TFT meghajto, 1M+ flash, sebessegben 1.5x 2x a H7-nek.
A hozzászólás módosítva: Jún 17, 2019
Rejtély megoldva:
Nem ad tápot a kínai ST-Link, külső 3.3V-al minden tökéletes. Köszönöm mindenki segítségét!
Melyik ST-Link nem ad tápot? Ez a fajta?
|
Bejelentkezés
Hirdetés |