Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   136 / 177
(#) Lucifer válasza gtk hozzászólására (») Jún 3, 2019 /
 
DMA van? Nem piszkíthat oda? linker fájlod hogy néz ki?
(#) david10 hozzászólása Jún 4, 2019 /
 
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
(#) csatti2 válasza gtk hozzászólására (») 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).
(#) kapu48 hozzászólása Jún 8, 2019 /
 
Sziasztok!

Ha valaki tudná a hiba okát?
Légyszives segitsen!

  1. /*  IDE: MDK5
  2.  *******************************************************************************
  3.  *  [subdsp.h]
  4.  *
  5.  *  This program is under the terms of the GPLv3.
  6.  *  https://www.gnu.org/licenses/gpl-3.0.html
  7.  *
  8.  *  Copyright(c) 2017 Keshikan (www.keshikan.net)
  9.  *******************************************************************************
  10.  */
  11. #ifndef SUBDSP_H_
  12. #define SUBDSP_H_
  13.  
  14. #include "stm32f7xx_hal.h"
  15.  
  16. __attribute__( ( always_inline ) ) static inline int32_t __SMULWB (uint32_t op1, uint32_t op2)
  17. {
  18.   int32_t result;
  19.  
  20.   __asm volatile ("smulwb %0, %1, %2" : "=r" (result) : "r" (op1), "r" (op2) );
  21.   return(result);
  22. }
  23.  
  24. #endif /* SUBDSP_H_ */

Error:
  1. ../Inc/subdsp.h(20): error:  #18: expected a ")"
  2.     __asm volatile ("smulwb %0, %1, %2" : "=r" (result) : "r" (op1), "r" (op2) );




Köszönöm!
A hozzászólás módosítva: Jún 8, 2019
(#) Bakman válasza kapu48 hozzászólására (») Jún 9, 2019 /
 
Mint abszolút hozzá nem értő, lőnék egyet a levegőbe. Az
  1. "r" (op1)
rész után vessző van, nem kettőspont.
A hozzászólás módosítva: Jún 9, 2019
(#) rolandgw válasza kapu48 hozzászólására (») Jún 9, 2019 / 1
 
Ú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.
(#) kapu48 válasza rolandgw hozzászólására (») Jún 9, 2019 /
 
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
(#) kapu48 válasza kapu48 hozzászólására (») 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.
  1. void cureSynthSetDryOutput(Operator *op)
  2. {
  3. ...
  4. /*
  5.         typedef struct{
  6.         uint16_t divider;
  7.         uint32_t idx;
  8.         EnvelopeStatus stat;
  9.         uint16_t attack;
  10.         uint16_t decay;
  11.         uint16_t sustainLevel;
  12.         uint16_t sustainRate;
  13.         uint16_t release;
  14.         uint16_t out;
  15. }EnvelopeGen;
  16.        
  17.         typedef struct{
  18.         WaveGen wav;
  19.         RingMod ringmod;
  20.         EnvelopeGen env;
  21.         NoteStatus stat;
  22.         NoteType ntype;
  23.         uint16_t velocity;
  24.         uint8_t ch;     //set 255 means "NO OUTPUT"
  25.         int16_t rightout;
  26.         int16_t leftout;
  27.         int32_t out;
  28.         uint8_t out_gain;
  29. }Operator;
  30.  
  31. / **
  32.   \brief   Signed Saturate
  33.   \details Saturates a signed value.
  34.   \param [in]  value  Value to be saturated
  35.   \param [in]    sat  Bit position to saturate to (1..32)
  36.   \return             Saturated value
  37.  * /
  38. #define __SSAT                            __ssat
  39.  
  40. __attribute__( ( always_inline ) ) static inline int32_t __SMULWB (uint32_t op1, uint32_t op2)
  41. {
  42.   int32_t result;
  43.  
  44.   __asm volatile ("smulwb %0, %1, %2" : "=r" (result) : "r" (op1), "r" (op2) );
  45.   return(result);
  46. }
  47. */
  48. //int32_t out;                          int32_t out;                                                                                    uint16_t out;           uint16_t velocity; uint8_t out_gain;
  49. op->out = __SMULWB( ( op->out ),  (int16_t)__SSAT ( ( op->env.out * ( (op->velocity *    op->out_gain) >> 6 ) ), 16 ) );
  50. ...

Valami ötlet, vagy tanács, jól jönne.
A hozzászólás módosítva: Jún 9, 2019
(#) kapu48 válasza rolandgw hozzászólására (») 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?
  1. op->out =  op->out *  (int32_t)__SSAT ( ( op->env.out * ( (op->velocity *        op->out_gain) >> 6 ) ), 16 );
(#) cross51 válasza kapu48 hozzászólására (») Jún 9, 2019 /
 
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.
(#) rolandgw válasza kapu48 hozzászólására (») Jún 9, 2019 /
 
Az Atollic nem importálja SW4STM32 project-et? Még nem próbáltam, csak olvastam valahol, hogy igen.
(#) kapu48 válasza cross51 hozzászólására (») Jún 9, 2019 /
 
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
(#) kapu48 válasza kapu48 hozzászólására (») Jún 11, 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
(#) toto hozzászólása Jún 14, 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 )
(#) cross51 válasza toto hozzászólására (») Jún 14, 2019 /
 
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
(#) vargham válasza toto hozzászólására (») Jún 15, 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)
(#) toto válasza vargham hozzászólására (») Jún 15, 2019 /
 
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.
(#) cross51 válasza toto hozzászólására (») Jún 16, 2019 /
 
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
(#) rolandgw válasza cross51 hozzászólására (») Jún 16, 2019 /
 
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.
(#) cross51 válasza rolandgw hozzászólására (») Jún 16, 2019 /
 
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.
(#) rolandgw válasza cross51 hozzászólására (») Jún 16, 2019 /
 
Egy kis irónia van ám az első mondatomban a megjegyzésedet illetően.
(#) icserny válasza toto hozzászólására (») Jún 16, 2019 /
 
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
(#) jefflynn válasza icserny hozzászólására (») Jún 16, 2019 /
 
Ú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ó.
(#) icserny válasza jefflynn hozzászólására (») Jún 16, 2019 /
 
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
(#) gtk válasza Lucifer hozzászólására (») Jún 16, 2019 / 1
 
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 ?
(#) Lucifer válasza gtk hozzászólására (») Jún 16, 2019 /
 
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
(#) Lucifer válasza icserny hozzászólására (») Jún 17, 2019 /
 
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.
(#) gtk válasza Lucifer hozzászólására (») Jún 17, 2019 /
 
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
(#) david10 válasza david10 hozzászólására (») 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!
(#) vargham válasza david10 hozzászólására (») Jún 18, 2019 /
 
Melyik ST-Link nem ad tápot? Ez a fajta?
Következő: »»   136 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem