Akkor csak a gyári fordítókkal érdemes dolgoznod. Azokhoz lehet példaprogramokat is találni bőségesen.

Potyo, utánanéztem kicsit a neten a "konkurens" fordítóknak.
Nagyon-nagyon dicsérik a HiTech Picc18-at és a Picc32-t. Állítólag rendkívül kidolgozott, nagyon optimalizált kódot készít és ráadásul hasonlít az ANSI C-re illetve a C#-re, amivel én PC-re dolgozom. Ha ez igaz, akkor nekem erre kell áttérnem, azt hiszem... Igaz az ára rendesen húzós (1500$), de van LITE verziója, amely ingyenes és csak a kódoptimalizálás van "lebutítva", más korlát nincsen benne, tehát tanulni kiváló lehet. Mit hallottál róla, igazak ezek a vélemények?

Talán azt is meg kellene fontolni, hogy mire használod majd. Mert ha egy-egy komolyabb feladathoz másoktól kell átvenni valamit (periféria-könyvtár, adatfeldolgozási könyvtár, grafikus könyvtár, USB/Ethernet stack, RTOS vagy egyéb operációs rendszer), akkor majd az diktálja, hogy melyik fordítót kell használni. Ebből a szempontból nézve a Microchip fordítói esélyesebbek.

Nem véletlen, és nem ízlésficam, hogy PC-ken mai napig is használunk FORTRAN-t. Bizonyos programok, könyvtárak csak ilyen nyelven állnak rendelkezésre...

Igen, a Hi-Tech fordítói nekem is nagyon profinak tűnnek, a Microchip fordítói annyi előnnyel rendelkeznek vele szemben, hogy gyáriak, és emiatt többen használják azokat.

A Lite verzió egy problémáját találtuk itt a fórumon nemrég, hogy az általunk beírt utasítások közé betesz további utasításokat, amik oda nem kellenének. Konkrétan emiatt az EEPROM írás nem működött, mert a MOVLW 0x55 MOVWF EECON2, MOVLW 0xAA MOVWF EECON2, BSF EECON1, WR utasítások közé bekerült más utasítás, és nem egymás után futott le a fent említett szekvencia. De ha a feladatban nem volt ilyen szigorú megkötés, akkor egyébként minden szempontból működő kódot kapunk. Tehát az, hogy csak a kódoptimalizálás van lebutítva, az azért egy kicsit sarkított változata az igazságnak, mert teljesen felesleges utasításokat helyezett el - nem csak arról volt szó, hogy nem ismeri fel, hogy az IF (i&0x80) feltételnél nem kell a MOVF i, W, ANDLW 0x80 majd ezután BTFSS STATUS, Z művelet, hanem elég csak egy BTFSS i,7-el ellenőrizni. De ismerkedéshez, kipróbáláshoz jó, azután pedig ha kell, akkor megveszed. Mintha lenne valami Pro Trial változat is, abban talán nincs ez a plusz kód berakás.

Teljesen igazad van. Ezek a dolgok nagyon fontosak, ugyanúgy, mint a példaprogramok és a meglévő driverek. Ezeket még le kell ellenőriznem, a gyári leírás szerint a Lite ugyanazokat tartalmazza, mint a kereskedelmi verzió. Megnéztem a fórumukat is, jónak tűnik, rengeteg téma, példa és hozzászólás... Mondjuk az is mellettük szól, hogy többféle MCU-ra is fejlesztenek compilert, többek között Atmelre is, amely, mint tudjuk meglehetősen népszerű. Egyébként saját szabadalmakon, fejlesztéseken dolgozom, esetenként meglehetősen bonyolult feladatok elé állítom magamat gépészetileg, elektronikailag és programozás-technikailag. Nyilván, ezért is érdekel, hogy mit hallottatok róla, mert ha átállok, akkor át kell írnom az eddigi programjaimat is és azokból eléggé sok van...

Látod, ez egy nagyon hasznos info máris, köszönöm is, mert rengetegszer használok eeprom írást, külsőt is, belsőt is. Nyilván a cég nem akarja minden kártyáját kiteregetni, ez viszont csúnya dolog... ilyenkor feljogosítva érzem magamat, hogy az első időkre megszerezzem magamnak a ker. verziót.
Később úgyis meg kell vennem, hiszen a termékeinknek rendelkeznie kell jogtiszta forrásokkal.
Az ilyen lebutításokkal viszont valóban nem lehet tanulni, vaktában meg az ember gyereke nem ad ki 1500 dodót ebben a válságos világban, nem igaz?

Igen van trial verzió, de csak 30 napos. Azt meg kicsit kevésnek tartom az alapos kipróbáláshoz, miután sajna nem tudok állandóan a programozó gépem előtt ülni...

Nem bontották ki az igazság minden részletét...

Ami a legendás minőséget illeti: az Omniscient Code Generation-ban lehet valami. Megpróbál összegyűjteni minden információt az összes forrásfájlból,hogy egy átfogóképet kapjon a programról, mielőtt nekifogna az object kód generálásának.

Van erről itt egy cikk is.

Pozitívum, hogy Linux alatt is használható. Negatívum, hogy Windows alatt csak rendszergazda jogokkal müködik az MPLAB alól.

---------


45 napos - bár ez sem sokkal több....

Szerintem semmi köze az Omniescent Code Generation-hoz. A teljes verzió nem gyártott bele semmi plusz utasítást. Nekem egyértelműen a Lite verzió butításának tűnt a dolog.

Érdekes a cikk, köszi. Csak átfutottam, de majd elolvasom alaposan, minden esetre működési ábra és a kódhossz összehasonlító táblázat eléggé meggyőző.

Bocs, ha félreérthető voltam: Az Ominscent Code Generation csak a teljes változatban van benne, s nem az EEPROM írásra, hanem egy korábbi megjegyzésre ("Állítólag rendkívül kidolgozott, nagyon optimalizált kódot készít") utaltam a "legendás minőség"-gel. Csak nem akartam litániát írni....

Valószínűleg így van, ahogy mondod. Nem ők találták fel ezt az üzleti módszert... Dolgozik a pasi, tetszik neki a darab, egyre merészebb lesz, egyre bonyolultabb dolgokat akar megcsinálni... Aztán egyszer csak nem megy, vagy hibásan megy. Ez egy jó módszer arra, hogy akinek addig megtetszett, az megnyissa a pénztárcát és megvegye a teljes, hibátlan verziót. Ezt hívják más "szakmákban" beetetésnek, nemde?

Hello,
egy betores vedelmi projekten dolgozom, mostanra elkeszitettem az aramkoroket. A projekthez PIC18F4620-as mikrokontrollert hasznalok. A kerdesem az lenne, hogy ti szerintetek mit hasznaljak MicroC-t vagy MPlabot, melyik lenne elonyosebb?

Ezek között nem lehet választani, mert a kettő közel sem ugyanarra való. A MikroC egy fordító, az MPLAB pedig egy komplett fejlesztőkörnyezet. De ha már 18F-et használsz, akkor miért nem C18 fordítót?

Szerintem arra gondolt... Csak azt nem értem, hogy ez hogy jön a CCS topikba?

Igen, szerintem is akkor már legyünk stílusosak: szerintem használj MPLAB-ot, mint fejlesztőkörnyezetet és abban pedig a projekt elkészítéséhez CCS C-t, mint fordítót. Egészen jól kijönnek egymással, a CCS C kisebb hisztériái ellenére...(lásd. feljebb)

Szerintem meg használjon C18-at, ha már 18F chipet használ...

Bocsi, hogy ide irtam, csak nem akartam nyitani egy uj topikot. Az en tudomasom szerint a MikroCnek is van fejlesztoi felulete, akar csak az MPlabnak. Engem az erdekelt volna, hogy melyikbe konyebb dolgozni, mert ugy hallottam, hogy Mikrocben sok fuggveny meg van irva, pl. UART, PWM mig MPlabban minden regisztert egyesivel be kenne allitsak.

Végig kell gondolni a szempontokat. Én az MPLAB-ot választanám, mert ebben tudok szimulálni, debuggolni a PICkit2-vel, azt pedig nem hátránynak, hanem előnynek vehetjük, hogy a regisztereket egyenként állítjuk, ugyanis így legalább tudható, hogy mit csinál a program.

Ha valaha Microchip fejlesztői kártyákat használsz majd, akkor azokhoz is a Microchip fordítóihoz írt programokat találsz majd.

Normális RTOS-t sem láttam még MikroC-hez vagy CCS-hez írva (kivéve a CCS saját PIC18-as RTOS-át).

Sziasztok !

Valaki meg tudná mondani hogy tundnám a CCS ben a 64128G tipusu LCD kijelzőmet használni ?
s6b1713 chip van ebben ami KS0713 al kompatibilis, a gond vele hogy a CS2 lába nincs a kijelzönek , ebben az esetben hogyan kössem be, vagy milyen drivert kell hozzá használnom ?

Előre is köszönöm a segítséget !

Ha nem okoz gondot, rakd fel ide a cucc adatlapját, hadd nézzünk bele, talán akkor tudunk valami okosat is mondani...

Már én is foglalkoztam a dologgal, de a CS2 láb hiánya miatt másik kijelzőt kellett elővennem.
Megkerestem az adatlapokat:
vezérlőcsipp
64128G LCD

Megnéztem az adatlapot, ez a vezérlő is kétféle interface lehetőséget ismer, a 6800-as és a 8080 (Epson párhuzamos) szabványt. A 8080-as a használatos, ebben az esetben a CS1 lábat alacsonyra kell tenni, tehát le kell kötni testhez. Az a tapasztalat, hogy ha nem kötöd le, hanem "lebegni" hagyod, akkor nem, vagy labilis módon működik. Én nem ezt az lcd-t használom, hanem az EDT EW32FA0-t (320x240) az is ugyanezeket az interface módokat támogatja ugyancsak 1 db select lábbal (ott SEL1-nek hívják), ez működik a fent leírt módon. Driverként elvileg a CCS EX_GLCD.C-ben megadott módon mennie kell, de ez csak tipp a részemről.

Ja, igen és javaslom még, hogy nézz körül a CCS fórumon:
ITT

Megnéztem a javasolt mintaprogramot.
Mrre a driverre hivatkozik:
#include HDM64GS12.c

Megnéztem a drivert:


A promlát az képezi számomra hogy ennek a kijelzőnek nincs CS2 -es lába csak CS1B.
Ha a CS1B -t lekötöm földre szerintem nem fog müködnia dolog.
Akkor most hogy is kössem be ?

Van egy másik kijelzőm annak van CS1 és CS2 lába is arra szépen tudok rajzolni.

Mint az írtam, a hivatkozott driver csak egy tipp volt, amiből el lehet indulni, át lehet írni. Újra átnéztem a vezérlő chip leírását és azt látom, hogy az MI lábbal (14) lehet kiválasztani a 8080-as interface módot, a CS1B pedig olyan mint más LCD-nél a chip select, tehát ez vezérelt láb. Nézd végig a leírást és kerestesd a "8080" kifejezést, meg fogod látni, hogy mit hogyan kell ehhez állítani. Amúgy én ilyenkor el szoktam kezdeni a neten keresgélni, mert biztosan volt már olyan, aki ezt az lcd-t használta valamihez és felrakott róla egy bekötési rajzot, vagy valamilyen drivert.

Keresgettem a neten, 2 megoldást találtam.
Az egyik SPI modban működik, ezzel megy a kijelző, de vannak korlátai. Mégpedig hogy nem lehet a kijelzőt csak írni.

A másik C18 ban készült és DSPIC re írodott , próbáltam valamit büvészkedni vele de nem tudtam eredményt elérni vele. Sajnos a C18-at C30-at, abszolút nem ismerem , és a CCS -nek sem vagyok a mestere , csak tanulgatom.
Samsung KS0713 Graphical LCD Driver for Microchip PIC24 and dsPIC33...rolers
LCD projekt C30-ra
Ha ebből lehetne CCS-nek emészthető verziót késziteni , lehet meg is lenne oldva a kérdés.

Én is csak olyat találtam ami SPI módban kezeli az lcd-t. Igazából így legalább betűket lehet rá írni.
Ezen az oldalon van a projekt.

Az jobb lenne , amit te találtál, csak én sem tudom átírni CCS-hez.

Valaki esetleg tudna ebben segíteni ?

Sziasztok!

Tudnátok nekem segíteni abban, hogy CCS-el hogyan tudom bekapcsolni a VPP/MCLR/RE3 láb felhúzó ellenállását?

Elvileg ez lenne, hogy:

port_e_pullups(0b00001000);

De ez az eredménye:
Error 12 "main.c" Line 64(15,16): Undefined identifier -- port_e_pullups

A pic amit használok 18f4550 és az a gyanúm, mintha nem tudná a compiler, hogy ez a pic tud ilyet.
A "B" porton tökéletesen működik a dolog, csak ezen nem.

Rosszul csinálok esetleg valamit?

Először is megnéztem a PIC adatlapját. Valamit féreolvastál. A PORTE legfelső bitjével a PORTD-n lehet felhúzni a bemeneteket, nem a PORTE-n.
Aztán a port_x_pullups(value); utasításban ennél a PIC-nél a value értéke vagy TRUE, vagy FALSE. (Vannak PIC-ek, ahol egyesével is be lehet állítani a felhúzást, de ez nem az.)
Ha még így sem veszi be a fordító, akkor egyszerű megoldás: