Fórum témák
» Több friss téma |
Az esca.atomki.hu/NUC140/ oldalamon találsz minimális információt. Nagyon ajánlom az oldal alján belinkelt mintapélda gyűjteményt (Richard Kuo). Ha jól látom, az Keil-hez készült, de minimális erőfeszítéssel bizonyára átpofozható Coocox CoIDE alá.
Én még az elején járok, s egyelőre egy Cortex-M0 alapozó tananyagot próbálok összehozni Nuvoton NUC140, STM32F0 Discovery, LPC1114 és Freescale FRDM-KL25Z eszközökkel.
Köszi !!! Az oldal sajnos nem működik !!!
Van pár példa a NuTiny-NUC140 kártyához is ! A Keil-t próbálgatom...sokkal profibbnak tűnik mint a CooCox. Idézet: Melyik nem működik?„Az oldal sajnos nem működik !!!” Idézet: Annyi pénzért lehet is... Mondjuk egy-két dologban nekem a CoIDE a szimpatikusabb. Pl. kezdőként könnyebbnek tűnik egy új projekt összerakása, kellemes, hogy kínálja a példákat és a driverek dokumentációját. De a Keil az oktatásban nyilván kihagyhatatlan... „A Keil-t próbálgatom...sokkal profibbnak tűnik mint a CooCox.”
http://esca.atomki.hu/NUC140/ - Nekem nem nyílik meg !
Elindítottam a Keil-el a Nuc140-est. A szimulátornak a következő beállítások kellenek ! /*------------------------------------------*/ /* NUC130/NUC140 MEMORY MAP */ /*------------------------------------------*/ map 0x00000000, 0x0001FFFF exec read // Flash map 0x20000000, 0x20003FFF read write // SRAM map 0x40000000, 0x400FFFFF read write // ABP1 map 0x40100000, 0x401FFFFF read write // ABP2 map 0x50000000, 0x501FFFFF read write // AHB map 0xE000E000, 0xE000EFFF read write // Sys Ctrl /*------------------------------------------*/ /* Run the Program (stop at main) */ /*------------------------------------------*/ //g, main Idézet: Ez roppant érdekes, mert most én is "kívülről" nézem, és működik. A szerver sem elérhető el? Hol vagy? „http://esca.atomki.hu/NUC140/ - Nekem nem nyílik meg !”
Próbáltam 3 böngészővel, de a ping sem megy ! Salgótarjánban vagyok ! Minden más működik !!!
A ping hivatalból nem megy. A honlapnak viszont be kellene jönnie. Na, mindegy, akkor felrakom ide. Előre szólok, hogy a CMSIS oldal még nincs megírva (strandon voltam helyette...).
PROFI MUNKA ! Gratulálok ! Igényes érthető, áttekinthető !
A semihosting érdekes, ha az USART másra kell. A "semihosting.h" a CooCox ban van ? Keil-ben ír a net retargetről, a Nu-Link change history is említi, de debugger settingsben nincs állítási lehetőség. Nem tudom működik-e ? A CMSIS a Nuc140-ben elég régi 1.3, most már a 3.1-nél tartanak. Van ennek jelentősége ? Élég nagy munka lenne átnyálazni és frissíteni, nem tudom lenne-e értelme. A Keil illetve CooCox smart linkeres ? Ha beteszem a DrvLib-eket, akkor befordít mindent, vagy csak a használt kódot ? A CooCox-nak úgy látom megint csak saját CoX per.lib.-je van. Bőség zavara. Még véletlenül sincs az USB benne, késik !!!! Igazán szabványosíthatnák a periféria kezelő könyvtárakat is. Elég gáz a proci portolás. Még egy kérdés : A DrvSYS_Open() freki állító fix-en feltételezi a 12Mhz -es quartz-ot. Hirtelen nem találtam alap freki állítási lehetőséget és a proci doksi is ragaszkodik a 12Mhz-hez. Köszi szépen a segítséget.
Én az STM32F2xx, 4xx-et ajánlom elsőre, aztán meg jöhet az NXP mondjuk LPC1788.
40-50$ a befektetés, + 20$ az ULINK2 a Keil-hez. Ebay-en mindegyikből van 2x60 lábú panel, rajta minden ami kell, SRAM, SDRAM, NAND-NOR Flash, és még pár apróság. Innen egybe megvehetsz mindent. A hozzászólás módosítva: Júl 18, 2013
A LPC1788 helyett megfontolandónak tartom a 4088-at, az már Cortex-M4, hardver FPU-val, alig több zsetonért.
Idézet: Igen. A Keil és IAR esetében pedig a gyártó által kiadott startup_NUC1xx.s és system_NUC1xx.h állományokban kell "varázsolni" a semihosting aktiválásához (lásd ebben a beírásban).„A "semihosting.h" a CooCox ban van?” Idézet: A 2.0 elsősorban DSP függvénykönyvtárral, a 3.0 pedig RTOS API-val bővítette a CMSIS-t. „A CMSIS a Nuc140-ben elég régi 1.3, most már a 3.1-nél tartanak. Van ennek jelentősége?” Idézet: Végigszőrözni az összes DRVlib-et? Ez a gyártó dolga.„Elég nagy munka lenne átnyálazni és frissíteni, nem tudom lenne-e értelme.” Idézet: Mivel a DrvLib-eket forráskód formájában adod hozzá a projekthez, csak a "mindent befordít"-ra tudok tippelni.„Ha beteszem a DrvLib-eket, akkor befordít mindent, vagy csak a használt kódot ?” Idézet: A kristály frekvenciáját a system_NUC1xx.h állomány #define __XTAL (12000000UL) sora definiálja. „Hirtelen nem találtam alap freki állítási lehetőséget és a proci doksi is ragaszkodik a 12Mhz-hez.”
Idézet: Nem ugyanaz a kategória! A Cortex-M0 termékvonalat az olcsó, kisfogyasztású alkalmazásokhoz készítik, a 8 és 16 bites mikrovezérlők kiváltására. „Én az STM32F2xx, 4xx-et ajánlom elsőre, aztán meg jöhet az NXP mondjuk LPC1788.”
M0 nekem tökéletes. Én egyenlőre a PIC-ekről szeretnék lemászni. Elmúlt a szerelem. Nem fizetek egy programozóért 40 ropit és holnaptól majd a gyártó meggondolja magát...örök hűség ígéret nem számít...vedd meg az újat. Fillérekért kellene adni ! ST Discovery 2 ropi és rajta van programozó.
Köszi..hasznos infók. Most megint cumi van. A Keil-ben van az Project/Optins for target. A C++ az ASM illetve a Linker fülön a control string sötét. Nem szerkeszthető ! Nem tudom elhinni, hogy nem enged hozzá nyúlni! Direktben a dep file 1. sorában ezt írja : Dependencies for Project 'NUC140_Test', Target 'Nuc140_Test': (DO NOT MODIFY !) A hozzászólás módosítva: Júl 19, 2013
Az élet szép....
 Egy meglévő minta project-et átraktam máshová, ahogy szoktam,más dir struktúra. Itt van minden CMSIS és DrvLib. A Keil-ben nincs a project fülön Save as... Kénytelen voltam 0-ról csinálni egyet. Minden opciót ugyanúgy állítottam be mint az eredeti projectben, mégis jön egy figyelmeztetés. Már mindent átnéztem..... linking... .\obj\NUC140_Test.axf: Warning: L6305W: Image does not have an entry point. (Not specified or not set due to multiple choices.)
A project Optins panelon a Linker fülön kiveszem a Use Memory Layout from Target Dialog pipát, akkor automatikusan beiir az Object beállítás dir-be egy scatter file-t.
Ezt azonban nem hozza létre, csak akkor ha be van pipálva. Ha kitörlöm a mezőt akkor jó, nincs Warning !!!! Csak a címeket be kell írni. Gondolom jól értelmezem...az R/O Base a belső ROM kezdete, az R/W pedig a belső RAM-é ? Most akkor kell scatter file vagy nem ? Nem tudom mi baja van ! A hozzászólás módosítva: Júl 19, 2013
...miért nem vagyok meglepve, hogy van kínai minőségi szoftver is !!!
Remélem chip-et nem Ők tervezték. A Nuvoton drive lib egyszerűen borzasztó...tele van hibával és kiváncsi vagyok, hogyan gondolták, azt ha beállítok egy bit-et akkor a viszaadja, hogy elcsesztem a paramétert. Érdekes lenne egy olyan program amiben minden bit állítás után a prociban megnézem, hogy jól hívtam-e meg a function-t. Vége van a világnak, ha ilyen szemetet ki mernek adni..... Most ganéjozzak ki mindent ? Idézet: Csináld meg, és add el nekik! „Most ganézzak ki mindent?”  Úgy tudom, hogy a jelenlegi szoftvert is külső céggel csináltatták.
Ki az az eszement aki ilyet ir ? Egy másik gyöngyszem pár sorral alább:
Az ST legalább korrekt ott assert van! A hozzászólás módosítva: Júl 19, 2013
Sziasztok!
CooCox IDE alatt próbálok összehozni pár alap periféria felélesztést. Az UART-nál elakadtam  . Vagyis egy dolog nem tiszta ott, ami a többi perifériát is érinteni fogja. Egy adott GPIOx_AFRL/H regisztereket hogy kellene kitölteni? A doksiból az sem kristálytiszta, hogy minden GPIO-hoz akármelyik perifériát hozzá lehet rendelni, vagy kötve van melyiket? Illetve, ha a GPIOx_AFRL/H beírok AF7-hez tartozó értéket, akkor az az USART1 RX, TX, CTS vagy melyik funkcionalitását rendeli az adott lábhoz?
Topi, a Jó Isten áldja kezed-lábad stb...
Sok-sok "kőbiztos" forrás áttanulmányozása után a Te általad küldött INIC végre működik is. 1 byte volt elírva (de nagyon). Csak azt nem értem, hogy másnak azok hogyan működtek??? Egy regiszterbe 0x0C-t véstek, ami a pdf szerint 0AAA0000 lehet, tehát alulra "C" birkaság. 0x20 a helyes, azonnal helyreállt minden. Mégegyszer nagyon köszönöm a segítséget!!! (nem kisebbíti a tényt, hogy ebben a forrásban olyan regisztereket is írnak, ami elméletileg nincs is, de több pdf-et átolvasva a gyártó is bizonytalan abban, hogy mit is csinál) JAni
Szia Jani!
Idézet: „HY35A 3.5" TFT SSD1963-as vezérlővel, STM32F407 Discovery portján 8-bites módban szeretném hajtani” Sikerült eredményre jutni a témában? Én is hasonlóval küzdöttem STM32F407 és 4,3" SSD1963 esetében, csak én 16 bites buszt használok. A piros nekem akkor kezdett végre működni, amikor a B0 regiszter 1. paramétereként 0x20-t adtam meg, vagyis a "TFT panel data width" értékét 24 bitesre állítottam a 18 bites helyett. Nem tudom, hogy miért működik így, mert az adatlap semmit nem ír erről a beállításról (a valódi adat ugye 16 bites: 565 RGB). A véletlenszerű lefagyások - az LCD kifehéredik - akkor szűntek meg, amikor az STM32 belső órajelét 168 MHz-ről jelentősen visszavettem. Mivel az LCD és a mikrokontroller panelek között nálam kb. 20 cm hosszú kábel van, én a hosszú vezetékre fogtam, hogy nem megy magasabb frekin a kijelzés. Viszont ami még mindig megmaradt, az a bizonyos színeknél való lefagyás. Akármilyen lassan vezérlem is az LCD-t, kb. 6-7 színnél (pl. 0xFFF2) még mindig kifehéredik az LCD. Ha programban letiltom ezeket a színeket, akkor szépen fut a rajzolgatás. Odáig jutottam, hogy rendeltem még egy LCD-t, hátha valamilyen hardver hiba játszadozik velem. Most itt tartok, várom a 2. LCD-t.  ui.: épp most látom, hogy előző hozzászólásodban sikerült megoldanod a problémát, de már csak nem törlöm a kommentem. A hozzászólás módosítva: Júl 21, 2013
Idézet: Kötve van. „A doksiból az sem kristálytiszta, hogy minden GPIO-hoz akármelyik perifériát hozzá lehet rendelni, vagy kötve van melyiket?”
Szia Toto!
Hát ez a hozzászólás jöhetett volna 1 héttel korábban is Szerintem a másik kijelzővel is így fog működni, nálam is pont ezek a színhez kötött lefagyások vannak. Mindketten már csak nem kaptunk ugyan olyan vackot...vagy mégis. Nálam is csak ki van madzagolva az ARM port kb 15cm madzagokon, szóval ennyire érzékeny lenne? Próbaképp rátettem AVR-re dugdosós próbapanelen és igaz, csak 22MHz-ről, de tökéletesen megy (csak így semmire sem használható, mert 1 sec egy teljes teleírás). Lehet ám, hogy az ARM portmeghajtásán kell még variálni, hogy nagyobb áramot adjon, most hirtelen nem is tudom, mire van belőve. Mindenesetre köszönöm a hozzászólásod, megerősítésnek mindenképp jól jött!!! JAni
Most én kérnék segítséget!
Úgy gondolom ebben a témában valószínűleg többen kezeltek már OLED-et. A jelenség a mellékletben található. Adott egy OLED kijelző SSD1305-ös vezérlővel. A készülék technológiai megvalósítása okán OLED fóliára van szükségem, nyák, fémkeret és egyéb körítés nélkül. A jelenség észrevehető a mellékletben lévő képen, miszerint enyhén csíkos a kijelző bárhol ahol teli pixelek után szünet, majd megint pixelek szükségesek. Úgy néztem, hogy hasonló problémával mások is küzdenek OLED-es kijelző esetében ( http://i.imgur.com/2ZGmil.jpg, vagy http://i.imgur.com/vdib9.jpg ) Hiába tették fel a kérdésüket, vagy nem kaptak választ, vagy valami kitérőt. Én arra tudok gondolni, hogy Pre-charge és VCOM detect probléma lehet, mert ezen a csíkozódáson tudok rontani. Csak javítani nem. Nem magával a kijelzővel van gond, mert ebből is kipróbáltam másik példányt, nyákos gyári modult is kipróbáltam (amin saját táp van) és mindegyiken hasonló a jelenség (ugyan azon programmal) Találkozott már valaki hasonló problémával? Köszönöm. A hozzászólás módosítva: Júl 22, 2013
Szia!
Igaz én nem COG-al hanem panelessel dolgoztam (a'la SOS-es) és ugyan ez a jelenség, ha nem is ennyire élesen, de jelentkezett. Kerültem is a nagy területeket megjelenítéskor, talán nézd meg, ha "beszamócázod" a nagy aktív felületet, akkor jelentkezik-e láthatóan. Nálam: SET Prechange: 0xD9 aztán ezek jönnek sorban:0xF1, 0xDB, 0x49,0xA4,0xA6,0xAF (utolsó már a display ON parancs) Hátha bejön... JAni
Köszönöm! Kipróbáltam, de sajnos változatlan a helyzet. Ideiglenesen amíg nem oldottam meg a gondot, addig átvariálom a megjelenést, és a mostani scrollbar helyett csak fel-le jelöléseket használok.
Nálam is csak itt markáns ez a jelenség, sok helyen használok ikonokat amik állapottól függően lehetnek akár inverzek is, ott a háttér kitöltésében is egy egészen kicsit látni ezt a problémát. 0xFF precharge-al sem jó, tehát gyanítom hogy ez az IC gondja, de hátha tud akkor még valaki valami trükköt.
Üdv!
Normális az, hogy 24 óra alat az stm32f4 RTC-je 30sec-et siet? Tudom, hogy lehet kalibrálni, nade ha ekkora lesz a szórás minden pnelen... Külső 32kHz kvarcról hajtom. Ettől még a legolcsób RTC chip is pontosabb volt. De mivel benne van az arm-ban nem akarnék külső rtc-t használni. Van valami megoldás? Ja akijelző csíkozódás nem mult még el, hiába állítgatom a V/H porch értéket. A csíkozás vízszintes, tehát gondolom csak az egyik értékkel van a baj.
Ez ~350ppm, ez semmiképpen nem normális. Kondik rendben vannak? Ugye nem breadboardon nézed? Mert ott bármi előfordulhat.
Nem bread board, hanem fejlesztőpanel. A kvarc elég közel van a cpuhoz, és 15pF kondik is rendben vannak.
|
Bejelentkezés
Hirdetés |
