Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Helló!
Nemrég volt egy kérdésem arról, hogy 16 bites PIC-eknél mi fele meg a #define direktívának. Azóta rengeteg fórumot megnéztem, de nem jutottam egyről a kettőre, csak bonyolult és kényelmetlen megoldásokat találtam eddig. Aki tudja választ kérem, hogy ossza meg velem.
Üdv!
Találtam a neten egy bluetoothos oscilloscopot androidos mobilhoz! Meg találtam a hozzá való Pic-et is a chipcad-nél, de sajna a bluetooth modult sehol nem találok! Az lenne a kérdésem, hogy ehhez vajon lehet használni más modult is, vagy ahhoz már a PIC programban is kell piszkálódni? És ha kell piszkálódni, bírna e segíteni nekem valaki benne? Előre is köszönöm a választ, segítséget! Bővebben: Link Peti
Hi All,
A következő problémában szeretnék segítséget kérni. Az alábbiakban ismertetésre kerülő program egy részlete 16F690-re íródott. Hi-Tec C segítségével. A Kijelző Displaytech 162b. Kipróbáltam és működik is rendesen. Most viszont szeretném áttenni 18F13K22-re, a nyelv Microchip PIC18 (csak ezt tudtam letölteni ingyen). A változások: (16F) 4MHz órajel helyett (18F) 64MHz Nem probléma, átírtam a pause.c-ben lévő részt és az időzítés precízen működik. Az LDC adat bitjei máshogy vannak kötve: (16F) egyik port alsó 4 bitje (18F) egyik port felső 4 bitje Itt annyit változtattam, hogy az lcd_write(unsigned char c) rész nálam most így néz ki a 18F-nél :
Van egy PIC haladóknak című téma, ez a kérdés szerintem oda tartozik
 ott hamarabb tudnak segíteni!
Szia,
1. PIC18-nál ha adatot akarsz kirni nem PORTC, hanem LATC a jó regiszter 2. bár az enyém hosszabb rutin de tutti jó igy mutatom:
Egy kis magyarázat:
Nekem a C porton megy ki minden E,RS ( RW fixen negativon). Ezért nálam ki kell maszkolni a felső részt mielőtt adatként kiteszem.
A String kiirashoz pedig ezt hasznalom sikerrel:
Idézet: Természetesen, s különbség van a data RAM és a ROM elérésében is.„Elképzelhető, hogy 18F-nél máshogy van a Pointer, Mutató kezelés?”
Ehelyett egy lcd_putrs() függvényt definiálj, ha ROM-ban elhelyezett szöveget írsz ki! A különbség a mutató deklarásában van:
Akkor még egyszer
Üdv Mindenkinek ! Köszönöm az eddigi hozzászólásokat! Holnap kipróbálom kzteam és icserny ötletét is, meglátjuk mit tudok kihozni a dologból. Egyébként az általatok javasolt két eltérő változatot már próbálgattam, szenvedtem vele, nagyon remélem, hogy rosszul, vagyis, hogy elírtam valamit és azért nem ment, majd meglátjuk, amint tudom kipróbálom ! köbzoli , Elnézést, hogy nyitottam egy új témát de ez egy 1044 oldalas jelenleg és mindenki kérdez mindenfélét, egyrészt nem akartam belerondítani egy adott folyamatban másrészt a kevés szabad időmet nem azzal akartam tölteni, hogy filterezem a fórumot, hogy vajon melyik válasz szól nekem. De semmi gond, ha itt ez a módi és mást sem zavarok ezzel akkor a jövőben igyekszem így eljárni. Androla.
Félreértés ne essék: nem ötletet írtam, hanem arra hívtam fel a figyelmedet, hogy ha a ROM-ban elhelyezett szöveget akarod kiírni (már pedig az lcd_putrs("kiirando szoveg") tipikusan az), akkor a mutatónál használni kell a const mellett a rom attribútumot is. Nem fakultatív...
Ha a RAM-ból íratsz ki, akkor más a helyzet, de az nem illeszkedett a problémádhoz.
Értelek!!!
(minden ötletből tanul valamit az ember), nekem az alapvető problémám az, hogy minden megy kivéve ezt a részt: //write a string of chars to the LCD void lcd_puts(const char * s) { LCD_RS = 1; // write characters while(*s) lcd_write(*s++); } És nem tudom, hogy miért. Ha használom az lcd_write(0bXXXXXXXX); függvényemet, ha megadom bemenő paraméterként az adott ASCII karakternek megfelelő bináris kódot akkor a megfelelő karakter szépen ki is írogatja az LCD-re. De amikor karakter láncot akarok kiíratni az lcd_puts("Működj Mááár!"); függvénnyel akkor ez nem csinál semmit.
Ha úgy írod, hogy
Holnap tudom csak kipróbálni. De ezt most nem értem !!!
lcd_puts("Működj Mááár!"); lcd_putrs("Működj Mááár!"); Az, hogy lcd_puts és lcd_putrs nem csak egy szimbolikus név amivel én neveztem el a függvényemet ?
Nem a függvénynév számít, hanem az, hogy kiteszed a rom módosítót. De ezt már éppen harmadjára írom le!
 Az lcd_putrs() függvénynevet csak azért javasoltam, hogy a függvény neve is tükrözze, hogy ez a függvény a ROM-ból ír ki.
Így értem !
De ha ezt most nem mondod, az az r bevitt volna az erdőbe. Akkor holnap teszt.
Lehet mar tudtok rola, de nekem ujdonsag volt: Microchip a napokban bejelentette az MPLAB X vegleges valtozatat. Le lehet tolteni Windows, Mac es Linux platformokra, PicKit2 es 3 is tamogatott, no meg jo par mas programozo is. C18, C30 es C32, no meg a HiTech PICC 10-12-16 es 18 is benne van (pontosabban kulon installerrel rakhatok ezek fel). Java futtato kornyezet szukseges hozza.
Linkek: Bejelentes - Letoltes
Én még eddig nem tudtam róla. Eddig azért kellett egy XP-t futtatnom Virtualboxban, hogy tudjam futtatni az MPLAB-ot. Jövő héten úgyis van pár dolog, aminek neki akarok állni, akkor majd megnézem, hogy mennyire használható az MPLAB X Ubuntu alatt.
Majd irdd meg legyszi a tapasztalataidat, en Mac alatt fogom kivesezni a dolgokat (es remelem minel kevesebb) buktatokat.
Jó lenne, ha a végleges változat kezelné a PICKit2 -t, de amit én októberben letöltöttem, az még nem tudta...
Kipróbáltam, Működik!
Köszönöm a segítséget mindenkinek ! Most szeretném megkérdezni a dolog miértjét ? Aminek eddig utána néztem, hogy a const előtag használatával a változó a program memóriában jön létre (C30) ? A rom használatával szintén ezt olvastam (C18) ? Ez most nem annyira értem. Ha nincs ott a rom csak a cons előtag akkor miért nem működik ? Vagy rosszul értelmezem és a const előtag azt jelenti, hogy a fordító ne nyúlhasson az adott adathoz ?
Fordítófüggő a dolog. C18 fordítónál ahhoz, hogy a rom területen legyen a holmi, ahhoz rom kulcsszó kell. C18-nál a const csak arra van, hogyha const-nak megadott változóba írni akarnál, akkor azt fordító kiböki fordítás közben, hogy azt úgy nem lehet.
Hi-Tech C fordítójánál a const használata elég, hogy a rom területre kerüljön a változód. C30-at nemtudom, lehet, hogy ott is a const használatával a rom területre kerül az adat. Igazából az a baj, hogy a C szabvány Neumann architektúrájú gépekre készült annakidején, és ott nincs külön rom és ram terület. Így erre, hogy egyik fordítóban a const elég, míg másikban a rom kell, egyikre sem lehet azt mondani, hogy nem jó, mert valamilyen szinten mindkettő logikus. Így marad az, hogy a fordító készítője amit választott, azt kell használnunk.
Kereső, kereső, kereső...
(A hozzászólás eltávolítva.)
Értem.
Az én esetemben végül is mi történt, hogy kihagytam a ,,const rom" módosítót ezért a C18 fordítás közben ezt a részt kihagyta ? Vagy olyan memória területre helyezte ahonnan nem lehet visszaolvasni vagy nem értelmezett terület jött létre ? Köszönöm az eddigi segítségeket!
A szöveg oda került, ahová kell. A mutató típusa nem volt helyesen megadva, ezért ennek a kezelése lett hibás, nem oda nyúlkált, ahová kellett volna.
Úgy képzeld el, hogy van két polcod egymás mellett, egyiken különféle almák, a másikon különféle diók. Amikor te beírsz egy szöveget, akkor az olyan, mintha hoznál egy láda diót és feltennéd a diós polc harmadik szintjére. Ha később csak azt mondod, hogy a harmadik polcról kell neked ami ott van, de azt nem mondod, hogy a diós polcról, akkor a fordító azt úgy veszi, hogy neked az almás polc harmadik szintjéről kell ami ott van, ott pedig nem diót fog találni, hanem almát.
Köszi a gyors választ.
Sziasztok azt szeretném kérdezni hogy van e olyan PIC programozó ami minden féle Pic-et tud programozni és ha van melyik az ?
Most van egy jdm-em de nem tudok vele PIC18f4550-est programozni én vagyok a béna vagy programozót kéne váltanom ? És ha váltok akkor pickit2-jó ?? |
Bejelentkezés
Hirdetés |
