Fórum témák
» Több friss téma |
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
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.
Optimalizálva:
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. Idézet: 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. „A C18 -ban kikapcsolható, így jóval hatékonyabb kódot generál.”
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.
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! 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. É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? „Más típusok fordítóinak tulajdonságát nem kellene agy PIC -es topikban felhozni példának.”
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!
 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.
(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.
Ill. használja a kedvenc kontrollerét, CPU -jót és írjon posztokat abba a témába....
Idézet: 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. „ezért nem értem miért támadsz!” Idézet: 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. „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.”
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
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
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
GP3 nál tiltottad a reset funkcióját?
A hozzászólás módosítva: 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ó.
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.
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!
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
Ü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.
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.
Szia Sasmadár! Köszi a segítséget! Kipróbáltam mindkét define beállítást, de eredménytelenül.
Szia! A mellékelt project beállítással próbáltam, működik Proteus-ban ezzel a kóddal:
Mekkora a tápfeszültség? BOR engedélyezve van.
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
Szia Hp41C! Köszönöm a segítséget! A táp 5V-ra van beállítva, a BOR engedélyezve van.
Ü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
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? |
Bejelentkezés
Hirdetés |
