Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
Szia
Elöször is köszönöm a sok segitséget!  Kipróbáltam amit irtál, de sajna nem megy. A zárojelek hiányát javitottam itt:
Ezután kiprobáltam, de beolvasás után az összes led kimenet magas szinten van. Mitöl lehet ez?  (Az olvasás és irás megtörténik mert villogtatok egy ledet végrehajtáskor.)
Bocs a lemaradt zárójelekért!
Ha programozásnál törlöd a memóriát, vagy még nem sikerült felülírni az EEPROM-ot, akkor csupa egyes van benne. Milyen felszerelésed van? PICkit2-vel pl. kiolvasható az EEPROM, tehát lehet ellenőrizni, hogy belekerült-e az adat. Ha nincs ilyen lehetőséged, akkor megpróbálhatod átírni az eeiras() fv.-túgy, hogy direkt nullát írjon ki (ee_write(0,0) ), s egy futás után reset-elve visszajön-e a nulla?
Jó korán keltél! Csak nem ezen gondolkoztál egész éjszaka?
 Megoldodott, köszönöm! Maradtam a saját elgondolásomnál és nem shifteltem a biteket. Egyszerűen a 0-ás cimre irok 0x01, 0x02, ...stb számokat. Induláskor vizsgálom mi van beirva majd beállitom a kimeneteket. A megoldás az lett hogy az elején kellett egy vizsgálat hogy eki==0xFF mert nem biztos hogy van benne valami. Ekkor beirok eki=0x01-et és készen is van. A második szivás meg az volt hogy ha rajta van a pickit akko néha félreugrik a prog és beir valamit. Miután levettem rolla jó is lett. Köszi mindent! Idézet: „Jó korán keltél! Csak nem ezen gondolkoztál egész éjszaka?” Őszintén szólva nem... Idézet: „ Maradtam a saját elgondolásomnál és nem shifteltem a biteket.” Pedig direkt azért javasoltam a shiftelést, hogy ne kelljen a feltétel vizsgálatokkal bonyolítani a programot. Idézet: „ A megoldás az lett hogy az elején kellett egy vizsgálat hogy eki==0xFF mert nem biztos hogy van benne valami.” Ez jó gondolat.
Elvileg a CCS is nyújt egyszerű RTOS megoldást (kooperatív multitasking). Próbálta már ezt valaki?
Szerintem arra, hogy PORTA semmit nem csinál a CCS.
Valahogy így képzelném el a dolgot 16F628 MCU esetén: #byte PORTA = 0x05 #byte PORTB = 0x06 write_eeprom(0, PORTA); ez kiolvassa a PORT_A állapotát és leteszi az EEPROM 0x0 címére. Ugyanígy működne a PORT_B is. Visszafelé: PORTA=read_eeprom(0); Ez kiírná az EEPROM tartalmat a portra. sysy
Köszönöm a kiegészítést! Valóban kell hozzá a
hozzárendelés...
Sziasztok!
Itt jártak a CCS-es fiúk és ezt hozták. Hátha valakinek még nincs meg. Bővebben: CCS4.078 sysy
Én a C PORTRA TETTEM EGY 16F726-on az lcd-t és nem igazán érem hogy ezt a pin pammet hogyn kéne úgy belőni, hogy a c0 c1 c2 az a vezérlő és c7-6-5-4 az adat.
Tud nekem valaki ebben segíteni? Idézet: „Tud nekem valaki ebben segíteni?” Forrás nélkül kicsit nehéz!
Próbáld meg ezzel:
Igaz, ez 4x16 karakteres LCD-re van, de ékezetes betűket is tud. Ügyelj a bekötésre: C0 enable C1 rs C2 rw C4 D4 C5 D5 C6 D6 C7 D7
Sziasztok!
Itt jártak a CCS-es krampuszok és ezt hozták még ki sem hűlt.   :zavart1: CCS4.084 :zavart1: Használjátok egészséggel! Link javítva
Szasztok!
be szeretnék illeszteni asm kódot CCS-be de nem fogadja el: #asm bcf status,rpo #endasm Először azt mondja nincs "status" nevű változó ha csinálok neki int8asat rp0-nak int1-est akkor meg ezt nyomja ki:Expression must evaluate to a constant valaki tud valami helpet ezügyben? Idézet: „Először azt mondja nincs "status" nevű változó ha csinálok neki int8asat rp0-nak int1-est” Ennek így nyilván nincs értelme, ha status nem egy C változó a RAM-ban valahol, hanem a STATUS regiszter az SFR területen. Éppen ezért meg kell adni, hogy hol van!
Továbbá rp0 sem egy RAM-ban elhelyezett tároló, hanem egy számkonstans, ami a megfelelő bit sorszámát adja meg. Ezt tehát #define-nal célszerű deklarálni:
A 294877. számú hozzászólás szerinti #byte deklarálás talán még jobb választás int8 és #locate helyett.
A felrakott ccs-ben a 16f726.h-ban van egy csúnya hiba: 266. sor
// Constants used in SETUP_ADC_PORTS() are: #define ALL_ANALOG 0x00FFFF // A0 A1 A2 A3 A5 B0 B1 B2 B3 B4 B5 #define ALL_ANALOG 0xFFFFFF // A0 A1 A2 A3 A5 E0 E1 E2 B0 B1 B2 B3 B4 B5 Mindjárt keresek egy másik header-ben egy ilyet és javítom az egyik sort, tegyétek meg Ti is.
Na sikerült annyi időt szakítani, hogy kipróbáljam. Szerencsére pontosan így volt bekötve. Nagyon kasán működik köszönet és hála.
Szerintem sokszor van néhány hiba/elírás a header fileok-ban,nem csak ebben a verzióban a régebbiekben is előfordult.
A CCS-fiúk nagyon siettek az update-el,mint mindíg. 
Köszönjük!
Már régóta vártunk erre! sysy
Sziasztok CCS guruk!
Ismerkedem a PIC-ek és a CCS lelkivilágával, de egy számomra nem tiszta problémába ütköztem. A jelenség az hogy a program szépem lassan hízogat, egyre több funkció kerül bele, és egyszer csak közli, hogy a szegmens túl nagy és elfogyott a ROM. Ezt alapban el is hinném, ha nem egy mezei fputs okozná a jelenséget, amit előtte sokszor használok és láthatóan alig hízik tőle a program. A másik amit kifigyeltem, hogy olyan helyeken jelentkezik, a hol a "sokadik" mélységben hívogatják egymást a függvények. egy 16F876A-t nyüstölök, az egyik fordításnál még 84% a ROM foglaltság, majd egy jól eltalált fprintf vagy majdnem bármi egy a program mélyebb bugyraiban és máris elfogyott a ROM. Az érdekes a dologban hogy ugyan azt a főprogramba illesztve alig változik a memóri foglaltság. Olyan, mintha a callstack zabálná fel. Van erre valami megoldás vagy programozástechnikai trükk amit nem ismerek?
Valószínűleg a függvény egy csomó regisztert használ, amiket a megszakítás kezdetekor el kell menteni, majd visszatölteni a megszakítás végén. Az is lehet hogy nem használja ezeket a regisztereket, de mivel a fordító nem tudja fordításkor, hogy miket használ, ezért amikor függvényhívást lát, akkor biztos ami biztos alapon beteszi az elmentésüket. Ha nem használod az ilyen függvényt a megszakítási rutinban, akkor ezekre a mentésekre nincs szükség. Megszakítási rutinban egyébként sem szép dolog függvényt hívni, főleg olyat, aminek nem tudjuk a belső felépítését.
És mindez kiderül, ha belenézel a listing fájlba, hogy mire fordult az adott kód!
Én ugyanígy jártam, csak HiTech fordítóval + 16F873. Nálam egy switch-case kellett több helyre, hogy "hülyebiztos" legyen a progi, de nem volt mindegy, hogy hová tettem, és egyik sem volt megszakításban.
Egyes helyeken azt mondta a fordító, hogy abba a bizonyos szegmensbe már nem fér több, ezért nem fordul, holott a szumma flash olyan 83-85% körül volt. Én arra jutottam, hogy a linker egyforma (legalábbis fix) darabokra bontja a flash-t, és ez nem rugalamas. Így ha egyik darabba nem fér el az oda szánt kód, akkor annyi. Arra meg nem volt energiám, hogy a linkert parancssori kapcsolókkal utasítgassam, inkább az eldugott szervizmenü nem lett "hülyeálló". Ilyen szempontból jobb az a fordító, amelyiknek egy szöveges fájlban hozzáférhető és paraméterezhető a linkerscript (pl. Microchip, GNU). HiTech-nél én nem találtam ilyet. Aztán lehet, hogy nincs igazam, én inkább hardveres vagyok.
Nem megszakításból hívja, ott csak letárolja a feldolgozandó cuccot, aztán a főprogram hívja meg a feldolgozót, ami aztán az adatok függvényében teszi a dolgát, de a feldolgozóban van sok fgv.
Ja! És dolog compiler függő, több verzióval próbáltam, más más a "tűrőképességük". Ami a listing filet illeti, ha hibával lehal mintha nem is készülne... de megnézem.
Sikerült újra elérni azt a pontot ahol nincs tovább....
*** Error 71 "main.c" Line 308(0,1): Out of ROM, A segment or the program is too large execute_cmd Seg 01000-017FF, 0712 left, need 084F Seg 01800-01FFF, 0800 left, need 084F Seg 00000-00003, 0000 left, need 084F Seg 00004-00054, 0000 left, need 084F Seg 00055-007FF, 0016 left, need 084F Seg 00800-00FFF, 0040 left, need 084F Sajnos nekem ez semmit nem mond (mármint ami előrébb vinne)
Sikerült "megoldást" találnom.
A hiba az volt, hogy az összes sorosporton érkező utasítást egyetlen függvénnyel akartam lekezelni, és az kinőtte a szegmens lehetséges méretét. A megoldás az volt, hogy a különböző típusú utasításokat (set, get, out, cmd stb..) szétdobáltam kisebb fileokba, és már a főprogramban szétválogattam. Így ugyan cipőkanállal, de be lehet tölteni a progit és még műxk is. Köszönet mindenkinek a segítő szándékért! W. |
Bejelentkezés
Hirdetés |
