Fórum témák
» Több friss téma |
Szerintem a "szoveg" már maga mutató, mivel tömbazonosító.
Viszont az xlcd.h-ban putrsXLCD() paramétere "auto const far rom char*"-nak van deklarálva. Ez a projekt opciók beállításától függően (near/far memory model) vagy egyezik a tömbdeklarációddal, vagy nem. Próbáld ki mostanitól eltérő beállítással is! Az egy másik kérdés, hogy a gyári library-t hogyan fordították? Ha így, akkor gáz, mert a PIC18F4450-nél nem sok értelme van a 24 bites pointereknek. Ha meg nem, akkor külön header készlet kellene a 64 kB-nál nagyobb memóriájú mikrovezérlőkhöz, és egy másik a 16 bites címzést használóknak. Utóirat: a könyvtári forráskódoknál található szkriptek "large memory model" opcióval futtatják a fordítót, tehát neked is ezt kellene beállítani a projekt opciói között.
Szia, köszi a segítséget, csak nem értek mindent
 ...Utóirat: a könyvtári forráskódoknál található szkriptek "large memory model" opcióval futtatják a fordítót, tehát neked is ezt kellene beállítani a projekt opciói között. ezt Te hol nézted meg ( még nem igazodok el teljesen, a mintánál én azt láttam, hogy egy mutatót kell átadnom és kész, se near, se far...)? A "large memory modell"-re emlékszem, hogy láttam, majd megkeresem, hol lehet beállítani és most mi a helyzet vele  !Köszi! Steve
Az információ forrása:
c:/Program Files/Microchip/MCC18/src/make_one_subsystem_t.bat Ebben az áll, hogy: for %%i in (*.c) do mcc18 -ls --no-extended -ml -p=%1 %%i A beállítás MPLAB-ban a Project/Build Options/Build/project menüben az MPLAB C18 fülön a Memory Model kategória kiválasztása után érhető el. Code model: a small model lenne a logikus, de a könyvtárat valószínűleg nem így fordították! Data model: a Large data model a célszerű választás Stack model: ha a linker állományban definiált veremtár egy lapon helyezkedik el, akkor a single bank model a célszerű választás
Most jöttem haza és nézem a Rebuild_Instruction.txt-ben, hogy a pmc_common könyvtárban található XLCD, amiről azt látom, hogy:
Idézet: „pmc_common Micro controller Peripheral library source common to extended and non-extended modes. ” Ez nem azt jelenti, hogy mind a extended és nem extended módban is használhatóak a rutinok ( eddig ezt meg se néztem egyébként ) ?!Próbálom egyébként amit írtál, mindjárt referálok... Steve
A Code Model az alapértelmezett Small-ra volt állítva, átállítottam a Large-ra, nem változott!
Köszi, hogy próbáltok segíteni, de egyéb ötlet? Steve
Két külön könyvtár van. Például p18f4450_e.lib és p18f4450.lib. Az első az extended módban használható, a második a "hagyományos" módban. Az ingyenes fordító csak az utóbbit támogatja.
A könyvtárakat hogyan adom meg, hogy melyiket használja, illetve mi van ezekben a könyvtárakban ( mintha olvastam volna valahol, hogy ott vannak a lefordított függvények.Ezeket az előre lefordított függvényeket hogyan lehet megnézni, illetve változtatni? ) ? Eddig én csak include-oltam a header fájlokat és használtam a függvényeket ?!
Bocs, hogy ennyire amatőr dolgokat kérdezek, de szenvedek már vele egy ideje és nem olvastam ilyen infót! Steve Idézet: A linker script gondoskodik róla. Nézd meg az elejét!„A könyvtárakat hogyan adom meg, hogy melyiket használja?” Idézet: Az, amiről a DOCS könyvtárban írnak, meg amit az src mappában találsz. (nálam az LCD rutinok még nincsenek dokumentálva, pedig a forrásuk ott van, s a lib-ben is benne vannak)„mi van ezekben a könyvtárakban?” Idézet: „Ezeket az előre lefordított függvényeket hogyan lehet megnézni, illetve változtatni?” Megnézni:
Módosítani: Az MCC18 src és h mappáiban notepad.exe-vel. Utána újra kell fordítani a már emlegetett szkriptek segítségével. Vigyázat! Egy mikrovezérlőre is elég lassan megy, s ahogy már mondtam, az extended módot az ingyenes fordító nem támogatja. Ha csak egyetlen mikrovezérlőre akarod futtatni, akor is le kell fordítani az általános futtatórendszert:
Majd az adott mikrovezérlő lib-jét, például:
Mi történik, ha én valamelyik 'C' forrásba belenyúlok ( mert pl. a BUSY vizsgálatnál a LAT-ot nézi a PORT helyett a mostani beállítással!) ? Ilyenkor teljesen le kellene fordítanom ( az általad leírt módon ), vagy ha a C forrásfájlt berakom source fájlnak, akkor az úgy is "belefordul" ?!
Steve
Ha módosítod a C fájlt, akkor azt újra fordítja.
Viszont olyan szerintem nincs gyári kódban, hogy LAT-ot néz egy bemenetnél...
Ha a forrást berakod a projektbe, vagy a "gyári" függvénnyel azonos nevűt írsz a saját programodba akkor az elsőbbséget élvez. A szabály az, hogy a linker csak azokat az eljárásokat csatolja be a .lib-ből, amelyek neve nem nyert felold(oz)ást a projekt objekt (.o) állományainak összelinkelése során.
Nézd már meg légyszíves az busyXLCD.c-t és a hozzá tartozó xlcd.h-t... Én úgy látom, hogy DATA_PORT-nak a LAT-ot nevezi ( MCC18 ), noha a busy vizsgálatánál a kijelzőt kell olvasni! Jól látom vagy elnéztem valamit?!
Köszönöm ! Steve
Nálam két MCC18 verzió (3.22 és 3.36) perifériakönyvtárának forrás is kéznél van, ezekben ez áll:
A mellékelt programokat nézd meg, működnek-e nálad? (az egyik printf-et használ, a másik nem, hogy memóriatakarékosabb legyen)
PIC18F4550 esetén a D-portra kell kötni az LCD-t (az RD0..RD3-on eredetileg rajta levő LED-ek is maradhatnak!) RD0 = RS RD1 = R/W RD2 = E RD3 = -- RD4 = LCD D4 RD5 = LCD D5 RD6 = LCD D6 RD7 = LCD D7 A program a PICCOLO projekt-ben használható, tehát piccolo_all.h, piccolo_config.h és piccolo-4550.h kellenek hozzá... Az USE_USB ne legyen definiálva!
Most volt időm kipróbálni a "gyári" könyvtárat (MCC18 v3.22), az alábbi program (ami lényegében ugyanaz, amit beírtál tegnap, csak kibővítettem egy második sorral) első blikkre működött. De az inicializálás nem tökéletes, néha előfordul, hogy szemeteket ír ki!
A 15 s helyett nálam azért van 50ms, mert túl alacsonyan van a BORV (2,7 V-nál már indul a PIC, s az LCD adatlap ajánlás szerint ilyenkor többet kell várni). A 18 TCY helyett nem kell 100 us-ot írnod, mert ahelyett az 5 ms-os késleltetést használja a gyári OpenXLCD() függvény.
Bekötés xlcd.h szerint, azaz: RB0 = LCD D4 RB1 = LCD D5 RB2 = LCD D6 RB3 = LCD D7 RB4 = E RB5 = RS RB6 = R/W RB7 = --
Köszi, megnézem...
Nekem a D portra van kötve az LCD ( felső 4 bit adat, 0--> E, 1-->RS, 2--> R/W, ha jól emlékszem, a header fájlt átírtam, a C forrásfájlokat beraktam a source fájlok közé! ). Az az érdekes, hogy 1 karaktert kiír és utána romlik el!? Légyszíves nézz már rá a #803422 hozzászólásomra, ha van egy kis időd  !Steve Idézet: „Légyszíves nézz már rá a #803422 hozzászólásomra, ha van egy kis időd!” Azt már megválaszoltam ebben a hozzászólásomban.
De ez jól van így? Ha a PORT-ot olvassa akkor OK szerintem, de ha írja?! Szerintem íráskor a LAT-ot kellene használni a RMW utasítás miatt, vagy nem jól gondolom ( én úgy tudom pont ezért vezették be a LAT-ot! ) ?!
Most nem tudom tovább nézegetni, valószínűleg vasárnap tudok foglalkozni vele legközelebb! Üdv mindenkinek! Steve
Ezt bemásoltam az én xlcd.h fájlommal nem ment ( nekem a PORTD-n van a kijelző!) --> ez azt jelenti, hogy valami elkötés lenne ( korábban már ellenőriztem és az első betűt mindig helyesen írja ki! )? A D porton én nem láttam semmi extrát, szerintem működnie kellene
.A C18 a log szerint: Idézet: .„Source: c:\Letölt_FIREFOX\MPLAB-C18-Std-Eval-v3_34(2).exe | 01-19-2010 | 22:45:50” Vasárnap majd folytatom és jelentkezek... Steve Idézet: Nekem ennél alapvetőbb gondjaim vannak az XLCD függvényekkel. Ha megnézed például az első hívás„De ez jól van így? Ha a PORT-ot olvassa akkor OK szerintem, de ha írja?!”
azt sugallja, hogy a függvény paraméterezésével választható, hogy 4 vagy 8 bites módban működjön. De ez nem igaz, mert
megléte vagy hiánya már eleve eldöntötte, hogy melyik módot használja. A függvénykészlet összeállítása is elég szerencsétlen (igaz, ez nemcsak az XLCD csomag kapcsán tűnt fel...).
Ezzel a C-vel nem haladok semmire, elakadtam kb ott hogy a kapcsos zárójelek a begin meg az end.
Az oké, hogy az asm utasításokat se akarja elfogadni, azt még elviselem. De akkor legalább egy picit legyen logikus a felépítése. Sehogy se tudtam rájönni, hogy hogyan lehet például vizsgálni egy byte változó x. bitét. Tud valaki valami leírást? Mert a neten mindent találok a C-ről csak azt nem, amit kéne. 
Minden topikba ötvenszer belinkeltem már!
BRIAN W. KERNIGHAN – DENNIS M. RITCHIE: A C programozási nyelv Mike Banahan, Declan Brady and Mark Doran: The C Book Idézet: „hogyan lehet például vizsgálni egy byte változó x. bitjétJ”
Ha bitekre akarsz bontani egy bájtot, és bitenként használni, akkor ez az egyik megoldás(részletek az egyik programomból).
Deklarálás:
Hivatkonzni lehet rá:
Vagy:
Illetve:
Köszönöm szépen.
ASM-be ez mennyivel egyszerűbb. 
Azért mert asm-ben gondolkodsz, nem C-ben...
|
Bejelentkezés
Hirdetés |
