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   86 / 175
(#) csatti2 hozzászólása Feb 7, 2017 / 3
 
Kíváncsiságból írtam egy runtime OS-t. Természetesen nem akar versenytársa lenni semmilyen nagy projektnek, a legfőbb szempont az volt, hogy más OS-ekkel ellentétben a lehető legkevésbé legyen útban és ne akarjon mindenféle HAL-t rákényszeríteni az emberre. Fontos volt még, hogy minél könnyebben kompatibilissé lehessen tenni már megírt könyvtáraimmal.
Jelenlegi formájában Cortex-M3-as uC-ket támogat (STM32F1-esekkel teszteltem, mert azok vannak itthon). Igyekeztem a kernelben elkerülni minden nem CMSIS hivatkozást, hogy minnél könnyebben portolható maradjon. Ha lesz időm megírom a Cortex-M4 támogatást, illetve ha kijön majd a LowLayer az ST-től, jöhetnek az M7-esek is.
GCC-t használok fordítóként, nem tudom mással, hogy viselkedik.
Egyéb képességek:
- Task prioritások: ezek elsősorban azt befolyásolják, mennyi CPU időt kap egy taszk, de van két speciális szint (high és runtime), ami prioritást élvez másokkal szemben
- IRQ zároló makrók számlálóval, lehetővé teszik "atomi" utasítások végrehajtását, miközben a kernel szintű megszakítások tovább működnek (SVC, SysTick).
- Két különböző erőforrás zárolás (egy sima bináris és egy round robin)
- Debug támogatás: CPU időfelhasználás, stack méret (overflow érzékeléssel), stb.
- Lehetőség van a main task megtartására is, ami továbbra is a main stack pointer-t használja (könnyebbé teszi a memória hatákony kihasználását)
Mint minden OS-nél, itt is oda kell figyelni pár dologra:
- Tilos a legmagasabb és a legalacsonyabb IRQ prioritásra megszakítást konfigurálni, ezek az oprendszer számára vannak fenntartva
- A közös erőforrásokat védeni kell (erre vannak a fent irt eszközök), egyszerre csak egy task használhatja
- Tilos erőforrást zárolni próbálni IRQ zároláson belül (ha foglalt, nem tud felszabadulni, mert nem adja át a vezérlést)
- Ha több ugyanolyan erőforrást foglal két vagy több task, akkor ugyanolyan sorrendben kell zárolni őket, nehogy blokkolják egymást.

A demo projekt egy filléres STM32F103C8T6 devboardon fut. Csak az USART1-et használja, azon lehet követni a taskok működését. A soros port sebessége: 921600

Ha van kedvetek, próbáljátok ki.
(#) rascal hozzászólása Feb 8, 2017 /
 
Sziasztok!
Éppen csak ismerkedek egy stm32f407 discoveryvel és az egyik timerhez gyűjtögetem a vezérlőregisztereket. Eközben rábukkantam a "RCC APB2 peripheral reset register (RCC_APB2RSTR)" nevű regiszterre is. Az rm0090-es referenciában és a stm32f407-ben és googlben sem találtam olyan leírásra, ami elmagyarázza a működését. Tudtok erről valamit? Pl. ha 1-be rakom resetben marad tartósan, és nekem kell törölni is, vagy a beírás a regiszterbe csak trigger? Honnan lehet tudni, hogy a periféria resetje megtörtént és lehet megint használni? Mikor kell használni? Első inicializáláskor is, vagy csak menet közben? Meg úgy egyáltalán minek van? Az RCC...ENR-ben levő bit úgy is agyoncsapja a perifériát ha kikapcsolom, meg vissza. Vagy nem?
(#) csatti2 válasza rascal hozzászólására (») Feb 8, 2017 /
 
Neked kell beírni és neked kell törölni is. Ez egyébként látszik a kézikönyvben megjegyzésként is (Set and cleared by software.). Tehát ha újra akarsz inicializálni egy perifériát, akkor először 1-be teszed a hozzá tartozó bitet, majd utána törlöd. Nem kell várni a két művelet között.
Elméletileg nem kell első inicializáláskor, de szokás, mert így újra lehet hívni az inicializáló kódot, ha menet közben kikapcsoltuk a perifériát (nem kell ezt is fejben tartani).
Az ..ENR az órajelet adja a perifériának (vagy veszi el), ez meg visszaállítja a kezdeti regiszterbeállításokat. A kettő nagyon nem ugyanarra való.
A hozzászólás módosítva: Feb 8, 2017
(#) rascal válasza csatti2 hozzászólására (») Feb 8, 2017 /
 
Köszönöm, így már tiszta!
(#) gtk hozzászólása Feb 14, 2017 /
 
Sziasztok,

Probalt valaki STM32F427, 29, vagy 32F7 TFT vezerlojevel TFTt meghajtani RGB modban ?
(#) cpt.zoltan.simon válasza gtk hozzászólására (») Feb 14, 2017 /
 
vzolee csinálta, az én kódom tőle van. Én annó NXP LPC-re csináltam, az STM-en nem akartam végigszívni ugyan azt a... Írj neki, más kódját nem szoktam osztogatni csak ha szabad.
Írok neki face-en gondolom odaadja.
Nem tudom, gondolom Discovery-t használsz, de ha TFT-t szeretnél, gondolom az SDRAM is kell mellé. Vagy nem?
A hozzászólás módosítva: Feb 14, 2017
(#) gtk válasza cpt.zoltan.simon hozzászólására (») Feb 14, 2017 /
 
Szia !

Sajat panelt szeretnek hasznalni, ez a dsp radiomnak lesz egy uj valtozata majd a 32H7-el, ha kijon vegre. Waterfallnak kellene. Elmeletileg lesz a H7-ben 1M SRAM. Nem szamoltam utanna, hogy kell-e ennel tobb, remelem nem kell.
(#) gtk válasza cpt.zoltan.simon hozzászólására (») Feb 14, 2017 /
 
Vagy inkabb SSD kontrolleres TFTt FSMCre ?
(#) Balázs válasza gtk hozzászólására (») Feb 14, 2017 /
 
STM32F746-tal van tapasztalatom. Annak az LCD vezérlőjét nagyon egyszerű használni, lényegében megadod neki a frame buffer címét, a színmódot és hasonlókat, és ő csinál mindent a háttérben. A Discovery panelhez például itt van egy csomó driver és demó projekt.
(#) cpt.zoltan.simon válasza gtk hozzászólására (») Feb 14, 2017 /
 
SSD1963-ra van saját kódom, (igaz STM32F207) de kompatibilis. FSMC-n a 207 esetében 512k SRAM van nálam. Na szóval bármire kell SSD1963 kód van, FSMC-re van ami az SRAM-ot implementálja, 429-re pedig SRDAM-ot. És ahogy írtam van TFT kód is. Írtam neki, amint válaszol, küldöm is.
(#) gtk válasza Balázs hozzászólására (») Feb 14, 2017 /
 
Koszi szepen az informaciot !
(#) gtk válasza cpt.zoltan.simon hozzászólására (») Feb 14, 2017 /
 
Koszi szepen ! Meg gondolkodom hogy melyik varians legyen. Vegulis a vezerlo nelkuli TFT hatranya hogy nagy framebuffer kell. Utanna kell szamoljak hogy mekkora SRAM kell a jelfeldolgozas reszehez. Ha nem tevedek akkor ehhez itt 5'' TFT RGB 480x272x24[bit] /8[bit] = 391,680 kbyte RAM kell.
Ha megosztod [megosztjatok] a kodot, az nagy segitseg lesz. Udv.
(#) cpt.zoltan.simon válasza gtk hozzászólására (») Feb 14, 2017 /
 
800x480-t használtam, 16 biten 384k volt az adat.
24 bit szerintem teljesen fölösleges. A gond az hogy mind a Discovery-n mind a 207-en a SRAM/SDRAM 16 bites buszon csatlakozott, és minimum 2 tranzakció volt minden egyes 24 bites színadat (2x16bit vagy 3x8bit).
Természetesen teljesen más volt a szitu az NXP LPC1788 SOC-al ahol a BGA tokozott SRAM-om 32 bites adatbusszal bírt. Ott nem is volt recece, közlekedtek a long változók, és senkit nem érdekelt hogy a felső 8 bit nulla volt.
Mellesleg 207-el 120 helyett 157MHz-en hajtva 16 bites színmélység mellett (természesesen) ugyan azon az FSMC buszon beolvasva SRAMból majd kiküldve az SSD-nek elértem 48FPS-t a fentebb említett 800x480-on. Úgy hogy 384k adatot 6 lépésben DMA memory-memory copy-val toltam ki 64 000-esével. Tehát amolyan fél-hardver fél-szoftver módon, mert a DMA csak 2^16 elemig hajtható.
A 429-en hardveres TFT-vel nem lesz ilyen gondod, mert a CromART mindent rendez neked, én ez utóbbit javaslom. Kevesebb külső komponens, kevesebb nyűg.
(#) gtk válasza cpt.zoltan.simon hozzászólására (») Feb 14, 2017 /
 
Igen, a beepitett TFT vezerlos valtozat szimpatikusabb nekem is. Hogy tudom elerni hogy ne kelljen mind a 24 bit ? [ ezen most nem gondolkodtam ] Termeszetesen ebben az esetben teljesen folosleges.
A hozzászólás módosítva: Feb 14, 2017
(#) vzoole válasza gtk hozzászólására (») Feb 15, 2017 /
 
Írtam elérhetőséget, mert ennyi mindent most nem tudok begépelni.
(#) gtk válasza vzoole hozzászólására (») Feb 15, 2017 /
 
Szia ! Koszi.
Meg tudnatok mondani hogy ez TFT meghajto mennyire fogja meg a procit ?
(#) cpt.zoltan.simon válasza gtk hozzászólására (») Feb 15, 2017 /
 
A 429-ben nem tapasztaltam vele fennakadást, mert saját DMA-ja van.
Annyival "keskenyebb" az ügy, hogy SDRAM-ból dolgozott, azon kellett kicsit osztozni. Semmi említésre méltó.
(#) gtk válasza cpt.zoltan.simon hozzászólására (») Feb 16, 2017 /
 
Koszi.
(#) rascal hozzászólása Feb 17, 2017 /
 
Sziasztok!
Ha a belső RC oszcillátort (HSI) használom PLL-el, akkor is biztonsággal elmehetek az elvi maximális frekvenciákig? (AHB, APB1, 2) Ha az oszcillátor pontatlansága pont felfele tér el, akkor túlléphetem a megengedett értékeket.
A PLL-nél a leírás csak az M-re ír javaslatot azzal, hogy a VCO input 2MHz esetén lesz a legkisebb a jitter, de az N és P paramétereknél nem ír ilyen okosságot. Ugyan ahhoz a kimenő frekvenciához néha több lehetséges érték pár is lehetséges. Van erre valami ajánlás, hogy melyiket válasszam?
(#) csatti2 válasza rascal hozzászólására (») Feb 18, 2017 /
 
Igen van, a P és a Q osztók előtti frekvenciának a 100MHz - 432MHz közötti tartományba kell esnie.
Nem tudok róla, hogy a HSI használata korlátozná a max használható frekvenciát (a pontosságtól eltekintve persze). Ha USB-t is használni akarsz, akkor esetleg gond lehet (tudomásom szerint a kristály nélküli USB-t támogató uC-k dedikált HSI48-al szoktak rendelkezni).

A legegyszerűbb egyébként ha letöltöd az SMT32CubeMX eszközt, ami figyelmeztet ha rossz paraméterekkel akarsz inicializálni egy perifériát. A végeredményként kapott osztókat/szorzókat/stb. aztán felhasználhatod akármilyen módot is használsz (SPL, HAL, direkt regiszterek) programozáskor a perifériád kezeléséhez.
(#) rascal válasza csatti2 hozzászólására (») Feb 18, 2017 /
 
Ez a 100-432MHz nem kerülte el a figyelmemet, arra lettem volna kíváncsi, hogy van-e valami optimum? Pl. 50 MHz-hez 100/2, 200/4, 400/8 párosok jók. Autónál tudom mivel jár ha kettesben megyek 50-el, vagy ha 4-esben, itt nem. Egyébként van cube-om, csak elméleti szempontból érdekelt, hogy van-e valami jelentősége?
(#) kiborg hozzászólása Feb 18, 2017 /
 
Sziasztok!

Olvasgattam, nézegettem IDE-t és a CoIDE(CooCox) és az Atollic TrueStudio maradt bent a rostán.
STMF32F103C8 lenne programozva ST-LinkV2-n keresztül.
Tudtommal támogatja mindkettő, egyiknél sincs kódméret korlát.
Mindkettő csupa jót ír magáról. Van aki már próbálta esetleg mindkettőt? Vagy valakinek bármi tapasztalata/ismerete pro és kontra bármelyikkel kapcsolatban?
A hozzászólás módosítva: Feb 18, 2017
(#) rascal válasza kiborg hozzászólására (») Feb 19, 2017 /
 
Én az stm32 világába csak most ugrottam fejest. Az Atollic-ot telepítettem, még a 6-ost. Jól elvagyok a free verziójával. 5x7-es ledmátrixos kijelzőt hajtok meg vele IRQ-ból, rotary enkódereket figyelek, most jön egy kis ADC kezelés. Ezekhez biztos elég.
Debugolás is megy, pár fejlettebb dolgot a free verzió nem enged, de azt sem tudom micsodák, ezért nem is hiányoznak. Lépkedhetsz a programban, nézheted assemblyben is. A változókat, regisztereket nézheted és meg is változtathatod "pause"-ban. Több breakpointot rakhatsz, akár irq rutinokba is.
Az editora jelzi gépelés közben is a syntax errorokat, és van még pár kényelmi funkciója. Pl makró kifejtés kis ablakban, hogy lásd mi az az INGYOMBINGYOM_MAX.
Ismeri a különböző gyártók eval bordjait is, projekt létrehozásánál nem csak procit adhatsz meg, hanem ezt is és akkor már mindent tud.
Amivel viszont majdnem nagyon megszívatott, hogy a projekt létrehozásánál azt gondoltam, hogy a kijelölt könyvtár alatt, pl. "FEJLESZTÉSEK" létrehoz a projekt nevével azonos könyvtárat és abba dolgozik. Hát nem. A durva dolog csak ezután történt, amikor törölni akartam a projektet. Ugye létrehozáskor odapakol egy csomó fájlt, meg alkönyvtárat, ami törlés után nem kell. Amikor rákérdezett, hogy a fájlokat is törölje, gondoltam persze. Nos nem csak azt törölte, amit ő odarakott, hanem az egész könyvtárat, meg mindent ami alatta van. A Lomtár úgy látszik csak dísznek van, az Atollic nem használja. Annyi szerencsém volt, hogy az igazán fontos dolgokat pár perccel korábban átmásoltam egy teljesen máshol levő könyvtárba, ezért a lényeg megmaradt. Szóval csak óvatosan, mert simán letörli a fél gépedet ha nem figyelsz.
(#) vargham válasza kiborg hozzászólására (») Feb 19, 2017 /
 
EmBitz? Kiesett vagy nem is nézted?
(#) kiborg válasza vargham hozzászólására (») Feb 19, 2017 /
 
Szia!

Ez eddig kimaradt.Innen szemezgettem és az ismertebbeknek utána néztem. Az EmBitz nincs benne, és eddig máshol sem halottam.
De ezek szerint te használod. Milyen? Véleményt mondhatnál róla.
(#) rolandgw válasza kiborg hozzászólására (») Feb 19, 2017 /
 
Ott van, csak régebben EmBlocks néven futott.
(#) kiborg válasza rolandgw hozzászólására (») Feb 19, 2017 /
 
Aha. Info a használhatóságáról?
(#) kiborg válasza kiborg hozzászólására (») Feb 19, 2017 /
 
Arról viszont nem találtam infót, hogy valamelyik IDE-nek van-e valami hasonló példa könyvtára, mint az Arduinonak. Tudtok ilyet?
Néztem videót a EmBitz-ről. Led Blinking. Egy csomó mindent be kell állítani, és kezdésnek lövésem sincs, hogy mit is, ezért lenne jó valami minta vagy példa összeállítás.
(#) vargham hozzászólása Feb 20, 2017 /
 
Röviden: Desktop / mobil Java fejlesztés felől jövök, rapid prototypinghoz kerestem eszközt, ami nem Arduino. Az mbed szimpatikus, de az online IDE-t minél messzebbre el akartam kerülni, miközben megmaradnak a platform kényelmes szolgáltatásai. Ilyen alapon néztem végig egy csomó IDE-t.

Keil uVision: Szép, gyors. Kiválóan működik az mbed. Ha nem akarsz mbed-et, akkor rengeteg MCU-t ismer, és sok példakód is letölthető hozzá, akár MCU-hoz, akár boardhoz. Próbáltam mbed projektekkel, saját konfigurátorával és cubeMXszel is. Érdemes megnézni. Hátránya az ingyenes verzió 32 kB kódméret limitje.

System Workbench for STM32, és néhány másik Ecipse alapú cucc: Valami sosem működött az mbed projektekkel: Nem fordult le. Lefordult, de a feltöltött blinky szintű kód azonnal fagyott. Mbed nélkül nem próbáltam. Szóval akár még jó is lehet.

ARM-GCC + makefile: Szép, gyors, multiplatform. Akármilyen szövegszerkesztővel összerakható, aztán lehet telepíteni debug servert, és akkor abban fejlesztesz, amiben akarsz. Rész sikereket értem el benne, de túl sok idő volt mindent telepíteni / konfigurálni ahhoz képest, hogy a feltételeim között szerepelt a rapid szó is.

CooCox CoIDE: Szép is, jó is. Csak a weboldaluk döglődik (package manager download timeout...) + a némelyik mbed projektemet mindig újra fordítja + nem mindegyik mbed projekttel működik. Van hozzá sok könyvtár, package manager és mintakódok is. Saját maga kezeli a debuggert, így például akár ST-Linkkel is lehet Nuvotonra feltölteni.

Atmel Studio: Nagyon jó. A munkám során többször találkoztam vele. Hátránya, hogy csak Windows és csak Atmel.

SEGGER Embedded Studio: Sample projektekkel próbáltam csak. A telepítés után viszonylag hamar összeklikkeltem egy blinky-t, ami aztán tényleg futott is. Akár jó is lehet.

STM32Cube + Atollic. Szuper. Csak azért nem használom, mert nem akartam ennyire alacsony szintről indulni. Mbed import közvetlenül nincs, közvetve pedig nem jött össze.

EmBitz: Elég jó. Kicsit rontja csak el az mbed az exportot. Pár paramétert át kell írni, hogy működjön. Az IDE működik, teszi a dolgát, egész gyors. Az automatikus kódkiegészítés a projekt egyes részeire működik csak. Példa: Keil RTX API függvényeket ajánl, de az mbed API-t nem, miközben a projekt lefordul, tehát látja. De az is lehet, hogy ez megint csak mbed exporter hiba.
(#) csatti2 válasza kiborg hozzászólására (») Feb 20, 2017 /
 
Az STM oldaláról kismillió példaprogramot letölthetsz a különböző perifériák használatához. Általában vmelyik discovery kithez optimalizálták őket, de kis munkával futtathatóak más eszközön is.

Annyi mindent szerintem nem kell beállítani egy "LED Blinking"-hez EmBitz-nél (én is azt használom). Létrehozol egy projektet SPL alappal a kívánt uC-hez. Hozzárendeled az ST-Linkedet (nem is kell konfigurálni rajta semmit). Ezután már írhatod is a programod.
Következő: »»   86 / 175
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.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