Fórum témák

» Több friss téma
Fórum » PIC kezdőknek
 
Témaindító: Placi84, idő: Okt 3, 2005
Témakörök:
- A PIC ÖSSZES Vdd és Vss (AVdd és AVss) (tápfeszültség) lábát be kell kötni!
- A táplábak mellé a lehető legközelebb 100nF-os KERÁMIA kondenzátorokat kell elhelyezni.
- Az MCLR lábat, 10kohm-mal fel kell húzni a Vdd tápfeszültségre.
- Külső kvarc használatakor 4MHz-ig XT, a fölött pedig HS konfigurációt kell beállítani.
- Stabilizált tápegységet kell használni, a kapcsoló üzemű "telefon töltő" adapterek okozhatnak hibákat.
- Programozáshoz, használj lehetőleg PICKIT2 vagy 3 programozót. Kerülendő a JDM (soros porti) programozó.
- A PIC adatlapja (PDF), tartalmazza a lábak kiosztását és a PIC minden paraméterét. Az adatlap ingyen letölthető!
- Egyes PIC típusoknál az RA4 nyitott nyelőelektródás (Csak lefelé húz L szintre, H szintet nem ad ki!)
- Ha a PGM lábat digitális ki-/bemenetnek használod, az alacsony feszültségű programozási lehetőséget le kell tiltani.
Lapozás: OK   707 / 1210
(#) morzsa15 válasza kissi hozzászólására (») Okt 10, 2015 /
 
Pontosabban esetleg meg tudnád mondani? Mert nem értem ott hol a hiba?
(#) zenetom válasza morzsa15 hozzászólására (») Okt 10, 2015 /
 
  1. if(temp_value>temp_max) temp_value == temp_max ;

Helyett:
  1. if(temp_value>temp_max) temp_value = temp_max ;

Az == logikai (összehasonlító), míg az = értékadó operátor.
(#) morzsa15 válasza zenetom hozzászólására (») Okt 10, 2015 /
 
Sajnos így sem jó ugyan úgy változik az érték.
A hozzászólás módosítva: Okt 10, 2015
(#) zenetom válasza (Felhasználó 15355) hozzászólására (») Okt 10, 2015 /
 
Na, ez van, mikor valaki (én) nem olvassa el amit ír.
morzsa5!
Próbáld meg így:
  1. if(temp_value>temp_max) {
  2. temp_max = temp_value
  3. }


Ez jellemző, az ilyenek miatt kaptam/kapom a suliban is a rossz jegyeket..
A hozzászólás módosítva: Okt 10, 2015
(#) Pali79 válasza rolandgw hozzászólására (») Okt 10, 2015 /
 
Javíts ki ha tévednék, de a 2-3ezer sor már nem hobbi kategória, gondolom te sem kedvtelésből írsz ilyen programokat.
(#) morzsa15 válasza zenetom hozzászólására (») Okt 10, 2015 /
 
Semmi ugyan úgy változik nem zavarja hogy a maximum értéket kellene neki kiírnia..
(#) zenetom válasza morzsa15 hozzászólására (») Okt 10, 2015 /
 
A gombra reagál, míg nyomod? Bemásolnád a módosított do - while részt?
(#) morzsa15 válasza zenetom hozzászólására (») Okt 10, 2015 /
 
Reagál de mindig az adott értéket írja ki.

  1. do {
  2.     //--- perform temperature reading
  3.     Ow_Reset(&PORTB, 0);      // Onewire reset signal
  4.     Ow_Write(&PORTB, 0, 0xCC);   // Issue command SKIP_ROM
  5.     Ow_Write(&PORTB, 0, 0x44);   // Issue command CONVERT_T
  6.     Delay_ms(600);
  7.     // If this delay is less than 500ms, you will see the first reading on LCD
  8.     //85C which is (if you remember from my article on DS1820)
  9.     //a power-on-reset value.
  10.  
  11.     Ow_Reset(&PORTB, 0);
  12.     Ow_Write(&PORTB, 0, 0xCC);    // Issue command SKIP_ROM
  13.     Ow_Write(&PORTB, 0, 0xBE);    // Issue command READ_SCRATCHPAD
  14.  
  15.     // Read Byte 0 from Scratchpad
  16.     temp_value =  Ow_Read(&PORTB, 0);
  17.     // Then read Byte 1 from Scratchpad and shift 8 bit left and add the Byte 0
  18.     temp_value = (Ow_Read(&PORTB, 0) << 8) + temp_value;
  19.  
  20.     //--- Format and display result on Lcd
  21.     Display_Temperature(temp_value);
  22.      if(temp_value>temp_max) {
  23.       temp_max = temp_value;
  24.        }
  25.  
  26.            /// Gomb
  27.  
  28.         if(PORTB.RB3 == 0){  //if push button is pressed
  29.         Lcd_Out(1, 3, "Maximum:    ");
  30.         Lcd_Chr(2,12, temp_max);   //Maximum
  31.         Lcd_Chr(2,12,'C');
  32.  
  33.        /*wait till button released as press of a buttons take time  and processor is too fast */
  34.         }
  35.         else{
  36.        Lcd_Out(1, 3, "Homerseklet:    ");
  37.        Lcd_Chr(2,12,'C');
  38.        Lcd_Chr(2,12,'C');
  39.         };
  40.     } while (1);
  41.  
  42.   }
(#) Hp41C válasza Pali79 hozzászólására (») Okt 10, 2015 /
 
Idézet:
„Javíts ki ha tévednék, de a 2-3 ezer sor már nem hobbi kategória...”

Assembly -ből 2000 sorral még egy 16F628 sem lesz tele...
Egy komolyabb program pl. 16F886 megtöltéséhez - a kommenteket is beleszámítva - 8000 sornál több kell. Az alábbi képen egy hobbiból készült és még néhány adat incule állomány nincs is hozzászámítva. Egyenlőre még átlátom...
(#) Attila86 válasza Hp41C hozzászólására (») Okt 10, 2015 /
 
Én eddig egy programomat írtam meg assembly-ben és C-ben is, mégpedig a legelső C programomat. Assemblyben 7652 bájt lett, C-ben, az XC8 fordító 1.33 verziójával, free módban 12674 bájt. A két program pontosan ugyan azt csinálja, semmi különbség nincs bennük azt leszámítva persze hogy másik nyelven íródtak.
Ugyan ennek a programomnak egy későbbi változata az 1.20 verziójú XC8-al free módban 18646 bájt, PRO módban 9066 bájt. Az 1.33-as XC8-al free módban 15932 bájt. (Az 1.33-hoz sajnos nincs okosításom hogy PRO-ban fordítson.)
Szóval szerintem annyira nem vészes a különbség, legalábbis én eddig nem tapasztaltam ilyesmit.

De szerintem nem is ez a lényeg. Hanem az hogy ez a program négy év masszív assembly programozási gyakorlattal két és fél hét alatt készült el, C-ben pedig megírtam mindössze 4 nap alatt úgy hogy közben tanulgattam csak a C-t és az MPLABX-et. Ma már egy délután kényelmesen, maximum 2-3 óra alatt meg tudnám írni. Az idő szerintem sokkal fontosabb tényező, mert az pénzbe kerül. Persze a nagyobb memóriájú mikrovezérlő is, de az mondjuk 700Ft helyett lesz 1300Ft, a munkadíj-különbség viszont nagyságrendekkel jelentősebb. Persze hogyha valamiből sok tízezer példány készül ott már valószínűleg a munkadíj fog eltörpülni az anyagköltséghez képest de talán hobbi szinten nem erről van szó. Minek dolgozzak egy X összegért hetekig hogyha egy délután alatt is végezhetek vele?!
Önmagában szerintem az nem gond hogyha egy program nagyobb, akár duplája vagy többszöröse annak mint ami egy ügyesebb kéz alatt lehetne. Belefér a PIC-be vagy sem? Ez a fontos, meg persze hogy ellássa a kívánt feladatát. Ha ezek megvannak onnan senkit nem zavar hogy kisebb is lehetne a kód.
Ma már PIC-ekből az 512kB memóriájúak teljesen normálisnak tekinthetőek, abba aztán szinte minden belefér.

Na meg egy talán még fontosabb érv, hogy assembly programnál az ember korlátozva van az adott mikrovezérlőtípus-családra. Sajnos én is belefutottam már ebbe, hogy írtam egy programot assemblyben egy 18F-es típusra mely 84137 bájt lett(!!!). Másfél évig programoztam melyből egy évig csak ezzel foglalkoztam a szabadidőm és a munkaidőm bő 90%-ában. Iszonyatos mennyiségű munka van benne. Sajnos méretéből adódóan csupán egyetlen 18F-es típusba fér bele a programom, a PIC18F4685-be melynek 96kB a memóriája. Ennél nagyobb 18F-es PIC nem létezik, ezt is úgy kellett megrendeltetnem külön a Chipcad-del.
A programom ebbe még éppen belefér de ha még hozzá kell írnom akkor az nem sokáig fog menni. Muszáj lesz nagyobb PIC-re váltanom de ennél nagyobb már csak a 16 bites dsPIC-ek közt van (128-256-512kB) melyre értelemszerűen a 8 bites 18F-re írt assembly programom nem fog felmenni...
Újra kell hát írnom az egészet. Mindettől megmenekültem volna hogyha eleve C-ben írtam volna a programot hiszen ott csak átállítom a fordítót az XC16-ra, átírom a típusspecifikus dolgokat és kész is. A teljesen más architektúrájú, más utasításkészletű, más adatszélességű, akár más gyártó mikrovezérlőjére is átültethető a C program, hiszen ezen sajátosság áthidalását a fordító szépen megoldja helyettem. Assembly esetében ilyen nem nagyon működik.

Ja és még egy dolog, az átláthatóság: A legelső C programomban egy működési-logikai szempontból egy blokknak tekinthető rész egy sort foglalt el, ugyan ez az assembly verzióban 274 sort. Egy valóban komoly, nagy programnál az átláthatóság rendkívül fontos és bármennyire is igyekszik az ember dokumentálni és agyonkommentezni az assembly kódot, sehol sem lesz egy C programhoz képest.
(#) AZoli válasza morzsa15 hozzászólására (») Okt 10, 2015 /
 
Display_Temperature() függvény mindig felülírja, nem?
(#) morzsa15 válasza AZoli hozzászólására (») Okt 10, 2015 /
 
Elméletileg igen. Mire gondolsz?
(#) AZoli válasza morzsa15 hozzászólására (») Okt 10, 2015 /
 
Arra hogy a
  1. Display_Temperature(temp_value);
temp_value -val írja fölül mindig, amint megy egy kört a program. Ezt a függvényt kéne vagy temp_max vagy temp_value paraméterrel és a kiírandó szöveggel meghívni.
(#) Hp41C válasza Attila86 hozzászólására (») Okt 10, 2015 /
 
Lehet a pro és kontra érveket sorolni napestig.
Amiket írtam 16Fxxx és 16F1xxx a Hitech C -ből átalakított XC8 azon felére írtam, ami ezeket a kontrollereket kezeli. A C18 -ból csinált másik fele valóban jobb.
Itt olvasható, hogy nem csak nekem van problémám a fordított kóddal.
A PICkit2 firmware -t C18 beli kézi optimalizálással (union mindenhová) sok-sok ezer utasítással lehetett csökkenteni. A gondom hasonlít a Tiedhez. Adott a maximális memóriával rendelkező 5V -os PIC18F USB modullal: 18F2550 vagy 18F4550. A 18F27J50 már 3.3V -os...
Rengeteg olyan megkötést hoz a megvalósított C fordító, ami jelentősen növeli a kód hosszát. Pl. nem lehet függvényben függvényt definiálni. Asm -ben nem gond, most is ezt csináltam kézzel a C18 alatt. Az eredmény kb. 2000 utasítás felszabadítása. Az végkép olvashatatlan forráshoz vezet, ha a sorok fele már assembly a másik fele pedig C. A további megkötés az, ha egy eljárásba egyetlen asm utasítást beteszel, az optimalizálás tetiltódik az egész eljárásra...

A 16 bitesek zöme 3.3V -os (24FxxK -k kicsik < 16K ami csak 5636 utasítás ) Át lehet tervezni az egész áramkört, főleg az analóg illesztéseket. Nem tudom a C30, XC16 mit is csinál a INTCON2bits.TMR0IP = 1; C utasításokkal. Arra viszont tippelnék, hogy izzasztó munka lesz a programot működőképessé tenni a 16 bites kontrollereken.
Gyöngyszem egy C30 által fordított programból (kly féle propeller óra programjából):
  1. 3103  0183C   A20400         btg w0,#0
  2.   3104  0183E   604061         and.b w0,#1,w0
  3.   3105  01840   604061         and.b w0,#1,w0
  4.   3106  01842   604061         and.b w0,#1,w0
  5.   3107  01844   604061         and.b w0,#1,w0
  6.   3108  01846   DD0142         sl w0,#2,w2

Miért kell négyszer elvégezni az and.b w0,#1,w0 utastást? Gondolom nem a szerző írta le négyszer. Rengetegszer előfordul ilyemi...
De miért is állnánk meg a 16 bites PIC -eknél. Sokkal több erőforrása van a 32MX vagy 32MZ -knek (az utóbbiban lebegő pontos támogatás is van), sőt a feladat ARM -mel és még nagyobb kontrollerekkel is megoldható... Csak persze a költségek nőnek. A C fordító áráról ne is beszéljek: MPLAB XC8 PRO MPLAB XC8 PRO Compiler 290000 HUF + ÁFA, amit már tényleg nem hobbis pénztárcához mértek.
Ehhez képest 50% bővítés még beleférne még a 18F4685 -be. a PICkit2 tapasztalatai alapján.

Vége.
Végülis mindenki azt a fordítót használja, amit szeretne.
A hozzászólás módosítva: Okt 10, 2015
(#) sonajkniz válasza Attila86 hozzászólására (») Okt 10, 2015 /
 
Nem csak az a promlémánk többünknek a C-vel, hogy hosszabb lessz a kód. Hanem az hogy fölöslegesen futnak le a program során egyes programsorok, ezért a reakció a legtöbb esetben nem azonnali. Ez a hiba legdurvábban a PLC-knél jelentkezik.
Nem írhatod úgy a programodat, hogy a program egyik sorában bekapcsolsz egy kimenetet, vagy egy memoriabitet, 10 sorral lejebb meg kikapcsolod. Ugyanis nem fog bekapcsolni. A program a futása során előszőr lekérdezi a bemeneteket, letárolja, a programmal feldolgozza, amit be- vagy ki kell kapcsolni, azt elhelyezi egy veremben, majd a program végén elvégzi a kapcsolásokat. Ennek megfelelően csak az utolsó parancs hajtódik végre egy adott kapcsolón, és az is késéssel.
Amikor kezdtem a PLC programozást, ez miatt nem egyszer a gutaütés kerülgetett. Ma már tudom kezelni, de még mindíg bosszant. Ez a legfőbb oka annak, hogy PIC-et csak asm.-ben programozok.
(#) matheattila válasza Pali79 hozzászólására (») Okt 10, 2015 /
 
Azzal egyetértek, hogy asm-ben lehet a legoptimálisabb kódot írni és nem C-ben, de a mai komplex (pl. USB, CAN, ethernet... perifériákkal megáldva) mikrovezérlőknél már sokkal praktikusabb C-ben mint asm-ben, mert ma már nincsenek gondok a memóriák kapacitásával.
Ami meg az 1000 soros asm és 1000 soros C programok összehasonlítását illeti az nem teljesen így van, mert a te 1000 soros asm programod C-ben max 300 sor
(#) Pali79 válasza matheattila hozzászólására (») Okt 10, 2015 /
 
Nem figyeltél. Azt írtam, hogy ha 1000 sort írsz C-ben akkor az mekkora helyet fog elfoglalni??? Tudom, hogy C-ben kevesebb, de ami a PIC memóriájába kerül az mindenképp több.
(#) Bell válasza sonajkniz hozzászólására (») Okt 11, 2015 /
 
A C nyelven írt program minden parancssora azonnal végrehajtódik, nincs semmiféle tárolás. Nagyságrendekkel gyorsabb a programírás, ha megismerkedsz vele.
A mikrosec-re kihegyezett programrésznél elővesszük az asm-et.
Próbáld ki.
(#) morzsa15 válasza AZoli hozzászólására (») Okt 11, 2015 /
 
Na proteusba tökéletesen megy de a valóságba -28 fokot ír ki valamiért. Ez mitől lehet?
(#) lastewer hozzászólása Okt 11, 2015 /
 
Sziasztok!

Szeretnék egy pic18f4520-as mikrovezérlővel feszültséget mérni , ezt hogyan lehet kivitelezni ?
(#) Pali79 válasza lastewer hozzászólására (») Okt 11, 2015 /
 
DC vagy AC? Mekkora feszültség?
(#) lastewer válasza Pali79 hozzászólására (») Okt 11, 2015 /
 
DC , 14-15V max. Autó aksi.
A hozzászólás módosítva: Okt 11, 2015
(#) Droot hozzászólása Okt 11, 2015 /
 
Sziasztok!

Ahogy láttam ebayen 3 féle klón kapható:
1. 3500-4500 Ft, ami ugyan úgy néz ki mint a gyári
2. 4500-5500 Ft, ami csak a nyers panel
3. 5500-x Ft, ami ugyan úgy néz ki mint az első

Vagy az első vagy a harmadik árút venném meg.
A kérdés az, hogy mi a különbség köztük?
Az első 3500Ftos is használható pl PIC30-al, alacsony feszültségen is? Ugyan annyit tud?
(#) Pali79 válasza lastewer hozzászólására (») Okt 11, 2015 /
 
Az szerintem megoldható sima feszültségosztással és ADC-vel.
(#) sonajkniz válasza lastewer hozzászólására (») Okt 11, 2015 /
 
Ha nem vágysz hajszálpontos mérésre, csak mondjuk akkuvisszajelzés a cél, egy 10 K-s potival osszad le a feszültséget. De a PIC bemenetét feltétlenül védjed le egy zenerrel.
(#) sonajkniz válasza Bell hozzászólására (») Okt 12, 2015 /
 
Nem kétlem, hogy C-ben gyorsabb a programírás, csak a feleslegesen beírt, vagy épp feleslegesen futtatott programsorok. (lásd fentebb Hp41C írását) lassítják a program futását. C-ben mindenre előre elkészített rutinok vannak, ami roppant kényelmes ugyan, csak a rutin nem biztos, hogy úgy fut le, ahhogy az nekem épp kellene. Egy példa: 4 karakteres ledkijelző multiplexelése.
(Gondolom, erre is van C-s rutin.) Én ezt úgy szoktam megoldani, hogy a főprogramot 4 részre osztom, és a karakterek várakozási idejében futtatom le a részeket. Így nincs haszontalan üresjárat, ráadásul a kritikus részek minden karakter idő alatt többször is lefuttathatóak. Így akár alacsonyabb frekin is dolgozhat a proci. Ezt a C hogy oldja meg? Még egy gondolat.
Olvastam valahol, hogy C-ben a kétsoros karakteres LCD működtetéséhez az ajánlott órajel 4MHZ, a minimum pedig 1MHZ. Asm.-ben levittem már 250KHz-ra is az órajelet, hozzáigazítottam az időzítéseket, és a kijelző működésében nem volt észlelhető változás.
A hozzászólás módosítva: Okt 12, 2015
(#) rolandgw válasza sonajkniz hozzászólására (») Okt 12, 2015 /
 
Értem amiket írsz,de itt alapvetően az a probléma,hogy a gyártó ingyenes módban ad egy olyan C fordítót,ami alig optimalizál ergo csak tanulásra,hobbi célra alkalmas.Általánosságban a jó C fordítókra abszolút nem jellemzőek ezek az észrevételek
(#) Hp41C válasza rolandgw hozzászólására (») Okt 12, 2015 /
 
Nézz bele egy PRO optimalizált XC8 által fordított Mid-range vagy Enhanced Mid-range assembly listába... Nem az a baj, hogy C, hanem az, hogy nem optimalizál. Illetve alig csinál többet annál, hogy kiszedi a free vagy a standard fordító által beletett szemetet.
A hozzászólás módosítva: Okt 12, 2015
(#) Bell válasza sonajkniz hozzászólására (») Okt 12, 2015 /
 
Meglátásom szerint, ha nem ismered egy PIC programozásának C nyelvi lehetőségeit is az alkotás szintjén, sosem tudod kiválasztani egy adott feladat korrekt és optimális megoldásához szükséges és elégséges eszközöket. Ugyanis nincs miből választani.
Ez olyasmi, mintha sofőrként csakis egy bizonyos típusú és piros színű teherautót tudnál vezetni, azt is csak délelőtt és előre menetben.

A tudásod remekül megfelel hobbi célokra, ami hallatlanul érdekes és élvezetes de nem lesz ütőképes, piacképes.

Valódi problémád a C nyelvvel kapcsolatban majd akkor lesz, ha sokkal jobb programokat írsz C-ben, mint asm-ben. A mostaniak inkább hiányos ismereteknek és kifogásnak tűnnek.
(#) sonajkniz válasza Bell hozzászólására (») Okt 12, 2015 / 1
 
Ez szépen hangzik,hogy "piacképes", és el is fogadom, mert egy bonyolultabb program asm. változatának költségeit senki nem fizeti meg. De attól még egy C-ben írt program sosem lessz olyan jó, mint egy profi (nem én) programozó álltal írt asm. kód.
Következő: »»   707 / 1210
Bejelentkezés

Belépés

Hirdetés
K�rlek v�rj...
XDT.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