Szimulátorban építek még.

Sikerült megtalálnom a hibát. Most már megy az általad javasolt módszerrel. Nem mellesleg elképesztően gyors. Szeretném érteni is. Elmagyaráznád ezt a részt? for (i = 2147483648; i; i>>= 1)
Pl. a >>= mit jelent? A feltétel ,hogy lehet csak annyi ,hogy i?

Előre is köszi!

Az i>>=1 az ugyanaz rövidebben, mint az i=i>>1, vagyis egy hellyel jobbra lépteti i-t, ami ugyanaz, mintha kettővel osztanád.

C-ben alapvetően az összehasonlítást végző műveletek is ugyanolyan műveletek, mint pl. a szorzás, vagyis eredményt adnak vissza. És minden feltétel számára az a lényeg, hogy a feltételben szereplő kifejezés eredménye nulla, vagy nem nulla. Ha leírsz egy olyat, hogy if (x==5), akkor az (x==5) mint kifejezés kiértékelődik, és az értéke nem nulla (akármennyi lehet, fordítótól is függ, hogy konkrétan mennyi lesz, a lényeg, hogy nullától különbözik), ha az x értéke 5, illetve az értéke nulla, ha az x nem 5. Az if számára pedig csak az a lényeg, hogy nulla vagy nem nulla, ami ott áll. Pl. csinálhatsz olyat is, hogy y=(x==5), ez teljesen legális C-ben. Így a jelen esetben szereplő ciklus is addig ismétlődik, amíg az i értéke nem nulla. Az pedig akkor lesz nulla, ha a jobbra léptetések végén az egyes bit kiléptetődik. Teljesen ekvivalens lenne azt írni, hogy i!=0, vagy ebben a konkrét esetben akár i>0-t is lehetne (mivel az i unsigned típusú, tehát csak pozitív lehet), a fordító vélhetően ugyanazt fordítaná mindhárom verzióból. De alapvetően C programozók egyszerűen csak i-t írnak ilyen esetben, hiszen az is teljesen megfelelő.

Köszönöm a bő választ, így már világos. Sőt! Fogom a fejem ,hogy ez nekem nem jutott eszembe.

Halihó, abban kérném a segítségeteket, hogy 18F2520-al hogy tudnám mérni 4-6 bemenet jelének a periódusidejét párhuzamosan?

Mekkora frekit/periódusidőt, milyen pontossággal szeretnél mérni?

Az attól függ, hogy mekkora frekvenciájúak azok a jelek és mekkora az elvárt pontosság.

Nem néztem meg, de gondolom össze lehet legózni hat darab megszakításra alkalmas bemenetet, timerrel lehet mérni az időt, kérdés csak az, hogy elég lesz-e az így összehozott pontosság, vagy olyan pic(ek) kell(enek), amiben van több hardveres CCP modul?

Elég pontosnak kellene lennie, ha pl a periódusidő egy előre beállított szint alá esik, akkor kellene jeleznie a készüléknek. Én is azon agyaltam, hogy több CCP modulos PIC-et használok.

Nem lehetne számszerűsíteni a megkívánt pontosságot? Nagyon nem mindegy, hogy 1 us vagy 1 ms a tűréshatár! A frekvencia is érdekes, mert nagyobb frekvenciák esetén nem a periódusidő mérése, hanem a periódusok számlálása adott ideig ad pontosabb eredményt.

Sziasztok.

Tud-e valaki segiteni?
Szóval akarok írni egy olyan függvényt amivel HD44780-asLCD-re akarok szöveget irni,csak nem tudom hogy lehet a függvénynek stringet átadni.
kod:
ez mőűködik de nem igy szeretném

Ez sana nem jó:


de igy szeretném ami nem megy:


Valahol azt olvastam hogy a C-s függvénynek csak pointert lehet átadni paraméternek ,de már láttam olyan függvényt ahol stringet adtak át paraméternek (igaz mikroC-volt)ugy hogy akkor biztos van valami megoldás ,de egyenlöre nem találom .Remélem elmondtam mindent és valamennyire érthető voltan.
Előre is köszi.

Sziasztok!
Ujabb problémába akadtam:
Mindig ezt dobja az MPLAB:
*** Error 71 "temp_ds18b20_7.c" Line 1144(0,1): Out of ROM, A segment or the program is too large SETUP_KEPERNYO
Seg 00800-00FFF, 05B7 left, need 007E6
Seg 01000-017FF, 0800 left, need 00802
Seg 01800-01FFF, 0800 left, need 00802
Seg 00000-00003, 0000 left, need 00802
Seg 00004-00030, 0000 left, need 00802
Seg 00031-007FF, 022C left, need 00802
Seg 00800-00FFF, 05B7 left, need 00802
Ha kitörlök egy sort bárhonnan akkor pedig lefordul igy:
Memory usage: ROM=62% RAM=22% - 31%

Nem értem mi lehet a gond?
A ROM az bizti nem fogyhat el ,akkor a SETUP_KEPERNYO függvényem mérete lehet nagy?
Mekkora lehet maximálisan egy függvény mérete? Eddig még ilyen gondom nem volt ,igaz ASM-ben firkálgattam .Nagyon örülnék ha valaki utba tudna igazitani hogy merre keressem a hibát.
Elöre is köszi.

Szia!
Ha ez egy 16F, akkor a 0x802 és a 0x7E6 utasítás hosszú függvényeket fel kellene darabolni.

Hu... ezt hogy is lehet csinálni?Hogy találom meg ezeket a hosszu fuggvényeket esetleg a disassembly listában vagy hol keressem?

Ránézel a forráskódra és keress egy több oldalas függvényt első körben...

Ok . Amiért a forditó pofázik az kb 40 sor ,de több függvényt is meghiv ami ujból függvényeket hiv (ez egy több szintü MENU-szerkezet)ezeket gondolom nem egy függvényként kezeli vagy ez is lehet probléma?
Main()
-SETUP_KEPERNYO()
-MANUAL_PRINT()
MENU_AUTO()
...LCD_PRINT_TEXT()...write_lcd()

Szia!
Egy kis assembly tapasztalattal egyből beugrana, hogy a 16F 2k -s program memória lapokkal dolgozik (0x800 utasítás). A C fordító nem kezeli, hogy egy függvény nagyobb, mint egy programmmemória lap.

Hu... pont ezért kezdtem C-vel foglalkozni mert 2 K fölött kicsit zürös az assembly.
Ha függvényből függvényt hívok azt egynek fordítja ?

Az is lehet, hogy sok string van abban a függvényben, mert az is kóddá fordul, aztán ki tudja, hogy van-e annyi esze a fordítónak, hogy azt külön is rakhatja.

Hogy tudok röviditeni egy függvényt?Kisebb komponensekre bontom és azokat külön függvénybe rakom amiket azután meghívok az eredetiből?Ez igy járható,vagy ez igy egy függvénynek fordul le és akkor nem csináltam semmit?

Itt már többen írták, hogy túl hosszú kódokat írsz.
Megpróbálhatod a #separate direktívát, ami egy szűz blokkba teszi a hosszú függvényedet.

Én nem emlékszem az előzményekre, de ha már csak 40 sornyi az a függvény, amivel problémázik, akkor megmutathatnád azt a függvényt és akkor többet tudunk mondani. Általánosságban igen, külön függvénynek fordul, az ami külön függvényként van létrehozva.


És pont a CCS-t kellett választani az asm után?

Szia!
A #separate sem tudja a 2K -nál nagyobb függvényt egy 2k -s lapra tenni...

A sokszor ismétlődő részeiből egy másik függvényt csinálsz és csak hívogatod megfelelő paraméterekkel. Egy elszeparálható részéből csinálsz egy másik függvényt. A switch - case struktúrákat if-then-else -re cseréled (nem használ ugrótáblát). Esetleg áttérsz egy lábkompatibilis és feszültségkompatibilis 18F -re. (Az assembly 2 -szer.. 4 -szer (a free XC8 esetében 12 -szer)) rövidebb kódot eredményezne.

Itt a "csodálatos" kód:
Ezzel a függvénnyel van gondja a fordítónak



Melyiket ajánlod mert a CCSC-t csak azért választottam mert a help-je az könnyen emészthető volt ,de ugy érzem hogy kellene váltanom ?

Igy próbáltam röviditeni de lehet hogy a switch-case lehet a probléma mert van benne bőven ,maj átírom este a kodot. Ez biztos igy van mert korábban csináltam hasonló projit ASM-be és az elfért 2K -ban csak amikor bővíteni akartam az már nem fért bele és 2K-ba fölött a 16F ASM-ben az

Első körben szedd ki a float változókat és a sok printf LCD-t. Látni fogod, hogy drasztikusan lecsökken a méret. Innentől kezdve már tudni fogod, hogy mi az ami ekkora részt foglal le.

Ez igaz, de ha már közösködni kell a blokkban más függvényekkel, akkor még kisebb az esélye annak, hogy elfér.
Abban meg Vicsys-nek van igaza, hogy a printf fügvvényhívással spórolni kell, mert az nagyon brutál tud lenni.

Nem tűnik bonyolultnak a függvényed, de biztosan lehet egyszerűsíteni.
Én bátorítalak a CCS használatára, mert nagyon kényelmes, jól kitalált és elég hatékony ahhoz, hogy amateur szinten csodákat lehessen vele művelni.
Az XC8 esetében egyszerűen nem igaz, hogy 12x rövidebb kódot generál, pláne nem a nagyon gyengén optimalizáló free verzióval ami még búgos is mellette. Az is elgondolkoztató, hogy assemblyben 4x rövidebb a kód, de XC8 esetén még ennél is harmadával kevesebb.
Légvonalban 3 km, de tudok egy rövidebb utat az erdőn át esete.
Höhö...

Tényleg jobban jársz egy lábkompatibilis 18Fxxx példánnyal. Tisztább, szárazabb érzés és sok nyűgtől megszabadulsz.

Teljesen félreértve.
A jereváni rádió jut eszembe: Tegnapi hírünk "Leningrádban Mercédeszket osztogatnak." nem teljesen igaz. Nem Leningrádban, hanem Moszkvában, nem Mercédeszeket, hanem Moszkvicsokat és nem osztogatnak, hanem fosztogatnak. Különben a hír igaz."

Ha az assembly elfér 1K -ban, akkor ugyan az az algoritmus átírva free XC8 -re 12k lenne, a full optimalizálással készült kód (995$) csak 3k... Kiróbálva, leméreve, az XC8 uninstallálva...

Biztos vagyok benne, hogy lehet ilyen példakódot írni, de azért nekem jobb tapasztalatom van az XC8-al. Free verziót használom most egy projekthez, kapott kódméret 7k utasítás körül van. Próbára megnéztem, mit tud a 45 napos demó, 4.x k lett a kódméret. Maradok az ingyenes verziónál, mert még a C kódon is tudnék optimalizálni, ha nagyon akarnék, de a 8k kódmemóriába belefér most is, így egyelőre nem foglalkozok vele, van most fontosabb dolgom. Persze nem kételkedek, hogy bele lehetne nyomni az egészet egy 4k kódmemóriás chipbe is, de ilyen kis sorozatnál nem éri meg a ráfordított időt a kettő közötti árkülönbség...