Megcsináltam, de így se megy.

Másik két gépen is próbálkoztam, sikertelenül.

Csak úgy kíváncsiságképpen üss egy entert a } jel után. Mindenképpen újsor karakternek kell zárnia a main függvényt.

Egy ilyen próba soha nem fog hibátlanul lefordulni, mert üres. Próbálj valami konkrétat beírni!

Még is hatalmas változást látok, miután nem jött fel a path hibaüzenete!
Viszont írj valami a main-be, mert ez értelmezhetetlen a fordítónak!
pl.


Ezenkívül javaslom, hogy olvasd el a felhasználói kézikönyvét, és a helpjét, mert jól leír mindent!

Sziasztok !
Valaki tudna nekem segíteni?
Eddig Basic-el programoztam az már megy de szeretnék átérni a C nyelvre, éppen ezzel küzdök.
Még szinte üres a programom de hibaüzenetet jelez
Esetleg valamit rosszul írtam ??
aga a program csak annyi, hogy portc-ét magasba állítom:

#include <16f877.h>
main (){
portc =0xFF;
}

Kérlek segítsetek!
Válaszotokat előre is köszönöm.

Gyerekek, nezzetek mar meg a legelso kepet (direkt arra a bejegyzesre valaszoltam most). Ott lathato, hogy valami nincs beallitva rendesen! Arra panaszkodik, hogy a fordito utvonalait nem sikerult rendesen beallitani es, hogy ezt manualisan kellene megtenni. Nem tudom PICC-nel mi a -O kapcsolo, ennek utana kellene nezni, de azt is mondja, hogy hianyzik a hozza tartozo parameter. Lehet az object file-ok eleresi utvonala, vagy az output konyvtar, nem tudom, de ugy erzem ennek kellene utana menni.

Amugy a 63 karakter csak a COD file formatum korlatai miatt vannak, ha jol emlekszem 16 es 32 bites chipek forditojanal nem kell (vagy lehet) COD file-t hasznalni hanem ELF formatumot es ott igy nem jelentkezik ugyanez a problema.

PORTC csupa nagybetuvel kell legyen irva, de amugy ha hibauzenetre hivatkozol idezd mar be legyszi, mert igy nehez kitalalni mire is panaszkodik valojaban

kell, hogy legyen valami típusa az eljárásnak, illetve a vacakabb cékben még a paraméterlista sem lehet üres,

int main()
void main()
int main(void)
void main(void)

kombik valamelyike lesz jó.

BTW., ha már úgyis C, akkor ideje lenne áttérni PIC24-re, sok örömöt fog okozni.

Azért előtte nem árt megnézni, mi is a feladat, mert a végén ágyúval verébre. Amúgy ha indokolt, jó döntés lehet. Bár sok példány indokolatlanul kis számban írható újra, ami igen nagy probléma lehet egy amatörnek! Szóval nagyon kevés amatör feladathoz kell 24...

PICek, watt mester. Nem ágyú meg veréb, hanem muslinca meg szúnyog.

Ugyanannyiba kerül. Többet tud. Kilencmilliószor gyorsabban és egyszerűen lehet rá fejleszteni. Cére optimalizált. Döbbenetes mennyiségű példaprogram és próbakütyü áll rendelkezésre fillérekért. Nincs bankolás. Van memória. Ugyanazon az órajelen dupla sebességgel megy (vagy inkább négyszeressel, a 16 wreg miatt). Megkötések nélkül használhatsz kernelt. Szinte megkötések nélkül oszthatsz funkciókat az egyes lábakhoz. Satöbbi, satöbbi.

Mi is az oka annak, hogy az állítólagos amatőröket igyekszünk a kőkorszakban tartani??

Ja és az újraírások számáról: három éve használom minden nap az Explorer16-ot rendszerint a PIC24FJ256GB110 feltéttel, még egyszer sem szólt a rílájsz, hogy bocs, nem tudom írni. De ha mégis, akkor veszek majd egy másikat 5000Ft-ért a ChipCad-nél, szerintem eléggé jó díl.

Ha csak ez a ket parameter lenne, akkor csodalatos lenne, Microchip be is fejezhetne a 8 bitesek gyartasat... Egyenlore azonban azokbol el meg es ez nem lehet veletlen!



Ezt milyen modszerrel merted le?



Inkabb az a kerdes mi az oka annak, hogy a Microchip tovabb fejleszti a 8 bites eszkozeit? Biztosan azert teszik, mert az mar kokorszaknak szamit es mar senki sem akar 8 bitesekkel foglalkozni...

Es akkor a tobbi idei hirek 8 bites fejlesztesekre:

Microchip Introduces Six New Low-Cost 8-bit Enhanced Mid-range Cor...ollers
Microchip Introduces 8-bit LCD PIC(r) MCUs With eXtreme Low Power T...nology
Microchip Expands 8-bit PICŸ Microcontroller Portfolio With New 20-...Family

Erdemes elgondolkodni miert is olnek bele rengeteg penzt uj fejlesztesekbe, ha mindenki mar 16 bites vagy akar 32 bites MCU-t hasznal manapsag... vagy megsem?!

bocsi, hogy enyit nyávogok de így sem jó a help-ben nem találtam semi hasznosat(főleg, hogy angol).

Uhh, hát ilyenkor valszeg az options-ben kell valamit csesztetni, vagy a pathek vannak vacakul beállítva, de majd az expertek megmondják, nem vagyok túlságosan büfé hájtekben. Btw., ha mindegy, hogy milyen cé fordító, javaslom a Microchip sajátját (azt, amit gcc-ből drótoztak, sokkal jobb a támogatottsága). Töltsd le a student editiont a Microchipről.

Nekem úgy tűnik, hogy nincs feltelepítve a Universal Toolsuite, ami az MPLAB-ba ágyazná a HI-TECH fordítót. Nézd csak meg a csatolt képen, a compile ikon teljesen máshogyan néz ki, ha hi-techet használ az ember.
Egyébként az üres main függvényt is lefordítja.
MPLAB 9.63 és HI-TECH 9.81 PRO verzió.

Hoppá, ez nekem fel sem tűnt! Szép találat!

Hát mondj még egy paramétert az "ez nem lehet véletlen" picit kevés.

A mérés egyszerű volt, elosztottam az ugyanolyan bonyolultságú probléma megoldására assembly/16F esetben fordítandó időt a C/24F idővel és az eredmény kilencmillió volt.

Egyébként azt, hogy miért nem állnak le a 16-osokkal, véletlenül tudom, mert a konferencián részletesen taglalta a fickó. A Microchip politikája, hogy 1. ha valaha valamit lehetett náluk kapni, abból mindig lehet rendelni (ciki is lenne, ha le akarnál gyártani valamiből ami már készen van még tízezer darabot és akkor jönnél rá, hogy hoppá, nem kapható az alkatrész) 2. az új fejlesztések mindig egy picit olcsóbbak (persze lábszám és szilikon felület arányában, de az egyértelmű, hogy azonos képességek mindig egy picit kisebb szilikonra férnek, bocs, szilícium.)
A fejlesztések pedig azért vannak, hogy ha már valaki úgyis a 16F-et használja, akkor legalább választhasson valami kompatibilis eszközt, ami technológiailag picit fejlettebb (pl. nanoWatt), esetleg egy kicsivel többet is tud. De azért a 16 bitesek adják most a mainstreamet és jóval több fejlesztés van rajtuk. Gondolok az USB-re meg a grafikus izékre. Az sem véletlen, hogy a dsPICek is 16 bitesek.

A kőkorszakért elnézést kérek és visszavonom. Átfogalmazva így hangzik: nem az a baj, hogy a szakik 8 bitest használnak (habár azt sem értem, hogy ha már 8 bites, akkor miért nem 18F, amikor lábkompatibilis, mégis sokkal többet tud és van értelme cében programozni), hanem az, hogy a szakik ráerőltetik a 16F-et az új generációra, miközben pont ugyanannyi energiát igényel bevágni az assemblyt meg az interruptokat készség szinten, mint biztonságosan használni a stacket, a kernelt, stb.

Egyébként ebben a Microchip is hibás. Miközben egyre élesebben elválik a hardver és a szoftver már mikrokontroller szinten is (nagyon sok helyen a beágyazott fejlesztőnek már nem feltétlenül kell tudnia nyákot tervezni), a Microchip példaprogramok még mindig tele vannak state machine-ekkel, ami hát finoman szólva a funkcionális programozás megb*szása. És akkor hol vannak még az objektumok.

Mindamellett számoljunk csak egy picit: 16 bites kontroller, dupla annyi utasítást végez el órajelenként. Az utasítások 90%-a paraméterezhető úgy, hogyaszondja "végezd el ezt a műveletet a WRegXáltal mutatott memóriacímhez képest ennyivel odébb lévő adaton", vessük össze ezt azzal, hogy (oké, hát ez Intel, de azért a Microchip 8 bitesekre is igaz valamelyest) "vágjuk be az első operandust az akkumulátorba, majd a másodikat is, utána pedig végezzük el a műveletet és az eredményt szedjük ki amonnan." Gyönyörűen látszik, hogy a 16 bites gépi kód negyedakkora és ráadásul nem kell tudni az összes trükköket, nem kell vért izzadni, az assemblyt úgyis összehozza a delikvens, amikor kernelt csinál magának. De legalább csak akkor és egyébként nem.

Reméljük így már nála is fordulni fog!

Bocs hogy belevau itt a "nagyok" vitajaba. Van sok olyan alkalmazas amire elegendo egy 6-8 labas uC. Ez viszont nincs csak a 16-os (konkretan 10Fxxx, 12Fxxx) sorozatban. Csinalni kell egy 10x10 mm teruleten valami intelligens cuccot. Ide azert a 24-es sorozat nem igen fer be. a 10Fxxx viszont van 6 labasban, a 12Fxxx 8 labasban. Ez is lehet egy fontos fejlesztesi szempont. Ezekre is lehet fejleszteni "C" nyelven, ha akarsz. De gyorsan teli lehet irni ASM-ben is. Szoval szep es jo a 16 bites amig az asztalodon programozgatsz egy probapanelt, de a valos vilagban ugye nem csak ezert dolgozunk, valamibol meg kell elni, el kell adni a termeket. Na ide viszont sokszor jobbak a kis labszamu 8 bitesek.
Csa Vili

Igy mar vilagos



24H/dsPIC-et nem gyartanak kis labszamban, sot 18F-eket sem, igy sok alkalmazasnal ez hatrany lehet. Amugy legjobb tudasom szerint a legolcsobb 16 bites is $1 felett van (5k feletti vasarlas eseten is), mig nagyon sok 8 bites cucc alatta -- igy gyartasi koltsegeket is meg lehet takaritani. Fejlesztesi koltsegek megtakaritasara pedig kilencmillio kis kinai fejlesztot alkalmaznak igy a raforditando ido ugyanannyi Amugy HiTech vagy ByteCraft forditokkal nem hiszem, hogy sok kulonbseg lenne fejlesztesi idoben. De vannak olyanok is akik sajat macro assembler pre-processorral segitik a fejleszteseiket kiterjedt tamogatoi konyvtarral (sajat USB stack assemblyben stb -- embedinc akikre most gondolok)

De vissza terva az arra: Pl a 10F sorozat mar 39 centert elerheto, SOT23-6 tokozasban. Ezt nehez lesz uberelniuk, es nincs is sok ertelme, hiszen sok LED vezerloben, kapcsolo uzemu tapokban, de akar motor vezerlesben is lehet hasznalni. Sot! Anno egy ket csatornas digitalis szurot epitettem vele alacsony frekis jelekre... semmi sem lehetetlen.

Elektronikai karakterisztikaban meg nem volt idom ossze hasonlitani, csak egy gyors pillantast vetve ket adatlapra: 16 bites (24F04KA201) 4MHz-es orajel mellett 3mA-t eszik, mig egy 8 bites (16F690) 420uA-t. Lehet feluletes voltam, es valamit elneztem, vagy ez akkor van ha minden modul be van kapcsolva, szoval itt jol esne egy kiegeszites! Mindenesetre a megnovekedett szamitasi igeny miatt logikusnak tunik nekem a magasabb fogyasztas.

Itt amator korokben viszont mas szempontok azok amik miatt a 8 biteseket javasoljuk:

- Sok meglevo project 8 bites eszkozokon alapszik

- Ez pedig nemcsak az utanepitest de annak tovabb fejleszteset is magaval vonzza, tehat nemcsak HEX beegetesi siznten kell ismerni az eszkozoket

- Meglevo tamogatoi konyvtarak

- Meglevo pedlaprogramok

- Meglevo tudas -- pl kitol lehet megtudni, hogy a C fordito miert nem megy MPLAB alatt...

- 3rd party alkalmazasok

- Rendelkezesre allo fejlesztoi eszkozok -- nem mindenkinek van itt RealICE-a viszont hobby szinten a PicKit2 vagy annak klonja nagyon is elerheto, de akar egy ICD2 vagy ICD3 is

Roviden ezek jutottak eszembe.

Igen, 24F-ben 14 láb a minimum és ez az oka annak, hogy (még) nem váltottam 32 bitre, ahol meg 64.
Azért majd ha egyszer véletlenül olyan alkalmazásból kell megélned, amihez 10x10 milliméteren meg kell hajtani egy kijelzőt, szólj nyugodtan, szívesen segítek.

Nem tudom elérni, hogy úgy nézzen ki.

Próbáltam a legújabb mblab-al(MPLAB X IDE beta6.00.01). Az eredmény siralmas.

Pedig letöltöttem hozzá mindent(hi-tech). és telepítettem is.

Oké, hát persze, ha valakinek x alkatrészre van szüksége, azzal dehogy akarok vitatkozni. Ez vonatkozik a .hex beégetés szintjére is, meg egy csomó minden másra.

Ami az órajelet illeti, azért ne feledjük, hogy nem feltétlenül az órajel számít, hanem a teljesítmény és azon belül sem csak az elvégzett műveletek száma, hanem az, hogy egy komplex feladathoz mennyi erőforrásra van szükség és e tekintetben verik a 24F-ek az összes többit, arról nem beszélve, hogy nem mindegy, hogy 5V-on hajtod a kontrollert, vagy 1.8-on. Ezeket figyelembe véve már nem olyan vészesek azok a mikroamperek.

Egyébként már 18F-re tökéletesen működik az a kernel, ahol a szálak mindig szavaznak, hogy tőlük lehet-e menni aludni, vagy sem. Kedvenc 18F26K20-asom egy szilikonba öntve egy CR2032-es elemről tökéletesen fut kettő éve, ott van a polcon. A termék ez: http://versbab.kibu.hu/ Egy négyzetcenti. Oké, most már ennek a projektnek se futnék neki 24F alatt.

Ami pedig a real ICE-t illeti, azon kissé meg vagyok lepődve, pár éve mintha feleennyibe került volna, talán lehet, hogy tévedek. De egyébként ugyanúgy ICSP és szuper kompatibilis az ICD2-vel és az ICD3-mal, sokszor megesik, hogy ha olyasmit kell debuggolnom amin kettő kontroller van, az egyik Real ICE pécéről, a másik pedig ICD2 laptopról, hibátlanul megy.

Figyu, dehogy akarok én elmenni itt anyázásba, csak azt szerettem volna mondani, hogy ha valaki most kezd el c-ben tanulni, akkor tegye ezt legalább 16 bites architektúrán, egy pillanatra sem fogja megbánni. Ezeket egymásnak teremtette a Jóisten. Ha az assembly érdekel valakit, ahhoz pedig kimondottan nem ajánlom a 16 bitet (a rengeteg WReg miatt, ami egyébként tök jó), de még a 18F sorozatot sem (a bankolás miatt, szerintem az borzalmasan el van cseszve).

Ez így rendben?

Szedd le az egész MPLAB-ot, minden kiegészítőjével, C fordítójával stb. Utána töltsd le ezt: MPLAB_IDE_v8_70.zip
Telepíted, mennie kell!

ok köszi majd próbálkozom :worship:

csak most sietnem kell

köszi mindenkinek majd írok [/color]

Annyira azért ne rohanj, hogy a shift gombot sincs időd lenyomni...

Van egy par ilyen projektom (nemelyik 500 feletti peldanyszamban). Sok kicsi sokra megy! Es nem minden a 1M ROM, 512k RAM. 10-20 sor ASM-ben es 1-2 byte valtozoval sok minden megoldhato. Persze mar sajnos odajutunk mint a PC-vel. Nagy memoria, nagy HD, nagy sebesseg kell, mert maskepp ez nem projekt. De egy egyszeru, intelligens PWM szabalyzohoz eleg egy 12F683. Ezt is tudod "C" -ben programozni ha akarod (igaz Java-ban nem).

Maximálisan egyetértek! A tudás hiányában erőforráshoz nyúlnak a programozók!
De lehet, hogy inkább maradni kéne ebben a topicban a C fordítóknál, bármit is akarnánk vele programozni!

Én nem értelek. Miért az MPLAB X -el próbálkozol? Az teljesen más, mint a sima MPLAB. Mivel a korábban csatolt képemen egyértelműen látható, hogy működik a fordítás, így javaslom ne térjünk el MPLAB X felé. Én nem tudom mit kutyultál eddig össze-vissza, de szerintem is jobban jársz, ha az egész MPLAB-ot meg HI-TECH-et újratelepíted.
Letöltöd az MPLAB 8.63-as verzióját, valamint a HI-TECH 9.81 setupját és az Universal Toolsuit-ot. Aztán feltelepíted az MPLAB-ot, majd a HI-TECH fordítót és végül a Toolsuitot. Aztán elindítod az MPLAB-ot és a Project Wizard segítségével létrehozod a projectet, hozzáadod a main.c-t aztán ráböksz a fordításra. Ennek elvileg működnie kell. Javaslom a telepítésnél a telepítési könyvtárakon ne variálj, hagyd úgy, ahogyan a telepítő felkínálja.
Fordító és Toolsuite letöltés
Biztosan működnie kell a dolognak, mert én is 8.63-as verziót használok és kb. 3 perccel korábban töltöttem le a HI-TECH cuccokat, mint amikor a korábbi hozzászólást írtam. Egyébként az sem baj, ha a legfrissebb MPLAB-ot telepíted (8.70), azon ugyanúgy mennie kell.

Persze, hogy nem a MHz a meghatarozo, ebben tokeletesen egyet ertunk! Nekem most nincs olyan osszehasonlito tesztem ahol ugyanazt a feladatok mindket kontrollerre le lehetne futtatni es megmondani melyik a hatekonyabb. Sajnos ehhez az is hozza tartozik, hogy sok 16F de akar 18F fordito eleg bugyuta kodot general -- ettol talan a komolyabb penzes forditok ternek csak el. Szoval nem elegendo ugyanazt a C kodot mindket platformra leforditani, mert abban biztos vagyok, hogy a C fordito hatekonysaga is erosen bele jatszik. Viszont erdekes lehet egy ilyen teszt, az is, higy ha ugyanolyan sebesseg mellett vegzik feladataikat, akkor vajon mennyi ido alatt vegez ez vagy amaz...

Amugy 3.3V ill 16F eseteben 3V -ra neztem az adatokat az adatlapbol. De most nezem, hogy elneztem, nem 4MHz, hanem 4 MIPS-et neztem a 24H-nal... Ha 1 MIPS-et nezek, akkor is majdnem 700 uA-t mond az adatlap (3.3V eseten), ami joval magasabb a 8 bites eszkoznel (ott 4MHz / 1 MIPS-et 3V-on figyelembe veve). Elemben abban igazad van, hogy a MIPS valos jelentese: Meaningless Indicator of Processor Speed -- azaz Ertelmetlen Processzor Sebesseg Indikator.

En sem vitatkozni szerettem volna, csak segiteni megerteni miert vannak meg 8 bitesek a piacon. Amugy halkan jegyzem megy az enhanced midrange core-t 8 bites) is C kodos kornyezetre fejlesztettek ki

Tenyleg, miert emlegetsz 'kernel-t' mindig? RTOS-t szoktal hasznalni?

Vagy inkább tudás hiányában nem használják ki az erőforrásokat a programozók, hm?

Van itt egy 24F az asztalomon, ami egyszerre hajt egy 320x240 TFT-t (igaz, SSD1926-on keresztül, de az újabbakhoz már az sem kell), ugyanakkor USB-s kapacitív touch-ot, hőnyomtatót, érmefelismerőt, GPRS modemet, 802.15.24-et, 2db. NFC olvasót és persze egy marék GPIO-t, meg analóg inputot.

Szerintem is maradjunk a C fordítóknál, de ne csak az assembly alternatívájaként, hanem nézzük meg, hogy mi mindent lehet velük megcsinálni. Bizonyos tulajdonságaik pedig nem fognak kijönni 18F alatt, ez tény.