Elég buta ötletnek tartom, mert így meg a korábbi Hitech fejlesztésekkel (PIC16, PIC18) vész el a kompatibilitás.

A legjobb út arra, hogy a Microchip mikrovezérlőitől elvadítsák a felhasználókat (azért bele fog telni néhány évbe, amíg a változtatások gyermekbetegségeit elfogadható szinten ki tudják vadászni a fordítóból meg kapcsolódó állományokból...)

Meglátjuk, de nekem nem tetszik az, amikor egy jól bevált vonalat megváltoztatnak annyira, hogy majdnem előről kell kezdjél mindent. Te is tudod, hogy nem a nyelv a lényeg, hanem a környezet. Bármilyen nyelvet "egy nap alatt" meg lehet tanulni(ha már asm-ban, és C-ben programoztál már előtte), de a környezetet hónapokig, évekig tart és ha megszoktad, nagyon nehéz váltani.
(Kicsit más, de most próbálok PNA-kat WinCE-re mókolni, hát azt se tudom hová nyúljak, pedig VB-ben már programoztam keveset...)

Abban bízom kicsit titkon, hogy ez még csak release candidate verzió, talán valahogy megoldják hogy a régi szintaktikával is lehessen használni. Vagy ha nem az érdekes lesz, lehet átvariálják a 16F -es fordítót is ?

Hello!
PIC12F615 -höz irnék MPLAB-ban programot, minden tökéletesen menne, csak 1 parancsot nem fogad el mégpedig a delay-t... ilyen reakcioval :

Error [500] ; 0. undefined symbols:
_Delay_ms(XXXX.obj) _delay_ms(XXXX.obj)

include-ban meghivom a pic-et , meg a standard input output -ot biztos ami biztos.. de nem javít a dolgon.. Érdekesség hogy tegnap egy más eszköz más progi, ugyanugy előfordult benne pár delay és semmi nyögés rá.. azt simán leforditotta, kidobta hex-be és működik is.. ez meg most miért nem szerintetek?

Én nem hiszem, hogy a 16-os fordítót bántanák...

Nincs valami delay.h, amit be kellene includolni? Csak tippelem, mert én utálom a delay-eket, így sosem használtam még...

samplek között találtam egyet, meghivtam, olyan formában használom ahogy abban a delay.h -ban van most.. de ugyanaz... már kezdek kétségbe esni ..

Van olyan, aki ASM után CCS C-re tért át? Nekem egyszerűen nem megy. Eddig ASM-ben csináltam mindent, semmi gondom nem volt, csak gondoltam, hátha a 18F-ekre gyorsabb lenne a fejlesztés C-ben. (PC-n használok C-t, C++-t, szóval az nem gond). Szereztem egy CCS-t, de én egyszerűen nem bírok arra átállni, hogy nem érem el pl. a TRISA-t, hanem output() függvénnyel ***akodjak. Lehet, hogy hülyén fog hangzani, de nekem a CCS túl felhasználóbarát azzal, hogy megpróbál mindent elrejteni.
Ha jól láttam, a C18-ban van "normális" TRISA=0x00;, úgyhogy megpróbálkozom azzal. Volt más is, akinek hasonló okok miatt nem jött be a CCS, vagy ez csak az én hülyeségem?

Hali
Ra lehet venni a forditot hogy a regisztereket valtozokent lassa. Eloszoris Meg kell neki magyarazni, hogy a portokat Te akarod kezelni:Ez igaz kicsi PIC-re van, de egyforman kell a 16-asoknal is. Majd a kodban, vagy egy header fileben a kovetkezoket kell elhelyezni: Itt termeszetesen a Te altalad hasznalt IO-kat kell beirni. Majd a programban hivatkozhatsz ezekre a valtozokra: Ezeket minden regiszterre megirhatod, es maris egyszero az elet. el lehet felejteni a "felhasznalobarat " fvenyeket.
Udv Vili

Nekem is pontosan ugyanezen ok miatt nem tetszik a CCS. A C18 jó lesz, illetve az a gyári fordító, ahhoz vannak a gyári demókódok is, úgyhogy a CCS-t le is törölheted. Kisebb picekre pedig a Hi-Tech néven ismert fordító a gyári, mivel a Microchip megvette, úgyhogy azokra is felejtsd el a CCS-t.

Engem pont ez tántorított el, hogy minek gyártsak saját headereket, ha egyszer a C18-ban ott vannak gyárilag az XXXbits unionok.

Hát igen, van mondjuk 128 SFR regiszter, azokban átlagosan négy bit, akkor írni kellene 128 regisztert és 512 bitnevet. Ráadásul elírsz valamit, akkor ez elég szopás tud lenni, mire megtalálod a hibát. A fordítóhoz adott headerekben meg remélhetőleg már mások megtalálták a hibákat. Jobb lesz neked a C18, főleg így asm-es előképzettséggel. Abban is vannak mindenféle beépített függvények, de nem erőtteti a fordító a használatukat. Vagy akár megnézheted az SDCC-t is, ami ingyenes. Bár a C18 ingyenes változata is tökéletesen használható pár apró lényegtelen korlátozás mellett.

Hali
Vegulis Te tudod. En hasznalom egy par eve. En Turbo C-n kezdtem, es nekem is fura volt eloszor. De egy nagy elonye van: kis meretu kodot general. Vegulis nem szukseges hasznalni az eredeti fvenyeket. Irtam en is sajatokat, mert igy jobban tudom kezelni, es ki tudom optimalizalni meretre es sebessegre (itt fontos szempont). Peldakat viszont talasz sokat a CCS forumon.
Szerintem egy probat meger.
Udv Vili

Ha ez segít én is így tértem át(illetve az asm ettől még nem lett kidobva, sőt), de a C18-ra, eszembe sem jutott más himihumi fordítókkal bajlódni...

A CCS C kellemes tulajdonságai közé tartozik, hogy jó a dokumentációja, a kezdőnek nagy segítséget jelent a perifériák bekonfigurálását segítő "varázsló", s a beépített függvényeknek és támogatásnak köszönhetően könnyen össze lehet benne dobni egy programmegszakítást és többféle perifériát kezelő programot.

Ugyanakkor ezek (a BASIC-hez hasonlóan) el is fedik a részleteket a használó elől, s finoman szólva nem késztetik a felhasználót arra, hogy elolvassák az adatlapot.

A CCS C egyik legnagyobb hátránya, hogy az ingyenes demó nagyon korlátozott, szemben a Hitech C Lite és a C18 Student verziókkal.

A másik megfontolandó szempont: az USB keretrendszer, a TCP/IP stack, s a komolyabb (preemptív) RTOS-ok mind a Microsoft fordítóját feltételezik, s ha később az igények megkövetelik a továbblépést a PIC24 vagy PIC32 világába, akkor ugyanabból a forrásból fordíthatók hozzájuk pl. az USB alkalmazások, ami még akkor is előny, ha közben az architektúra miatt fordítót kell váltani.

Hali.

A C18-as fordító csak a 18-as sorozathoz jó vagy használható más sorozaton is?

Csak 18F-re használható a C18. 16F, 12F és 10F-re a gyári fordító a régebben Hi-Tech néven ismert fordító, ma már ez Microchip tulajdon. Ezen kívül van még a MikroC, CCS, SDCC, sourceboost, cc5x, meg még biztosan van ezeken kívül is. A 16 bites tipusokra (24F, 24H, dsPIC30, dsPIC33) a C30 gyári fordító használható. PIC32-re pedig a C32.

Értem köszönöm a választ.

Erről a kis méretű kódról van valahol összehasonlítás? Próbáltam keresni neten CCS-C18 összehasonlítást, de nem igazán láttam.

Régebben sok hozzászólásodat láttam még a Terminálon, és azt hittem, te leszel az utolsó ember a földön, aki áttér C-re

De komolyra fordítva: gyorsult a fejlesztés az áttéréssel? Vagy érzed más előnyét?

Hali
Az osszehasonltas (lehet egy kicsit santit mert a CCS oldalan van) itt talalhato: CCS. De en sokszor neztem az ASM listakat, es elegge rovid a forditas. Osszehasonlitva a tobbiekkel jelentosen rovidebb listat (es hexet) produkal. Regebben probaltam klf. forditokat, de talaltam olyat, ami egy-ket sima float szorzassal teliirta a '877et (Mikroe). Nagy elonye, hogy siman (kis javitassal) hordozhato a kodod a 10F, a 12F, a 16F es a 18F kozott ugyanabban a forditoban. En meg nem hasznaltam dsPIC-eket, sem a 24-eseket, tehat errol nem tudok nyilatkozni. Viszont a tobbit eleg sokat. Az biztos, ha belejossz igen gyorsan tudsz eredmenyesen programozni vele. Erdmes beregisztralni a CCS forumra, mert sok mintapeldat talahatsz.
Udv Vili

Most kíváncsiságból megnéztem. A lebegőpontos példára azt mondja, hogy CCS= 27.5 us, C18=60.0 us, HtC=16.88 us. Ezzel szemben nálam a C18 ideje 27.6 us....

Igaz, nem v3.21, hanem v3.22, de nem valószínű, hogy az alverziószám növelésével megduplázták volna a teljesítményt.

Persze, hogy van előnye! Matematikai műveleteknél elsősorban. Képzeld el mi meló lenne egy mérésből kapott pontokra illesztett trendből származó harmadfokú polinom eredményének kiszámítása assemblerben! Ha nem az első cél a sebesség és a kis méret, akkor sokkal egyszerűbb haladni. Például egy menürendszer, vagy egy protokol lekezelése, elágazások(case), stb.
Persze sok mindent asm jellegűen programozok C-ben is, mert ritkán használom az OPEN-t. Inkább direktben állítom a regisztereket. Persze ez nem azt jelenti, hogy aki másképp csinálja az nem jól teszi, esetleg azt, hogy ha nem működik neki valami, és nem lát az OPEN mögé, akkor neki nehéz dolga lesz.
Szóval érdemes C-be is belefolyni, ha az ASM, azaz a PIC megismerésén már túl van valaki!

Üdv
C-ben írt programot, hogy tudom visszafordítani .asm-ra ?

Nem "vissza", hanem "le"! Ez a C fordító dolga.

Van egy gyári ajánlás C-ben írva. Ezt szeretném assembly-ben látni, mert csak ezt hályogkovácsolom.
Üdv

Lefordítod, és a generált listát elolvasod, vagy MPLAB-ban a Disassembly listát megnézed. Mi a probléma?

Hogy az életbe még nem foglalkoztam C-vel és társaival.
Tehát a C-fordító tud assemlyt is generálni a C-ből ?

Általában igen, de néha titkolják ezt a képességüket....
Mellesleg a géppel lefordított kód sohasem lesz olyan, mint a "kézzel írt" assembly program, tehát nem lesz túl olvasmányos.

Köszönöm