efiscp kollega irta a CCS C vitaban, mely szerint csak ezt hasznalta. Akkor most hogyan is van ez?

Áprilisban még nem használtam, de azóta áttértem rá (az is elég motiváló volt, hogy a CCS nem barátja a PIC32-nek).

Mármint az xc-t nem használtam még áprilisban na.
Közben kicsit továbbfejlesztettem a programot, most számítógépről távvezérelve kattogtatom a reléimet, és nem fagy le a rádiós modul sem, úgyhogy hála nektek teljes a siker.

Szoval a CCS es mas C forditok is alkalmasak program irasara. De... Minden forditonak megvannak a nyugjei. En magam probaltam egy par C forditot PIC-re, de vegulis a legjobban bevalt (nekem) a CCS. A 16F sorozatra pl a HTC nem volt kezesbarany, a MikroC eleg sok kotottseggel rendelkezik, es meg a MPLAB ala sem lehet beintegralni. 18F-re probaltam a C18-at, de pl 16F887<-> 18F4620 kozotti portolas (HTC<->C18)bizony kinlodas volt. Igy maradtam a CCS-nel, mert szinte valtoztatas nelkul lehet portolni a 16F<->18F kozott. Majd ha egyszer raerek kiprobalom ezt a XC forditot.

Szia!
Én már megkínlódtam a magamét az XC8 -cal... Részletek itt. A hozzászólásban hivatkozott assembly program elkészült 16F1847, 16F1827, 16F88, 16F886 típusokra is, de csak a 16F1847 -et tudtam még átírni XC8 ra. Ugyanis a fordító nem tudja az adatokat elhelyezni a rendelkezésre álló 384 byte -ban. Az assembly program csak 348 -at használ. A memória gondokon úgy lehet segíteni, hogy majdnem vissza kell menni az assembly programozás stílusához. Az adat EEProm -ban definiált adatstruktúrák helyét a fordító szabja meg, egy 128 byte-os átkódoló táblázatom darabjait átrendezte. A leírás sorrendje csak a __EEPROM_DATA makroval megadott adatatokra marad meg, a makronak csak 8 byte -ot lehet megadni (a kevesebbet kiegészíti 0 -val) - így nem lehet a C kódból hivatkozni az EEProm -ban definiált adatokra, csak ha még egyszer megadjuk a címeket.

Akkor marad a CCS. Ebben legalabb kezben tudom tartani a memoriakezelest.

Ennyire irányíthatatlanok ezek az új XC fordítók?
C18-cal és MPASM-el sose volt ilyen problémám, még keverve se. A linker szkriptben szépen megadhatók a régiók és mind a kettővel hivatkozhatok rá. Amit egymás mellé írok, az úgy is marad.

Hát ez nem hangzik túl jól. Van esély arra, hogy egy későbbi verzióban ezeket rendbe rakják?

Biztosan nézted, de hátha nem, nincs véletlenül valahol egy beállítási lehetőség, ahol a memóriakezelés módját be lehet állítani? Lehet, hogy le akarták venni a felhasználó válláról a memóriakiosztás terhét, de lehet, hogy ki lehet ezt az opciót kapcsolni.

Szerintem irreális elvárás bármilyen C fordítótól, hogy a felsorolt modellek igen korlátozott méretű, és össze-vissza darabolt memóriájába be tudja szuszakolni 80-90%-os kitöltöttséggel a változókat, automatán. Nyilván most nem az 1-2-4 byte-os változókról beszélünk, tömbökből meg úgy sem fér olyan sok el, hogy azt kézzel ne lehetne elrendezgetni.

Akkor miért fejlesztenek fordítót? Ha a 16F -eknél irrealis az elvárás, hagyjuk ki őket. A C18 fordító meg már kész volt. Akkor minek az XC8 ?

Sajnos ilyen apró változókkal sem megy neki... Egyébként a 16F1xxx -ben van folyamatos címzéssel való elérési lehetőség, ezért nem akkora kihívás a tömb kezelése sem. Nézegetem a PRO módban fordított assembly kódot (a free módét nem tudom, nem fér el a program memóriában)... És fogom a fejem... Akkor is átmeneti változóba pakolja a részeredményt, ha utána rögtön fel is használja és a továbbiakban nem kell ez az érték. A változóimat szépen elhelyezte, de ezek miatt az átmeneti változók miatt nem fér el a memóriában. Most szépen szedegetem szét a C stílusú kifejezéseket elemi lépésekre. Már több, mit 64 byte átmeneti változót sikerült kiirtanom, mellesleg a program is rövidült vagy 1/2 k -t. Csak a végére érjek a két hónapig ingyenes PRO mód lejárta előtt. Utánna már a 8K program memória is kevés a feladathoz. Megéri-e a free mód négyszeres kód mérete, az összetettebb műveletek kézzel történő optimalizálása, a nagyobb méretű kontroller használata vagy a PRO mód megvásárlása az XC8 -ra való áttérést?
Remélem más is kipróbálja és közzé teszi a véleményét...

A C18 egész jó fordító. Ha az ember a saját kütyükéit fejleszti a jól bevált uC-kkel, maga írja a függvényeit, akkor csak önszívatás az áttérés.
Ez nem is olyan rossz: C18 optimization disable: 1000 word, enable all: 785 word.
Ugyanez a PICKit3-mal. Akad egy, soha nem használtam, biztonsági tartalék, ha a watt-féle PK2 meghibásodik.

Egy kis elméleti problém van. Lebegőpontos adatokat (32 bites) olvask ki egy processzorral, melyet átalakítás után vezetnék egy Digital/Analog konverterre. A gondom az, hogy a DAC binárisan számolva lineárisan emeli a kimeneti feszültségét az Uref és a felbontás adta lépcsőben. Tehát pl: h'0000' esetén 0V, h'0001' esetén mondjuk 60 uV, h'0002' esetén 120 uV, stb.
Hogyan tudom ezt az átkódolást 16 bites DAC megoldani, ha azt tudom, hogy a float adat decimálisan 0...200 között van, felbontása 0.1?
Jó volna ha assembly megoldást tudnátok javasolni!

Ha a 200-at a DAC maximális értékére (65535) akarod leképezni, akkor az R = 65535/200 tényezővel kell beszorozni a beolvasott lebegőpontos számot, s azt kell a DAC-ra kiküldeni (egészre kerekítve).

Lebegopontost megszozod tizzel. Igy kapsz EGESZ, 0-2000 koze eso szamot, nevezzuk X-nek.

Mivel a 16 bites DAC max 65535 lehet, mondjuk kb 66000, igy X-et megszorzod 33-al (vagy 32-vel, ha nem szabad tulcsordulni).

Ha viszont NAGYON pontosan kell, akkor 65535/2000 a szamod, ami 32.7675, egy tort.
Akkor egyszeruen X-et megszorzod 327675-el es elosztod tizezerrel. Ennek az egeszresze lesz a kivant PONTOS ertek.

storno.

Köszönöm mindkettőtök válaszát! Közben rájöttem a float szorzás/osztás nem lehetetlen művelet. Úgy fogok eljárni, hogy a szorzó/osztó számokat konstansként felveszem mint float értéket. (4 byte hely) Az eredmény is floatban lesz. Ezt pedig lehet kerekíteni egészre,

Sziasztok!

Mitől lesz egy regiszter(RCVAL) restricted (memory)? És hogyan tudnék hozzá férni?

Hosszas küzdelem erdménye:
XC8:
- Még mindig nem tudom irányítani a EEPRom -ban foglalt adatstruktúrák elhelyezését... Áttértem az "ömlesztett" __EEPROM_DATA() megoldásra. Sajnos nagy a tévesztés lehetősége, mert a kezdőcímeket külön kell megadni.
- Már csak 940 utasítást és 24 byte RAM -ot kellene felszabadítanom, hogy beférjek a 16F1827 -be, aminek az assembly megoldás csak 70..75% programtárát és 90% RAM -ját használja ki.

C18:
- Itt sem találtam megoldást a szimbólumot tartalmazó szekció kezdőcímre...

Az az érdekes számomra, hogy a használatában teljesen megegyező ALRMVAL regisztert normálisan jeleniti meg a watch ablak.

Szia!
A C18 tényleg jobb... Rajta is sokat segít, ha újragondoljuk az utasításokat. Egy 18F2550 -re írt program optimalizálás nélkül 12k utasítás, optimalizációval kb. 8k -ra tudtam levinni. A bonyolultabb utasításokat átírva (a disassembly listát nézve), most már 7500 utasításnál tartok.

Az XC8 fordító a 16F1459 miatt került elő, az USB HID eszközt nem szerettem volna assemblyben leprogramozni. Az eredeti verzió (az ami 8k -ra fért el a 18F2550 -en, de kivettem belőle az UART kiszolgálását) nem fért el a 16F1459 -ben pro optimalizálással (8k utasítás). Az utasításokat és a függvények paraméterezését átírva, ma már kb. 800 utasítás hely van benne... Más C kifelyezések kiértékelése hoz jelentősebb kódot, mint a C18 -nál, és minduntalan átmeneti változókat használ.

Egy kicsit off téma, de a bináris aritmetika és a PIC kapcsán itt teszem fel.
A lebegőpontos ábrázolást érem, a mantissziák szorzását végzem, a rejtett 1 est is figyelembe véve.
Decimálisan a következő számokat szoroztam:
20 000 X 3,27675 = 65535

A szorzót és a szorzandó lebegőpontos ábrázolásban a következő:
Ebben segít az online konverter is

20 000 lebegőpontosan:
01000110 10011100 01000000 00000000
mantissza rejtett 1 el:
10011100 01000000 00000000

3,27675 lebegőpontosan:
01000000 01010001 10110110 01000110
mantissza rejtett 1 el:
11010001 10110110 01000110

A bináris szorzatra azt várom, hogy hexaban 'FFFF' lesz, mivel decimálisan számolva a 20 000 * 3,27675 = 65 535.

Számomra meglepő módon a szorzatban a kettedesponttól jobbra is keletkeznek bitek, mutatva, hogy van tört része is az eredménynek. Ez miért van? Azért érdekes, mert a 65535/20000 pontosan (és nem végtelen tizedestört alakban) 3,27675.
Itt valami nincs rendben, tudtok segíteni?

Szervusz!
Mert a 20 000 nem írható le pontosan bináris alapú lebegőpontos számként!
A float 0b01000110100111000100000000000000 = 19999,9995904 = (16384*1,2207031)

Kiegészítés: 32 bitesben nem, de 64 bites floatba már leírható 16384*1,220703125=20 000, de PIC esetében ez már tényleg luxus.

Na ezt most nem értem. Végeredményben azt hittem értem a dolgot, de úgy tűnik mégsem.
Nézzük a 20000 -et.

floatban:
01000110 10011100 01000000 00000000

kitevő:
10001101 vagyis 141. Ebből lejön 127, így 14 lesz az eltolás.

Mantissza rejtett egyessel:
1.0011100 01000000 00000000

Az eltolást is figyelembe véve:
10011100 0100000.0 00000000

Szerintem ez pedig pontosan 20000.
Hol rontom el?

Megj:
Binárisból való átszámításban segít ez is.

Szia!

Nem a 20000 -rel van a baj, hanem a 3,27675 -tel. A megadott float reprezentáció a 3.276750087738037109375 számhoz tartozik.

Te most a csak a mantisszákat szoroztad össze, mint integer számokat?

Igen.

Ezt benéztem...