OK Mégsem
Fórum témák

» Több friss téma
Fórum » PIC programozása C nyelven, C-Compiler
Lapozás: OK   113 / 153
(#) benjami válasza AZoli hozzászólására (») Aug 18, 2015 / 1
 
Előjeles számokkal könnyebb megoldani:
  1. int fDeg(signed int Deg)
  2. {
  3.   signed int Diff;
  4.   static signed int Deg_Last = 0;
  5.  
  6.   // melyik irányba fordulva van közelebb?
  7.   Diff = Deg - Deg_Last;
  8.   if(Diff > 180)
  9.     Diff -= 360;  // ha előre ugorva 180 foknál több kellene akkor visszafelé fordulunk
  10.   else if(Diff < -180)
  11.     Diff += 360;  // ha hátra ugorva 180 foknál több kellene akkor előre
  12.  
  13.   // max 45 fokos ugrás
  14.   if(Diff > 45)
  15.     Diff = 45;
  16.   else if(Diff < -45)
  17.     Diff = -45;
  18.  
  19.   Deg_Last += Diff;
  20.  
  21.   // előre és hátra körbefordulás eltüntetése
  22.   if(Deg_Last < 0)
  23.     Deg_Last += 360;
  24.   else if(Deg_Last > 360)
  25.     Deg_Last -= 360;
  26.  
  27.   return Deg_Last;
  28. }
(#) AZoli válasza benjami hozzászólására (») Aug 21, 2015 /
 
Köszönöm, valóban egyszerűbb és áttekinthetőbb. Működik.
Sajnos csak most volt időm jobban megnézni.
(#) cross51 hozzászólása Aug 31, 2015 /
 
Sziasztok!

Mit jelentene ez a sor struktúra, union vagy változó előtt
  1. __attribute__ ((packed))
.

Az __attribute__ még világos, hogy valamilyen specifikus beállítás, de a packed nem világos, hogy mire utal?
(#) Zsolt2 válasza cross51 hozzászólására (») Szept 1, 2015 /
 
A packed az union eseteben azt jeloli, hogy az adattagokat a leheto legkisebb helyre probalja besuriteni (nem hagy ki ures helyet ket mezo kozott).
(#) usane hozzászólása Szept 2, 2015 /
 
Üdv!

XC8 megint szívat. PIC16F1459-re akartam írni egy gyors UART tesztet, mert nincs nálam a saját UART könyvtáram. Már kapásból az OpenUSART() függvénnyel is gondja van. Az editor (Mplab X) azt mondja nem tudja azonosítani, de ezzel a betegségével már nem szoktam foglalkozni, megpróbáltam lefordítani.
Hibaüzenet:
Idézet:
„warning: (1464) number of arguments passed to function "_OpenUSART" does not match function's prototype
:0: error: (499) undefined symbol:
_OpenUSART(dist/default/production\BT.X.production.obj)”

Ötlet, hogy mi lehet a baja?

szerk:Microchip Belenéztem a fejlécekbe, csak PIC18-ra van peripherial library.
Irhatom a rutinokat, mert nincs nálam PIC18.
A hozzászólás módosítva: Szept 2, 2015
(#) Stadi válasza usane hozzászólására (») Szept 2, 2015 /
 
Microchip Code Configurator ismeri. Jó "csontváz" kódokat tud generálni. Nézd meg, hátha UART-ra is van benne előre megírt kód, és meg tudsz spórolni egy kis munkát.
(#) don_peter hozzászólása Szept 3, 2015 /
 
Srácok, porbálok éleszteni és használni egy ST7920-as 128x64-es GLCD-t.
PIC18F46K22-es okoskával akarom meghajtani, de belefutottam egy olyan struktúrába amely kiszalad a megengedett memóriából.

C18 fordítót használok.
A struktúra:
  1. #define XVAL 16
  2. #define YVAL 32
  3. typedef union
  4. {
  5.   unsigned int word;
  6.   unsigned char nbyte[2];
  7. } Dots;
  8.  
  9. typedef struct
  10. {
  11.   unsigned char refresh;
  12.   Dots pix[YVAL][XVAL];   // Max dimensions for display (x,y) = (128,32)
  13.   } GD_RAM;             //  (0,0) corresponds to upper lefthand corner.
  14.  
  15. GD_RAM gdram;

Az eredeti kód CSS-ben van itt: Bővebben: Link
Ezt írom át C18-ra, de a az x,y tengelyek megadásához szükséges struktúra túlcsordulást hoz a fordításnál.
Van erre valamilyen megoldás vagy másként kell megírjam a grafikus kijelzés pozicionálását?

Hiba:
Idézet:
„Error - section '.udata_main.o' can not fit the section. Section '.udata_main.o' length=0x00000401”

Előre is köszi..
A hozzászólás módosítva: Szept 3, 2015
(#) foxi63 válasza don_peter hozzászólására (») Szept 5, 2015 /
 
Szia!
A PIC18F46K22.lkr linkerfájlt kell módosítani, ahol nagyobb területet kell lefoglalni és elzárni a fordító elől.
pl.: DATABANK NAME=buff1 START=0X400 END=0X7FF PROTECTED

SECTION NAME=buff1 RAM=buff1

aztán a mainban :

#pragma udata buff1 //linker fájl módosítva.
unsigned char buf1[1024]; //adatpuffer
#pragma udata
(#) don_peter válasza foxi63 hozzászólására (») Szept 10, 2015 /
 
Köszi, én is erre gondoltam, de nem mertem hozzányúlni.

Ez nem befolyásolja az esetleges interruptokat?
Mert, hogy állitalában az is át van helyezve persze másabb memória területeket érint, de akkor is.
(#) foxi63 válasza don_peter hozzászólására (») Szept 10, 2015 /
 
Szia!
Ez RAM terület, nem a programmemória.
Nyugodtan használjad...
üdv.: Foxi
(#) zenetom hozzászólása Szept 10, 2015 /
 
Sziasztok!
Eddig C-ben amit programoztam, az 18F volt, azt is C18-ban. Azonban már ugye XC fordítók vannak, amiket nem ismerek, de valami mégis azt súgja, hogy a gyártó saját compilerét érdemesebb használni.
Kérdésem, hogy éri meg XC fordítót használni? A másik ami még szerintem szóba jöhet, a MikroC.
(#) Wezuv válasza zenetom hozzászólására (») Szept 11, 2015 / 1
 
MPLAB X -ben is lehet használni a régi fordítókat, akár C32-t is. Talán az XC8, ami a Hi-TechC helyett esetleg szóba kerülhet a 18F-alattiakhoz...
(#) zenetom válasza Wezuv hozzászólására (») Szept 11, 2015 /
 
Ez viszont jó hír, köszi!
(#) don_peter válasza foxi63 hozzászólására (») Szept 15, 2015 /
 
Közben megnéztem.
Nem értem a dolgot, segítenél?
Linker módosítva:
  1. DATABANK   NAME=gpr0       START=0x60              END=0xFF
  2. DATABANK   NAME=gpr1       START=0x100             END=0x1FF
  3. DATABANK   NAME=gpr2       START=0x200             END=0x2FF
  4. DATABANK   NAME=gpr3       START=0x300             END=0x3FF
  5. //DATABANK   NAME=gpr4       START=0x400             END=0x4FF
  6. //DATABANK   NAME=gpr5       START=0x500             END=0x5FF
  7. DATABANK   NAME=buff1      START=0X400             END=0X5FF PROTECTED //512
  8. DATABANK   NAME=gpr6       START=0x600             END=0x6FF
  9. DATABANK   NAME=gpr7       START=0x700             END=0x7FF
  10. DATABANK   NAME=gpr8       START=0x800             END=0x8FF
  11. DATABANK   NAME=gpr9       START=0x900             END=0x9FF
  12. DATABANK   NAME=gprA       START=0xA00             END=0xAFF
  13. DATABANK   NAME=gprB       START=0xB00             END=0xBFF
  14. DATABANK   NAME=gprC       START=0xC00             END=0xCFF
  15. DATABANK   NAME=gprD       START=0xD00             END=0xDFF
  16. DATABANK   NAME=gprE       START=0xE00             END=0xEFF
  17. DATABANK   NAME=gprF       START=0xF00             END=0xF37
  18. DATABANK   NAME=sfr15      START=0xF38             END=0xF5F          PROTECTED
  19. ACCESSBANK NAME=accesssfr  START=0xF60             END=0xFFF          PROTECTED
  20.  
  21. SECTION    NAME=buff1      RAM=buff1

Program kód módosítva:
  1. #pragma udata buff1             //linker fájl módosítva.
  2. unsigned char pix[512]; //adatpuffer
  3. #pragma udata
  4.  
  5. typedef union {
  6.   unsigned int word;
  7.   unsigned char nbyte[2];
  8. } Dots;
  9.  
  10. typedef struct {
  11.   unsigned char refresh;
  12.   Dots pix[YVAL][XVAL];         // Max dimensions for display (x,y) = (128,32)
  13. } GD_RAM;                                       //  (0,0) corresponds to upper lefthand corner.
  14.  
  15. GD_RAM gdram;

Mit nézek be?
Ugyan az a hiba:
Idézet:
„Error - section '.udata_main.o' can not fit the section. Section '.udata_main.o' length=0x00000401”

Előre is köszi..
(#) don_peter hozzászólása Szept 15, 2015 /
 
Közben rájöttem, hogy ez a sor:
  1. Dots pix[YVAL][XVAL];  // Max dimensions for display (x,y) = (128,32)

Erre változik:
  1. Dots pix;  // Max dimensions for display (x,y) = (128,32)

Mivel már egyszer a változót definiáltam.

Így jó, szerintetek is?
(#) don_peter hozzászólása Szept 15, 2015 /
 
Közben kidűlt, hogy nem jó, mert más a "pix" változó és más, ha struktúrán belül van.
Nem tudom, hogy oldjam meg a fentebb lévő struktúrának a megfelelő memória terület felszabadítását.

Kérnék segítséget.
(#) foxi63 válasza don_peter hozzászólására (») Szept 15, 2015 / 1
 
Szia!
Hát van némi probléma...
Elsőnek a struktúra definíciója kell, aztán a lefoglalás.
Szerintem a Dots struktúra 2 byte a dots tipusú kétindexes tömb 128x32x2 byte =8192 byte + refresh = 8193 byte ez 32 db 256-os lap + 1 byte a ram területről. Ennyi nincs is a PIC-ben.
... ha mégis belefér már a ram-ba, akkor pedig így kellene:

#pragma udata buff1 //linker fájl módosítva.
GD_RAM gdram; //adatpuffer
#pragma udata

üdv.: Foxi
A hozzászólás módosítva: Szept 15, 2015
(#) don_peter válasza foxi63 hozzászólására (») Szept 16, 2015 /
 
Köszi, így be is nyelte igaz, 1024byte-ot kellett neki lefoglalnom.
(#) foxi63 válasza don_peter hozzászólására (») Szept 16, 2015 /
 
Szia!
Örülök, hogy jó lett!
üdv.: Foxi
A hozzászólás módosítva: Szept 16, 2015
(#) Wezuv hozzászólása Szept 20, 2015 /
 
Meg lehet oldani valahogy, hogy a fordító módosítsa a sorszámokat egy deklarálásban, ha közé szúrok egy újabbat?
Erre gondolok:
  1. #define gombAbal 1
  2. #define gombTbal 2
  3. #define gombCbal 3
  4. #define gombAJobb 4
  5. #define gombTjobb 5
  6. #define gombCjobb 6

Ide kéne beszúrni egy #define gombFbal 4 sort úgy, hogy a további hozzárendelt számok egyel növekedjenek. Nyílván nem 5-6 sornál probléma ez...
(#) benjami válasza Wezuv hozzászólására (») Szept 20, 2015 /
 
Felsorolás típussal esetleg megoldható:
  1. enum tgombok{gombAbal, gombTbal, gombCbal, gombAJobb, gombTjobb, gombCjobb} gombok;
(#) killbill válasza benjami hozzászólására (») Szept 21, 2015 /
 
Azt tegyuk hozza, hogy ha kulon nem jelzed, akkor 0-rol indul a szamozas. Ha azt akarod, hogy a gombAbal valoban 1 legyen, akkor :
  1. enum {
  2.  gombAbal = 1,
  3.  gombTbal,
  4.  stb...
  5. };
A hozzászólás módosítva: Szept 21, 2015
(#) Wezuv válasza benjami hozzászólására (») Szept 21, 2015 /
 
Köszi, mindkettőtöknek! Az enum, jól gondolom, egyik memóriát sem terheli ezekkel az adatokkal ugye?
(#) potyo válasza Wezuv hozzászólására (») Szept 21, 2015 /
 
Nem. Kb. ugyanaz az enum is, mint a define, csak van rajta valamilyen szintű típusellenőrzés.
(#) ativagyok hozzászólása Szept 28, 2015 /
 
Sziasztok!

Hőmérséklet szabályzást szeretnék megvalósítani PWM-mel.
A terv, hogy a hőmérséklettel arányosan nő a kitöltési tényező.
Az alábbi programrészlet mennyire lehet működőképes a gyakorlatban?
Főleg a hiszterézissel kapcsolatban vagyok bizonytalan. Van esetleg jobb módszer erre?
Köszönöm előre is a segítséget.

  1. if(adc_HS_T < 100){fan_duty = 255;} //  ha nincs szenzor
  2.   else if(adc_HS_T >= (FAN_TARGET+20)){   // melegebb a célhőmérsékletnél
  3.     diff = (adc_HS_T - FAN_TARGET); // diff = különbség a mért és a kívánt hőm. között
  4.       if(diff <= MIN_FANDIFF) {fan_duty = 0;} // alacsony különbés esetén
  5.       else if(diff >= 255) {fan_duty = 255;}   // magas különbség esetén
  6.       else {fan_duty = (diff * SLOPE);}}      // kitöltési tényező = különbség (meredekségállítással)
  7.  
  8.   else if(adc_HS_T <= (FAN_TARGET-20)) {fan_duty = 0;} //  nincs hűtés
  9.  
  10.   Pwm2_Set_Duty(fan_duty);
(#) Bakman válasza ativagyok hozzászólására (») Szept 28, 2015 / 1
 
Nem értek a C nyelvhez, de a kérdésben van némi csavar. Egyszer hőmérséklettel arányos kitöltési tényezőt említesz, egyszer pedig hiszterézist.
(#) Wezuv válasza ativagyok hozzászólására (») Szept 28, 2015 /
 
Azzal is gond van, hogy ha nő a hőmérséklet, pont csökkennie kellene a kitöltésnek...
Nézz körül a PID, de legalább PI szabályzás terén, utána kell folgalkozni azzal, hogyan programozod le (ami az egyszerűbb része a dolgonak, miután néhány függvény az egész...).
(#) kissi válasza Wezuv hozzászólására (») Szept 28, 2015 /
 
Idézet:
„Azzal is gond van, hogy ha nő a hőmérséklet, pont csökkennie kellene a kitöltésnek...”

Miért, honnan tudod, hogy mit vezérel a kitöltési tényezővel ( fűtést vagy hűtést ?! ), így szabályozva a hőmérsékletet ( a FAN pont ventillátorra--> hűtésre utal ! ) ?!
A hozzászólás módosítva: Szept 28, 2015
(#) ativagyok hozzászólása Szept 29, 2015 /
 
Sziasztok!
Igen, ventilátort szabályoz, tehát a növekvő kitöltési tényezőben nem látok gondot. A hiszterézist pedig a ki- és bekapcsolási határértékre terveztem, hogy ne forduljon elő az, hogy 0 és 20% között ugrál a kitöltési tényező (20% a minimum).
Olvasgattam már a PID szabályzásról, erre a feladatra egy viszonylag egyszerű megoldást szeretnék kitalálni.
Üdv,
Ati
(#) Wezuv válasza kissi hozzászólására (») Szept 29, 2015 /
 
Ez igaz!
Ezekre szükség lehet! - HESTORE.HU

PIC18F4620-I/P
PIC18F1320-I/P
PWM2V
LASER-12MM-5MW-LM
1N5366B
Következő: »»   113 / 153
Bejelentkezés

Belépés
Hirdetés
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