Ugyan ezen a gépemen nincs CCS, de szerintem elég egyértelmű a hiba...

esetleg ha megtenéd hogy megnéznéd..... netán elárulnád hogy melyik CCS verzió.... lehet hogy sokat lendítene a dolgon.

Üdv,
A verzió 4.130. A hibaüzenetet értem, viszont azt nem értem ahova mutat, a header-ben a második sor ez: "#device PIC16F1454" és ebben találta a hibát, bármely más 16f145x-el is ugyan ezt csinálja, eddig nem találkoztam a hibával, pedig már több mint másfél éve használom a fordítót, sőt a google sem segített a hiba felderítésében. Most még azt fogom megpróbálni, hogy beszedem a legfrissebb stabil verziót, hátha segít, viszont ez van meg nekem teljes verzióban...

Üdv,
Leírom azoknak akik esetleg hasonló problémával szembesültek volna, hogy a CCS V5-ös verziója valamelyest kezeli a PIC16F1454-est, de az USB-t nem lehet ezzel sem beizzítani, csak akkor ha megírjuk hozzá a saját könyvtárunkat. Alapból az 5-ös verzió is csak a 18F-ekhez kínál USB támogatást, meg még a 16C765-höz, ami már eléggé elavult, szóval ha így szeretnétek készíteni egy USB-UART átalakítót akkor ne CCS-el írjátok hozzá a programot, én is most kezdtem el az XC8 tanulását, bár vannak még hatalmas megválaszolatlan kérdések...
Üdv Gyimate

A #device PIC16F1454 error-ra mi volt a megoldás? Honnan lehet a V5 verziót letőlteni?

A CCS oldaláról letöltöttem a demó verziót, ha kell akkor berakom rá a linket, de ahogy említettem nem ad teljes körű megoldást.

Azt hittem van fullos verziód.
Egyébként senki nem ad igazi megoldást semmire. Neked sokat kell dolgozni rajta. Sem a fájlkezelés, sem a TCP/IP, sem az USB kezelés, sem semelyik komolyabb funkció nincs beépítve a fordítókba. Sehol. Adnak tippeket, demo progikat, de igazából mindegyik izzadság szagú. Legözelebbi a JAVA, ami ilyen szempontból DeLux, de az nem nagyon futkorászik PIC procikon.

Idézet:
„Legözelebbi a JAVA, ami ilyen szempontból DeLux, de az nem nagyon futkorászik PIC procikon.”

Az máson sem futkorászik, inkább csak vánszorog...

Igen, ezt tapasztaltam én is, a fájlkezelést/FAT32 kezelést is megírtam, a "gyárival" nem voltam teljesen megelégedve, igaz, hogy sokat tudott, viszont pont ezt láttam a hátrányának, lassan futott, sok ramot megevett stb, pont ahogy mondtad. Az igazság az, hogy már korábban is gondolkoztam rajta, hogy megtanulok egy másik fordítót is kezelni, így esett a választásom az XC8-ra, nem olyan nehéz, bár rá kell érezni és akkor az is adja magát, persze nem lesz ilyen kényelmes, viszont több lehetőséget is kínál.

Sziasztok!

Már egy jó ideje megépítettem az oldalon található leírás alapján a PIC vezérelt utastér világítás késleltető elektronikát. Most viszont módosítani szeretnék 1-2 értéket illetve utasítást benne. Ehhez viszont C kódban kellene átírni a megfelelő dolgokat, majd lefordíttatni hex-be. Addig eljutottam, hogy letöltöttem a megfelelő progikat (MPLAB IDE több verzióját is illetve a megfelelő, 12-16F -es beépülő C fordítót). Ha jól értelmezem ennek a menetét, olyan fordító program sajnos nem létezik amit amivel megnyitom a C kódot és hex kódot csinál nekem. Amit már csak beleégetek a PIC-be ugyan úgy mint ahogyan a kész hex kóddal tettem korábban, amit le lehet tölteni a késleltető leírásából.
A fordítás menete elvileg az hogy elindítok egy új projektet az MPLAB IDE-ben, amihez hozzáadom a C kódot, ezután ezzel a progival közvetlenül lefordítom majd beleégetem a PIC-be. Itt akadtam meg, ha jól láttam a projekten belül olyan beállításokat kell végeznem a PIC típuúsához kötötten ami megoldaná, h hibát dobjon a fordítás közben. A jelenlegi beállításokkal (legalábbis szerintem beállítás baja van) ezeket a hiba üziket dobja ki:

Error [800] undefined symbol "INTIO"
Error [800] undefined symbol "WDTDIS"
Error [800] undefined symbol "PWRTEN"
Error [800] undefined symbol "MCLREN"
Error [800] undefined symbol "UNPROTECT"
Error [800] undefined symbol "BOREN_XSLP"
Error [800] undefined symbol "IESODIS"
Error [800] undefined symbol "FCMDIS"

(Ha a kódhoz hozzá sem nyúlok is ezt kapom, tehát nem a belepiszkálás rontotta el). Külföldi fórumok alapján szerintem a projekten belül kellett vna még vmit beállítanom. Vagy ha tévedek remélem meg tudja mondani valaki h mégis mi lehet a baja, mit rondottam el.
Előre is köszönöm.

üdv

Üdv!
Tudnál esetleg küldeni egy linket a kapcsoláshoz, mert úgy könnyebb lenne megtalálni, hogy miről is van szó. Azokat a hibaüzeneteket meg azért kaptad mert rosszul lettek beírva a fuses bitek, ha ccs-t használsz akkor ezt úgy kell megtenni, hogy "#fuses INTIO, WDTDIS .......". Ha gondolod akkor viszont írok neked egy c kódot hozzá amiben könnyebben eligazodhatsz.

Ezt a programot melyik C fordítóban kell fordítani, mert ez nem CCS C?

A cikkben és potyo kódjában is benne van, hogy Hi-tech c, nem ccs. Úgyhogy mostanában marad az xc8, ami változtatás nélkül, símán fordítja.

Bocs, jogos! Ez az a cikk
Megköszönném, ha kapnék egy kódot (project formájában) amit csak megnyitok átírok amit szeretnék és fordíttatnom.
Egyébként csak az időt szeretném átírni, és azt hogy gyújtás levétele után ne kapcsoljon vissza. Ahogy láttam a C kódot ez nem vészes, csak a fordítás bekavart sajnos....
Tehát a Fuse bitekkel voltak bajok, akkor jól gondoltam mert a "Configuration Bits"-eknél próbáltam állítgatni ezt azt, a fordító mappájában található PIC12F683-hoz tartozó kézikönyv vagy példa progi alapján, de nem jött össze sajnos.
Vagy az említett CCS C progival egyszerűben meg tudnám oldani?

Tehát: a cikk Hi-Tech C fordítóra készített kódot tartalmaz.
Ez a topik a CCS C fordítóról szól. A CCS az életben nem fogja neked azt a kódot lefordítani.
El kell döntened, hogy azt a kódot szeretnéd használni - ebben az esetben javasolt az eredeti C fordító (vagy ahogy egyesek írták, az XC8) használata - viszont így akkor nem ebbe a topikba tartozik a történet.
Vagy megkérsz valakit, hogy írja újra az eredeti program alapján az egészet CCS C-re, és akkor tudod a CCS fordítóját használni - és csak azt, mivel semmi mással nem fog fordulni a program.

Értem, köszönöm!
Azt nem figyeltem h nem ugyan olyan fordítótól szól a topik mint ami a cikkben szerepel. Átrakom a megfelelő topicba a kérdésemet. Ide

Kedves Fórumtársak!

Egy PIC16F1829-es PIC interrupt-on-change funkcióját próbálom megcsinálni ccs c compiler-rel (v4.114). De egyszerűen nem sikerül. Úgyhogy megcsináltam MPLAB X IDE-ben assembly-ben, és úgy meg megy. De én azt szeretném, hogy a ccs-ben készült C programmal is menjen, mert egy nagyobb programnak egy kis része lenne ez az interrupt-on-change funkció, és a program további nagy részét nem szeretném assembly-ben megcsinálni.

A kérdesem az lenne, hogy valaki meg tudná-e mondani, hogy mi a c programom hibája?

A PIC16F1829-es mikrovezérlőm C portjára 8 db LED van kapcsolva, valamint a PORTA 2-es pin-jére egy optokapcsoló (optointerrupter), mely úgy van a pin-re kapcsolva, hogy ha a fotodiódát megvilágítja a LED, akkor a fotodióda a földre húzza a pin-t (0.34V-ot mérek), ha meg eltakarom a fotodiódát a LED-től, akkor a fotodióda lezár, és a pin egy 1kOhm-os ellenálláson keresztül 5V-ra van felhúzva (ennyit is mérek).
A program azt csinálja, hogy bekapcsoláskor a PORTC,0 pin-jén levő LED-et felkapcsolja, hogy az mutassa, hogy bekapcsolt a mikrovezérlő és elindult a program. Ezt követően ha az optokapcsolóban letakarom az fotodiódát, akkor a logikai 0-ról logikai 1-re változik a jelszint a PORTA,2 pin-en, azaz el kellene indulnia az interrupt-on-change megszakitáskezelő szubrutinnak, ami azt csinálja, hogy ha az első LED világított, akkor most a második fog világítani, ha viszont a második LED világított, akkor az első fog. Nem a LED világítás a feladat, ez most csak a debuggolást szolgálja, hogy lássam elindul-e a megszakításkezelő szubrutin vagy sem.

Namost ezt a működést nem produkálja a C program:




Bemásolom az assembly kódomat, ami szépen működik (ennél az interrupt nem felváltja kapcsolgatja az első és második LED-et, hanem 2 LED-et működtet, és minden egyes interrupt-ba lépéskor lépteti a LED-eket egyel jobbra, ugyanis ezt egyszerűbb volt beprogramoznom assembly-be, de ahogy fentebb is említettem, jelenleg nem a LED kapcsolgatás a lényeg).

Az assembly program:

Az előző nyitó hozzászólásomban bennemaradt a megszakításkezelő szubrutinban a output_c(0x03); sor, de azt csak próbaként írtam be, hogy hátha az if-be nem megy bele a program (bár akkor az if utáni else-be be kellene mennie). Azt most nem kell figyelembe venni, csak már nem tudtam a nyitó hozzászólásomat módosítani.

Sziasztok van egy problémám A ccs -el hexbe akarom forditani, de 1 hibát jelez és nem tudom miért

#use i2c(master,sda=DAL_SDA, scl=DAL_SCL, Force_HW)

a Force_HW hiba mit lehet tenni?

köszi Attila

Hardveres I2C kommunikációhoz azokat a lábakat kell használni, ahol az I2C busz kijön!

Oké de én nem nagyon értem a programozást. Segítenél ez mit jelent. Mit kell megváltoztatni, hogy jó legyen?

Ha az áramköri elrendezés már adott, akkor a FORCE_HW paramétert kellene hanyagolni. Vagyis szoftveres I2C kommunikációt kellene használni.

Üdv
A FORCE_HW. beállítással azt mondod a fordítónak hogy a hardveres I2C-t használja minden képpen, viszont ha a megadott lábak nem a pic hardveres I2C lábai akkor a fordító ellentmondásba kerül. Ez olyan mintha megparancsolnák neked hogy menj be egy épületbe a főbejáraton viszont de utasításként kapnád azt is hogy csak a hátsó ajtót használhatod amit ráadásul neked kell megépíteni (mivel szoftweres komunikációt kell végrehajtanod).

Oké, így már értem. De hogy tudom, hogy a pic, jelen esetben a 16F876A nak melyik a i2c lába és hogy lehet ezt a programban beállítani.

Próbáltam SW állítani, de akkor nem mutatta a hőmérsékletet, nem jelzett ki semmit.

Többek között erre való a PIC adatlapja, jelen esetben ez a RC3 (órajel) és RC4(adat)-es láb. Nem nehéz megtalálni őket, első lépésben ellenőrizzük, hogy a PIC-et ellátták-e egyáltalán a szükséges modullal, amennyiben igen 3 lehetőségünk van:
1, Megnézzük az IC lábkiosztását és megkeressük az SCK és SDA lábakat, ezek a hardveres I2C lábak.
2, Megkeressük az adatlapon belül a lábak leírását, ez egy hosszú táblázat az adatlap elején és itt keressük meg az I2C portot.
3, Megkeressük az SSP porttal (ebbe beletartozik az I2C és az SPI) foglalkozó bekezdést és itt is megtaláljuk a szükséges lábakat.
A programban úgy tudod beállítani, hogy a lábak helyett ennyit írsz be: "I2C1" persze idézőjelek nélkül, ezzel megmondod a fordítónak, hogy PIC hardveres I2C lábait használja, ő ezt onnan tudja, hogy létezik a C:/Program Files/PICC mappában egy Devices nevű almappa, ebben benne van az összes PIC amit a fordító támogat, ezek tartalmazzák többek között a lábkiosztást is.
Mellesleg hogy ha elindítod a CCS-C-t és megnyomod az F12-őt akkor előhozza a segítséget ahonnan bármit megtudsz, többek között az I2C beállítási lehetőségeit is.
Ha mindenképpen szoftveres kommunikációt szeretnél akkor pedig használd ezt: "FORCE_SW", viszont ennek megvannak a hátrányai, ilyenkor a a PIC-be égetett program fogja generálni a kommunikációhoz szükséges órajelet és a kimenő adatot ezáltal egy csomó programidőt vesztesz, míg a hardveres kommunikációnál csak betöltöd a kívánt adatot egy regiszterbe és a PIC magától elvégzi a feladatot és persze eközben a program fut tovább párhuzamosan az adatküldéssel.
Ha kérdésed van nyugodtan kérdezz, segítek a megoldásban.
Üdv Máté

Kedves Forumtársak!

A CCS C compiler-rel van gondom. A PIC16F1829 mikrovezérlő PORTA:2-es pinjén érkező felfutó él esetén megszakítás hívódik meg. Ez már jól müködik. A megszakításon belül az egyik felfutó élnél az 123 számnak kell megjelennie az LCD kijelzőn, ha újra jön egy felfutó él akkor pedig a 9876 számnak kellene megjelennie. Újabb felfutó élre megint az 123 karakter jelenik meg, és így tovább váltakozva (ez tesztelés miatt van). Az 123 karakter egyesével vannak kiiratva az LCD-re, mint különálló számok, és ez működik is. A 9876 számnál viszont egy szubrutin hívódna meg, ami ezt számjegyekre bontja, és ezeket a számjegyek lennének utána kiiratva. Na ez a rész nem működik, csak egy nulla jelenik meg ennél. A szubrutin a main(){} részben meghívva jól működik, akkor kiírja a számjegyeket. A problémám az, hogy nem értem, az interruptban meghívva miért nem működik.
Remélem valaki tud segíteni, és elmondja, miért nem hívódik meg a bit16szam_konverzio_BCD szubrutinom az interrupt-ot lekezelő szubrutinon belül, vagy ha meg is hívódik, akkor miért nem kerülnek a "tízezres, ezres, szazas, tizes, egyes" globális változókba bele az értékek. Bemásoltam a programot (az LCD_inicializalas szubrutint nem, mert elég hosszú, és az működik).
(Megjegyzés: Az LCD-t 4 biten vezérlem, ezért van az, hogy a karaktert reprezentáló byte felső és alsó 4 bitjét egymás után küldöm az LCD-nek)

Tovább tesztelve a programot úgy látom, hogy az interruptnak a szubrutinjában meghívva a bit16szam_konverzio_BCD(kijelzendoertek) szubrutint az lefut, de nem adódik át neki a kijelzendoertek, ezert ir ki 0-t. Valaki meg tudná magyarázni nekem, hogy mi az oka annak, hogy a szubrutint meghívva miért nem adódik át a paraméterben megadott érték?

Lehet, hogy a bit16 kulcsszó a fordítónak és nem lehet használni változó névnek? Így kis betűvel még veszélyesebb. Próbáld ki valami másik névvel. Hátha...

Megváltoztattam a bit16 változónevet másra, de nemez volt a gond. Viszont még tovább kísérletezve azt vettem észre, hogy ha az interrupton belul a bit16szam_konverzio_BCD() függvényt úgy hívom meg, hogy bit16szam_konverzio_BCD(9876), akkor szépen kiírja a kijelzőre a 9876 számokat, viszont ha a
kijelzendoertek=9876;
LCD_kepernyotorles();
bit16szam_konverzio_BCD(kijelzendoertek);
módon hívom meg, akkor 0-t ad át függvényparaméternek.

Ha viszont felcserelem ebből a 3 sorból az első kettőt, akkor meg már jól működik:
LCD_kepernyotorles();
kijelzendoertek=9876;
bit16szam_konverzio_BCD(kijelzendoertek);
Azaz ha a változónak közvetlenül az előtt adok értéket, mielőtt meghívnám a bit16szam_konverzio_BCD() szubrutint.

Miért nem mindegy a sorrend?

Szia!

Több dolog, ami megütötte a szemem:

Szerintem ezeket az ASM blokkokat nem érdemes erőltetni, mivel a CCS-nek vannak függvényei, amik megcsinálják (pl. interrupt beállítás). Egy csomó minden automatikusan megy, pl. az interrupt letiltása (ez ráadásul hardware-ből, a flag csak a compiler közbenjárására törlődik), miközben épp az interrupt fut. Ezt a programot meg lehet csinálni teljesen C nyelven, ezzel csak a hibát viszed be szerintem.

A TRIS állítgatását is elvégzi a compiler, hacsak nem használsz FAST_IO-t.

Magára a hibára: szerintem próbáld meg a printf, sprintf, stb. beépített függvényekkel. Ezek tudják az int->string konverziót. Ha jól emlékszem, arra is van lehetőség, hogy a printf függvényben megadd az argumentumban, hogy melyik függvény írja ki a kijelzőre a karaktert (függvény pointer), és akkor így közvetlenül mehet a kijelzőre is. (egy kis segítség: Bővebben: Link)

Ja és a CCS fórumon van egy flex_lcd.c nevezetű kis könyvtár, amia h44780-kompatibilis kijelzők meghajtására van. Szóval neked nem is kell megírnod ezt a részét.

Kedves efiscp!

Nagyon szépen köszönöm, hogy foglalkoztál a problémámmal és válaszoltál, és részben a megérzésed az ASM blokkal igaznak is bizonyult. Ugyanis közben a CCS által készített .lst file átbogarászása során szerencsére rájöttem a problémára. Az interrupt-ot lekezelő void bit16szam_konverzio_BCD(signed int16 bit16_szam) szubrutinban levő ASM blokkban a bankváltást csináltam a 7-es bankra, amit aztán nem váltottam vissza. A CCS viszont a változóimat a 0-ás bank General Purpose Registereben helyezte el. A CCS a LCD_kepernyotorles(); (és egyébként minden más szubrutint) úgy fejezett be, hogy a bank-ot a 0-ásra váltotta vissza, ezért amikor először azt írtam a kódba, és utána jött a változónak az értékadás, akkor jól működött a dolog, fordítva meg nem.

Az ASM blokk azért kellett bele, mert valamiért a CCS függvényeivel megírt interrupt-on-change megszakítás a PORTA,2-es pinen (illetve más PORTA pinen) sem működött rendesen. Ráadásul ezen 16F1829-es chipnek a PORTB-jén is van ilyen interrupt-on-change lehetőség, viszont a CCS-ben ezen chiphez tartozó PIC16F1829.h header file alapján az enable_interrupt() utasításba csak PORTA-t, vagy PORTA-s pineket írhatok, PORTB-t egyáltalán nem. Nekem meg majd a PORTB kell.
Az, hogy CCS saját függvényeit felhasználva nem működik az interrupt-on-change megszakítás rendesen szintén megírtam ide a fórumba Bővebben: Link, de arra senki nem válaszolt.
Pedig lehet csak én rontok el ott is valamit, és örülnék, ha legalább a PORTA menne a CCS beépített függvényeivel.