Fórum témák

» Több friss téma
Fórum » PIC programozása C nyelven, C-Compiler
Lapozás: OK   141 / 153
(#) Hp41C válasza killbill hozzászólására (») Szept 23, 2018 /
 
Sokan mégis ezt használják...
(#) Hp41C válasza Hp41C hozzászólására (») Szept 23, 2018 /
 
C18 User's Guide:
Idézet:
„Integer Promotions
ISO mandates that all arithmetic be performed at int precision or greater. By default, MPLAB C18 will perform arithmetic at the size of the largest operand, even if both operands are smaller than an int. The ISO mandated behavior can be instated via the -Oi command-line option.”


De minek is fárasztjuk itt magunkat. Az u_n_i_o_n -os megoldásban nincs típuskonverzió, nem kell fölöslegesen a PORTC értékét 16 bitre konvertálni, azon 16 bitesen elvégezni a logikai és műveletet, 16 bitesen léptetni majd 16 bites logikai vagy kapcsolatot képezni a PORTB értékével. Az u_n_i_o_n -os megoldás négy darab byte -os adatmozgatást és egy 8 bites és műveletet hajt csak végre.

De Te is érted, én is értem, sőt én javasoltam a használatát is....
A hozzászólás módosítva: Szept 23, 2018
(#) rolandgw válasza Hp41C hozzászólására (») Szept 23, 2018 /
 
Idézet:
„Az u_n_i_o_n -os megoldás négy darab byte -os adatmozgatást és egy 8 bites és műveletet hajt csak végre.”

A jó C fordító is így oldja meg az eredeti sort, csak a végeredmény is jó. Persze más az architektúra, de MC ez is.
  1. 53:     uint16_t valtozo =  ((PORTC & 0b11) << 8) | PORTB;
  2. 000000D0 88.b1                IN R24,0x08               In from I/O location
  3. 000000D1 83.70                ANDI R24,0x03             Logical AND with immediate
  4. 000000D2 90.e0                LDI R25,0x00              Load immediate
  5. 000000D3 98.2f                MOV R25,R24               Copy register
  6. 000000D4 88.27                CLR R24           Clear Register
  7. 000000D5 25.b1                IN R18,0x05               In from I/O location
  8. 000000D6 82.2b                OR R24,R18                Logical OR

Optimalizálva:
  1. 000000A5 28.b1                IN R18,0x08               In from I/O location
  2. 000000A6 85.b1                IN R24,0x05               In from I/O location
  3. 000000A7 23.70                ANDI R18,0x03             Logical AND with immediate
  4. 000000A8 90.e0                LDI R25,0x00              Load immediate
  5. 000000A9 92.2b                OR R25,R18                Logical OR
(#) Hp41C válasza rolandgw hozzászólására (») Szept 23, 2018 /
 
Idézet:
„A jó C fordító is így oldja meg az eredeti sort, csak a végeredmény is jó. Persze más az architektúra, de MC ez is.”

Az XC fordító szériában nem lehet kikapcsolni, hogy az int -nél kisebb méretű adatokat ne konvertálja int -é és ne int méretű műveleteket végezzen. A C18 -ban kikapcsolható, így jóval hatékonyabb kódot generál.

Adott egy kis programtáras Midrange kontroller amiben használhánk egy néhány elemű tömböt. Az index számításánál int -et értelmetlen lenne használni. tomb[2 * a + 4]
Ha egz 16, 32 bites kontrollert használok, ahol nem szorít annyira a programtár, nyugodtan számolhat ilyen esetben is int -ekkel.
(#) killbill válasza Hp41C hozzászólására (») Szept 23, 2018 /
 
Idézet:
„A C18 -ban kikapcsolható, így jóval hatékonyabb kódot generál.”
Attól nem hatékonyabb a kód, hogy nem tartja be a C szabályokat. Ugyanis egy rendes fordító sem fog felesleges shift-elést, egyebet befordítani, ha az a végeredmény szempontjából nem szükséges. De, ha valaki C-ben programozik, akkor elvárja, hogy a PORTC << 8, az ne 0 legyen. Az AVR gcc sem fog 16 bites műveletet fordítani abból, ha egy 8 bites változót and-olsz 0x10-zel. De, ha előbb shift-eled balra 8 bittel, akkor azt fogja csinálni, amit a C nyelv mond. Szóval ez csak rossz duma a mikrocsipp részéről, nem pedig optimálisabb kód. Attól, hogy sokan használják, még nem jó. Lásd vindóz, vhs, mp3, stb... Annyi szól a mikrocsipp mellett, hogy ilyen gyenge architektúrára nehéz lenne normális C fordítót írni. Nem is tudnak. Nekem csak az a bajom, hogy ennek ellenére C-nek hívják.
(#) Hp41C válasza killbill hozzászólására (») Szept 23, 2018 /
 
Sajnos egyikünknek sincs ráhatása, hogy milyen C fordítót készít/készített a Microchip. Más típusok fordítóinak tulajdonságát nem kellene agy PIC -es topikban felhozni példának. A fenti példák egy C18 -as fordítóval készült kódból valók (-Oi nélkül). Nem látok benne 8 léptetéses ciklust, csak átmeneti változó felhasználását, amit egyébként a "más Microchip termék" fordítójában, az optimalizált is verzióban is látok.
Idézet:
„Attól, hogy sokan használják, még nem jó.”

Nos ebben igazad van, de nincs jobb C fordító a PIC -ekhez.

Addig is, az általam leírt megoldás elkerül minden számítást, rövid és hatékony.
Aki akarja, használhatja, akinek nem tetszik, csinálja úgy, ahogy jól esik neki.
Ezennel befejezem.
(#) oregharcos válasza oregharcos hozzászólására (») Szept 23, 2018 /
 
Szia Mate_x!
Hamar volt az örömöm. Az van, hogy a compiler hiba nélkül lefordítja, de ha berakom a proteusba akkor a nyomógombot nem kezeli, mintha ott sem lenne, villog indítás nélkül. Arra gondoltam, hogy talán a config nem jól van beállítva, próbáltam állítgatni de nem kezeli a nyg-ot. Azt is próbáltam, hogy átrakom a gombot a GP2-re, ez sem jött be. Most tanácstalan vagyok, hogy merre tovább? Ha van ötleted, ötletek, nagyon megköszönöm a segítséget!
(#) killbill válasza Hp41C hozzászólására (») Szept 24, 2018 /
 
Idézet:
„Más típusok fordítóinak tulajdonságát nem kellene agy PIC -es topikban felhozni példának.”
Lehet, hogy itt van közöttünk a félreértés, mert én meg pont úgy gondolom, hogy egy C fordító az legyen C fordító, függetlenül attól, hogy milyen processzorra fordít. És ennek elemi része, hogy jól értse a C nyelvet és ne fordítson felesleges kódot. Én nem vitattam az általad adott megoldás hatékonyságát egy pillanatig sem. Bár, arra azért pusztán szakmailag kíváncsi lennék, hogy a két byte-ot miért nem egymás melletti címekre tette le? Mert ugye az uni_on-os megoldásnak éppen ez lenne a lényege. Vagy ő megteheti, hogy egy 16 bites int az nem két szomszédos byte-on van a memóriában?
(#) Wezuv válasza killbill hozzászólására (») Szept 24, 2018 /
 
Nem értem miért Hp41C-t vegzálod, teljesen világos és elfogadható az álláspontja, ahogyan a tiéd is, csak a két álláspont nem egymás ellentéte ezért nem értem miért támadsz! A C fordítója az MC-nek ilyen, ezt kell szeretni. Ha problémának látod, hogy bitorolja a C fordító titulust, írj nekik, vagy jeletsd fel őket!
(#) Hp41C válasza killbill hozzászólására (») Szept 24, 2018 /
 
Idézet:
„Lehet, hogy itt van közöttünk a félreértés, mert én meg pont úgy gondolom, hogy egy C fordító az legyen C fordító, függetlenül attól, hogy milyen processzorra fordít.”

Igazad van, de mit kezdjek pl. egy ARM kóddal, ha PIC16F628-re kellene fordítanom egy projektet.
Idézet:
„Bár, arra azért pusztán szakmailag kíváncsi lennék, hogy a két byte-ot miért nem egymás melletti címekre tette le?”

A változók a main eljárás lokális változói, így őket ez a "nem_C" fordító indirekten éri el.
Még egyszer.
  1. 510:               INT_VAL valtozo;
  2.     511:               valtozo.bytes.LB = PORTB;
  3.       2032    5081     MOVF 0xf81, W, ACCESS                 ;;; PORTB
  4.       2034    6EDF     MOVWF 0xfdf, ACCESS                   ;;; INDF2
  5.     512:               valtozo.bytes.HB = PORTC & 0b11;
  6.       2036    0E03     MOVLW 0x3
  7.       2038    1482     ANDWF 0xf82, W, ACCESS            ;;; PORTC
  8.       203A    6EE7     MOVWF 0xfe7, ACCESS                ;;; INDF1

(Mert én vettem a fáradságot és beírtam, lefordítottam, kiértékeltem....)
Összegezve:
Az eredeti kérdés az volt, hogy az u_n_i_o_n -os megoldás miért rövidebb. A válasz az, hogy nem végez számítást. Továbbá ez a megoldás kiterjeszthető nagyobb szóhosszúságra is: 32 vagy 64 bitre is. (((Ott már megint előjönne, hogy az adott kontrolleren/CPU -n mekkora is a C fordító int típusa....)))
Örülök, hogy visszatértél, de már rég eltávolodtunk a kérdéstől.
(#) Hp41C válasza Wezuv hozzászólására (») Szept 24, 2018 /
 
Ill. használja a kedvenc kontrollerét, CPU -jót és írjon posztokat abba a témába....
(#) killbill válasza Wezuv hozzászólására (») Szept 24, 2018 /
 
Idézet:
„ezért nem értem miért támadsz!”
Valamit nagyon félreértesz, ugyanis én nem támadok. A fordítóval van a bajom, nem Hp41C-vel. És nem is veled. A mikrocsippel, a mikrocsip slendrián hozzáállásával, a hazug és erőszakos marketingjükkel van bajom, és ha valaki azt állítja, hogy ez jó, vagy azt, hogy ezt kell szeretni, akkor ezzel vitába szállok. Ha csak 1 ember is belátja, hogy az MC-nél vannak sokkal jobb alternatívák, akkor már megérte. Nem azért használnak az emberek PIC-et, mert ezt szeretik, hanem azért, mert ezt ismerik. Ha megismernek mást, talán jobb lesz nekik.
(#) killbill válasza Hp41C hozzászólására (») Szept 24, 2018 /
 
Idézet:
„A változók a main eljárás lokális változói, így őket ez a "nem_C" fordító indirekten éri el.
Még egyszer.”
Tehat a 0xfe7 és 0xfdf címek nem a változó címei, hanem az INDF1 és 2 regisztereké. Így már értem. Én vettem a fáradtságot, hogy elolvassam a fenti disassembly listát, csak nem olvastam el a PIC dokumentációt, hogy melyik címen milyen regiszter van, mert feltételeztem, hogy egy szimbólikus disassembler 2018-ban az alapvető regisztereket névvel írja ki és nem csak a címet. De igazad van, teljesen feleslegesen vitatkozom veled, mert ettől a fordító vagy a MC nem lesz más, és aki ezt akarja használni, vagy ezt kell használnia, az marad ennél. Bocsánatot kérek mindenkitől, hogy ezzel a vitával off-oltam a topic-ot.
(#) usane válasza killbill hozzászólására (») Szept 24, 2018 /
 
Szerintem nem kell bocsánatot kérned, nem vitatkoztál senki álláspontjával MC-t kivéve.
Én is azért kérdeztem meg Hp41C-t hogy is van ez, én is PC-n tanultam rendes C fordítóval anno és nem értettem mi miért jó vagy nem jó a fentebb említettek közül. Igaz az XC8-at mér régóta a pokolba kívánom, de jelenleg ezzel kell dolgoznom, mert van amikor meglevő MC által írt kódot kell beillesztenem, és még így is egyszerűbb mint azokat C18-ra átírni. Az is igaz, hogy magamtól is megírhatnám őket, de erre sajnos mostanában nincs időm, örülök ha azzal végzek amivel kell.

Mindenki nevében köszönük a részletes magyarázatokat.
A hozzászólás módosítva: Szept 24, 2018
(#) Wezuv válasza killbill hozzászólására (») Szept 24, 2018 /
 
Nincs is semmi baj, csak nekem kicsit ez az érzésem volt. Amúgy jó olvasni az ilyen vitákat, mert rengeteg magas szintű szakmai tartalom van benne, ami mindkettőtöket minősíti. A hitvita viszont messzire vezetne, mert szerintem minden gyártónak megvannak a maga hibái. Az MC használható, rengeteg projectben megbízhatóan működnek, amit a részemről el tudok mondani. Hogy van jobb is? Biztos. A Suzuki-nál is talán jobb a Merci... (biztosan, egyébként ???)
A hozzászólás módosítva: Szept 24, 2018
(#) oregharcos válasza mate_x hozzászólására (») Szept 25, 2018 /
 
Szia Mate_x, üdv Mindenkinek!
Megcsináltam az általad javasolt változásokat. Addig eljutottam, hogy nem áll ki hibára a compiler, de a nyomógombot nem kezeli, berakom a proteusba és már indul minden gombnyomás nélkül. Akármit állítok az ANSEL és a CMCON-on nem hajlandó észrevenni, hogy van egy nyomógomb. Próbáltam a CONFIG-ot is állítgatni, de eredménytelenül. Ez a kis program simán megy PIC16F84-el és PIC16F877A-val, csak a PIC12F675-el nem. A CCS C compiler is rendesen kezeli a 675-t, nyomógombbal lehet indítani. Azért szerettem volna a microC PRO for PIC v6.0-val megcsinálni, mert nagyon sok jó tutorial van hozzá. Egyáltalán meglehet csinálni, hogy működjön ezzel a compilerrel? Minden segítséget előre is nagyon köszönök!
A hozzászólás módosítva: Szept 25, 2018
(#) Elektro.on válasza oregharcos hozzászólására (») Szept 25, 2018 /
 
GP3 nál tiltottad a reset funkcióját?
A hozzászólás módosítva: Szept 25, 2018
(#) oregharcos válasza Elektro.on hozzászólására (») Szept 25, 2018 /
 
Szia Elektro.on! Köszönöm a bejegyzést! Kínomban próbáltam, tiltottam és engedélyeztem, de változatlanul nem jó.
(#) Elektro.on válasza oregharcos hozzászólására (») Szept 25, 2018 /
 
Azt hiszem megtaláltam a hibádat!
A feltéteses elágazásodnál a ! = helyett != kellene.
Van benne neked egy space a két karakter közt. Valószínű , hogy valami bug miatt nem reklamál, de ezt így hibásan dolgozza fel.
(#) oregharcos válasza Elektro.on hozzászólására (») Szept 26, 2018 /
 
Szia Elektro.on! Köszönöm a segítséget! Nálam nincs szóköz a"!" és "=" jel között, lehet, hogy a itt fórumnál úgy látszik. Kipróbáltam szóközzel és nem fogadta el. Fogalmam sincs, hogy mi a baja. Azért köszi a jó szándékot!
(#) usane válasza oregharcos hozzászólására (») Szept 26, 2018 /
 
Felhúztad azt a GP3-at a proteuszban tápra 10k ellenállással? A másik meg, hogy ez így nemcsak gombnyomásra indul, de csak a gombot nyomva tartva működik.
A hozzászólás módosítva: Szept 26, 2018
(#) Sasmadár válasza oregharcos hozzászólására (») Szept 26, 2018 /
 
Üdv!
#define nyg GPIO.GP3 vagy #define nyg GP3_Bit nálam 7-es fordítóval, Proteus-ban működik.
Proteus-ban kézzel kell beállítani (legalábbis nálam) a Program Configuration Word-öt.
(#) oregharcos válasza usane hozzászólására (») Szept 27, 2018 /
 
Szia Usane! Köszönöm a segítséget! Fel van húzva a GP3, Igaz, hogy addig megy amíg nyomjuk, de már annak is örülnék ha nyomógombra indulna.
(#) oregharcos válasza Sasmadár hozzászólására (») Szept 27, 2018 /
 
Szia Sasmadár! Köszi a segítséget! Kipróbáltam mindkét define beállítást, de eredménytelenül.
(#) Sasmadár válasza oregharcos hozzászólására (») Szept 28, 2018 /
 
Szia! A mellékelt project beállítással próbáltam, működik Proteus-ban ezzel a kóddal:
  1. //Egyszerű villogó PIC12F675-el gombnyomásra indul.
  2.   //a programot mikroC PRO for PIC v:6.00-val készítettem.
  3.  
  4. //#define nyg GP3_Bit
  5. #define nyg GPIO.GP3
  6.  
  7.  void main()
  8.   {
  9.     GPIO = 0;
  10.     TRISIO = 0b00001000;
  11.     CMCON = 0b00000111;
  12.     ANSEL = 0;
  13.  
  14.     while (1)
  15.       {
  16.         if(nyg != 1)
  17.           {
  18.             GPIO = 0b00000001;
  19.             Delay_ms (500);
  20.             GPIO = 0b00000000;
  21.             Delay_ms (500);
  22.           }
  23.       }
  24.   }

PIC12F675.jpg
    
(#) Hp41C válasza oregharcos hozzászólására (») Szept 28, 2018 /
 
Mekkora a tápfeszültség? BOR engedélyezve van.
(#) oregharcos válasza Sasmadár hozzászólására (») Szept 30, 2018 /
 
Szia Sasmadár!
Nagy öröm ért ma! Beírtam az általad átalakított kódot, és a configot is úgy állítottam be ahogy a képen van, és működi! Nagyon-nagyon köszönöm a segítségedet! Most már léphetek tovább a gombkezeléssel.
A hozzászólás módosítva: Szept 30, 2018
(#) oregharcos válasza Hp41C hozzászólására (») Szept 30, 2018 /
 
Szia Hp41C! Köszönöm a segítséget! A táp 5V-ra van beállítva, a BOR engedélyezve van.
(#) oregharcos hozzászólása Okt 22, 2018 /
 
Üdv. Mindenkinek! A youtube-on van egy nagyon jó tutorial a PIC programozása C-nyelven, "microC PRO for PIC v. 6.0.0" compilerrel. Nagyon jól magyarázza a srác, kép a képben lehet látni az eredményt is. Ha valaki C-ben akar megtanulni programozni, arra kiváló tutorial. Érdemes megnézni!
itt van a film
(#) lóri hozzászólása Nov 21, 2018 /
 
Sziasztok!
Amint olvasgatom, nem jók ezek a fordítók. Meg kéne tanulnom programozni, de akkor miben?
Nekem jobban tetszik az assembly, de a főnököm c párti. Mit csináljak?
Következő: »»   141 / 153
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem