Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
Én is a Norbertónak adok igazat abban, hogy ez nem egy ANSI C tanfolyam azoknak, akik ebből akarnak megélni. Ez egy baráti csevely a CCS C baráti körének, hogy mit hogyan lehet megoldani EZZEL a fordítóval. Hidd el, ha elkezd valaki egy másik fordítóval pepecselni akkor az első fordítás után utánanéz, hogy miért is van 987 hiba abbana kódban, ami már egyszer lefordúlt a CCS alatt. Ésakkor megkeres téged, aki elmeséli neki, hogy nem is úgy van a C programozás, ahogy eddig hitte.
De! Addig is, amíg eljön ez a pillanat, nagyon szép dolgokat fog csinálni EZZEL a fordítóval, úgy, hogy fogalma sem lesz arról, hogy mi is az a prototipus, precedencia és társai. Nem is beszélve arról, hogy az ANSI C-vel ellentétben nem lehet a CCS-ben rekurzív függvényhívást alkalmazni és még számos korlátai vannak az ANSI C-vel szemben. Ha most ezeket elmagyarázod a kezdőnek, nem fogja érteni, hogy akkor miért nem működik a dolog, pedig a dpeti azt mondta, hogy így kell ezt szépen, profin megcsinálni. A másik az, hogy mindíg a feltett kérdésre illik válaszolni, mert AZT kell megoldani a kezdőnek és nem hiszem, hogy programozás-tecnhikai eltévelyedését kell vele szembesítei. Ha helytelen a kód, akkor fel kell rá hívni a figyelmét és nem beleverni a fejét, hogy valahol egy isten hátamögötti site-on egy ismeretlen embernek vannak jó diái és miért nem azzal kezdte, hogy ezeket kezdte elemezgetni esténként a cellájában imádkozás után. uff! én szólottam sysypet
Az miért baj mostanában, hogy miközben az ember megtanulja a CCS használatát, amellett megtanulja úgy megoldani a dolgokat, hogy az egy másik fordítóban is működőképes legyen?
Ez nem baj. Csak képzeld bele magadat annak az embernek a helyébe, aki azzal küzd, hogy ha megnyom egy gombot, akkor kigyullad egy LED. Vajon elmegy-e ez a fickó a Continental Teves céghez ABS Embedded rendszert programozni? Ha az interjún felteszik a kérdést neki, hogy: "Ön eddig milyen fejlesztő környezetben fejlesztett programokat és mondjon néhány referenciát a nemzetközi megbízásaiból, különös tekintettel az ANSI C környezetre." Vajon van ennek reális alapja? Általában ezek az emberek napközben gályáznak valahol és esténként vagy hétvégén bütykölnek a maguk örömére. Nem is tudták eddig, hogy mi fán terem az ANSI Compatible C Language. Ezekben a hozzászólásokban mindíg a régi munkatársaimat látom, akik izzadva és sok-sok puskával szigorlatoztak kegyelem-kettesre. Az ötödik évben már el is végezték a Gábor Dénest. Most féltéglával verik a mellüket és az előadásokon felszedett félmondatokal dobálózva osztják az észt az új és a fiatalabb kollégáknak. Információtartalom=0 de nagyon jól néz ki, hogy húha, de érti ez a fickó eztet a dógot.
Természetesen a jenlenlévők mindíg kivételek  sysypet
már bocs...
én egyrészt BMEn tanulok, és 5-ös voltam Vitéznél C programozásból... (amit nem sok ember mondhat el magáról...) úgyhogy ilyen idióta következtetéseket lehetőleg ne vonj le a hozzászólásokból Köszönöm! (tudom hogy ott az az utolsó mondat, de nagyon úgy tűnt, hogy azt csak enyhítésként teszed oda)
+:
mi van ha a kedves cég nem akar milliókat költeni arra a C fejlesztőkörnyezetre, amit a méllyen tisztelt újdonsült kolléga ismer... akkor bizony bajban lesz, mert meg kell tanulnia bánni "azzal a másikkal" (ami köztudottan egyszerűbb, ha ismeri az ANSI C-t)
Tudtam! Tudtam!
Mintha megéreztem volna! Mindenki magára ismer egyszer. De utoljára szólok ehhez hozzá. Valószinűleg nem olvastad el az egész hozzászólásomat. NEM professzionális felhasználásokra kérnek itt megoldásokat. Nem mérnök csimoták fényezik itt magukat. Hanem meg szerették volna tudni, hogy miért nem fordúl le egy kódrészlet. Gondolod, hogy az, aki ilyet kérdez:"Még van egy hülye kérdésem: milyen cimkével kell "szubrutin" szerűséget írni c-ben." az azon gondolkozik, hogy vajon minden fordítón lefordúl-e a kódja. Álmatlan éjszakái lesznek, hogy nem elég ANSI a kód? Szerintem nem erről szól ez a topic. Tudom, hogy meg kell mutatni, hogy mások is foglalkoznak itt C programozással. Csak nem így kellene kivitelezni. Aki ilyet kérdez, az nem azon a szinten van, hogy ha flegmán bedobunk egy maréknyi kódot, komment nélkül természetesen, mert a BME-n ezt így kell csinálni, akkor azt rögtön értelmezni is tudja. Ennyi. Egyébként meg kellene kérdezni Prinner kolléga észrevételeit is ebben a tekintetben. Utolsó gondolat. Ha most éled az édes életet az egyetemen, akkor vajon mennyi rálátásod lehet neked a céges munkákról és egyáltalán a mai céges gadaságról? Tőlem az első munkahelyemen megkérdezték, hogy mit gondolok, milyen feltételek között és milyen fejlesztői környezetben tudnák a leghatékonyabban dolgozni? Lista leadva, eszközök megvéve. Ja, és nem volt vörös diplomám. Prinner kolléga pedig nem hiszem, hogy vezető programozó lenne valamelyik jólmenő szoftverháznál. Nos, ennyit szerettem volna erről kifejteni. Részemről vége ennek a szócséplésnek. Ha valaki kérdez valamit itt, a tisztelt társaságtól, akkor a legnagyobb alázattal és örömmel sagítek annak, aki vette a fáradtságot és hobbiból elkezdett a CCS C nyelven programozgatni. Ezek viszik előre a világot. sysypet
De azért láthatod (olvashattad legalábbis), hogy Prinner az alapkérdése előtt olvasgatta!!!, ami nem pite dolog, ezt: ccs book
Tehát program írása előtt megpróbált informálódni arról, hogy mégis mik az alapok...az már más kérdés, hogy épp EGYETLEN súlyos hibába ütközött, az if végére pontosvesszőt téve... Ezzel most kizárólag annyit akartam mondani, hogy a NEM HÜLYE ember esetleg másik típusú nyelvre áttérve (pl. a CCS saját? nyelvéről - aminek köze nincs a C-hez egyáltalán, mondjuk az ANSI C-re) felfedezi azt a dolgot ismételten olvasással, hogy nem teljesen ugyanazok esetleg a szabályok, vagy formátumok...tehát nem kell ennyire félteni mindenkit a programozástól! Akinek van egy kis gógyija, az magától rájön arra, hogy miként ismerhet meg minél több típusú nyelvet...ez főleg azokra értendő, akik majd később valami ilyesmiből akarnak megélni... Mert akik csak otthoni, hobby-programozgatók, azok nyilván szinte egész életükben ellesznek a CCS-sel...mit sem törődve a többi fajtával... Ezt én is ugyanígy tettem korábban, amikor elkezdtem Assembly-ben programozni...átbogarásztam egy csomó féle fordítót PIC-ekhez...és mindegyik eltér valamiben...DE!!!...ezek az eltérések dokumentálva vannak (nem közvetlenül az eltérések)...azaz a delikvens szépen elolvashatja egyesével, hogy az adott fordító miket támogat (milyen adatokat, struktúrákat, utasításokat, stb.)... Abban egyébként teljesen igazad van, hogy mért nem lehet követni a szabvány C-t (legalább az alapokat) pl. egy a CCS esetében is...erre én nem tudom a választ, de nem is túlzottan izgat... A CCS nyilván azt is le fogja tudni fordítani, hogy while(1) , de nem ezt ajánlja elsődlegesen, és fene se tudja miért, nem ez az alapértelmezett a doksi szerint is...ez van, ezen nem lehet változtatni...
Csak érdekességképpen...
Én átnéztem most egy hivatalos CCS-t bemutató Code Book nevezetű doksit, és nem találtam benne olyat EGY SZEMET SEM, hogy
Majdnem minden végtelen ciklus az ANSI szabvány szerint volt a példaprogramokban leírva! Azaz while-lal, a következők szerint (ahogy mindenki ismeri):
Szóval ezek után miről is beszélünk...senki meg se nézte a CCS példa-anyagait, és látatlanul elítélte úgy, hogy előtte soha nem is használta ezt a fordítót? Vicc...  Idézet: „Szóval ezek után miről is beszélünk...senki meg se nézte a CCS példa-anyagait, és látatlanul elítélte úgy, hogy előtte soha nem is használta ezt a fordítót?” És te miért nem nézted meg?????? Nézz már bele az examples mappába, és azután írkálj ijeneket.!!! Én egyébként sem itélem el a fordítót, én csak azt akartam, hogy ne szokjon rá a CCS nyelv specifikus dolgaira. Szimplán azért, hogyha később egy kicsit komolyabb projektbe fog, amihez pl. 18F sorozatból választ chipet, ahhoz már jóformán csak a C18 fordítóhoz fog kódot találni, és akkor ne keljen agyalnia azon, hogy mi miért van.
Én a while(true)-t egy PICC fáljnevű 7Megás pdf-ben láttam. Valahova fel van téve pár hsz.-al feljebb egy zipben.
Csatolok róla egy képet. dpeti-nek igaza van, tényleg nem ártana a c nyelvet az alapokról kezdve átvenni, de sajnos én inkább jobban szeretem próbaalkalmazások elkészítésekor is elsajátítani a pic programozását. Így tanultam meg ASM-ezni is, csak egy idő után már nagyon gáz lett: -2-3000 soros progit nagyon lassan lehet kibuggolni. -Bármennyire jól fel volt kommentezve egy kód, másnak nehéz átlátni azt. -18-as picekre már nehezebb asm-et írni -a kollégák kinevettek  Ezek kiküszöbölésére írtam ini.-ket SPI-re, rs232-re, t6963-ra ADI DDS-ek illesztésére, de sajnos ezek csak félmegoldások voltak  Csak technikus vagyok, eddig még soha nem tanultam programoztást, csak ki akartam próbálni a ccs-t hátha bejön (nem jött be  ).És igen sysy-nek igaza van, tényleg egész nap gályázok, még szombaton is, csak esténként, vagy vasárnap érek rá forrasztagtni, tervezgetni, és így is elég csóró vagyok :yes: . Nem tudtam, hogy ekkora port kavarok fel egy ilyen kérdéssel, de most már egy kicsit szégyellem magam miatta. Először nem gondoltam volna, hogy  lesz belőle, mert a fórumon nem csak ez az egyetlen "okos" kérdés.
Böngésztem egy kicsit a PIC-ec header fájljait, és ezekre bukkanta:
#define FALSE 0 #define TRUE 1 #define BYTE int #define BOOLEAN short int Ezek szerint mindegy, hogy melyiket használjuk 
Üdv.
Bátorkodok megint segítséget kérni, mert elakadtam: Írtam egy olyan függvényt, ami hd44780-as vezérlőjű lcd-nek egy karaktert írat ki. A függvényhez tartozik egy unsigned char is, amibe a főprogramon belül belerakom a karakter ASCII kódját, és függvényhívás után kiírja a karaktert. Hoszabb szövegeknél, már egy kicsit áttekinthetetlen a program, mivel minden karaktert egyesével kell küldeni+ a sok függvényhívás... Arra gondoltam, hogy milyen jó lenne ha PRINTF( ) utasítással ki tudnám küldeni az egészet (ami max. 8 karaktert jelent). Megnéztem a CCS-C Reference Manual-t, és a 115. oldalon megtaláltam a PRINTF() utasítás leírását. Ebben néhány dolgot nem értek: The format takes the generic form %wt where w is optional and may be 1-9 to specify how many characters are to be outputted, or 01-09 to indicate leading zeros or 1.1 to 9.9 for floating point. t is the type and may be one of the following: • C Character • S String or character • U Unsigned int • x Hex int (lower case output) • X Hex int (upper case output) • D Signed int • e Float in exp format • f Float • Lx Hex long int (lower case) • LX Hex long int (upper case) • Iu unsigned decimal long • Id signed decimal long • % Just a % Ezeket a formákat hová kell beírni? Ha valaki leírná, hogy a fenti alkalmazásban, hogy lehetne használni a PRINTF() utasítást? A válaszokat előre is kösz! Tudom, hogy van a ccs-hez kölün LCD kezelő modul, de én egy kicsit gyakorolni akarok
Nézd át ennek a forráskódját, hátha segít.
Bővebben: Link
Helló!
Ehhez szerintem nem tudod használni a printf-et, ugyanis ezzel a soros portra lehet adatokat küldözgetni. Ha csatolod az LCD kezelős függvényeket, akkor átírom neked egy egyszerűbbre. És még el is magyarázom, hogy mi miért van üdv brejti
Szerintem úgy kellene megírni az LCD-re karaktert kitevő függvényt, hogy bármennyi karaktert képes legyen kiíratni. Paraméterként át kellene adni a kurzor pozicióját, ide bepozicionálja a kurzort, majd innen kezdve egy pointerrel (szintén átadva neki) kezdené felszedegetni egy bufferből a karaktereket. Ezt egészen addig csinálná amíg a végére nem érne. Ez praktikusan egy 0x00 karakter lenne. Ezt még lehetne csipkézni, hogy akkor is megáll, ha több karaktert akarunk kiküldeni, mint amennyi az LCD sorába kifér und zu weitere, et cetera, satöbbi.
sysy Idézet: „felszedegetni egy bufferből a karaktereket” Hogyan kell létrehozni egy ilyen sokbites buffert? A PICC nevű könyvben olvastam olyan formákat, hogy "long" illetve "double long", ezek 40 és 80 bitesek, de a ccs fordító nem ismeri fel. A másik köny (CCS-C reference manual) szerint a leghosszab forma az 32bites, de void-al létre lehet hozni nem specifikus hosszuságú buffereket. De sajnos nem láttam rá megvalósítási példát. Ha leírná valaki röviden, akkor nagyon megköszönném. Van egy másik probléma is: átírtam a programot 16f877a-ról 18f4550-re, a kijelzőt sikeresen beinicializálja, de nem küld ki karaktereket. Rájöttem, hogy a kiíró függvényben van egy PORTD = cr_latch; utasítás, és a prog elején meg kell adni PORTD címét. Megadtam, hogy #byte PORTD = 0x83 , de most sem másolja cr_latch tartalmát PORTD-be. Pedig ez a címe (az adatlapban benne van).
A második problémát sikerült megoldani, output_d(cr_latch); utasítással.
Egyébként a ccs egyik rossz tulajdonsága, hogy alaphelyzetben nem ismeri fel a portx=0xFF vagy trisx=0xFF utasításokat.  Pedig a mikroC vagy a HiTechc fordítók is felismerik.
18F sorozatnál a kimenetre íráskor a LATD regisztert használd!
A PORTD címe 0xF83h. A 0x83 az nem az SFR zónában van.
Ok, kösz
 PORTD = 0xF8C és ezután megfelelően működött
Ezzel azért vigyázz. A 0xF8C memóriacím (LATD) olvasása nem a lábak állapotát olvassa be, ha azok bemenetnek vannak beállítva. Azokat a 0xF83 cím (PORTD) olvasása adja be. Tehát ha írunka portra, akkor a LATD regiszterbe írunk, ha olvasni akarunk a portról, akkor a PORTD regisztert olvassuk. Adatlapban benne van, hogy miért.
Helló!
Egy kicsit alakítottam a forráskódon, remélem működik. üdv brejti
Köszi szépen!
Csak az ini történik meg, a kurzor az első pozíción van. Amit én csatoltam c forrás, azon a portd címe 0x83 ami nem jó, oda 0xF8C-t kell beírni, ezt átírtam rajta. Egész ügyes, átnézem 
Ezt hogy érted?: alaphelyzetben nem ismeri fel a portx=0xFF vagy trisx=0xFF utasításokat.
set_tris_D(0xFF); ennek működnie kell (legalábbis nálam működik.) ha a portok címeit definiálod memória címként, akkor szinte bármit csinálhatsz vele, amit egy változóval csinálni lehet. Pl.: #byte PORTD = 0xF8C PORTD=0x55; és láss csodát, kiteszi neked a bitmintát a portra. Sajnos a CCSes fiúk nem olyan előzékenyek mint a HiTeches fiúk és nem definiálták előre le az összes regisztert a device.h állományban. Ezt neked kell megcsinálnod. De utána Hawai van!
Ja bocsi, még kell az elejére egy két include is
18F4550.h, stdio.h, stdlib.h, string.h, stddef.h üdv brejti
Majd' elfelejtettem. Lehet buffereket csinálni a RAM ban az alábbiak szerint:
int LCD_buff[20]; ezzel egy 20karakteres buffert csináltál magadnak. Ha rövidebb a lijelző akkor értelemszerűen kisebb számot adsz meg. int * LCD_pointer; ezzel létrehozol egy int-eket pointerező pointert LCD_pointer=LCD_buff[0]; ezzel beállítod a buffer első elemére (vagy oda ahova akarod) és máris lehet címezni az LCD_buffert. Változó=LCD_buffer[LCD_pointer]; ezekután csak a pointert kell inkrementálni, dekrementálni, szorozgatni, kivonogatni és ő hűségesen címezgeti a buffert.
Köszi, most már működik
 De volt benne egy kis elírás: A maszkolás után hozzáadtál a bájthoz 0x02-őt, és mivel az alsó 4 bájt mindegyike 0, ezért az 1. bitet 1-re állítja. De a d1-en az r/w van, és nem az RS. Most átírtam 0x04-re, és most megfelelően működik.
Hiába beszél az ember? A PORTD címe a 0xF83, a LATD címe a 0xF8C. A kettő között különbség van, és nem lehet csak úgy összecserélgetni őket.
Idézet: „int LCD_buff[20]; ezzel egy 20karakteres buffert csináltál magadnak.” Szerenyen megjegyeznem hogy ansii C-ben karakterlanc_hossz+1 kell legyen a buffer merete. A sorvegkarakternek: '\0' is hely kell.Lehet hogy CCS-ben is el ez. Azert off mert mar emlitettek hogy ez nem ansii C hogyan Kijelentem irasom celja figyelemfelkeltes, nem kotekedes jellegu. Az ilyen apro dolgok tudnak kellemetlenseget okozni neha !Udv. De most hogy elnezem ujra, a tobbi kod is furcsa. Ez tenyleg mukodne igy??  int LCD_buff[20]; int * LCD_pointer; LCD_pointer=LCD_buff[0]; Változó=LCD_buffer[LCD_pointer]; |
Bejelentkezés
Hirdetés |
