A deklaráció és a használat ellentmondásban vannak. A set_out_(p) hívásra mit kellene csinálnia?

A preprocesszor első körben behelyettesíti a set_out makróba a pld. B,0-t, a második körben pedig az így kapott argumentumot már a set_out_ makró kapja meg. Az összekonkatenálja a megfelelő konstannssá, és miután mindenhol végzett a behelyettesítéssel, lefordítja.

A nyílt forrású Small Device C Compiler ( SDCC ) legújabb előzetes kiadása ( RC1 ) már letölthető a SourceForge oldaláról.
A Microchip PIC16F1xxx ( Enhanced core ) eszközök támogatása is belekerült az újítások közé.
Bővebben az SDCC wiki oldalán.

Szia
Én C18-at használok, a TCP/IP stack miatt, nagy ritkán meg HI TECh C-t. Meg tudnád mondani nekem, mint laikusnak, hogy megérné-e áttérnem erre a C-re és miért,

Én leginkább hitech c-t használok vagy assemblyt. Pascalban is dolgoztam PIC-en és ott sem volt olyan hajmeresztő. Ez milyen fejlesztőkörnyezet? Mennyire használható mennyire tér el a hitech c-től?

Erre a kérdésre csak te tudhatod a választ. Én nem tudom, hogy neked megérné-e. Én azért szeretem ezt használni, mert teljesen átlátható. Nagyon jó assembly listát készít, amiből néha még ötletet is tudok meríteni.
Másrészről úgy gondolom, hogy az igazi jövő a szabad szoftvereké. Itt nincs olyan veszély, hogy illegálisan használsz valamit. Ez egy szabad szoftver.

Szerintem aki HiTech C-t vagy hasonlót használ, annak nehezebb az átállás. Én elsősorban azoknak merem ajánlani, akik hobby szinten akarnak C-t használni. A befektetés legfeljebb a megtanulására fordított idő, pénzbe ugyanis az SDCC nem kerül. A tapasztalatom az, hogy a HiTech fordítójához képest sokkal szigorúbb. Ez persze csak egy nagyon rövid idejű tapasztalat, mert a fejlesztéseim zömét SDCC-vel ( illetve assemblyben ) csinálom. Példának említeném ezt, ami ugye nem egy bonyolult eset. Eltérésként amit említenék, hogy a regiszterek bitszintű eléréséhez a Hitech a REGbits.bit kifejezést használja, ami a 18F sorozat esetén egyezik az SDCC jelöléssel, viszont a 16F sorozatnál bekerült egy alsó vonal, tehát REG_bits.bit. Ezt a különbségtételt nem értetem az SDCC-ben. Én remélem, hogy majd egységesítik valamikor. A csipbe épített eepromhoz a HiTechben vannak gyári függvények/makrók. Az SDCC esetén ezeket a rutinokat magadnak kell megírni.
A HiTech-es kitérőm a fejlett magvas 16F sorozat miatt történt, de már ezt a hiányt is orvosolták a fejlesztők.
A fejlesztői környezet ugyanaz a megszokott, amit valószínűleg jelenleg is használsz. Az MPlab és az MPlabX egyaránt működik vele. Én Linuxon a PikLab nevű programot használom.

Hogyan sikerült beizzítani MPLAB alá az SDCC-t? Én kb. egy éve kísérleteztem vele, de sehogy sem akart működni...

Mplabbal nem próbálkoztam, de az MPlabX alatt nem volt különösebb nehézség.

Hát én is próbáltam beintegrálni de nem akart menni esetleg egy pontosabb leírást tudnál adni mert a képet nem tudom megnyitni. Amúgy nézegettem azt a kijelzős programot semmi különösebb bonyolultság nincsen benne szerintem a HITECH c- hez képest legalábbis szerintem. Egész jónak tűnik és lehet hogy ki is próbálom.

Először is a Tools menüben ki kell választani az Options lehetőséget.
A megjelenő ablakon az Embedded ikont kell választani.
Azon a lapon pedig jobb alsó szélen van egy olyan gomb, hogy Scan for Build Tools. Nálam ez megtalálta az SDCC-t.
Az OK után, ha mindent bezártam és egy új projeket indítok, ott már a valahanyadik lépésnél választható lesz az SDCC is.
7.12-es változat van telepítve nálam.

Az SDCC-MPLAB integrálásához...
Ki még nem próbáltam ugyan, hogy hogyan működik, de a telepítéssel nem volt gond és a Language tools menüben meg is jelent az SDCC opció.
Hosszas keresgélés után ezen az oldalon leltem meg a szükséges plugint.
Ha kicit törni magyar az lenni google fordító.

Ha angolra fordítod, érthetőbb lesz!

Helló. Telepítettem a SDCC-t és a plugint is de a plugin beállításánál kér két fájlt az egyik gpasm a másik pedig gplnk de ezeket nem találom. Az MPLAB 8.80-at használom.

[quote]Sőt továbbra is assemblyben fogok pic-et programozni, de ezt most C-ben akarom megírni. Úgylátszik ez abban egyszerűbb...

Ezért is találták ki egyrészt a C-t gondolom, mert a bonyolultabb dolgokat egyszerűbb összehozni.

Ahhoz előbb le kell tölteni, majd telepíteni. Az SDCC-t szintúgy.
Az SDCC használatához mindenképpen szükséges a gputils ( pontosabban nem minden esetben... ), ugyanis az SDCC nem gépikódot hanem assembly listát készít. Az assemblyt szokta általában fordítani a gputils programmal, de az mpasm szintén alkalmas erre a feladatra.

Sziasztok!
Az lenne a problémám, hogy van egy 2x16 karakteres lcd-m (a használt PIC 16f874). Analóg digitál konverzió után ki kellene iratnom az eredményt decimálisan. Nincs is vele gond, csak annyi, hogy ha 100-255ig van az eredmény és utána lemegy 99-00ra akkor nem tudom mit kezdjek az első számjeggyel. Ugyanis ha minden kiiratás után letörlöm az lcd-t, akkor vibrál a képernyő. Ha meg nem törlöm le akkor meg ott marad a számjegy. Itt a forráskód.

int main(void)
{
TRISC = 0x00;
PORTC = 0x00;
vInit_a2d();
lcd_init(); //init LCD
lcd_clear(); //képernyő törlés
while(1)
{
ADGO = 1;//AD mintavételezés beindítása
while(!ADGO);//várakozás AD végére
temp =(ADRESH);
lcd_goto(0); //Első sor
sprintf (buf,"The Value :%i",temp); //egy bufferbe
lcd_puts(buf); //ki az lcdre
}

}

Egy szóközt írass ki abban a pozícióban!

Ha már sprintf akkor létezik szélesség megadó paraméter, ne vacakoljatok már manuálisan szóközökkel. És nem kell az egész lcd-t letörölni, csak a számjegyeket írd át. Lehet meglepő, de lehet mozgatni a kurzort, hogy hová írodjon az adat.

Egy meglévő számot te hogyan máskép tüntetnél el, ha nem akarsz helyette 0-t írni, mint hogy szóközt írsz oda? Erre kíváncsi vagyok!

Úgy hogy megadom az sprintf ben paraméterként a szélességet, és magától odateszi. De ez annyira alap C hogy nem is értem, hogy van aki manuálisan vacakol ilyesmivel. Nézzetek utána a printf formátum leíró sztringnek. Tud szóközt is tenni, meg vezető nullát is. http://lidi.uw.hu/krc/files/07.html#7.2.

Én mondjuk ezeket ismerem, de nem szoktam használni a printf és társait a kód mérete miatt (bár egyszer olvastam valami olyat, hogy a Hi-Tech fordító csak azt fordítja be belőle, amit muszáj). De ha már itt tényleg valóban használva van a printf, akkor előrébb kellene lépni egy kicsit és megnézni a dokumentációját, hogy mi mindent tud.

sprintf sok helyet foglal el és lassú is, emiatt szokás vacak ölni vele manuálisan.

Itt egy karakterről van szó. Én sem használom a sprintf-t. Abszolut nem érzem vacakolásnak ezt...

Persze, volt már nekem is hogy kellett írnom számkiíró rutint helyszűke miatt, de itt már használja a sprintf -et, csak nem használja ki a tudását. Hamost sprintf mellé manuálban szóközözik, na az tényleg pazarlás. Idő meg tárhely is.

Köszönöm a válaszokat. Ha már ilyen profikkal van dolgom, egy kis segítséget kérnék még. Azt kellene megcsinálnom, hogy 10 másodpercenként kiiratni az LCD-re az aktuális hőmérsékletet + az utolsó 4 mérési eredmény átlagát. A fele az már megvan, csak azon gondolkodom, hogy hogyan lehet azt megcsinálni, hogy csak az utolsó négy mérési eredményt átlagoljuk le. Talán bele kellene rakni egy tömbbe és mindig csúsztatni az értékeket(tehát a legrégebbit mindig felülírja az új). A tömb egydimenziós és négy eleme lenne. Így végül is mindig csak a legutolsó 4 lenne benne. De hogy ez jó is?

Igen, így kellene csinálni.

És a tömbök értékét hogy kell csúsztatni? Mert feltölteni OK, kiolvasni OK, de csúsztatni? Vagy egyszerűen írni kell rá egy algoritmust, hogy 3.érték=4.érték; 2.érték=3.érték;1. érték=2.érték;legújabb érték=1.érték.
Vagy van rá valami egyszerűbb is?

Minden bejövő értéknél növeled a tömbmutató értékét ( 0-3-ig megy! ) és oda tárolod le a bejövő értéket. Ez mindig az utolsó 4 mintádat fogja tárolni ( igaz nem sorrendben, de az nem kell az átlaghoz! ).

Steve