Abból van ilyen 45 napos verzió, nem? Csinálni kell virtuális gépet, amire felrakod az MPLAB-ot, kompletten lemented a virtuális gépet, 45 naponta visszaállítod a mentésből, felrakod rá az XC8-at és ismét van 45 napig teljes verziós fordítód Persze tudom, nem épp ideális megoldás, de ha más nincs...

Szóval. Mivel ilyen szinten rabolja az értékes helyet, de fontos a c-ben akár a bonyolultság , vagy más miatt dolgoznunk, akkor kiegészítőként muszáj memóriakártyát használni?! Persze a sebességet ezzel sem szerezzük vissza. Én személy szerint a pic öszetettebb usb-s kommunikációja miatt kezdtem el. De persze nagyon az alapoknál vagyok. Még az assembly sincsen teljes szélességében kihasználva. De való igaz ha nem azzal kezdem akkor most tényleg semmit sem értenék az egészből.

A programkód esetén nem sok mindent érsz el a memóriakártyával...

Szia!
Nem ilyen egyszerű, az XCakármi minden indításánál elmegy, körülnéz a Microchip-nél, megnézi van-e állandó licenszed vagy nem járt még le a beregisztrált ingyenes időtartamod. Ha lejárt, a Free mode érhető csak el. 60 naponként új gép vagy új internet szolgáltató?? Egyébként az XC8 fordítása rendkívül lassú... Fizess, fizess, fizess alapon... (XC8 + XC16 + XC32 licensz már egy vagyon.) Ez a példa az ingyenes full optimalizálásnál is jelentezett:

1. movf  z,w
2.     movwf x
3.     movlw 0x0F
4.     andwf z,f

a

1. movf z,w
2. andlw 0x0f
3. movwf x

helyett, ami rövidebb (még akkor is, ha lapváltás is kellene), egy egyszerű Midrange is meg tudja csinálni és mellesleg jól működik...

Az előbb hülyeséget írtam. Igazából a meóriakártya csak adatokra jó. De lehet olyat, hogy saját, ami ugyan elég furcsa, de bizonyos részeit a pic maga újraírja a memóriakártyán tárolt programmal?
Szerk: Persze mindent meg lehet csinálni, de bonyolultság/haszon viszonylatban?

Ezt nem értem, a kettő nem ugyanazt csinálja szerintem ( nem csak a méret a különbség!)!
Ha jól látom az elsőnél x=z(eredeti), z=z&0x0F, míg a másodiknál x=z&0x0F , z=z(eredeti)!? Így nincs értelme összehasonlítani, mert nem ugyanaz az eredmény ( már késő van, remélem nem néztem el ! ) !?
Steve

Szerintem az első a fordító hülyesége és a 2. ahogy kellene lennie.

HP41C kolléga a Bővebben: Link hozzászólásban azt írta, hogy : az a baj, hogy ezzel nem csak a megszakítás jöhet rosszkor, hanem nem is azt csinálja!
Így, ha nem néztem el, akkor abszolút mindegy a hosszuk, mert nem egyforma a végrehajtott feladat !
Steve

Értem. Tényleg mindegy a megszakítás ha jön is, akkor is rossz a művelet.visszatérve, tényleg pofátlan a fordítóktól, hogy ennyire teli nyomják sallanggal a kódot.

Szia!
Köszönöm az észrevételt. Ennyire nem akartam rossz hírét kelteni a fordítónak, hanem valamit elírtam...
Ez lett volna a kiindulás:

Szia!
Nem gondoltam, hogy rossz hírét akarod kelteni a fordítónak, nem úgy ismertelek meg itt a fórumon... Én nem vagyok annyira benne a C-ben, bár csináltam már néhány dolgot, de úgy gondolom, hogy erre már nem figyel egyik fordító sem, hogy ha a normál ( W, STATUS, BSR PIC18 ) regisztereken kívül akarok valamivel foglalkozni a megszakításon kívül, azt ő eldöntse, hogy engedje vagy ne engedje a megszakítás kiváltását! Ha ezt akarom, akkor le kell tiltanom a megszakítás fogadást ( GIE )! Mindenesetre tanulságos eset ez is, mint egy másik topicban Potyo-é, mert az ember nem biztos, hogy alapból gondol erre ( de ha assemblerben írod, akkor Te is beszúrod a sorokat, ezért is jó szerintem assembly-vel kezdeni !) !
Steve

Szia!

Nem az okozta a problémámat, hogy a fordító eldöntheti-e, hogy belefordítsa a megszakítást tiltó és engedélyző utasításokat - tovább nyújtva feleslegesen a programot.
Hanem az, hogy nem az elvárható formát fordítja be a programba. Tegyük fel, hogy egy normál Midrange kontrollerről van sz, amiben az x és a z ráadásul kölön lapon van. A C sor így nézett ki:

Az elvárt programrészlet így nézne ki:

Hasonlítsuk össze a befordítottal:

Ezzel a kóddal két helyen is "megteremtődik" a hibás működés lehetősége... A "normál" felhasználóban a gyanú sem merül fel, hogy a fordított kód idétlensége miatt hibázik a programja.
Ez már jó kódra fordul, de újabb RAM helyeket foglal...


Szerintem egy igencsak gyakran használt számítási műveletről van szó, amit kötelesség lett volna rendesen, optimálisan megoldani.

A hibázási lehetőségeket láttam és szerintem utaltam rá én is. Az x és z külön bankban? Ezt a fordítónak tudni kell, erre eddig nem volt utalás! Mégegyszer megkérdezem, hogy tudsz-e olyan C fordítóról, ami automatikusan tiltja egy változó módosítása alatt a főprogramban a megszakítás elfogadását, ha az a változó használt a megszakítás rutinban ( úgy gondolom, hogy ilyen nincs, mert a program fordítója nem tudhatja, hogy ezek egyidőben bekövetkezhetnek-e !) ?
Steve
szerk.: nem érzem magam profinak C-ben, csak pont ezért kérdezősködöm, hogy előre felkészüljek az ilyen meglepetésekre !

Remélem, hogy nincs ilyen és szerintem nem a megszakítás letiltása a megoldás.

pl. ring bufferes UART kezelés mutatójának léptetésénél, ahol inkrementálás után meg kell vizsgálni, hogy nem kell-e visszaléptetni a tár elejére, én egy segédváltozóban végzem a számítást és csak a a végeredményt írom be. (A megszakítás csak olvassa ezt a mutatót, de kínos lenne, ha ideiglenesen rossz helyre mutatna...)

pl. hardver regiszterek matatásánál, ahol a főprogram csak bizonyos biteket matathat, miközben a megszakítás ugyanazon regiszter más bitjeit matathatja, bevált megoldás az XOR művelet alkalmazása.
#define ChangeBits(reg,val,mask) reg ^= ((reg^val) & mask)

Ha felmerül a gyanú, hogy a fordító ezt "félrefordítja" (C18-at használva eddig nem volt gondom vele), akkor assembly betétként kell megírni. PIC24-re egyszer valamelyik topikba bemásoltam egy ilyen assembly betétes makrót, amit az AVIX RTOS szerzője tett közzé a Microchip fórumán valamelyik RTOS topikban. Ott pont az volt a téma, hogy egy RTOS-t is meg lehet írni a megszakítás letiltása nélkül.

HP41C felvetésénél is problémát okoz, ha csak olvassa is, eből alakult ez a beszélgetés... A Te megoldásodnál, ha nem tiltod le közben a megszakítást, akkor mi biztosítja, hogy amikor vissza kellene tenni a mutatót az elejére, akkor nem a művelet közben jön a megszakítás ( gondolom, hogy a felépítés alapján ez nem következhet be, mert addig nem érkezhet megszakítás valamilyen okból ! )?!
Ezt én is remélem, de adott esetben nem tudok mást elképzelni, mint a megszakítás letiltása, amit viszont a programozóra kell bízni!
Steve

Tudja és helyesen kezeli a bankokat.

Úgy érzem nem értjük egymást:
Legyen u egy olyan változó, amit a megszakítás rutin is kezel.
Primitív művelet: Egy gépi utasítás, amit a megszakítás nem tud félbeszakítani, így a művelet egyben végrehajtódik. Pl: incf u,f esetén az olvasás növelés és visszaírás fázisokat a megszakítás nem tudja elválasztani egymástól.
Nem primitív művelettel is meg lehet oldani a feladatot, de a feladat elvégzésének idejáre tiltani kell a megszakítást (ahogy írod): pl. az u növelése movf u,w incf u,w movwf u csak abban az esetben működik jól, ha kiegészítjük a következőkkel (tekintsünk el attól, hogy egyes típusokban meg kell győződni, hogy a GIE bit valóban 0 -ra állt) movf INTCON,w movwf intconsave bcf INTCON,GIE movf u,w incf u,w movwf u btfsc intconsave,GIE bsf INTCON, GIE. Nem lehet bambán engedélyezni a megszakítást, hiszen akkor is hívhatták a rutint, ha épen tilva volt... Nem egyszerűbb azt a bizonyos egy utasítást használni mindig, ami minden esetben működik?

Az x = z & 0x0F; C beli sor fordítása esetén az elvárt kód (fent már idéztem movf z,w banksel x andlw 0x0F movwf x) primitív műveletet használ az x állítására. Így a C sort leíró szerző (nem a fordító) nem is gondol arra, hogy a le kellene tiltani a megszakítást. E helyett egy nem primitív művelettel megvalósított kód fordul, amit csak a fordító által írt asm állomány vizsgálatával lehet kideríteni. Hányan nézik meg, hogy egy fordító milyen assembly utasítássorozatra fordítja a C programjának sorait. Meg sem fordul a fejében... Sok-sok programot írtam már, rögtön gyanús lett, amikor nem jól működött. Az a vicc az egészben, hogy a cég más fordítója (C18) pedig jó kódot fordít a fenti sorra. Ez megkérdőjelezi a C egyetlen megmaradt előnyét: Hordozható ezek után egy C program? Vagy minden fordítóra való áttérés esetén egyesével végig kell nézni minden utasításhoz lefordított assembly sorok helyességét. Pont azért választják a C -t, mert nem szeretnének assembly -vel vesződni. Ráadásul az XC8 uniója szeretett volna lenni a HiTech Midrange és a hajdani 18F -hez írt C18 -nak. Tehát még nem is térek át más fordítóra sem, ha a 18F2550 -ről egy egyszerű programot szeretnék a 16F1459 -re portálni. Az esetemben ez törént és megdöbbenten vettem észre a következőket:
18F2550 (32kb azaz 16kw program memória) C18: a programtár felénél egy kicsit többet elfoglaló program, ami az USB mellett egy kétirányú UART kapcsolatot is képes tartani egyidőben.
16F1459 (8kw): Ugyan az a program (a kisebb kontroller miatt UART kapcsolat nélkül) full optimalizálással sem fért bele a programtárba. Az utasításokat kb. assembly szintre átírva, full optimalizálás mellett kb 2 kw -val lehetett csökkenteni a program méretét - végül belefért a kontrollerbe. Ekkor jöttek a fentihez hasonló proiblémák...

icserny:

Leírtam, hogy átmeneti változóval jól működik. De minek átmeneit változó a C szintjén, ha ott a WREG, amit úgyis használ. Az andlw 0x0F utasítás használatával megoldódna minden... Az a baj, hogy nem is gondol rá az ember, hogy nem az forítódik bele. A te esetedben a programozó "felkészül" a problémára.

XC8 Midrange fordítóról beszélünk....
Igen lehet assembly betét... Más állományban van - átláthatatlanabb a program. Külön függvényben - optimaliztálás letiltása csak rövid kódot érint. Minden esetre külön függvényt írni? Egy andlw 0x0F -nek is? Abban a függvényben, amiben kell - Az egész függvény optimalizálását letiltja egyetlen asm sor.

Nem kellene annyi pénzért "használható" fordítót adni?? A fórumukat olvastátok? Milyen gyorsan letörölték a hozzászólást, ami ecsetele ezeket a hibákat.

Készen lettem az assembyben is megírt, 32 bites távirányító értelmezésével amit lcd ír ki c.-ben. Én is már az elején hiányoltam a sublw egyszerű nagyszerűsűgét. Úgy látszik bőven nem ez a cél ehelyett ,megszámoltam 4x hosszabb ez a program. Nem vagyok nagyon paranoiás de gyanítom szándékosan bosszantják az embert, hogy a kezdő is elborzadjon hogy a 900 soros programból 30 felesleges goto. És majd akkor megy vásárolni. Persze a fentebb tárgyalt alantasabb hibát nagy öröm megtalálni de sokkalta jobb idegméreg. Ennek ellenére továbbra is gyakorlom ezt a nyelvet!

Feltettem az Mplabx-et ugyanaz a program lefordul, de nem megy. Biztosan köze van a kövezkező képnek hozzá. Kicsit idegen ez a program még.

Jöhet közben megszakítás, mert nem a kritikus változón, hanem annak egy másolatán végzem az inkrementálás, ellenőrzés és szükség esetén korrekció - nyilvánvalóan nem atomi - műveleteit. A végeredmény beírása a kritikus változóba már egyetlen lépés, azzal nincs gond.

Dehogynem!
De ezen én nem tudok változtatni (igaz, pénzt sem adtam érte...).
Én _asm _endasm közé zárt assembly betétre gondoltam, nem külön fordítási egységre.

Egy ilyen sor a függvényben az egész függvényt kizárja az optimalizálásból...

Aha, értem már, hogy mire gondoltál ( nem esett le, hogy így egy sor lesz, pedig HP41C-nél ezt kapásból értettem ) !
Steve

Szia!
Köszönöm, így már értem !
Ezt viszont nem : Itt mire gondoltál?!
Steve

Pl. ha ez a kritikus kódrészlet egy másik függvényben van, akár másik fájlban, és te a hívása előtt más okból tiltod a megszakítást, akkor miután ezt lefuttatod, engedélyezve lesznek a megszakítások, miközben te nem szeretted volna. Tehát minimum ki kell azzal egészíteni, hogy tiltás előtt megnézni, hogy mi volt a helyzet, és az engedélyezés helyén meg megnézni, hogy mi volt, és attól függően engedélyezni vagy sem.


Egyébként a volatile kulcsszó használata a váltózó létrehozásánál nem javítana itt a problémán?

OK, értem!

Steve

Üdv, megkérdezem, hátha: valakinek nincs esetleg mikrobasic-ben egy kész rotary encoder progi, amiből tudnék bogarászni, mert én nem tudom sajna megcsinálni? Köszönöm!

Szia
CCS-hez van egy működő kódom, ha az segít. Esetleg át tudnád írni.

Ok, köszönöm!

Sziasztok!
Valaki tudna nekem segíteni esetleg?

ASSEMBLY-ben tanulok pic-et programozni, de én jobban szeretnék áttérni C-re.

Most analóg bemeneteknél tartok kb, meg nyomógombnál, bit figyelésnél.

Szeretnék megkérni valakit, hogy egy programot (kompletten, csak fel kelljen égetni) írjon le nekem C-ben.
Egy szimpla ledes villogás megteszi kb. Csak látni akarom, hogyan épül fel, mit tartalmaz. Innentől meg majd megoldom a továbbiakat magamtól.
Mondjuk ezt:


digital_io:



És ezt:



Előre is köszönöm, akinek lesz egy kis ideje és türelme hozzá!

Milan Verle könyvét ebben a topikban többször is ajánlottuk.
PIC Microcontrollers - Programming in C