Fórum témák

» Több friss téma
Fórum » PIC programozása C nyelven, C-Compiler
Lapozás: OK   2 / 153
(#) Muri válasza Muri hozzászólására (») Jún 24, 2006 /
 
Sikerült!
(#) raron válasza Muri hozzászólására (») Jún 24, 2006 /
 
Van MicroC is, de arról azt írták, hogy nagyon nagy kódot generált.
Szerintem nézzetek körül a chipcad fórumán.
Nekem A ccs fordító tetszik a legjobban, itt is van csomó pl.
A SourceBoost jó, csak a LCD meg egyébért fizetni kell.
Kipróbáláshoz inkább a PIC SIMULATOR IDE -jó.(ebbe van basic fordító)

C könyvet biztos ajánlanak a prog.hu-n.
(#) 4cdömpe válasza Pavel hozzászólására (») Jún 28, 2006 /
 
Én is örülnék ha +dobnál a basic programozóval.
16-oshoz és 18as hoz is ha lehetne.
Előre is köszi!
(#) miklosch hozzászólása Feb 14, 2007 /
 
Meg tudná nekem valaki mondani, hogy a Borland C programot hogyan tudom normálisan használni XP alatt? Mert ha megírok egy programot, és el akarom indítani, akkor beüt a kékhalál, hogy a rendszer hibát talált, és újraindul az egész gép! Meg lehet valahogy csinálni, hogy normálisan tudjam használni ezt a programot?
(#) kukac_24 hozzászólása Máj 17, 2007 /
 
Hály!
Tudna valaki valami okosságot az Mplab C18 compiler student verziójának a végtelenitésére ?
(#) bubu válasza miklosch hozzászólására (») Jún 24, 2007 /
 
HI!
A BC re gondolsz? Amit a bcsmall-lal kell feltenni? Mert ha erre akkor lehet a fejlesztőkörnyereted rossz.
Egyik haverom járt ugy h sz. volt és nem működött semmi. Utána adtunk neki egy jot és tökéletesen futott a progi. De ez csak C és C++ volt.
Ha ez kell szolj!
Csao
(#) potyo válasza kukac_24 hozzászólására (») Jún 25, 2007 /
 
Állítsd vissza a dátumot.
(#) Lucifer hozzászólása Jún 25, 2007 /
 
Sziasztok!

Tudom nem pont a témába vág, de PIC C fordítóról lenne szó.
Valaki Linux guru említette itt, hogy nagy spíler az SDCC-ben szóval remélem segíteni fog.

Tehát egy PIC16F818-assal szeretnék sima HD44780-as LCD kijelzőt verérelni.
Lustaság fél egészség -> a guglival találtam egy már kész könyvtárat LCD kezelésre.

Csináltam egy új projektet, beleraktam a fájlokat, main függvénybe lcd_init(),meg egy sor kiíratás.
Az hd44780.h fájlban átvariáltam az adatvezetékeket. Fordítás: PORTAbits.RA2 nincs definiálva.

Na nézem a pic16F818.h fájlt. Tényleg nincs definiálva. Nézzük a PIC18f252.h-t. Ott bizony van.


Na ezt szépen átvágólapoztam, de így sem működik.
A projekt két fájlja az lcd.c, és a hd44780.c egyesével lefordul.
Azonban a projektet fordítva az alábbi üzenetet kapom:

  1. msdcc -mpic14 -p16f818 -V -Wl-c -l -olcdtest.hex lcd.o hd44780.o
  2. message: using default linker script "/usr/share/gputils/lkr/16f818.lkr"
  3. error: missing definition for symbol "_PORTAbits", required by "hd44780.o"


A gugli bácsi ismét jó barátom volt elvezetett az SDCC kézikönyvéhez.


A hatvanegyedik oldalon ott van egy hasonló hiba leírása.

Idézet:


4.5.7.1 error: missing definition for symbol “__gptrget1”

The PIC14 port uses library routines to provide more complex operations like multiplication, division/modulus
and (generic) pointer dereferencing. In order to add these routines to your project, you must link with PIC14’s
libsdcc.lib. For single source file projects this is done automatically, more complex projects must add
libsdcc.lib to the linker’s arguments. Make sure you also add an include path for the library (using the -I
switch to the linker)!
4.5.7.2 Processor mismatch




Szóval a megoldás megvan csak fogalmam nincs, hogy innen hogyan tovább...

Piklab Projekt options -> linker hozzáadtam egy -l kapcsolót is.
Próbálkoztam -l libsdcc.lib hozzáadásával is de semmi haladás...

(#) pid1951 hozzászólása Jún 25, 2007 /
 
Szerintem sokkal értelmesebb lenne, ha mindenki megtanulna assembly-ben pic-et programozni.
Először is sokkal egyszerűbb, nem kell annyit gépeléni.
Másodszor a megírt kód a legminimálisabb, ugyanis ha C-t fordítassz asm-re egy csomó felesleges marad benne, ami csak foglalja a memóriát.
Harmadszor: még az egyszerűbb emberek is értik.

(#) potyo válasza pid1951 hozzászólására (») Jún 25, 2007 /
 
Idézet:
„Szerintem sokkal értelmesebb lenne, ha mindenki megtanulna assembly-ben pic-et programozni.”

Az biztos. Csak úgy lehet megérteni a kontroller működését, és az elengedhetetlen egy rendes programhoz.

Idézet:
„Először is sokkal egyszerűbb, nem kell annyit gépelni.”

Ezt nem mondanám, a magasabb szintű nyelvek épp azért lettek kitalálva, hogy kevesebbet kelljen gépelni, egyszerűbben felírhatóak legyenek a feltételek, alprogramok, stb.
(#) MPi-c válasza pid1951 hozzászólására (») Jún 25, 2007 /
 
Na ezzel a hozzászólással egy páran nem fognak egyet érteni. Legalább is egy részével. Abban teljesen igazad van, hogy az assembly fontos. Azt már vitatható, hogy kevesebbet kellen gépelni és hogy sok felesleges kód marad benne, meg egyszerűbb emberek is értik...
Én most jutottam el oda, hogy meg kell tanulni a C-t. Hobbi célra, szépen komótosan, a saját ütememben. Egy dolgot már észrevettem: így 4X felett már nem fog úgy az ember agya , szóval, talán nekem is hamarabb kellett volna kezdemen. Ja, akkor még nem volt itthon PC meg PIC.

(#) Lucifer válasza pid1951 hozzászólására (») Jún 25, 2007 /
 
Persze.

Nem kell annyit gépelni...
Egy 2000 soros C programot hány sorban kódolnál le ASM-ben? És mennyi idő alatt?

Nézzük példnak a Microchipet. Ők fejlesztik a PIC-eket, tehát van egy kis konyításuk a dolgokhoz. Vajon miért írták a 18-as sorozathoz az USB-s és az Ethernetes stackeket C nyelven?

Abban igazad van hogy lesznek felesleges dolgok a C által lefordított kódban, de egy ponton túl kit izgat. Ha valamit gyárani kezdel sorozatban F-es PIC-el, úgysem fogod úgy gyártani, hogy van két szó hely még a programmamóriában. Sose lehetsz biztos benne, hogy nem lesz e szükséges valaha az sw módosítása. Akkor pedig már egy nagyobb prgrammemóriájú PIC-et használsz.

Egyszerűbb emberek is értik?
Ez egy érdekes megközelítés. Nekünk spec az iskolában Pascalt tanítottak általánosban. Nem a pascalon van a hangsúly, hanem azon, hogy fejlett programnyelvet nyomtak. Tehát szerintem az emberek nagytöbbsége a fejlett programnyelvvekkel találkozik először, tehát hamarabb megért egy C programot mint egy ASM progit.

Nem mondom azt, hogy nem jó dolog az assembly. Én is rengeteget használom C-be beszúrva.
És azt sem mondom, hogy mindent C-ben kell megírni.
De van egy határ ami felett szerintem célszerűbb a C használata mint az assemblyé.


(#) pbalazs hozzászólása Jún 25, 2007 /
 
Sziasztok,

PIC16F872-re kell progit írom, a compiler Hitech PICC 8.05.
A gond az, hogy oda fordítja a kódot, ahol az ICD2-nek is kell a terület, így sem a progi, sem az ICD2 nem megy. Ha nem használom a debuggert, akkor fut a progi jól.

A kérdés, hogy miként lehet rábírni a lilnkert, hogy oda fordítson, ahová én akarom? Nem találtam semmi linker scriptet a Hitech mappáiban.
Természetesen mindezt MPLAB alól kellene, nem a parancssorral szerencsétlenkedni.

A projekt létrehozásakor nem kért semmi linkelési infót, nem is találtam olyat az MPLAB menüjében, amit megváltoztathatnék.
(#) Lucifer válasza pbalazs hozzászólására (») Jún 25, 2007 /
 
Szia!
A hitech C fordítóhoz nem értek, viszont C18 alól nem az .lkr fájltkell használni, hanem az i.lkr fájlt az ICD-s verzió.

(#) Lucifer válasza Lucifer hozzászólására (») Jún 25, 2007 /
 
Vazz nem írta ki a kacsacsőr közé írt picneve szót.
Szóval nem a picneve.lkr, hanem a picneve i .lkr fájlt kell használni.
(#) Moderátor hozzászólása pid1951 hozzászólására (») Jún 26, 2007
 
Idézet:
„Szerintem sokkal értelmesebb lenne, ha mindenki megtanulna assembly-ben pic-et programozni.”


Legyetek szívesek, ne OFF-oljatok!

Arról nem is beszélve, hogy nincs igazad, mert az emberek 80%-a assembly-ben kezdi el tanulgatni a PIC-eket...és csak egy bizonyos szint után kell C-re váltani, ahol már több ezer soros assemby-ben írt programok lennének...ennyi, nincs ezen mit megbeszélni...de ha mégis van, ott van pl. a PIC vs. AVR topik...
(#) Norberto hozzászólása Jún 26, 2007 /
 
És különben is! Egyik fórumtársunk (Lucifer) megakadt egy ponton, inkább számára kéne keresni valami megoldást!

Én nézegettem a problémát, de kb. sokra nem jutottam vele kapcsolatban, mert egyrészt, nem vagyok vmi nagy C-s, másrészt meg nem szoktam Linux alatt fejlesztgetni...
(#) pbalazs válasza Lucifer hozzászólására (») Jún 26, 2007 /
 
Igen, ezt tudom, de a Hitech mappáiban nincsenek ilyen fájlok, hanem .lib fájlokból szedi az infót, amit, ugye, nem tudok olvasni.

Tehát a kérdés továbbra is az, hogy hogyan vegyem rá a Hitech fordítót, hogy ne fordítson az ICD területére?
(#) árpix hozzászólása Okt 29, 2007 /
 
Sziasztok ! azt szeretném megtudni ,hogy tudok mondjuk egy B portot figyelni h. egyszerre több bemenet is változik
, én erre gondoltam bit_test(0b00010100) de ez így nem műxik vagy bit_test(PORTB,EGY&&KETTO)
(#) MPi-c válasza árpix hozzászólására (») Okt 29, 2007 /
 
Ez CCS-ben van? Mert ott egy bitet tesztelhetsz vele, pl így: bit_test(PORTB,1), előtte azért egy #byte PORTB = 0x06 is kell. És több bit meg pl. így:
if(bit_test(PORTB,1) && bit_test(PORTB,2)){...
szerintem.
(#) árpix válasza MPi-c hozzászólására (») Okt 29, 2007 /
 
igeeen ! köszönöm szépen ! :yes:
(#) MPi-c válasza árpix hozzászólására (») Okt 29, 2007 /
 
Kérlek! És ha véletlenül nem lenne meg a Reference Manual.
(#) árpix válasza MPi-c hozzászólására (») Okt 29, 2007 /
 
húúú ! ezt is köszönöm !
(#) Prinner válasza árpix hozzászólására (») Nov 17, 2007 /
 
Írtam egy olyan c kódrészletet, ami egy 32 bites előjel nélküli int változó (globaluint) decimális ascii kódját számojegyenként kiirat egy tömbbe (string), és azt egy LCD kiíró fg segítségével megjelenít karakteres lcd-n.
Az a probléma, hogy az integer legutolsó számjegyét irja be a tömb első elemébe. Az alsó while ciklus működik, kipróbáltam, de a for-on nem látom a hibát.
Segítséget, észrevétet előre is köszönöm.

cod.txt
    
(#) MPi-c válasza Prinner hozzászólására (») Nov 17, 2007 /
 
"for(oszto=1000000000, index=0, nullflag=0; oszto!=0; string[index+1]=0, index=0)"
Én úgy látom, hogy minden ciklus elején az index nulla lesz, ezért a tömbben felülírod az értékeket.
(#) Prinner válasza MPi-c hozzászólására (») Nov 17, 2007 /
 
Köszi
Kiszedtem a for-ból a 3. kifejezést, és beírtam a ciklustörzs után azt a két utasítást, így már működött. Úgy látszik rosszul értelmeztem a fort, mivel a 3. dik kifejezés a minden ciklusfejnél hajtódik végre, és nem a cikluskilépés után közvetlenül.
(#) MPi-c válasza Prinner hozzászólására (») Nov 17, 2007 /
 
OK!
Nem tudom milyen C-ben írod, de CCS-ben az LCD-re egyszerűen így íratható ki a változód:
printf(lcd_putc,"%d",globaluint);

Az egész -> string konverzióra pedig "standard c" függvények vannak: a CCS-ben itoa, a MPLAB C18-ban meg itoa, ltoa,utoa.

(#) Prinner válasza MPi-c hozzászólására (») Nov 24, 2007 /
 
Üdv.
Olyan függvényre lenne szükségem, ami egy float változó értékét decimálisan string-é alakítja át.
Jelenleg úgy oldottam meg, hogy a float-ot beszoroztam az értékének megfelelően( ha pl. 100-1000 között van az értéke akkor e+6-al megszoroztam, hogy egymilliárdos nagyságrendet kapjak), hogy a lehető legnagyob értéket kapjam, amikor egésszé konvertálom. Az int-é való konvertálást a matematikai headerben található ceil() függvény segítségével oldottam meg, csak a kiiratáskor meg kellet oldani a tizedespont helyét, és 1-nél kisebb bemeneti érték esetén a tizedespont előtti, és 0.1-nél kisebb érték esetén az utánakövetkező 0-ák kiiratasat.
Ennek a módszernek az a hátránya, hogy elvész a pontosság.
(#) MPi-c válasza Prinner hozzászólására (») Nov 24, 2007 /
 
Szia!
Nem értem egészen mit akarsz, de nem hiszem, hogy ennyi "bűvészkedés" kellene.
Még mindig nem írtad milyen C-ben? (Nem azért, mert annyira vágom mind a kettőt, amire korábban hívatkoztam, sőt egyáltalán nem vágom)
A CCS-ben, mint ahogy korábban írtam, a printf fügvénnyel tudsz LCD-re írni. Ott pedig a szokásos formátum-specifikáció szerint egy lebegőpontos számot a %n.mf formátumban símán kiírhatsz (n szélességben, m tizedesjeggyel).
Egyébként pedig a C-ben a kifejezések kiértékelése során típus konverzió kell, ami vagy automatikus, vagy te kényszeríted ki! Pl.: egy értékadásnál a a jobb oldal értéke átalakul a baloldal típúsának megfelelően, vagy teadod meg a típust: eredmeny = (long)lebegopontos;
(#) Prinner válasza MPi-c hozzászólására (») Nov 24, 2007 /
 
Szia!
CCS-ben írkálok, de az lcd egyedi soros vezérlésű, így nem tudom használni (közvetlenül) a beépített lcd függvényt, most egyedi függvény kezeli, aminek tömb pointer a bemenő értéke.
Az float értékeket is tömbként tárolom el az eeprom-ba, hogy könnyeben menjen a kiiratas vagy atof()-al vissza tudjam olvasni.
Ezért kell a szorzás átalakítás előtt, hogy a lehető legpontosabban sikerüljön az átalakítás. A ceil() csak attól jobb a cast operátortól, hogy pontosan kerekít, míg a típuskonverzió 0-felé csonkol.
Pl.: int változó=(int) float változó, ha float 0.99, akkor 0-lesz az eredmény, persze ha megszorzom 10 egész számú hatványával, és visszaigazítom a tizedespontot kiiratáskor, akkor elhanyagolható lesz a nem pontos kerekítés.
Következő: »»   2 / 153
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem