Biztos bennem van a hiba, de ezt most nem értem.
Mit kéne csinálnom?
#include-ok megvannak a *.h file-okra.

A project Source Files (mplab x-en belül) mappában benne van a LiquidCrystal.cpp?

Nincs.
A brutál egyszerű teszt programmal próbáltam cpp-t, épp azzal derült ki, hogy ha a projekt könyvtárban van minden, akkor OK. Ha a class "h"-ja és "cpp"-je másik könyvtárban van, akkor nem megy.
De "sima" c-vel működik a dolog, ha az előbb írt 4 helyen beállítom a saját include könyvtárt. c++-al valami még kéne, gondolom.
A projekt betöltésekor kapok is egy ilyen üzenetet, csak eddig erre nem figyeltem fel:
"Warning: Project "LCD_170_cpp" appears to have a CPP source file. The project may fail to build if you are using a C compiler.
"

Jó akkor már értem mit akarsz csinálni, saját hordozható könyvtárakat. Hogy beállítod az könyvtár src/inc helyét és utána csak #include és mindent csinál a fordító.

Emlékszem, hogy kérdezted már ezt a dolgot. Ez engem is érdekel nem foglalkoztam még ezzel, most kezdek oda kerülni, hogy jöhetnek a mobilis könyvtárak.
De lehet Libary projectet is csinálni az X-ben.

Lehet még valami más bibi is. A header file-jaidban mik vannak függvény prototípusokon és globális változókon kívül?

1. Igen, ezt szeretnék csinálni, és ha nem c++-olok, csak sima c-ben írom, akkor a fenti beállításokkal működik is rendesen a dolog.
Egyébként a c-nél is megküzdöttem, pedig kaptam segítséget is. Csak kiderült, hogy abban a leírásban 1 hiányzott a 4-ből, de valahogy sikerült megtalálnom.


2. Láttam a menüben, de ezzel még nem próbálkoztam.

Tök egyszerű makrók, és CoreTimer interrupt.

A makrókból hívsz rá bármilyen függvényre? A core timer interrupt is végrehajtható kódot eredményez. Egyik sincsen jó helyen headerben a kettő közül. Mindkettőnek .c / .cpp forrásban a helye.

Headerben ezek vannak jó helyen:
-függvény prototípus
-változó típus definíció
-változó deklaráció
-#define, ami végrehajtható kódot nem eredményez (mint pld macro)

És semmi más.

Mivel kettőtöknek a válasz, ezért inkább új hozzászólásba írom.

Pillanatnyilag úgy tűnik, minden OK! Átírtam egy egyszerű LED villogtatót c++ formára, hogy mégsem mindjárt a bonyolultabb LCD kezeléssel tökölődjek a c++ rejtelmein. Miután sikerült kigyomlálni belőle minden hibát (az LCD kezelésnél is hasonló hibákat vétettem), a main kivételével mindent átraktam a saját include könyvtárba, és a fentebb említett 4 beállítással így is fordul.

Kicsit wines feelingem támadt (évek óta nem használom) a hibajelzéstől: az include-olt cpp-ben hiba volt, de nem azt jelezte, hanem hogy az abban megírt függvény nincs definiálva. A hibákat csak akkor jelezte, amikor az összes forrást a projekt alá pakoltam.

Mindenkinek köszönöm az eddigi segítséget, ami persze nem jelenti azt, hogy nem fogok majd ezután is kérdezni.

Előző hozzászólásomban már írtam, hogy megoldódott a saját include könyvtár kérdése. Már két saját include könyvtáram van, mindkettő beállítva, és működik. Egyikben amiket én írtam, "újra hasznosítható" - egyelőre nem sok - források, a másikban amiket átvettem máshonnan. Egyelőre az sem sok, a karakteres LCD kezeléshez való források.

Működik a karakteres LCD kezelés, az ehhez való dolgokat az Arduino rendszerből vettem, persze kicsit meg kellett piszkálni. Aki nem ismerné az Arduino rendszert, igen sok library található hozzá a neten, ezért gondoltam ezt mint forrást. A korábbi, makrókra vonatkozó kérdéseimet is sikerült - ha nem is egészen úgy, ahogy eredetileg gondoltam - megoldani. Ez nekem egy Arduino-szerű paraméterként átadható lábkiosztáshoz kellett, ne kelljen fixen bedrótozni a későbbiekben készülő library-kben a lábakat, regisztereket.

Csak kíváncsiságból ránéztem a tft kijelzőkre, mibe kerülnek, és elég rendesen furcsállom, hogy amilyen drágán árulják őket pld hestore-ban, akár egy nagyképernyős színes tv-t veszek használtan azon az áron, aminek ugyan úgy van szinkron bemenete, amit egy pic is vezérelni tud.

Filozom azon a viccen is, hogy a pic-ekből talán előbb lesz ethernetes média szerver, mint saját tft-jük lenne, az android okos tv-k ugyanis nem álltak meg a fejlődésben, mára már mindenféle vicces szabvány létezik, ami egy pic-nek sem lehetetlen terhelés.

Ezt a kijelzőt már igen régen vettem, csak mindig megálltam a PIC témában, és előlről kellett kezdeni. Ugyancsak régóta van egy másik ilyenem, csak kék-fehér, meg néhány kétsoros, amik meg olcó bontandó panelen voltak, amiket lényegében nem is a kijelzők miatt vettem meg. De van már TFT-m is, és a továbbiakban már abban gondolkodom, mert alig több az áruk (persze nem a HESTOR-ban, meg hasonló helyeken), viszont sokkal szebb, képet lehet vele csinálni, és információ is jóval több fér el rajta.

Tud vezérelni, csak lassú lesz (már csak a hatalmas felbontás miatt is). A nagyon nagy képernyő nem alkalmas a legtöbb feladatra. Ideális méret az 5-7-9", felbontás 800x480. Ezeket be lehet szerezni 10-20e között meghajtókkal egybeépítve. Ahová ezek szükségesek, ott nem számítanak drágának

Én egyelőre nem is gondolkodom ilyen nagyban. 2,2, 2,4 meg van egy 3,9 collosom is.

A méretet valóban a szükségesség határozza meg, van ahová elég, sőt kell a kisebb méret. Gyakorlásra pedig az a legjobb, ami van...

Ha már szóba jöttek a méretes TFT-k szerintetek mennyire valóság, mikor lesz elérhető a PIC32MZ DA grafikus család.
Elvileg a kisebb lábszámú verziókban 32MB DRAM (és 640kB SRAM) a grafikának és egyebeknek fent tartva valamint kapott SDIO perifériát, TFT vezérlőt (8R 8G 8B), meg 2D grafikus gyorsítót nagyjából ezeket láttam amik újak.

Én félek egy kicsit túl csodálatosan hangzik...

Én attól félek, hogy teli lesz hibákkal, ahogy olvasgatom az új PIC-ek eléggé bugosak (vagy legalábbis ami a supportot illeti).
Én maradok még egy darabig a 18F szériánál.

Ez is egy hozzáállás
Én munka miatt elkezdtem az ARM-okkal is foglalkozni, de csak dev board-okon használom őket tehát így igazi tapasztalat nincs, csak hiányolom a SET CLR INV registereket.
Csak a Silabs doksik katasztrófák az M-é "szebb".
Azért az 32MZ EF-el már nincs annyi gond.

Én azért reménykedek mert sok lehetőség van benne.

Az a 32mz da család már előnézeti doksi formájában kint volt a neten 2 évvel ezelőtt is, amikor végül leszedték az előnézeti adatlapot is a netről. Az kb egy-két hónappal az előtt volt, hogy az mz ef piacra került.

Most láttam a napokban újra az mz da család erratáját a microchip oldalán, és kicsit beleolvasva én azt mondanám, okkal szedték le még az előnézeti doksit is a netről (apropó, magát a doksit, most sem találtam meg). Ha történik is valami csoda az ügyben, szerintem 2 éven belül még ne számíts használható mz da cuccra, és abban már a csoda is benne lesz. Én mostanában kevés csodát látok, te hogy vagy vele?

Amúgy mi kellene belőle, az sdio, a tft, az intelligens 2d support, vagy a dram?

Az SDIO és a DRAM ami jelentős előrelépés lenne...

A dramot illetően egy nulláról induló project lehet hamarabb kerül piacra, tekintettel rá, hogy mc-ék mennyit bénáztak az elmúlt 4-5 évben.

TFT-hez nagyon lassú, máshoz meg nem nagyon kell sok RAM. Nem tudom...

Én nem kezelek tft-t, nem tudom, milyen sebesség kell hozzá. Megnéztem azt a tft-t, ami a pic32maxiweb-be van beépítve, és azt találtam, hogy van 180 kbyte-nyi beépített memóriája. Ha azt kiszámolom 20 megabit/sec spi porthoz, másodpercenként 10x újraírhatom az egészet. Az 10 fps.

Én 10 fps-el wowozok egy tbc privát szerveren, és élvezhető a játék minősége. És akkor egy MMO-ról beszélek. Elárulod nekem, mihez kell még nagyobb sebesség? Esetleg nincsen megcsinálva normálisan az aszinkron alkalmazás design dma csatornásra, és a szinkron végrehajtások egymást akadályozzák? Azért kell a bivaly speed, hogy abban a pillanatban azonnal legyen gyors valami? Mert akkor tényleg a világ összes sebessége sem lesz elég.

800x480 16bit RGB565. Egy SQI Flash-ből már normálisan ki lehet tenni egy hátteret, SD 25MHz kevés a szemnek, játéknak meg abszolut kevés. Ha lenne ilyen SDRAM SQI kivitelben, akkor az már igencsak jól használható lenne!

Az 50MHz dotclock nem lenne elég gyors amit találtam doksit abban azt írták?

pajt2 a 2d support érdekelne a legkevésbé. Az SDIO "integrált" DMA-val (nem kell külön DMAt használni van az SDIO-hoz) TFT ismét integrált DMA-val és a TFT-hez kellene a DRAM mint frame ram. Meg asszem hw 3 layert támogat amikre lehet alpha blendig-et beállítani, ami sw-sen szerintem elég lassú (565 RGB-vel mindenképp) ja meg, hogy nem kell a külső DRAM high speed-es length match-ével foglalkozni (bár az ért ebben az Altium nagy segítség) hanem 32MB integrált DRAM.

Alsó hangon talán, de a PIC nem tudja az 50MHz-et, legalább is nekem nem jön ki 25-nél több, csak hibákkal, de az SQI ettől kétszer gyorsabb és így is a sebesség csak éppen elfogadható. DRAM támogatással ez javulna.

Elkezdtem azt kiszámolni, hogy 100 megabitnyi pixel streamet tolnál ki másodpercenként. Oké. Az azt is jelenti, hogy a 200 mhz-es pic32mz képes legyen értelmesen manipulálni a képet, és közben újra tudjon számolni pixeleket 2 órajelenként. Nem gondolod, hogy egy kicsit sokat vársz attól a szerencsétlen pic32mz-től?

Tisztában vagyok a képességeivel és azt ki is használom. A ~10MBájt/sec elérhető és ez elegendő az iparilag is elfogadható sebességű megjelenítéshez(statikus, időnként változó képek (nem videojáték)). Ha létezne SQI DRAM, az nagyon jó lenne. Ha ez nem lesz, akkor reménykedek, hogy lesz egyszer DRAM támogatás. Vagy más MCU-t fogok használni, ha szükséges...

Ami tft-ket használsz, van azoknak dupla memória bufferelésük?

Ezeken nincs.