Egyelőre maradok az ingyenes verzióknál. Illetve nekiesek az adatlapnak. A 8 bites PIC-eknél könnyebb dolgom volt, mert az adatlapban betűről betűre le volt leírva, mit-hogyan kell használni. Itt viszont máshogy kell elsajátítani a tudást, csak még nem tudom hogy.

STM32 vonalon:
STM CubeMX project konfiguráló és generáló eszköz.
STM HAL, ha nem akarod regiszter szinten piszkálni az MCU-t.

Nekem két IDE működött kapásból az ingyenesek közül:
-Atollic TrueStudio (IDE ingyen, ARM-GCC ingyen, alap debug ingyen, RTOS debug fizetős.)
-EmBitz (Minden ingyen)

CubeMX tud makefile projectet és TrueStudio projectet is generálni. EmBitz-be importálni kell a forrásfájlokat, ez plusz egy lépés.

Itt is le van.
Van az adatlap (amit te is linkeltél), ami egy adott mikrokontrollerre (vagy hasonló mikrokontrollerekre) vonatkozik. Ez tartalmazza a rendelkezésre álló perifériák felsorolását, illetve az elektromos specifikációkat.
Van a referencia kézikönyv, ami elmagyarázza regiszterekre lebontva a különböző perifériák működését. Ez általánosabb és benne szokott lenni akár a teljes F0/F1/F4/stb. családra vonatkozó összes infó.
Van a programozói kézikönyv, ami az adott Cortex-M család utasításkészletét magyarázza el.
És vannak még az applikációs kézikönyvek, amik különböző példamegoldásokkal mutatják meg (vannak példaprogramok is) a különböző perifériák használatát.

Köszi az infókat (csatti2-nek is) !
Azt hiszem a STM CubeMX & Atollic párosnál maradok, illetve elmélyülök a kézikönyvekben.

Kapu48, nekem semmi problémám a short / byte típusokkal. Használom is őket, viszont 32 bites gépeken az int-et használom alapban. Ha 1-től 10-ig számolok (for), arra simán mehet 32 bit.

Amin kiakadtam, hogy a map függvény 16 bites volt.

A map egy intervallum leképzése egy másik intervallumra. A 16 bites map függvény 8 bites számokat tud értelmesen kezelni a túlcsordulás miatt. Kiakadtam, hogy 32 bites processzoron minek 16 bites map függvényt írni? A műveletvégző egység 32 biten is simán menne, többlet erőforrást sem igényel, miért nem 32 bites?

Az AVR-es C kódjaimat egyébként ARM-on újraírtam. A 8 bit beszorít, kényszer pályára rak, arra késztet, hogy mániákusan elkerüld a 32/64 bites számokat, a végeredmény meg úgy néz ki, ahogy. AVR-en kiszámolod, hogy ez 8 biten foglal kevés helyet, ez 16-on, még bűvészkedsz is, hogy át ne lépd a tartomány határát. Mindez komplett hülyeség ARM rendszeren, igazából magadat szívatod a 8/16 bites számokkal.

Nekem sajnos nem sikerült olyan programot írni, ami 8 és 32 bites rendszeren egyaránt normálisan néz ki. Persze lehet, hogy AVR alatt nem kellene lekorlátozni saját magam, ha 64 bit kell, akkor 64 bitet használok, a fordító meg arra fordítja, amire akarja, annyi időt vesz igénybe, amennyi kell hozzá.

A probléma gyökere az, hogy az emberi gondolkodás nem -128 és 127 között mozog, viszont 32 biten már a problémák 99%-a megoldható. A 8 bites gépek felajánlanak egy kitekert gondolatmenetet, ami abnormális programszerkezetté válik és végeredményként kusza kódot kapsz, aminek tényleg semmi értelme 32 bites rendszeren, csak a bajod lesz vele.

A kódod alapján (felesleges 16 bites korlát), az jött le, hogy nem sikerült még teljesen otthagynod a 8 bites világot. Alapból minden 32 bites, ha több kell 64, ha memóriával spórolni szeretnél 8/16. Nincs értelme lekorlátozni a gondolkodásod.

Ok meguntam a meddő vitát!
Ezt az érvet, hangoztatod.
Viszont mikor nem fértél el a kis mini F103-asban a grafikus programoddal?
Te is azt csináltad, amit én most.

Hiába 32 bites a proci, ha spórolni kel a kevés rammal.
Mert az SD kártyának is elvileg kellene 2*512 Byte
+ az LCD leképezés 320*240*16bit. (Bár ezt lehet kihagyom, mert ennél a 16bites LCD-nél jók a képváltási sebességek.)

Ha lefoglalnák a 16 bites LCD memóriának 32 bites tömböt? Akkor tele lenne, 16 bites nem használ lukakkal. És 2*akkora helyett foglalna. És a DMA-val is körülményesebb lenne átküldeni.

És ha már ebben az LCD-ben minden regiszter 16 bites, akkor minek bonyolítsam az életem oda-vissza konvertálgatással? STB…

Különben meg a vita azon alakult ki, hogy azt állítottad belassul a processzor a 16 bites utasításoktól.
Ami viszont nem igaz!

Azért köszi, az érdeklődést!
A Touch kontra LCD-re irt, map függvényem jól teszi a dolgát.

Most egy ilyennek az ST32f4xx-eshez illesztésével küzdök:
Air Mouse + billentyűzet: Bővebben: Link
Kissé egyedi kód kiosztása van.

A bil. része már OK. Most ugrok a Mouse kezelésneek.

> Viszont mikor nem fértél el a kis mini F103-asban a grafikus programoddal?

Azért nem fértem el, mert virtuális osztályokat használtam, ahogy nagy gépen szokás. Kivettem a legtöbbet belőlük, bár lehet, hogy hiba volt.

Ha nem férsz el a memóriában, mikrovezérlőt kell cserélni. Ezt a tapasztalat mondja.
A méret-optimalizálással olvashatatlanná, hordozhatatlanná teszed a kódod, rengeteg befektetett energia a semmiért, ehelyett mondjuk 1000 Ft-ért többért megveszel egy másik processzort és az élet megint szép lesz.

Ki beszél!?

Aki annyira spórol, hogy F103C8-ast használ grafikus programhoz? Ez a legkisebb eben a szériában!
Kb. kétszeres áron már kapsz nagyobbat.
És a kis pin száma miatt SPI-s LCDt használ? Ami pedig kinosan lassú animáciohoz.

Mikór, eleve ez a párosítás nem erre való!

Sajnos az ár is 3* több az F407ZET kontra F7xx

Az LCD-ről:

LCD-n RAM-mal senki sem spórol, inkább az eszükön szoktak spórolni, bocs. Minden balek a teljes képet a memóriában akarja tárolni, utána azon csodálkozik, hogy kevés a RAM.

A legtöbb LCD képes ablakozni. Kijelölöd, hogy a [10,10,40,40] keretben akarsz írni, utána DMA-val áttolod. Egy példaprogramot nem láttam, hogy ablakoznának. Helyette trükkös megoldások százai vannak dögivel.

Az érintett LCD (320*240*16bit) még arra is képes, hogy hardverből forgasson, ha megfelelő parancsokat használsz. A neten tonnaszámra látod az ügyes kis programokat, amik "ügyesen" bitmap-et forgatnak, miközben megfelelő parancsokkal az LCD is megcsinálja neked ingyen. A képet flash-ben tárolod, DMA-val áttolod, az LCD beforgatja, helyfoglalás: 0 byte RAM.

Láttam olyan fantasztikus kódot is, hogy pontonként rajzolnak LCD-re, ahol egy pont átvitele 10 bájtot vesz igénybe. Kijelöli az [x, y, x, y] ablakot, abba meg belertölt 2 bájtot színnek.

Nem attól fogsz kevés memóriát használni, hogy uint16_t-ot használsz, bocs. Attól, hogy gondolkodsz.

Az LCD kezelés egyébként a hülyeség netovábbja.
Arduino példa kód itt van 1021. sor-tól

Kompletten delayMicroseconds(40)-et beleraktak, hogy biztos, ami biztos működjön. Ettől lesz gyors az átvitel, főleg ha pontonként rajzolunk. A tapasztalat egyébként azt mutatja, hogy felesleges, mert az LCD 20 MHz körül simán képes speckó alapján is fogadni az adatokat.

Ebben viszont milyen igazad van!

Ez a kis ügyes is tud ablakozni. Eddig elhanyagoltam ezt a részét.
De most, neki ugrok a rendszerbe állításának.

Nálam sajnos, a 15cm-es szalagkábel okoz kényszerű sebesség csökkentést.
(Olyan rosszul vannak a csatlakozók rajta, hogy 4* meg kel hajtani 90fokban a kábelt.)

A felhozott példa pedig AVR-ekre és SAM3X8E-ra is alkalmas!

Ha már kijelzők... MIPI 4 lane-ben otthon vagy?

Nem vagyok annyira otthon. 320x200-as LCD-nél magasabb felbontásúval nem játszottam.

Van egy I2C-s SSD1306, egy SPI-s ST7735 és egy párhuzamos ILI9341. Ezekkel szórakoztam.

Az ablakozás egyedül az I2C-s monokróm SSD1306-on működött korlátozásokkal, mert 1 pont 1 bit és Y irányban csak 8 pontonként lehetett ablakozni. Egyébként nagyon hasonlóak, csak az illesztésük más.

Nagy felbontású LCD-nél 800x600, vagy még több, nincs tapasztalatom.

Ez szerintem még annyira újdonság, hogy nem kerültbe az amatőrök fiókjába.

Te hol szerzetedbe, milyen típus, link van, (milyen áron)?

Ha már felhoztad az Arduinos pédát.

A benne levő progmem megoldás, müködhet STM32-esen?

Vagy ez nem is szükséges, a KEIL IDE-nél?

Egyelőre még nem szereztem be, csak ismerkedek a témával. De elég combos HW kell alá, az STM32F4 szériánál is ha jól látom, csak a legújabb támogatja (állítólag a világon elsőként, mint MCU).

Szerintem ennyiért meg éri: Discovery kit with STM32F469NI

Vágjál bele! Hajrá!

Főleg a bővítések miatt:
4Mx32bit SDRAM
128-Mbit Quad-SPI NOR flash

Szemeztem már vele, bár egy kissé mély víznek érzem a témát, de hát haladni kell a korral.
Szerk.: ja igen, bár ez csak tud MIPI DSI-t, viszont csak 2 vonalon, szóval a 4 lane-t nem tudja.

Kis telhetetlen!

Szerintem az még nem éri meg az árát!
És még ehhez sem találni komolyabb alkalmazás példákat.

Alapnak felhasználhatod, de át kellene írnod, mert a biteket másképp állítgatod ARM-on, mint Arduinon.

Mindenesetre én nem ölnék bele energiát, mert DMA-val kellene megoldani az egészet, nem bit manipulációval. Szerintem vakvágány.

Még esetleg arra gondoltam, hogy bridge IC-t használni (pl. RGB - DSI), de az már erősen feszegeti a mazoizmus határát. Főleg hogy olyat csak BGA-ban találtam...

Ezek csak ilyen kisebb konstans tömbök.
Amivel nem vagyok tisztában, hogy flasban marad, vagy memóriába töltődik?

pl.:

Ez 1 pontmátrix lenne az LCD menü button határvonalinak.
Meghatározza, hogy melyik gombot érintették meg.
Nem lessz DMA-val kezelve.

Viszont lenne belöle több is.

Azt hiszem, te nem ezen a földön élsz?

Már az előző boardal is csak az embed foglalkozik még. Náluk a licenc díj 3000 Eu.
+ a GUI lic. 5000Eu. + a rengeteg ráfordítandó idő is pénz. ...

Mikor térül ez meg?

Ami van demo GUI az meg időnként kidob 1 reklám vízjelet.

Közben rájöttem, hogy ez már megvan oldva.

Több tiszteletet, köszönöm!

Sejtem miről írsz, de én az STM32F407 panelt az ingyenes IDE-vel (több is van) egész jól kódolgattam, meg szerintem többen is. Ezügyben érdemes megkérdezni killbill fórumtársat, ő otthon van az ilyenekben, legalábbis FPGA téren biztosan. Azért ott is vannak igen szép árak, és szerintem ő sem adott ki csilliókat..

Minden Tiszteletem!

De az álmodozásból, legtöbbször csak álom marad!
Pláne ha csak egyedül vagy a projectre?

Csak most 1 még kevésbé dokumentált grafikus LCDröl vanszó.

Még csak ismerkedek a témával, próbálom felmérni a terepet. Bár nincs a hátam mögött több évtizedes hardcore mélységű NASA project, de azért csináltam már ezt-azt pár év alatt.
Viszont ne haragudj, de én nem torelárom ezt a stílust.

Ok!

Úgysem tudok segíteni a témában! Inkább:

Üdv.

STM32 DMA-nál mikor jelez pontosan a Transfer Complete flag?

Minden egyes byte másolás végezténél vagy a még átküldendő adatok számát tartalmazó regiszter amikor nullára fut akkor?

Illetve mit jelez a Half transfer complete flag?