Ez egy konkrét függvény, nem pedig függvény pointer.
Ez lenne az:

Pointer csak akkor tud működni, ha ismert a típus, tehát vagy megadod előre, vagy castolsz. Honnan tudná különben, hogy 1, 2, vagy 4 bájtot kell lépnie a mutató növelésekor? A fordító nem gondolat olvasó!

Ugyanonnan ahonnan a void * -nál tudja. Sehonnan. Teljesen életszerű dolog, hogy egy csomó függvény csak pointereket ad át egymásnak és a majd pl. a 12-edik függvény fog valami kezdeni azzal pointerrel ténylegesen. Az "átadogatáskor" lehet void * is. Csak az utolsó függvénynek kell tudni, hogy akkor az most micsoda is valójában, (char *, int * stb).
Ugyanerre gondoltam függvény pointernél is. A pointer mérete független attól, hogy mire mutat. Egy void (*xyz) (void) ugyanakkora, mint egy int (*abc) (char, int, char, int).

Azért merült fel ez gond, mert ilyesmi fgv-ek vannak:
void x (void *, char);
void y (void *, int);
void z (void *, unsigned int);

Az első paraméter stimmelne is, de a második mindig más és nem pointer.

Sziasztok!

Találkozott valaki olyan jelenséggel, hogy az LCD (2x16) kijelzőmnek csak a fele jelenít meg karaktereket? Tehát mindkét sorban az első 8 karakter nem látszik a második 8 igen.
A pozicionálással semmi gond nincs ami látszik az jó helyen van.
(((a deszka modellen még jól működött))) (4 bites módban vezérelem és nem történik lekérdezés)

Az ötleteket előre is köszönöm.

Igen. Amíg csak a függvénypointerről van szó, addig elegendő annyit tudni, hogy "pointer valamire". Még az se kell, hogy a függvény, amire mutat, az hány paraméterrel rendelkezik (sőt, a legtöbb CPU architektúrán - kivéve a 8-bites PIC-eket - még az se kell, hogy ez adatra mutató pointer vagy függvényre). Amikor azonban ezt a függvénypointert használni is szeretnéd, ott már a pontos paramétertípusokat ismerni kell, mivel egy char, egy unsigned int, vagy egy bármilyen pointer más módon kerül átadásra - és itt ezeket le is kell másolni, azaz a fordítónak tudnia kell, hogy mekkora a lemásolandó terület.

Szerintem egy függvény esetében előre ismert, hogy milyen típust szeretnék visszakapni, menet közben ezt nem lehet és nem is értem mi okból kéne változtatni. Arról nem is beszélve, hogy a függvényben is elágazásokkal kéne kiválogatni, hogy egy esemény szerint milyen típusú változót adjon vissza, de honnan tudja majd, hogy milyet vár a hívó, ha azt a híváskor nem adom át neki. Ha meg átadom, akkor már tudom előre, hogy milyen.
Miért van erre a megoldásra szükséged egyébként?

Így van!
Pont ez lényeg, hogy simán lehet használni a "pointer valamire" elképzelést, míg ténylegesen meg nem hívod a függvényt. De lényeg lényeg, hogy akkor nincs erre külön szintaktika, hogy "valamilyen függvényre pointer".
Köszönöm a segítséget!

Természetesen egy függvény tudja mit ad vissza. Ha egy függvényt meghívsz, akkor pontosan kell tudni, hogy milyen. Én csak pointerre gondoltam, hogy lehet ezt is általánosan kezelni.

Nincs, a void * használatos erre is. Persze ahol a függvénypointerek speciálisak (PIC 8-bit), meg a void *-ból is többféle van, ott doksit kell olvasni.

Értem, köszi. Én is void *-ot használtam, de PIC32-n. Fel is merült bennem, hogy mennyire architektúra független megoldás. De ezek szerint, csak a 8 biteseknél van másképp. Az meg nem gond

Ahogy a frekvenciával és az időzítésekkel "játszok" az LCD vezérlésében, úgy halványan megjelennek a karakterek az első 8 helyen is.

Vajon mi lehet a hiba???

Ha a deszkán ment ellenőrizd a nyákot. Valamit elkötöttél, forrasztottál, esetleg szakadás a nyákon.

ezt már megtettem párszor.

Nos ha ugyanaz a program és a kijelző is mint a deszkán volt akkor a következő lehetőségek vannak.
1. Hibás a nyák
2. Mivel az előzőt már leellenőrizted (bár ettől még előfordulhat) változtass időzítéseken az inicializálásnál. Ha nagyon határértékeket állítottál be, lehet, hogy rosszul inicializál. Ami a deszkán ment a drótokon, lehet, hogy a nyáknak kevés.
3. Ha ígysem megy akkor ellőtted a vezérlőjét forrasztás közben.

Szia!
Én dsPIC33EP256MU806-al küzdök jelenleg, s én használom a QEI modult, s nekem elsőre elindult, bár én csak egy rotary encodert kezelek vele, de nagyon jól működik, persze nem szimulátorban.
Viszont lenne nekem is egy kérdésem.
Nekem is van periféria hozzáférés problémám, a 48-as láb (TQFP64-es tok esetén) a következő funkciókkal van felvértezve: PGEC2/SOSCO/C3IN1-/T1CK/RPI62/RC14
Nekem ezek közül az RPI62 kellene, hogy a 4-es Timer külső órajellel léptessem (T4CK)
A lábon meg is jelenik az órajel, de sem a Timer1-et (T1CK-n keresztül) sem pedig a Timer4-et (T4CK-n keresztül) nem tudom léptetni, belsőről mind a kettő szépen működik.
A programozás a PGEC1, PGED1-en keresztül megy. A proci belső FRC osciról megy, komparátort nem használok, s még sem tudom elérni a T1CK vagy az RPI62-es funkciókat.
Nekem nagyon az a gyanúm, hogy a Secondary oscillator foglalja a lábat, holott az OSCCON regiszterben tiltom ezt az órajel forrást az LPOSCEN bit törlésével.
Van esetleg valami tapasztalat ezzel kapcsolatban?
Már egy csomószor elolvastam az idetartozó fejezetek az adatlapban, de nem találtam semmit, az ERRATA sem ír semmit.
Köszönöm előre is!

Megnézted?

Szia!
Igen, megnéztem már.
Ha az első pontra gondoltál akkor az ahogy én értelmezem, ez csak a PortC 15-re érvényes illetve a PortA 3-ra.
Nekem viszont a PortC14-el van problémám, s a dsPIC33EP256MU806-nak nincs "A" portja.
Köszönöm azért, minden ötlet, hozzászólás jól jön, hisz lehet átsiklottam valami felett.

A bemenő jel látszik a port olvasásával? Ha nem, akkor esetleg analógra van állítva a port. Ha port olvasással látszik, akkor lehet még gond az I/O lábak átkonfigurálásával (melyik perifériára legyen rákötve), mivel ez csak a megfelelő kódszekvencia után működik, tehát el lehet téveszteni. Ezt le kéne tesztelni: valami lábra olyan periféria kimenetét ráküldeni, ami garantáltan látható jelet fog eredményezni, és megnézni, hogy ottvan-e.

Szia!
Az adott portot (PORTC<14>) a programban nem olvasom ki. Amit tudok, hogy ha debug módban megállítom a program futását, akkor soha sem sikerült úgy megállítanom, hogy a 14-es bitnél 1-est lássak a PORTC regiszterben. Ennek a portnak egyébként nincs AD funkciója, csak a következők: PGEC2/SOSCO/C3IN1-/T1CK/RPI62/RC14.
Mivel az adott lábra (48-as TQFP64-es toknál) van kötve a külső 1MHz-es órajel, ezért próbálkoztam a Timer1-el, a T1CK-n keresztül, nem működött, s kipróbáltam Timer4-el, úgy hogy az RPI62-re mappoltam a T4CK-t, s így sem ment. Viszont ha kis vezetékkel ezt az órajelet rákötöm a pin13-ra (AN3/C2IN1+/VPIO/RPI35/RB3), s a T4CK-t az RPI35-re mappolom, akkor számol a Timer4.
Amúgy erről a kódszekvenciáról nem olvastam még.
A következző utasítással mappoltam a T4CK-t az RPI35-re:

Viszont az RPI62-re történő mappolás már nem működik.
Tegnap még azt próbáltam ki, hogy az 1-es ICSP port helyett használtam a 2-est, mivel a PortC14, egyik funkciója a PGEC2, s tudtam programozni a procit.

Nem használsz másik olyan perifériát, ami lefoglalja a portot?

Szia!
Na igen, ez egy jó kérdés, nekem is az a gyanúm, hogy valami foglalja a portot.
Viszont ezek közül: PGEC2/SOSCO/C3IN1-/T1CK/RPI62/RC14
Szerintem csak az első három funkció közül lehet valamelyik, hisz azok magasabb prioritásúak, mint a T1CK vagy az RPI62. Ezekből viszont szerintem a PGEC2 nem lehet, mert az 1-es ICSP-t használom programozásra. Komparátort (C3IN1) egyáltalán nem használok, az összes regisztere reset utáni állapotban van. A "Secondary Oscillator" funkciót pedig kikapcsoltam, már ha elég nullára állítani az OSCCON regiszter LPOSCEN bitjét.
Amúgy nekem az SOSCO a gyanús.

Próbáld kikapcsolni a resetkor elvileg beálló regisztereket is, hátha mégsem...

Ha nem csinálod meg előtte a szükséges kódszekvenciát, akkor ez az utasítás semmit se fog csinálni. Így pedig nem is meglepő az eredmény. Olvasd el az adatlap idevágó részét (10.4.4): Bővebben: Link

Szia!
Ja, igen, ezt olvastam.
Az OSCCON regiszter IOLOCK bitje törölve van, valamint a configurációs bitek közül a IOL1WAY is törölve van, ezzel engedélyezve, hogy bármikor tudjam a portokat konfigurálni.
Annak ellenére, hogy nem a megadott OSCCON szekvenciát futtatom, a T4CK funkciót tudom mappolni az RPI35-re, működik is, ahogy már írtam is, viszont az RPI62-re nem tudom mappolni.
Amúgy pl a QEI portokat is mappolom, és az megfelelően működik.
Illetve ha a mappolás nem lenne megfelelően engedélyezve akkor az adatlap alapján nem is frissíti az RPINRx regisztereket, viszont ha kiolvasom az RPINR4-es regisztert akkor a tartalma 35 vagy 62.
Tehát véleményem szerint maga a mappolás működik.

Kifogom próbálni, s jelentkezem az eredménnyel.

Igen, ez alapján az rendben van.
Azt kipróbálhatod, hogy tényleg üzemel-e a SOSCI/SOSCO. Ha igen, akkor a SOSCO-n a SOSCI-re adott jel inverzét kell látnod.

Szia!
Kipróbáltam az SOSCI/SOSCO párost, ha engedélyezem a Secondary oscillatort akkor invertálgat, viszont ha törlöm az LPOSCEN bitet az OSCCON regsizterben akkor már nem.
Kipróbáltam amit "watt" írt, de sajna az sem segített. Aztán digitális kimenetként is működött a láb rendesen, viszont inputként már nem.
Na de nem is szaporítom a szót, tegnap este megtaláltam a probléma okát.
Az RC13, RC14-nek nincs AD funkciója, viszont komparátorként használható, s gondolom a komparátor miatt van ANSELC13 és ANSELC14, ami persze magasra áll be reset után.
Miután töröltem az inicializáláskor ezt a két bitet már működött is a mappolás.
Köszönöm szépen a tippeket, hisz segítettek rávezetni a hibára!

Az "analóg bemenet" közel sem csak az A/D-ra vonatkozik, hanem mindenféle analóg funkciókra.

Én is azt írtam, hogy minden perifériát be kell állítani, ami ehhez a lábhoz tartozik, akkor is, ha elvileg a resetkor be kéne álljon. Ez alól az sem kivétel, ami jól áll be csak neked nem megfelelően!

Ha valakinek kompatibilitási vagy egyéb okokból kellenek, a "hagyományos" fordítók még mindig elérhetők Linuxhuz az alábbi linkeken:
C18: http://www.microchip.com/mplabc18-linux-installer
C30: http://www.microchip.com/mplabc30-linux-installer
C32: http://www.microchip.com/mplabc32-linux-installer

MPLAB X alatt is használhatók, de ahogy korábban írtam, parancssorból is futtathatók.