A fejlesztők tévedtek volna? Az olimexes panelen is 15pF van.

Kvarc fajtától függ, hogy mekkora illik hozzá. Mivel adatlapod jó eséllyel nincs (még a boltban kaphatóak 90%-ához se nagyon szokott lenni), így nem tudhatod, hogy mekkora is kéne oda. A +5pF nem okozhatna ekkora eltérést akkor se, ha a 10pF lenne a helyes érték.
Viszont lehet, hogy nem teljesen 100-as a kondi, vagy nem jó a forrasztás, azok már okozhatnak ilyen gondot. Igazából a kvarcot is ki lehetne cserélni, és lehet, hogy azt kellett volna legelőször javasolnom.

Értem, megpróbálom, de anno a pcf8583-al nem volt ilyen gondom, bár ott azt hiszem a kvarc egyik lábára kellett a kondi csak. Lehet jobb lenne, valami oszcillátort használni?

Esetleg ha működés közben mérsz frekvenciát? 32.768 KHz nagyon alacsony frekvencia, szkóppal, frekimérővel könnyen kideríthető hogy mi a gond. HW-es probléma van, vagy hibás SW miatt csúszik.

Szerk: Egyébként én 10-10 pF-ot szoktam használni és kristállyal párhuzamos 1MOhm-ot.

Olimexék is tévedhetnek. Nekem van olyan olimexes panelem amin utólag derült ki, hogy hibásan van bekötve az RMII interfész (Ethernethez), és később tettek fel javítást.
Amilyen tempóban adják ki az újabb panelokat, nem lepődnék meg semmin.

Pedig elvileg azért vesz az ember ilyen eszközt, hogy ne kelljen szívni, és legalább a HW biztos legyen.

Délután megmérem a frekit.

Az a 347-348ppm azt jelenti, hogy a 32.768KHz helyett közel 11,5 Hz-es eltérés tapasztalható.
32.756 KHz - 32.779 KHz. Ez szemmel láthatóan lesz más.

Ha már így szóba került, készítettem hozzá gyorsan egy számolót a segédprogramokba, hátha hasznodra lesz mérésnél is.

Segédprogramok: ppm -> Hz

A Freescale FRDM-KL25z "Freedom" board esete a három debuggerrel

Amatőr körökben divatos lett a Freescale FRDM-KL25Z kártya, amely a 80 lábú, Cortex-M0+ kategóriájú MKL25Z128VLK4 MCU (48 MHz 128 kB flask, 16 kB RAM) köré épül. Van a kártyán Open SDA debuuger, RGB LED, 3 tengelyű gyorsulásmérő és egy érintőcsúszka is. Az első pofáraesés csak akkor jön, amikor az ember rutinból nekiesik a kedvenc fejlesztőrendszerével (Keil, CodeWarrior, Coocox, stb.) és nem tudja letölteni a programot. Az OpenSDA áramkörben ugyanis alapértelmezetten egy másik firmware van, ami az mbed stílusú fejlesztéshez (flash drive bootloader) talán jó, de a "hagyományos" fejlesztői környezetekhez, pláne nyomkövetéshez alkalmatlan.

Elsőként le kell tehát tölteni a FRDM -KL 25Z Quick Start Package
nevű csomagot. Abban van egy FRDM-KL25Z Quick Start Guide című leírás, az abban leírtakat kell követni.

A fenti csomagban van több firmware is:
MSD-FRDM-KL25Z_Pemicro_v105.SDA - ez az alapértelmezett flash drive típusú letöltő.

DEBUG-APP_Pemicro_v102.SDA - ez a PEmicro eszközeivel kompatibilis hardveres nyomkövető firmware. Ennek előnye, hogy az USB kombo eszközként bejelentkező nyomkövető mellékesen egy virtuális soros portot is létrehoz, ami kellemes a fejlesztéseknél. Ezt a típusú nyomkövetőt a CodeWarrior és a Keil is használni tudja (a Keil-hez le kell tölteni a Freescale Kinetis OpenJTAG diversc csomagot). A Coocox CoIDE azonban nem tudja kezelni ezt az eszközt.

CMSIS-DAP_OpenSDA.S19 - Ez a szabványos CMSIS-DAP firmware, amelyet a Keil és a CoIDE is kezelni tud. A Code Warrior azonban nem (vagy én nem jöttem rá, hogy hogyan kellene összebarátkoztatni vele...). Ez a firmware nem biztosít virtuális soros portot.

Van még egy negyedik firmware is, amit azonban a Segger honlapjáról kell letölteni:

J-Link OpenSDA firmware - ennek betöltése után a FRDM-KL25Z nyomkövetője úgy viselkedik, mintha J-Link nyomkövető volna. Tapasztalataim szerint ez használható Keil, CoIDE és CodeWarrior környezetben is, tehát ez a legáltalánosabban használható firmware. Viszont ez sem biztosít virtuális soros port kommunikációt a debuggeren keresztül.

Firmware csere: Ha bekapcsoláskor (értsd USB kábel bedugáskor) lenyomva tartjuk a Freedom kártya Reset gombját, akkor bootloader módba kerül. Ilyenkor egy BOOTLOADER kötetcimkéjű flash meghajtó jelenik meg, amibe csak bele kell másolni a kiválasztott firmware állományt.

Köszönöm, nagy segítség, de ma amikor hazaértem majd leesett az állam.

Ránéztem az órára és 2sec-et késett!!!
Tegnap ilyenkor még 30sec-et sietett!
Tegnepelőtt indítottam.
A kvarc lábain nem tudok frekit mérni, mert ha ráteszem a szkópot, akkor megáll az RTC is, ha elveszem a mérőcsúcsot, akkor folytatja a számolást.
Na most ilyenkor mivan?

Hülye viccet csinál a fórummotor: az előző beírásomban a gondosan beírt linkjeim egy részét pofátlanul lecserélte a HEstore reklámlinkekre!

Te raktad be a kondikat, vagy gyárilag benne voltak?

A két láb közül az egyiken ez helyénvaló (az "input" láb esetén), a másikon viszont ez nincs rendben így (az "output" lábnak el kell viselnie a mérőfejet - feltéve, hogy nem valami házilag eszkábált, 42000pF-os mérőfejed van).

Gyárilag voltak benne.
Hát nem házi a mérőfej, de nem hinném, hogy attól sokkal jobb lenne, MINI DS0201. De multiméterrel sem tudom mérni, mert 0-t mutat, lehet inkább kilököm, a kvarcot.
Lehet, hogy szétfőzték, mert elég durván leforrasztották gnd-re a kis kvarcot teljesen ellepi az ón .

Egy csomó féle-fajta órajelet ki lehet vezeti az ARM prociból. Nem próbáltad meg az RTC órajelét kivezetni?
Másik ötlet méréshez: RTC-nek tuti van valami Interrupt kimenete. Csináld meg azt hogy bizonyos időközönként az RTC megszakításkor egy GPIO láb HL, majd LH, ciklikusan, majd mért azt DSO-val.
Pl: LPC1788-ban van RTC-CLK-OUT a Clocking fejezet szerint.

A Texas Instruments már szállítja a EK-TM4C123GXL - Tiva™ C Series TM4C123G Launchpad kártyát(Bővebben: Link), de még mindig 8-10 hetes várakozásra kell számítania az új megrendelőknek. Én április 30-án rendeltem egyet, ami a múlt héten érkezett meg.

Az EK-TM4C123GXL kártya egyéként majdnem ugyanaz, minta az LM4F120 mikrovezérlővel szerelt Stellaris Launchpad kártya, csak egy nagyobb kiépítettségű MCU került bele (s közben átkeresztelték a szériát Stellarisról Tiva C-re).

Egyébként most még kapható az eredeti EK-LM4F120XL Stellaris Launchpad kártya is (Bővebben: Link), sőt, most leszállították az árát ($12.99 helyett $9.99).

Szia!
A kvarcon a jelet 1:10-es osztóval kell nézni, akkor nem áll le az oszcillátor!
Topi írta, hogy:
Szerintem ennek a mérésére az általános oszcilloszkópok alkalmatlanok, esetleg egy digitszkóppal ( de abban sem bíznék, inkább egy sok számjegyű frekimérő , ! ), viszont az, hogy egyszer késik, egyszer siet, az szerintem nem a kvarc pontatlansága !

Üdv!

A TFT csíkozódás továbbra is fenn áll, nem tudom, hogy pontosan mire állíthatnám, be a front/back porch-értékeket. A neten akárhány videót nézek sehol nem látok ilyesmit és nem is panaszkodnak rá, és ahol kirakták a forráskódot azokban ugyanazokkal a beállításokkal megy, mint amit én használok.
Létezhet, hogy a kijelző hibás?

Szia!
Na, csak szenvedtem vele még egy hetet. Természetesen találtam még 2 elírást a "tuttijó" mintában, a csúcs, a Winstar ajánlás, ami 99%-os, de ott is félrecsúszott 1-2 adat.
Végül is működik, csak az X coordináta 2-től kezdődött, az Y meg már nem látszott, szóval el volt tolódva a szinkron. Először nem is vettem észre, de a 0,0-319,239 keretrajzoláskor kijött.
Addig tököltem a szinkronokkal, ameddig a deffiniált terület minden eleme nem látszott.
A színekkel viszont van valami gubanc, te is írtad, hogy van olyan szín, amitől kihal.
Na, elkezdtem kísérletezni és valami furcsa dolog jött ki, normál 5-6-5 nem. Bin11111xx...., tehát
full pirosra kiakad, az alsó biti nullába kell hagyni, de csak akkor, ha nincs kék. Szóval valami furcsa dolog ez. És függ a memóriahelytől is. Erre akkor jöttem rá, amikor egy JPEG meg BMP kis ikont kipakoltam és ha X>254 volt, akkor elszállt. Természetesen ezen a területen a 320-ig mást rajzolhatok, szóval nem a memória hozzáféréstől akad ki.
Mivel sok RAM van az SSD1963-ban, legközelebb majd azzal kísérletezek, hogy lapokat váltani és akkor megkergül-e. Utána másik kontrolleres (valami 1925 vagy mi...) jön, ha megjön. Sajnos ST32F407 Discovery-n portolva a kijelző 140MHz-ről szerintem csak játéknak jó, lassú (már nekem, mert műszereket farigcsálok), szóval memóriába kell ágyazni és DMA-zni illik, de ezt a Discoveryn nem tudom bemadzagolni csak ha mindenvackot leforrasztok róla. Különben szép a kijelző, sajnálom, hogy porton nem lehet megkergetni (nekem elég lenne 256 szín akár paletta nélkül is, de a kedves tervező 8-színes üzemmódban is 3-byte-ot kér). Brrrr.
JAni

Nálam az SSD1963 16 bit széles buszon működik, RGB565 színekkel, egy STM32F407VET6 hajtja meg FSMC-vel.

Ha ezeket a színeket soha nem küldöm ki, akkor egészen jól elműködik a kijelző. Én a pixelek pozíciójával való összefüggést nem vizsgáltam, kicsit belefáradtam ebbe a játszadozásba a kijelzővel. A double buffer vagy nevezzük lapváltásnak - eddigi tapasztalataim szerint legalábbis - jól megy.
Én továbbra is arra gyanakszom, hogy mivel a kijelző doksija egy csomag sz@r, sok minden nincs leírva benne, ezért valamelyik regiszterbe rossz értékeket írunk, vagy épp nem írunk semmit.. Ha megnézzük a datasheet különböző verzióit (0.2, 1.1, 1.2) akkor ott is van olyan regiszter, ahol az egyik datasheet alapján fontos, hogy beállítsd a regisztert, a másik szerint meg ne használd, mert a regiszter "reserved".
Én is megnéztem pár minta-beállítást a netről, de sok csak 8 bitesen programozza, meg nem ezt a felbontást, így nyilván nem is ugyanaz a beállítás. Olyat is találtam, ami egyszerűen félre volt konfigurálva, úgy nem is működhetett a szerzőnek.
Azon én is gondolkodtam, hogyan lehetne még gyorsabbá tenni a kijelzést, de sajnos ezeket a display-controllereket nem vektoros kijelzésre tervezték, hanem teljes képernyős vagy legalábbis egy részterület felülírására. Ezért tart olyan sokáig egy árva pixel kirajzolása.
Én anno azért választottam ezt a kijelző-meghajtót, mert ha nem a full 800x480 felbontást használod, hanem mondjuk 480x272-t, akkor double-bufferként használhatod a maradék képernyő memóriát, és akkor már nem villog egy lassabb megjelenítésnél sem. Ha váltanék is meghajtó-típust, akkor az FT800-at próbálnám ki az FTDI-től. Abban sok minden meg van oldva hardveresen, kár, hogy még nem terjedt el.

Én is csak a nagy memória miatt döntöttem mellette, nekem 320x240 bőven elég és akkor jó sok lap beleférne...már ha nem hullott volna ki a maradék hajam is miatta.
A pdf.-ek ellentmondásosak, kínomban már tényleg bitenként lökdöstem.
Az EVE az FTDItől nagyon bizergálja a fantáziám, de ahogy láttam, csak a Mikro(basic/pascal/C)-hez csináltak valami LIBet. (ja, persze MikroBasic for ARM-el az SSD konfig úgy ahogy van, egy kalap sz.r, a forumban ígérik, hogy dolgoznak rajta...hogy lett ez a cég az év cége...) A mintákra meg tényleg, minek mondja valaki hogy jó, amkor ránézésre hibás.
(vagy lehet, mi kapunk kinai selejtet???)
Az FT800 EVE -ről meg leírást sehol sem találtam, lehet, nem is lesz??? Olyan lesz, mint a GFX gyorsítók, minden titkos, max kapsz egy LIBet
14e körül láttam TFT-vel együtt...hát ha lesz rá keret, csak kipróbálom mit tud.
(még 2 hét izzadás)
Igazából nekem normál 128x64-es LCD kiváltására kellene valami TFT de egyszerűen nincs ilyen méretben alacsony felbontással. Kell a francnak a HD felbontás 24-biten...de nincs.
JAni

Nem szeretném tovább OFF-olni az ARM-os topic-ot az LCD-s témánkkal, csak jelzem, hogy az FTDI végre kirakta a honlapjára az EVE adatlapját, programozási útmutatót, példaprogramokat. Végre már nem csak a béna Mikroelektronikás program áll rendelkezésre.

Ezt láttátok már?

Ez igen! Csak a Farnell-nél néztem, sajnos 65 nap múlva lesz, de 6000-ért igen jó cucc.
Azért megint sikerült jól szétszórni azt a 23 free I/O-t.
JAni

Már én is várom egy ideje ezt a chip családot.
De így kompletten még izgalmasabb lenne...
Csak sajnos ebben nincs benne az LCD vezérlő, csak a nagyobb tokozásokban.

Kicsit figyelmetlen voltam az adatlappal... Ebben is benne van az LCD vezérlő, csak jobban el van dugva a hozzá tartozó láb. Így teljes az öröm .

Azért ez érdekes részemről...
Van egy olyan uC, amiben van TFT kontroller, erre hozzátesznek egy olyan TFT-t, amiben van vezérlő (no, jó, nem okos, de 230 oldalt átnyálazni). Memóriába ágyazva a régebbi 407-es is meg tudta bizergálni a kontrolleres TFT lazán. Akkor most ide miért is van belső TFTvezérlős uC ami direktben tudná hajtani a buta/olcsó TFT-t is?
JAni

Sziasztok,

Én is belefutottam ebbe a devboard-ba minap. Ennyi pénzért tuti veszek.

És nekem is szemet szúrt a vezérlős TFT a panelon. Egy 4.3" vagy 7" vezérlő nélküli TFT-t simán rápakolhattak volna. Ez jobban kihoznáa a proci teljesítményét. SVGA felbontást támogat a proci. Kíváncsi leszek.

Engem is ez zavart be egy kicsit...

Biztos azért használták ezt, mert olcsón be tudták szerezni.
Viszont 16bit-es RGB módban hajtható a kijelző, így ki lehet használni az MCU lehetőségeit.

Én sajnos 5 sornál bővebb tájékoztatást nem találtam a NET-en erről a uC belső TFT vezérlőről és használatáról!

Nem ezért alkalmaztak külső vezérlőt?

Ha jól látom a patakiosztást TFT vezérlő és RGB lábak ugyan azokon a portokon vannak, tehát elméletileg normál buta TFT is mehet oda.
A pénzfeldobással vagy vakon össze-vissza kiosztott bitekre akkor most ki kell egyenként bitezgetni a küldendő adatokat? Vagy én vagyok béna, vagy ők, de 30 utasítás lesz egy adat kipakolása? Már nem is annyira tetszik így, egyben, jó "nagy" sebességet lehet elérni akkor a kijelzőn...