Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Jól sejtem, hogy az a sebesség neked arra kell, hogy ne villogjon a kép zavaróan, amikor kiraksz egy új alakzatot, vagy mozgatsz, vagy ilyesmi?
Persze. Ha egy új képet kell kirakni, mondjuk egy szerviz lapot megjeleníteni, akkor az "azonnal" jelenjen meg. Ha elő lehetne készíteni a képet RAM-ba, akkor a valós várakozás a kép előkészítéséig nem lenne zavaró, az sokkal inkább, ha lassan rajzolódik ki a kép. Jelenleg egy SQI Flash-ben tárolom ezeket a képeket és elég gyors, de jó lenne, ha ablakokat is tudnék kezelni, amihez már video RAM kéne (tárolni a háteret és kezelni az ablakokat, visszaállítani a hátteret stb.) A dolog nem kritikus most, de jó lenne...
Kotorásztam tft lcd modulok után, mert mondom képtelenség, hogy mindenki csak olyan hulladékot nyomjon, amiben nincsen elég ram dupla bufferelni, és utasítani a vezérlőt a swap-ra, de az a helyzet, hogy nem találok olyan terméket. Egyáltalán semmi pénzért sem. Csak pislogok, hogy mi a fene?
![]() Valami nagyon görbeorrú népség kezébe került a tft lcd piac.
A TFT k többsége arduinohoz készül ott meg mindegy....
A HMI TFT-k is egy lehetőség, de pont erre nem jók, mert azok is csak előre megdott képekkel tudnak dolgozni. Előnyük, hogy nem kell erőgép hozzá, soros porton mondod meg, melyik letárolt képet tegye ki. Hátrány, hogy megköti a kezet és nem olcsó. És tényleg nincs dupla pufferelt, vagy külön videorammal ellátott TFT panel. Lehet, ez egy jó üzlet lenne...
Egy fpga drammal meg tudná csinálni, viszont normális nyák kellene hozzá, ipari beültetés és forrasztás (túl sok lábas bga tokokat beültetni). Ismersz valakit, aki fusiban hozzá tud férni normális gyártó berendezésekhez?
Sziasztok!
PWM-mel szeretnék egy PIC16F887-es PIC-re RC1 lábon lógó LED-et működtetni. Tudnátok nekem Mplab XC8-ra egy forrásprogramot küldeni? Sokszor próbálkoztam már megírni, de mindig elakadtam. Köszi előre is!
Szia,
Van megoldás 8bites mikrokontrollerekhez is TFT LCD vezérlésre, ha nem túl nagyok az igények a design tekintetében.. Nem tudom ismered-e ezeket: https://riverdi.com/product-category/displays/ft8xx/ Én ezeket használom AtMega64-el (mióta a Microchip felvásárolta őket talán nem off topic itt) A Riverdi termékei közül a fenti linken lévők SPI/IIC interfészen keresztül vezérelhetők, és nem kell teljes bitmintát kiküldeni, csak az FT8xx vezérlőnek kell parancsokat küldeni. Ezek között megtalálhatóak a teljesség igénye nélkül: pont, vonal, négyszög, vagy akár bonyolultabb egységek (widget az ő szóhasználatuk szerint): button, scrollbar, progressbar stb, vagy bmp kép esetleg MIDI parancsok, mivel hangok generálására is képes. Én két grafikus fejlesző eszközüket ismerem : FTDI EVE MicroC support Az FTDI grafikus szerkesztője támogat több platformot többek között az Arduino-t is. Nálunk a TME.eu forgalmazza.
Köszönöm a linket, egész pofásak azok a kijelzők!
Nincs mit, nekem bevált az FTDI 8xx vezérlő chip család, de kicsit bele kell mélyedni a lelkivilágába. Lehet hogy más TFT LCD gyártók is használják, nem néztem utána.
Ha jól tudom ezekez hívják HMI kijelzőknek, de lehet, hogy tévedek. Jó kompromisszum lehet.
Igen, ezt már lehet így hívni:
Hermes Ez egy olcsó dev. board, a már említett FTDI grafikus szerkesztő tud forrást generálni hozzá, PC-ről fut USB-n keresztül.
c++ help!
Mint már korábban említettem, a c++-t az Arduinon keresztül ismertem meg, már amennyire egyáltalán megismertem. Adott egy karakteres LCD kezelő class, amit egyébként az Arduino/mpIDE-ből minimális alakítgatással tudtam átvenni. Így hívható a konstruktorom:
Nézzétek el, ha esetleg nem fogalmaztam mindenütt korrektűl. Mi a megoldás XC32-ben?
Példa a függvény deklarációra ?
A hozzászólás módosítva: Jún 16, 2017
Megpróbálom részletesebben...
Van egy "LiquidCrystal" classom, ennek konstruktora:
Arduinon nem igazán tudom, mi is van - azt az sdk-t nem használom - de egy normálisabb c / c++ programnál mondjuk olyasmit illik csinálni, hogy elsőként alapinit részt hívsz a main függvényből, és oda raksz be minden initet (constructorokat is), utána belépsz a főciklusba, és ott is maradsz végleg eseményfeldolgozni. Globális változók közé kirakni constructort, az valami scriptes dolog, C programokban olyan nincsen. És constructort csak egyszer hívsz meg. Nem kell azt többször. Ha létrehoztad az objektumot, utána már csak használod, amíg le nem törlöd (destructor).
A hozzászólás módosítva: Jún 17, 2017
Hát... végül most úgy oldottam meg, hogy átadtam az objektumot is paraméterként.
Amiért én nem ajánlom ezt az arduinos ctor-t mert ez a main lefutása előtt lefut és létrehozza az objektumot viszont, először mindig a hardware-t állítsuk be és utána jöhet a software.
Én ezt úgy szoktam csinálni, hogy csinálok egy empty ctor-t és ez nem zavarja a program futását. A main() paraméteri feleslegesek ki törölheted, mikor belép a program a main-be akkor én ott szoktam egy System Init-et tolni cache, interrupt, esetleges órajel (de ezt lehet configból is), ticktimer stb.. aztán jönnek a hardware init-ek majd jön egy while (true) és ide jön a végrehajtandó kód. Ha globális objektumot akarsz csinálni: Csinálsz egy pl: GobalObjects.h-t extern <class name> <object name>; és egy source file-ban meg globálisan létrehozod a class-t. És egy példa a végére a ctor-okat megcsinálod init(params) (vagy initialize) függvénnyel. LiquidCrystal.h, LiquidCrystal.c
GlobalObjects.h
main
A hozzászólás módosítva: Jún 17, 2017
Hasznos volt számomra a válaszod, általa rájöttem a hibára. Itt volt a kutya eltemetve:
Idézet: Bár a konstruktorom alapvetően csak eltárolta a paramétereket, meg összeállította az alapértelmezést, de egy kis írás a B regiszterre belekerült. Ezt kivéve onnan már kitéve globálisnak is működik. Azért az így praktikusabb, mert elérem a függvényekből is, nem csak a main-ből. Bár ha végignézem az általad írt mintát a program felépítésre, ugyan ott vagyok annyi különbséggel, hogy nem teszem külön forrásba az osztály konstruktorának hívását. „először mindig a hardware-t állítsuk be és utána jöhet a software”
Ha a ctor nincs külön definiálva akkor lefut egy default ctor avagy ha az objektum dinamikusan allokált és megszűnik a felhasználása lefut egy default dtor (destructor) de ezt is át lehet definiálni.
A c++ is nagyon sok mindenre ad lehetőséget nagyon sok irányból meg lehet valamit közelíteni én azt ajánlom nézz minél több féle kódot és ki fognak alakulni a preferenciák. Idézet: „először mindig a hardware-t állítsuk be és utána jöhet a software” Ez csak egy felfogás. Én mikor elkezdtem nem tetszett, hogy a ctor előbb fut le hardware (pl uart spi) init-el mint, hogy a cache vagy a ticktimer init. De elvileg ha jobban tetszik a ctor-ban beállítani mindent az is járható csak véleményem szerint az előbbi szebb.
Elfejtettem,
Nem feltétlen kell globálisnak definiálni egy objektumot, lehetőség van arra is, hogy indirekt módon kezeld az egészet. Létrehozod a LiquidCrystal objektumot, majd ahol fel akarod használni ott az adott class initialize (vagy ctor) függvényében csinálsz egy LiquidCrystal& pLcd változót. és egy valóságosabb példa: egy custom class header-je
main az előző példából átalakítva
bár a két objektum most globális, de ha nem definiálod őket máshol extern-ként nem fogod őket elérni. A hozzászólás módosítva: Jún 17, 2017
Sziasztok,
sok év után meguntam, hogy az MPLABC18-nál mindig trükkösen szorzok. Merthogy, nálam a fordító, ha ha két bájtot szorzok, 1 bájtos eredményt ad, ha két intet, egy intest, ésatöbbi. Eddig körbeírtam, de már öregszem, türelmetlen vagyok. Mi a szabályos módja, hogy bájt*bájt int legyen stb? (User Guide szerint ha az -Oi- kapcsolót használom a fordítóban, akkor ez történne, de nem történik. A disassemblyt megnézve, természetesen jól szoroz a rutin, pl FXM16x16, csak épp a felső értékeket nem tölti be illetve kinullázza. ) köszönöm Szasza Idézet: Igazi C forditot kell hasznalni. „Mi a szabályos módja, hogy bájt*bájt int legyen?”
Ha más nem, rá kell kényszeríteni a fordítót típuskonverzióval: if ((unsigned int)valtozo*valtozo>500) ... Azt hiszem, elég csak az egyik tagnak int típusúnak lennie, a másikat automatikusan konvertálja. Próbáld ki.
Az engem jobban zavarna, ha a fordító magától konvertálna egy változót más típusúra. Szerintem nincs ezzel így semmi gond. Ha int-et akarok, akkor abba irányítom a szorzást, ha nem, akkor nekem ne csináljon int-et...
Pedig a C nyelv egyertelmuen kimondja, hogy minden char es short erteket int-re konvertal, mielott egy muveletet vegez vele. Es az eredmeny is int lesz. Ha valamelyik operandus elojel nelkuli, akkor a masik operandust is elojel nelkuli int-re modositja es az eredmeny is unsigned int lesz. Ezt jo ha tudod, ha esetleg mas C forditot is akarsz hasznalni az eletben.
Nem csinálok problémát abból, ha valami nem úgy működik, ahogy "elvileg" kéne, ha az következetes. Elfogadom, hogy ez ilyen és használom. Megoldom, ha másképpen szeretném, hogy működjön. Oktalanság lenne időt pocsékolni arra, hogy ez miért ilyen, vagy olyan, főleg ha meg kell oldani egy problémát. Sajnos egyre több olyan dologgal találkozok, ami jobb is lehetne, vagy legalább olyan, aminek leírták, de ezen túl kell lendülni...
Üdv! Egy félig szakmai kérdésem lenne.
Próbálom lefordítgatni magamnak az i2c.h-ban (plib.h) lévő magyarázó szövegeket. A google fordítás eredményein néha még az én igen erősen mínuszos angolommal is röhögök, de azért nagy segítség. Viszont találtam egy szót, amire nem tudok rájönni, hogy ebben a szövegkörnyezetben mi a fenét jelent. arbitration = (googl) választottbírósági Kipróbáltam legalább 5-6 interneten elérhető angol-magyar szótárt, de mind hasonló bírósági találatokat ad. Mit jelent ez a szó ebben a szövegkörnyezetben? Idézet: „arbitration ... Viszont találtam egy szót, amire nem tudok rájönni, hogy ebben a szövegkörnyezetben mi a fenét jelent.” A bírósághoz csak annyi köze van, hogy jog szerzésről van szó. Az arbitráció a busz vezérlési jogáért való küzdelem. Egy időben csak egy aktív master lehet a buszon. |
Bejelentkezés
Hirdetés |