A munkahelyemen csak C++t használunk a mikrokontrollerekhez. Az STM32től az AVRen át az ESPig mindenen.

É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.

ARM-GCC

CubeIde+CubeMX
STlink V2/V3

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

é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:

Itt kellene a BUILD_NUM értékét módosítani.
Tud nekem ebben valaki segíteni?
Előre is köszönöm!

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

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

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:

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:

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

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.

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?

Megoldódott: a boot láb nem volt lehúzva

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.

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ó:

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.

Köszi, ki is próbálom..

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?

Igen, jó.

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?

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?

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.

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.

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.

BOOT0 nincsen sehová sem kötve?

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

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?

Itt bemutatják hogyan van jumperolva a BOOT0 először botloadert használ, később ST-LiNKET:
Bővebben: Link

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?

Ilyen a programozóm

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.