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   148 / 177
(#) vargham válasza Rockmenyét hozzászólására (») Ápr 23, 2020 /
 
A munkahelyemen csak C++t használunk a mikrokontrollerekhez. Az STM32től az AVRen át az ESPig mindenen.
(#) Rockmenyét válasza vargham hozzászólására (») Ápr 24, 2020 /
 
És mit használtok a fejlesztéshez? Keil vagy IAR EWARM?
Én PC-n (Linux és Win) kb. 15 éve programozok C++ban, de mikrovezérlőn kicsit el vagyok veszve, mert nincs igazán tapasztalatom arról hogy pl. mennyire "memóriapazarló" pl. STL konténerek használata.
Közben olvasok hideget-meleget a C++ MUC-s alkalmazésaival kapcsolatban.
Mikrovezérlőkkel komolyabban csak egy-másfél éve kezdtem foglalkozni, a Raspberry Pi-s múltam-jelenem miatt
RPi-vel készítek mérésadatgyűjtő eszközt. A feladat valós idejű részét végzi MCU, az adatmentést-feldolgozást-megjelenítést pedig az RPi.
Emiatt én kifejezetten az ARM Cortex magos eszközöket kerestem, és jelenleg az ST termékvonala (és maga a cég) a legszimpatikusabb.
(#) vargham válasza Rockmenyét hozzászólására (») Ápr 24, 2020 /
 
ARM-GCC
(#) Peppe válasza Rockmenyét hozzászólására (») Ápr 24, 2020 /
 
CubeIde+CubeMX
STlink V2/V3
A hozzászólás módosítva: Ápr 24, 2020
(#) Attis92 hozzászólása Ápr 25, 2020 /
 
Sziasztok!

Szeretnék egy kis segítséget kérni. Szeretnék egy auto-increment build number változót létrehozni, aminek értéke fordítási időben dől el, mégpedig úgy, hogy lekéri a GIT commitok számát
  1. git rev-list HEAD --count

és azt rakja ide be. Atollic TrueStudio-val dolgozom egy STM32F405-ös kontrolleren. Ez a funkció pár éve már működött, de az egy tiszta Eclipse Makefile project volt és ott szabadon lehetett script-ezni a Makefile-t. Hogyan tudom ezt elkészíteni az Atollic-ban? A linker fájlt már módosítottam, ott már van egy egyedi flash terület ennek a kostansnak. Ez most így néz ki a kódban:
  1. #define BUILD_MAJOR     (1)
  2. #define BUILD_MINOR     (0)
  3. #define BUILD_MAIN      (0)
  4. #define BUILD_NUM       (0)
  5.  
  6. typedef struct
  7. {
  8.     uint32_t  FwVer[4];       // major minor maintenance build
  9.     uint32_t  BootCompMask;  
  10.     uint32_t  ImgKey;        
  11.     uint32_t  ImgSize;        
  12.     uint32_t  HeadCrc;        
  13. } Header_t;
  14.  
  15. const volatile Header_t __attribute__ ((section (".header_sect"))) APP_HEADER =
  16. {
  17.     .FwVer = {BUILD_MAJOR, BUILD_MINOR, BUILD_MAIN, BUILD_NUM},
  18.     .BootCompMask = BL_VER_MASK(BL_VERSION),
  19.     .ImgKey = 0xffffffff,
  20.     .ImgSize = 0,                            
  21.     .HeadCrc = 0                              
  22. };

Itt kellene a BUILD_NUM értékét módosítani.
Tud nekem ebben valaki segíteni?
Előre is köszönöm!
(#) cross51 válasza Rockmenyét hozzászólására (») Ápr 25, 2020 /
 
Kicsi controller-en az STL felejtős.
Az STL >=512k nál használható szerintem kényelmesen. Ha veszel egy üres projektet és bekapcsolod az exception kezelést és RTTI-t és csak annyi a program
  1. int main(void)
  2. {
  3.         std::string s = "Hello";
  4.         std::cout << s;
  5. }

160k-ra fordul ebből a string kb 20-30k az STL tárolókat nem használtam de azok is kb hasonló méretűek lehetnek.

A hideget azért olvasod leginkább (szerintem) a C++/STL-ről mert minden dinamikus ami controller-en nem biztos, hogy jó, viszont van az a szint ahol már elengedhetetlen a kényelmes és újrafelhasználható kód érdekében.

A c++ a controller-ek felé ott van (szerintem) az igazi előnye, hogy van class és namespace mert strukturáltabb kódot tudsz írni.
(ezt csinálják C-ben is van egy struktúra amiben van változó leírás pl egy UART driver-re és egy mindig első paraméterként átadják a függvénynek <-> a struktúra a this pointer láthatatlanul megcsinálja ezt a fordító)

Eddigi tapasztalataim alapján:
- Írtam/írok inkább saját könyvtárakat amik kisebbek és lehetőséget adnak exception kezelés átváltására assert formájában (és a nyelvezete szebb, én nagyon C# mániás vagyok, így minden úgy néz ki nálam mintha C# lenne, a C# low-layer-e elég jó "cucc")

- Rétegelni kell a kódot, el kell dönteni melyik réteg mit csinálhat pl a driver réteg nem allokálhat dinamikusan

- A legtöbb esetben készen van az API csak C-s formában pl FreeRTOS ezek fölé érdemes wrapper-t írni amivel húzol egy C++ API-t a C API fölé.

- El kell dönteni mit akarsz te megírni pl az mbed egész jó megoldást ad, de az API-ját én nem szeretem (nekem marad a mindent megírok én..)


Amúgy az std::string 15 hosszúságú char string-ing nem allokál dinamikusan memóriát
(#) csatti2 válasza Attis92 hozzászólására (») Ápr 25, 2020 / 1
 
Be lehet kapcsolni, hogy saját makefile segítségével fordítsa le a programot. Lásd a képen. Ezután a makefile segítségével legenerálhatsz egy header file-t, ami tartalmazza a kívánt értékeket.
Itt a saját megoldásom:
  1. ## Git
  2. VERSION_SHORT           =       $(shell git describe --tags --abbrev=0)
  3. VERSION                         =       $(shell git describe --tags --long)
  4. COMMITDATETIME          =       $(shell git log -1 --date=format:'%Y%m%d-%H%M' --format=%cd)
  5. BRANCH                          =       $(shell git rev-parse --abbrev-ref HEAD)
  6.  
  7. # Outputs
  8. VER = $(SRC)/version.h
  9. ELF = $(BUILD_DIR)/$(TARGET).elf
  10. HEX = $(BUILD_DIR)/$(TARGET)_$(VERSION)-$(BRANCH)-$(COMMITDATETIME).hex
  11. BIN = $(BUILD_DIR)/$(TARGET).bin
  12. MAP = $(BUILD_DIR)/$(TARGET).map
  13. EXE = $(BUILD_DIR)/$(TARGET)_$(VERSION)-$(BRANCH)-$(COMMITDATETIME).exe
  14. ISE = .vscode/c_cpp_properties.json
  15.  
  16. # Generating version file
  17. $(VER):
  18.         @echo Generating $@
  19.         @echo /* THIS IS A GENERATED FILE, DO NOT EDIT IT! */  > $@
  20.         @echo #define VERSION_SHORT     "$(VERSION_SHORT)" >> $@
  21.         @echo #define VERSION           "$(VERSION)-$(BRANCH)-$(COMMITDATETIME)" >> $@
A hozzászólás módosítva: Ápr 25, 2020
(#) Peppe hozzászólása Ápr 26, 2020 /
 
Sziasztok,
Foglalkozott már valaki STM32F746 LTDC(TFT kijelző)+SDRAM perifériával? Terveztem egy saját panelt 4.3"TFT kijelzővel.
És küzdök a felélesztéssel. Az istennek sem akar beindulni normálisan a kijelző. Vagyis egy vonalban van csak az amit szeretnék. A képernyő méret beállítva és minden aminek be kell. Videó a hibáról:
(#) Peppe válasza Peppe hozzászólására (») Ápr 26, 2020 /
 
Megoldódott a probléma. A CubeMX csodásan olyan alap konfigot állít be a pixelCLK polarity-nek amivel az előző videón látható hiba. És egy videó a helyes működésről
Működik
(#) Lucifer válasza Attis92 hozzászólására (») Ápr 26, 2020 / 1
 
Mi a git describe kimenetet szoktuk belefordítani a kódokba úgy, hogy van egy getrevision bash szkriptünk ami generál egy headert a pre-build step-ben. (Úgy van megírva, hogy ha nem változott a hash akkor nem bántja a fájlt, így nem okoz újrafordítást ha nincs rá ok.)

Közben látom fentebb csatt vázolta kb. ugyanezt.
A hozzászólás módosítva: Ápr 26, 2020
(#) artur60 hozzászólása Máj 4, 2020 /
 
Sziasztok,

Stm32L031F6 procira CubeMx-el generáltam egy egyszerű PWM-es led vezérlést.
Debug módban rendesen működik, de ha futtatni akarom nem indul el.
Annyit kiderítettem, hogy az __libc_init_array() függvényben kerül végtelen ciklusba.
Mellékel a CubeMx fájlt, hátha valamit nem jól állítottam be.
Vagy hardver hiba lehet?
(#) artur60 válasza artur60 hozzászólására (») Máj 4, 2020 /
 
Megoldódott: a boot láb nem volt lehúzva
(#) Attis92 válasza csatti2 hozzászólására (») Máj 5, 2020 /
 
Köszönöm szépen!
Közben én is így oldottam meg. Azt hittem ennél az Atollic kicsit ügyesebb és nem kell saját Makefile-t írni, de hát ez van.
(#) don_peter hozzászólása Máj 11, 2020 /
 
Srácok, van egy olyan kis problémám, hogy egy adatporton nem fér el sajnos 8bit egymás után.
Kicsit szét kell szedjem és ebben kérnék segítséget illetve megerősítést.
Így oldottam meg, de lehet nem jó:
  1. #define PORT(data)      GPIOB->BRR = ((GPIOB->IDR & 0xEF04) | data)
  2. unsigned int temp = 0;
  3. unsigned char byte = 0x33;
  4.         if(byte&0x02)
  5.                 temp = 0x1000 | (byte&0xFB);    // D2 Magas
  6.         else
  7.                 temp = 0x0000 | (byte&0xFB);    // D2 Alacsony
  8.         PORT(temp);

A lényege, hogy B port 0-1 majd 3-7-ig elérhetőek a bitek, de sajnos a 2-es nem és azt átcsoportosítottam a 12-edik helyi értékre. Szerintetek jó és optimális a fentebbi kód?
Előre is köszi.
(#) benjami válasza don_peter hozzászólására (») Máj 11, 2020 / 2
 
  1. #define PORT(data) GPIOB->ODR = (GPIOB->ODR & ~0b0001000011111011) | (((data & 0b00000100) << 10) | (data & 0b11111011));
A hozzászólás módosítva: Máj 11, 2020
(#) don_peter válasza benjami hozzászólására (») Máj 12, 2020 /
 
Köszi, ki is próbálom..
(#) Pali79 hozzászólása Máj 19, 2020 /
 
Sziasztok!
Nagyon nem szeretnék elmerülni ebben a témában, de van egy projekt amit után alakor építeni, ehhez szeretnék megerősítést kérni, hogy nem vásároljak össze feleslegesen semmit.
Szóval az áramkör lelke egy STM32F103C8. Ehhez vennék egy ilyen programozót Az ST32 ST-link utility programot letöltöttem, a beprogramozandó HEX megvan. Ez az összeállítás jó így?
(#) vargham válasza Pali79 hozzászólására (») Máj 19, 2020 / 1
 
Igen, jó.
(#) Pali79 hozzászólása Jún 15, 2020 /
 
Tegnap este beültettem az áramkört és véletlenül az NRST láb 10k-s felhúzó ellenállása helyett sikerült egy 0 ohm -ost betennem. Egy ideig nem is vettem észre úgy próbálkoztam működésre bírni, de nem működik. Két kérdés:
1. vajon túlélte?
2. ha túlélte, okozhatja a működésképtelenséget az elrontott ellenállás érték?
(#) benjami válasza Pali79 hozzászólására (») Jún 15, 2020 /
 
Az áttekintő adatlap 31. ábrája szerint az NRST láb csak bemenet fix belső felhúzó ellenállással. Ennek elvileg nem árt meg ha fixen a VDD-re kötöd. Viszont a reset gombot megnyomva rövidzárat okoztál a tápon, amit ki tudja hogyan viselt a 3.3V-os stabilizátor. Megvan a 3.3V a táp lábon?
(#) Peter65 válasza benjami hozzászólására (») Jún 15, 2020 /
 
A CPU-hoz tartozó manual 91. oldalán a 7-es ábra szerint nem csak bemenet, hanem kimenet is. A belülről generált resetek a külső lábon is megjelennek legalább 20usec-es "lehúzások" formájában.
Általában el szoktak viselni ezek az IC-k egy rövidzárlatot, és oka lehetett, hogy reset jel nélkül a CPU nem indult el megfelelően.
(#) benjami válasza Peter65 hozzászólására (») Jún 15, 2020 /
 
Lehet hogy így van. Írj egy programot, ami mondjuk 1 másodperc múlva reset-be állítja procit, tegyél rá egy logikai analizátort és mérd meg (persze egy másik jól működő procival). Ha így van, akkor elképzelhető, hogy az NRST GND felé húzó FET-je megpusztult, bár ebben az esetben az lenne a logikus, ha csak a belsőleg kiváltott reset működése szűnne meg, kívülről meg lehetne resetelni.
(#) Pali79 hozzászólása Jún 21, 2020 /
 
Hát akármit csinálok nem akar működni, ezért egy kis segítséget szeretnék kérni. Csatoltam az áramkör kapcsolási rajzát és a hozzá tartozó hex fájlt. Szeretném letesztelni, hogy maga a kontroller működik-e, csak épp ennek a programozásához teljes sötét vagyok. Ezért szeretnék megkérni egy hozzáértőt, hogy a írjon egy olyan kis programot erre ami a panelon lévő LED-et villogtatja. Így megtudnám, hogy van-e értelme küzdeni vele még.
A hozzászólás módosítva: Jún 21, 2020
(#) vargham válasza Pali79 hozzászólására (») Jún 21, 2020 /
 
BOOT0 nincsen sehová sem kötve?
(#) vargham válasza Pali79 hozzászólására (») Jún 21, 2020 /
 
Flatpack2Test_HSE.bin
Külső 8 MHz kvarcról jár, 250ms időközzel kapcsolgatja PB3-t.

Flatpack2Test_HSI.bin
Belső 8 MHz órajleről jár, 1000ms időközzel kapcsolgatja PB3-t.

Flatpack2Test.ioc
CubeMX project file
(#) Pali79 válasza vargham hozzászólására (») Jún 23, 2020 /
 
Köszönöm a segítséget! A BOOT0 nincs bekötve sehová ha jól néztem.
Kipróbáltam a küldött progikat, illetve csak az egyiket sikerült, ami külső kvarcról megy. Szépen villog a LED ahogy kell, de viszont azóta nem tud kapcsolódni a programozó. Erre van valami ötlet, hogy mi lehet a baj?
(#) kapu48 válasza Pali79 hozzászólására (») Jún 23, 2020 /
 
Itt bemutatják hogyan van jumperolva a BOOT0 először botloadert használ, később ST-LiNKET:
Bővebben: Link
(#) vargham válasza Pali79 hozzászólására (») Jún 23, 2020 /
 
Idézet:
„azóta nem tud kapcsolódni a programozó”

Nem kapcsoltam be a debugot. Csak hardveres resettel tudsz hozzá újra csatlakozni. Össze kell kötni a debugger reset kimenetét (ha van) az MCU reset lábával.
Milyen programozód van?
(#) Pali79 válasza vargham hozzászólására (») Jún 24, 2020 /
 
(#) vargham válasza Pali79 hozzászólására (») Jún 24, 2020 /
 
Ezen nincs reset.
Lehetőségek:
1. Raksz reset gombot a cél áramkörbe. Resetben tartod az MCU-t, és kiválasztod, hogy connect under reset. Ha jó ütemben engeded el a gombot, akkor sikerülni fog a csatlakozás.
2. Szétszeded a programozódat, és ráforrsztasz a benne lévő STM32F103 MCU PB0 lábára egy vezetéket. Ezen fog resetet adni a cél MCU-nak.
3. Veszel egy eredeti ST-Linket, azon van reset kimenet.

Tudok küldeni a teszt programból olyan verziót is, ahol engedélyezve van a debug, és akkor legközelebb nem lesz ilyen gond.
Sajnálom, eszembe sem jutott, hogy nincs reseted bekötve.
A hozzászólás módosítva: Jún 24, 2020
Következő: »»   148 / 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