Fórum témák
» Több friss téma |
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.
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?
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
Sziasztok,
Probalt valaki STM32F427, 29, vagy 32F7 TFT vezerlojevel TFTt meghajtani RGB modban ?
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
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.
Vagy inkabb SSD kontrolleres TFTt FSMCre ?
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.
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.
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.
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.
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
Írtam elérhetőséget, mert ennyi mindent most nem tudok begépelni.
Szia ! Koszi.
Meg tudnatok mondani hogy ez TFT meghajto mennyire fogja meg a procit ?
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ó.
Koszi.
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?
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.
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?
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
É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.
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.
Ott van, csak régebben EmBlocks néven futott.
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.
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.
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. |
Bejelentkezés
Hirdetés |