Lehet segédváltozó nélkül is, csak akkor két helyen lesz RCREG olvasás:

A frame error esetén az érkezett karakter azért lehet fontos, mert pl. ha frame error van, és az RCREG == 0, akkor egy BREAK jelet érzékeltünk, és azt is lehet mondjuk szinkronizálásra használni. Az azért lehet jó, mert nagyon nem zavarérzékeny (tehát én a '*' karakter helyett inkább a BREAK-et használnám erre).

Így nem jó?

Így nem jó. Az FERR addig valid, amíg ki nem olvastad az RCREG-et. Utána már a következő karakterre vonatkozik.

Aha! Erre nem gondoltam, köszi!

Azt értem, hogy a tömörség a szépsége a példakódodnak, de igazából ha OERR, vagy FERR hibánk van, akkor a csomagnak annyi. Van mikor nem elég a CREN törlése, mert nem kerül szinkronba a vétel. Ha ezt is le akarjuk kezelni, akkor eléggé bel kell rondítani a letisztult képbe.

Igen, ezt írtam lentebb is, hogy hiba esetén a legközelebbi szinkronig mindent el kell dobni. Az végülis egy extra bit/flag, plusz egy if a jó byte-ok feldolgozása elé.
Egyébként a lenti kód inkább pszeudo-kód (azaz algoritmus, kódban megfogalmazva), mint közvetlenül felhasználható kód akart leni.

Nekem a (void)RCREG; volt új, még nem láttam így használni. Ilyenkor hová kerül a tartalom? (meg kéne néznem, mire fordul, de most lusta vagyok... )
Azért megnéztem, fura, a C18 nem fordít semmit oda! ?

A levesbe. Mondjuk az XC8 simán ugyanezt teszi az "RCREG;" utasítás hatására is. A (void) arra szolgál, hogy ne pampogjon a fordító, hogy az utasítás nem csinál semmit. Ha pl. egy értékadást elgépelsz, és az x = 0; helyett x == 0; lesz a kódban, arra illik panaszkodnia, hiszen annak semmi értelme nincsen.

Kéne neki, bár őt sose használtam.

C18:

WREG = RCREG;


(void)RCEG;

Szia! Akkor jól láttam, hogy nem fordít oda semmit? Vagy nem veszek észre valamit?

Az nem furcsa, hogy két sort fordít a WREG = RCREG-re? Nem lenne elég a MOVF RCREG,W?

Értem, de melyik assembly utasítás a leves?
Biztosan a WREG-be kéne nyomnia, ha nyomja, de nem látok ilyen kódrészletet a listában. Hp41C által felrakott lista második részében sem. És hibát sem ad a fordító...

"megy a levesbe" = "megy a kukába", esetünkben a kiolvasott byte-ot el kéne dobnia a kódnak.
Az XC8 ezt csinálja belőle (valami 16F18xx-re fordított kód volt, épp ezt találtam egy gyors grep-pel):

A C18 - ahogy lentebb szerepelt - teljesen kioptimalizálja a kódot. Remélem, legalább warningot ad mellé...

Jól látod, a C18 a (void)RCREG -re nem jelez hibát, nem ad figyelmeztetést, de legalább nem fordít semmit sem. Vagyis kioptimalizálja.
A WREG kezelése ugyanúgy megy, minha egy változó lenne. A return (WREG) biztos, ami biztos befordít egy movf WREG,w, ACCESS -t.

Optimalizál ax XC8? A Hi-Tech benne hagyja...

Úgy tűnik ezt nem szabad használni a C18-ban.
A teszt=RCREG sornál nem értem minek fordít be egy NOP-ot...

A movff 4 byte -os, a második szó, a paraméter, aminek a felső 4 bitje 1. Visszafordításkor az is nop.

Értem én, hogy kidobja, de binárisan ezt nem lehet ilyen egyszerűen elintézni. Esetünkben ha W-be olvassa, majd utána nem csinálna vele semmit, az megfelelne a kidobásnak. A baj az, hogy csak hasonlót látok a kódokban. Ezt egy sorral el lehetne intézni, de a fordító mindig két sorral terheli meg a szűk memóriánkat.

Most, hogy mondod, már nekem is leesett. Elfelejtettem, hogy vannak kétszavasak... Köszi!
De a MOVF x,W egyszavas és pont azt csinálná, amit a WREG=RCREG-el akarnánk.

Hát ilyen a C és a többi... Akkor is eltesz az értéket, ha el kellene dobni. Lehet másként is csinálni (char dummy; dummy = WREG; ), de az még hosszabb.

Ez valamennyire biztosan, mert nulla optimalizációval teljes mértékben használhatatlan. Na, megnéztem, "--opt=all,+asm,-asmfile,+speed,-space,-debug,9" van a Makefile-ban, gondolom ezzel fordított utoljára.

Azért ez erős lenne a C-ben sűrűn használni, csak azért, hogy tömör, gyors programunk fordítódjon.

Üdv!

Tudja valaki, hogy xc8 fordítóval az mplab X miért nem fogadja el a __delay_ms() utasítást, ha egyszer benn van a header fileok között a pic.h?

Másik kérdés.
Meg tudom oldani valahogy, hogy a portok bitjeit tömbbe rakjam?
Az a baj, hogy konstanst vár a tömbelemeknél. Próbáltam #define-al is úgysem sikerült.

Keresd meg a delay.h vagy hasonló nevű headert, és nézd meg abban, hogy vannak a delay függvények.

Azt tudom fejből is, hogy abban ciklusokkal számol, delayktcy meg hasonlók, de a ms-os meg benne van a pic.h-ban. Végül is mindegy, jó a ciklusos is. A portbitek tömbökbe rendezésére nem tudsz valamit?

Esetleg ha megfogalmaznád pontosan, hogy mit szeretnél, mert annak, amit leírtál, nincs túl sok értelme.

Ok. Elnézést, ha nem voltam egyértelmű.
Van 8 darab bemeneti pin, több porton. És van 8 darab kimeneti pinem szintén összevissza több porton.
pl valami ilyet szerettem volna:
unsigned char input[8]={PORTAbits.RA3,PORTCbits.RC1.......}
unsigned char output[8]={PORTAbits.RA2,PORTCbits.RC4.......}

Azért, hogy utána ciklusban könyebb egyen kezelni ne kelljen ezer IF-et irni.

Közben megtaláltam a választ, hogy ez így nem működik. lásd:pinarray

Az 5-ös pont leírja mit tehetek.
Esetleg egyéb ötlet?

A C nyelv nem a kényelemről szól. Továbbá mikrokontrolleres környezetben (ez itt súlyosbító tényező) a C nyelvben nem mindegy, hogy mit írsz le - mivel a fordító a leírt kód alapján készíti el az assembly kódot. A mikrokontroller teljesítménye erősen korlátozott, ha ugyanazt a feladatot 10 utasítás helyett 200 utasítással csinálod meg, akkor simán lehet, hogy már nem lesz elég gyors a kívánt feladatra. Ez az, ami miatt nem mindegy, hogy mit írsz le. Sajnos a mikrokontrollerre C-ben fejlesztésnél az a legfőbb meló, hogy rávedd a C fordítót, hogy minél jobb assembly kódot generáljon az adott feladathoz. Persze ehhez tisztában kell lenni azzal, hogy kb. mi a jó assembly kód - és úgy szerkeszteni a C kódot, hogy az legyen belőle, amit szeretnénk.
Az adott feladatra: ha engem kérdezel, alapból úgy kell bekötni a biteket, hogy minél egyszerűbben lehessen őket összerakni (azaz NEM össze-vissza hozzárendelni a lábakhoz). Másrészt inkább egy marék if, minthogy 10x lassabban fusson a kód.

Igen, sajnos tudom, hogy a uC korlátozza a lehetőségeket, de úgy gondoltam, hogy az adott feladatra elég lesz. Nem kell egyebet csinálnia, mint 8 bemeneten figyelni a gombokat és ki-be kapcsonli a hozzájuk rendelt kimenetet. Szerencsétlenségemre elég macerás 1 portra gyüjteni a biteket a nyák miatt. Így is elég kacifántos lett a körülötte levő cuccoktól. Na mind1, akkor megírom a marék if-et, esetleg egy részét switch-case szerkezettel, vagy ha időm engedi nekiesek assemblyben kigyötröm magamból a kódot, csak ugyebár a lusta állatfaj, ezért keresi az egyszerűséget. (igaz, villanyosmérnök lennék vagy mifene) Esetleg a uC-t is lecserélhetném, hogy át tudjam variálni a nyákot, de nem vagyok benne biztos, el akarok még szórakozni vele 3-4 napot.
Mindenesetre köszönöm a véleményed.

If (vagy más feltételes elágazás) nélkül elég nehéz lenne gombot kezelni, bármilyen struktúrát hozol létre! A port bitjére pedig közvetlenül lehet hivatkozni, amit BCF, BSF, illetve BTFSS, BTFSC-re fordít a fordító, jó esetben! Esetleg maszkolni lehet a portot, ha több bitet egyidőben kell váltani, igaz ez is csak egy porthoz tartozó bitekkel lehet megcsinálni, mert ez fizikai kapcsolat, nem csak logikai.
De ez semmiképpen nem az a feladat, amit egyszerűbbé lehetne tenni azzal, ha a port bitjeire egy tömb elemeként tudnál hivatkozni, még ha lehetne akkor sem.