Fórum témák
» Több friss téma |
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.
É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!
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?
Hály!
Tudna valaki valami okosságot az Mplab C18 compiler student verziójának a végtelenitésére ? 
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
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:
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...
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. 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.
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. 
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é.
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.
Szia!
A hitech C fordítóhoz nem értek, viszont C18 alól nem az
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. 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...
É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...
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?
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) 
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.
Kérlek! És ha véletlenül nem lenne meg a Reference Manual.
Í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.
"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.
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.
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.
Ü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.
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;
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. |
Bejelentkezés
Hirdetés |
