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

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   1109 / 1320
(#) kissi válasza Hp41C hozzászólására (») Jan 22, 2013 /
 
Szerintem én is ezt javasoltam, de még nem nézte meg !
Steve
(#) watt válasza kissi hozzászólására (») Jan 22, 2013 /
 
Én ezt kértem tőle legelőször...
(#) kissi válasza watt hozzászólására (») Jan 22, 2013 /
 
Én a szimulátorra értettem, a kódot ( 4 lapnyi ) először nézze át ő ( és hátha megtanul egy jó hibakeresési technikát is a szimulátorral! ) !
Steve
(#) watt válasza kissi hozzászólására (») Jan 22, 2013 /
 
Ja értem, én meg kértem, hogy tegyen fel kódot. Mindegy...
(#) sirály12 hozzászólása Jan 24, 2013 /
 
Egy kis segítséget kérnék.
Egy pic32mx procira rádrótoztam egy 320x240-es színes kijelzőt ami touch-os.
A kijelző szépen ad képet, a touch részt is sikerült segítséggel belefaragni a mikrochip-es projektbe.
De a probléma az, hogy, hiába kapja vissza az adatokat a gol nem csinál vele semmit. Tehát rányomok egy gombra, és semmi nem történik, a gomb nem reagál. Mi lehet a gond?

A main itt kapja vissza az adatot a TouchGetMsg(&msg); részben:
  1. while(1)
  2.     {
  3.         if(GOLDraw())               // Draw GOL object
  4.         {
  5.             TouchGetMsg(&msg);      // Get message from touch screen           
  6.             GOLMsg(&msg);           // Process message
  7.         }
  8.     }//end while


Itt debugger alatt szépen látom is a visszaküldött adatokat.
pl: (02, 01, 189,126) az utolsó kettő a visszaküldött x,y koordináta.

Valahová kellhet még valami?
A hozzászólás módosítva: Jan 24, 2013
(#) Hp41C hozzászólása Jan 24, 2013 /
 
Sziasztok!
Talált-e valaki programozási leírást a PIC18F65J94, 66J94, 67J94, 85J94, 86J94, 95J94, 96J94, 97J94, 95J99, 96J99, 97J99 kontrollrekhez? PIC18FxxJ94, in production, adtlap és egy errata tölthető le csak, vagy én nem találom?
(#) Istvanpisti válasza sirály12 hozzászólására (») Jan 24, 2013 /
 
Szia !

Ém már működésre bírtam ezt, igaz AVR-rel, de ez a lényeget nem érinti
Idézet:
„De a probléma az, hogy, hiába kapja vissza az adatokat a gol nem csinál vele semmit.”


A TouchGetMsg(&msg) függvény "készíti el" az üzenetet, (mi történt : nyomás, elengedés, nyomvatartás stb. és rendel hozzá x,y koordinátát)
A GOLMsg(&msg) függvény végigmegy az objektumokon, és meghívja a pCurrentObj->MsgObj(pCurrentObj, pMsg) függvényt mindegyik objektum esetén. Az objektumok (button, checkbox, progressbar....) ezen függvénye reagál az üzenetre, ha az x,y koordináták beleesnek a "felületébe". Ekkor az objektum visszaküld egy értéket pl. return (BTN_MSG_PRESSED) ez lesz a translatedMsg a GOLMsg függvényen belül. Ezután egyrészt meghívódik a GOLMsgCallback fv. amit neked kell megírni, itt tudsz reagálni a történésre, majd a meghívódik az objektum MsgDefaultObj fv-e, amiben megtörténik az objektum grafikus viselkedésének beállítása pl. SetState(pB, BTN_PRESSED | BTN_DRAW). Az objektum tényleges kirajzolása nem itt történik, hanem majd a GOLDraw() fv. hívja meg annak az objektumnak a draw() rutinját ami az előbb reagált az üzenetre.
Röviden ennyi a működés. Lépésenként végig lehet menni és kiíratni az LCD-re különböző soroknál adatokat, így kiderül eljut-e oda. Ha az objektum nem reagál, akkor ennek lehet nagyon egyszerű oka is pl. a touch-nál lentről indul az y koordináta, míg az objektumnál felülről.

(#) sirály12 válasza Istvanpisti hozzászólására (») Jan 24, 2013 /
 
Akkor ha jól értem a "GOLMsgCallback" részbe kell írnom hogy mi történjen, ha megnyomom a gombot.
De attól a gomb animációja nem kellene, hogy lefusson? Tehát nem kellene-e benyomódnia a gombnak? Mert nekem ez sem történik meg.
Átnézem, hátha jutok valamire.
A hozzászólás módosítva: Jan 24, 2013
(#) Istvanpisti válasza sirály12 hozzászólására (») Jan 24, 2013 /
 
A gomb lenyomásakor az animációnak meg kell történni, függetlenül attól, hogy lekezeled-e az eseményt, vagy nem. Szerintem kezdd el a TouchGetMsg(&msg) fv. vizsgálatával, írasd ki milyen eseményt és milyen x,y koordinátát ad vissza, ha megnyomod a touch-ot. Ennek minden híváskor kell visszaadni értéket, ha nincs nyomás akkor is ekkor pl. azt, hogy nincs semmi x=0;y=0;. Ennek a rutinnak kell tudni kezelni a lenyomást, elengedést, nyomva tartást, és a nyomás közbeni mozgatást.
Esetleg feltehetnéd ennek a kódját, hátha látszik belőle valami.

Mellékelek egy program vázat, kb. így építettem fel a saját programomat.

  1. typedef enum
  2. {              
  3.   CREATE_MAIN_SCREEN= 0,
  4.   DISPLAY_MAIN_SCREEN,
  5.   CREATE_SETUP,
  6.   DISPLAY_SETUP,
  7. } SCREEN_STATES;
  8.  
  9.  
  10. //hogy ez mi azt az OBJMsgCallback fv-hez leírtam
  11. WORD MSG_MainScreen(WORD objMsg, OBJ_HEADER* pObj, OBJ_MSG* pMsg)
  12. {      
  13.    WORD O_ID = GetObjID(pObj);
  14.    if(objMsg == BTN_MSG_RELEASED)
  15.    {
  16.       switch(O_ID)
  17.       {
  18.          case ID_SETUP :
  19.          {
  20.             screenState = CREATE_SETUP;
  21.             break;
  22.          }
  23.       }
  24. }
  25.  
  26. void CreateMainScreen(void)
  27. {
  28.    OBJFree();
  29.    BtnCreate(ID_SETUP,  .......)
  30.    BtnCreate(ID_XXX,  .......) //vagy amilyen objektumot létrehozol
  31. }
  32.  
  33. WORD OBJDrawCallback(void)  //ezt a fv-t a GOLDraw() hívja meg
  34. {
  35.  switch(screenState)
  36.  {
  37.    case CREATE_MAIN_SCREEN:
  38.   {
  39.      CreateMainScreen();        //ebben a fv-ben hozod létre az objektumokat pl. BtnCreate(ID_SETUP,.......
  40.      screenState=DISPLAY_MAIN_SCREEN;  //aztán a screenState-t átállítod ezt majd az OBJMsgCallback fv-ben kezeled le.
  41.      return(TRUE);
  42.   }
  43.   case CREATE_SETUP:
  44.   {
  45.      Create_setup();
  46.      screenState=DISPLAY_SETUP;
  47.      return(TRUE);
  48.    }
  49.  }
  50. }
  51.  
  52. WORD OBJMsgCallback(WORD objMsg, OBJ_HEADER *pObj, OBJ_MSG *pMsg)
  53. {      
  54. LIGHT_ON; // ide akkor jön a vezérlés, ha a touch-hoz érünk pl. itt lehet bekapcsolni a az LCD háttérvilágítását.
  55. switch(screenState)
  56. {
  57.    case DISPLAY_MAIN_SCREEN:
  58.    {
  59.       MSG_MainScreen(objMsg, pObj, pMsg);//ezt is neked kell megírni a CreateMainScreen() fv-nél, ez a fv. küldi ide az objektum üzenetét.
  60.       return(TRUE);
  61.    }
  62.    case DISPLAY_SETUP:
  63.   {    
  64.       MSG_setup(objMsg, pObj, pMsg);
  65.       return(TRUE);
  66.    }
  67. }
  68. //ezt a main-be
  69.     screenState = CREATE_MAIN_SCREEN;
  70.     while(1)
  71.     {
  72.         if(GOLDraw())               // Draw GOL object
  73.         {
  74.             TouchGetMsg(&msg);      // Get message from touch screen      
  75.             GOLMsg(&msg);           // Process message
  76.         }
  77.      }//end while
(#) sirály12 válasza Istvanpisti hozzászólására (») Jan 24, 2013 /
 
Csatolom a forráskódomat, hátha csak nem veszek valamit észre.
Bár még nem írtam semmit a "GOLMsgCallback" részbe, de a legnagyobb gondom, hogy maga az animáció sem zajlik már le.
A programban jelenleg egyetlen egy gomb van, az is a képernyő közepén.
A "TouchGetMsg(&msg);" debug alatt jónak tűnik. A vissza adott érték biztosan belül van a gomb területén. Egy példa: 02,01,168,128

Ez a függvény amit használok a touchhoz:
  1. void TouchGetMsg(GOL_MSG* pMsg){
  2.     static SHORT prevX = -1;
  3.     static SHORT prevY = -1;
  4.     SHORT x,y;
  5.  
  6.     ReadTouchXY();
  7.  
  8.     x = TP_X;
  9.     y = TP_Y;
  10.     pMsg->type    = TYPE_TOUCHSCREEN;
  11.     pMsg->uiEvent = EVENT_INVALID;
  12.  
  13.     if( x == -1 ){
  14.         y = -1;
  15.     }else{
  16.         if( y == -1 )           //if( y == -1 )
  17.             x = -1;
  18.     }
  19.  
  20.     if( (prevX == x) && (prevY == y) )
  21.         return;
  22.  
  23.     if( (prevX != -1) || (prevY != -1) ){
  24.  
  25.         if( (x != -1) && (y != -1) ){
  26.             // Move
  27.             pMsg->uiEvent = EVENT_MOVE;
  28.         }else{
  29.             // Released
  30.             pMsg->uiEvent = EVENT_RELEASE;
  31.             pMsg->param1 = prevX;
  32.             pMsg->param2 = prevY;
  33.             prevX = x;
  34.             prevY = y;
  35.             return;
  36.         }
  37.  
  38.     }else{
  39.  
  40.         if( (x != -1) && (y != -1) ){
  41.             // Pressed
  42.             pMsg->uiEvent = EVENT_PRESS;
  43.         }else{
  44.             // No message
  45.             pMsg->uiEvent = EVENT_INVALID;
  46.         }
  47.  
  48.     }
  49.  
  50.     pMsg->param1 = x;
  51.     pMsg->param2 = y;
  52.     prevX = x;
  53.     prevY = y;
  54.    
  55. }


Main.c		    
(#) Istvanpisti válasza sirály12 hozzászólására (») Jan 25, 2013 /
 
amit írsz :
Idézet:
„Egy példa: 02,01,168,128”
ez a TouchGetMsg fv. által visszaadott struktúra a pMsg értéke ?
Ha igen, akkor az első paraméter adja meg a beviteli eszközt (type), ami most a TYPE_TOUCHSCREEN, a második paraméter az általa generált esemény (uiEvent), ami az EVENT_MOVE a következő paraméter (param1) az x, a következő pedig (param2) az y koordináta.
Szerintem nézd meg a BtnTranslateMsg fv.-t, hogy itt kell-e reagálni az EVENT_MOVE eseményre a nyomógombnak. Esetleg kipróbálhatod, hogy TouchGetMsg fv.-ben ebben a sorban pMsg->uiEvent = EVENT_MOVE;kicseréled az EVENT_MOVE-ot EVENT_PRESS-re és utána rögtön return;. Ha ettől mozogna a nyomógomb képe, akkor itt vana baj, ha nem akkor...
  1. typedef struct
  2. {
  3.     BYTE    type;                   // Type of input device.
  4.     BYTE    uiEvent;                // The generic events for input device.
  5.     SHORT   param1;                 // Parameter 1 meaning is dependent on the type of input device.
  6.     SHORT   param2;                 // Parameter 2 meaning is dependent on the type of input device.
  7. } GOL_MSG;
  8. typedef enum
  9. {
  10.     TYPE_UNKNOWN    = 0,            // Unknown device.
  11.     TYPE_KEYBOARD,                  // Keyboard.
  12.     TYPE_TOUCHSCREEN,               // Touchscreen.
  13.     TYPE_MOUSE,                     // Mouse.
  14.     TYPE_TIMER,                     // Timer.
  15.     TYPE_SYSTEM                     // System Messages.
  16. } INPUT_DEVICE_TYPE;
  17. typedef enum
  18. {
  19.     EVENT_INVALID   = 0,            // An invalid event.
  20.     EVENT_MOVE,                     // A move event.
  21.     EVENT_PRESS,                    // A press event.
  22.     EVENT_STILLPRESS,               // A continuous press event.
  23.     EVENT_RELEASE,                  // A release event.
  24.     EVENT_KEYSCAN,                  // A keyscan event, parameters has the object ID keyboard scan code.
  25.     EVENT_CHARCODE,                 // Character code is presented at the parameters.
  26.     EVENT_SET,                      // A generic set event.
  27.     EVENT_SET_STATE,                // A set state event.      
  28.     EVENT_CLR_STATE                 // A clear state event.
  29. } INPUT_DEVICE_EVENT;

(#) jarossy.zoltan hozzászólása Jan 25, 2013 1 /
 
Köszönöm a segítséget. Természetesen használtam volna a szimulátort, ha lenne gyakorlati haszna az én esetemben. Ugyanis nem elég, hogy négy memórialapnyi programot használok, hanem még a TMR1 (mint megszakítás forrás indítása) indítása is teljesen véletlenszerű, több menetet és I2C-n fogadott adat ÉS/VAGY kapcsolatának függvénye. Nem is beszélve arról, hogy szintén véletlenszerű esemény meg is szakíthatja vagy "beletörölhet" Elméletben jó tehát csak a szimulátor, akkor ha számítható a TIMER(ek) futása. De itt nem. Természetesen maga a megszakítás kiszolgáló rész nem ilyen egyszerű, az is tekintélyes, de a flag törlése majd RETFIE-re is ugyanígy viselkedik a program. Éppen ezért programkódot teljesen értelmetlen közölnöm. Született viszont megoldás, de magam sem értem miért jó. Ebben kérném a további segítségeteket! Ha a megszakítás címére (0x0004) egy goto xxxx utasítást teszek és magát a megszakítást végrehajtó rutint "elteszem" onnan ugyanazon memórialap más címére (szubruntinként), úgy a program teljesen jól működik. W, STATUS, PCLATH mentéssel és lapváltásokkal együtt. Tehát az a számomra érthetetlen, hogy miért nem bírja végrehajtani a megszakítás kiszolgálást ha az a 0x0004 címtől folytatólagosan van?
(#) kissi válasza jarossy.zoltan hozzászólására (») Jan 25, 2013 /
 
Te írtad:
Idézet:
„Köszönöm a válaszokat! Természetesen "tökén fogtam" a PCLATH-ot már, azonban az a rettenetesen érdekes, hogy ha a megszakításban csak annyit csinálok, hogy törlöm az IRQ-FLAG-et, majd zavarom is vissza RETFIE-vel - na ekkor is elkószál...”
Na ezt kellett volna megnézni és itt mindegy, hogy milyen "variációk" miatt kerül megszakításba ( mivel azt írtad, hogy innen mindig elakad!), látnod kell, hogy mi a gond, mikor kilép!
Steve
(#) jarossy.zoltan hozzászólása Jan 25, 2013 /
 
Nem látom - a szimulátorban a következő az eredmény:
BCF TMR1IF - végrehajt
BSF LED - adott port 1-be áll
RETFIE - visszaugrik az eredeti programba p.memórialaptól függetlenül.

Valóságban a LED már nem kapcsol be.
Ha felcserélem a TMRIF törlése és LED bekapcsolása sorokat, akkor a LED kigyullad, de innen elakad a program.

További kiegészítés - módosítom a progit:

BSF LED1 - adott port 1-be áll
BCF TMR1IF - végrehajt
BSF LED2 - adott port 1-be áll
RETFIE - visszaugrik az eredeti programba p.memórialaptól függetlenül.

vagy:

BSF LED1 - adott port 1-be áll
BSF LED2 - adott port 1-be áll
BCF TMR1IF - végrehajt
RETFIE - visszaugrik az eredeti programba p.memórialaptól függetlenül.

a LED2 egyik esetben sem kapcsol már be! Bezzeg ha így néz ki a dolog:

ORG 0x0004
GOTO (Címkére teszem a fentieket - és a címke ugyanazon a memórialapon van de nem folytatólagos)

Na ebben az esetben szimulátor szerint is és a valóságban is jól működik.
Olyan mintha a 0x0005 címen a program megbolondulna. Elképzelhető programmemória hiba szerintetek?
(#) _vl_ válasza jarossy.zoltan hozzászólására (») Jan 25, 2013 /
 
A bankot hol választod ki az interrupt rutinodban? A TMR1IF biztosan nem érhető el minden lapról, tehát előtte el kell mentened a W + STATUS regisztereket, és beállítani a kívánt bankot. Természetesen a visszaállításnak is meg kell lennie a RETFIE előtt.
A BSF LED ugye portbitet állít, az szintén fix bankbeállítást igényel.
(#) mrobi válasza jarossy.zoltan hozzászólására (») Jan 25, 2013 /
 
Nézd meg ezt a cikket!
(#) Hp41C válasza jarossy.zoltan hozzászólására (») Jan 25, 2013 /
 
Idézet:
„Ha a megszakítás címére (0x0004) egy goto xxxx utasítást teszek és magát a megszakítást végrehajtó rutint "elteszem" onnan ugyanazon memórialap más címére (szubruntinként), úgy a program teljesen jól működik. W, STATUS, PCLATH mentéssel és lapváltásokkal együtt.”

Ne sértődj meg... Ez a megoldás teljesen hibás! Ha lenne hajam, kitépném. Egy hete mondjuk a megoldást...
Ugyanis: A megszakítás a 0x0004 -et tölti be a PC -be, a PCLATH regiszter értéke a megszakítás előtt érték marad. A fent említett goto xxx utasítás a PCLATH értékéből veszi a 4. és 3. bitet, kiegészíti az utasítás alsó 10 bitjével. A Te esetedben pontosan arra a program lapra ugrik (véletlenül), amin a megszakítási rutint tetted. De ez csak egy lapra igaz. Vagy mind a 4 lapra iugyan azt a megszakítási rutin teszed? Ha a megszakítási rutinban elágazol az októl függően és nem állítod a PCLATH -t, a program megint "elkolbászol", ráadásul a megszakítás tilott állapotában.
Készíts egy kis eljárást egy harmadik lapra (ne arra, amin a megszakítási rutin van), ami jó sokat vár, tesztnek egy végtelen ciklus is jó lesz, hívd meg. A várakozáshoz goto -t kell használnod, ami erre a lapra kell ugorjon, tehát a PCLATH -t erre a lapra kell beállítanod. A szimulátorban tegyél töréspontot a 0x0004 címen levő goto xxx -re és nézd meg, hova ugrik megszakításkor! Hidd el a szimulátornak, hogy azon a lapon fog a megszakítási rutin kezdőcímére (xxxx & 0x7FF) ugrani, amin a megszakítás bekövetkezéséig futott. Ekkor "kolbászol el"...
Egyébként subrutinokat call -al szoktuk hívni, és általában nem tesszük a megszakítás kiszolgálót vagy részeit szubrutinba, főleg nem egy korlátozott férőhelyű hardware stack -kal megáldott kontrolleren. Apropo az "elkolbászolásnak" lehet stack túlírás is az oka, amit a szimulátor jelezne neked...
Olvasd már el a cikket, amit ajánlottam. Próbáld ki a benne elmagyarázott programot. Kipróbáltam, működik - Én írtam a cikket és a programot is. De vajon minek, ha nem is olvassák el... Én már tudom, csinálom, örülök, hogy pl. 16F886 -ban több 8000 utasításnál nagyobb programom működik.
A hozzászólás módosítva: Jan 25, 2013
(#) jarossy.zoltan válasza Hp41C hozzászólására (») Jan 25, 2013 /
 
Igazad van - azt nem írtam, hogy magát a programot is lehülyítettem, így az org 0x0004-ről való azonnali goto nem okozott problémát, mivel a program mindig page0-n volt mikor az irq bejött. Bármilyen fura - igazolódott, hogy hardverhiba ugyanis másik processzorral kifogástalan az eredeti megszakítás. Ilyennel még nem találkoztam...
(#) röntgen hozzászólása Jan 25, 2013 /
 
Az ICD2 prog/debuggert valóban nem támogatja az MPLAB X? Ezt nem értem......
MPLAB IDE revízióihoz meg nem tudok találni win7 alá drivert. Valaki tud ebben tanácsot adni?

Lehet hogy más compilerrel kell használnom ezután az ICD2-őt, ha win7 alatt akarom használni?
(#) icserny válasza röntgen hozzászólására (») Jan 25, 2013 /
 
Idézet:
„MPLAB IDE revízióihoz meg nem tudok találni win7 alá drivert.”
Állítólag Vista driverrel megy. Itt írnak róla. (nem tudom ellenőrizni, mert nekem nincs ICD2-m, csak Guglizni tudok...)
(#) röntgen válasza icserny hozzászólására (») Jan 25, 2013 /
 
Csak az a gondom, hogy az alábbi ICD2-m van: P/N 10-00319
Idézet:
„Older MPLAB ICD 2 debuggers (P/N 10-00319) will NOT support 64-bit VISTA.
”

(#) icserny válasza röntgen hozzászólására (») Jan 25, 2013 /
 
Akkor csak XP vagy virtualizált XP segít rajtad.
(#) sirály12 válasza Istvanpisti hozzászólására (») Jan 25, 2013 /
 
Ez nem igaz! Hogy egy ilyen banális hibát követek el, nem hiszem el!

Mivel a touch kezelőt részben én írtam, ezért a hardwareprofile-ban nem volt definiálva a #define USE_TOUCHSCREEN();
Ezért hiába is küldte a touch az adatokat, a button.c-ben lévő BtnTranslateMsg fel sem dolgozta.

Köszönöm a segítséget.
(#) röntgen válasza icserny hozzászólására (») Jan 25, 2013 /
 
Ezt akartam elkerülni, most hogy win7-re váltottam.............
Van még valamilyen compiler ami támogatja az ICD2-őt?
(#) icserny válasza röntgen hozzászólására (») Jan 25, 2013 /
 
Idézet:
„Van még valamilyen compiler ami támogatja az ICD2-őt?”
Nem a compiler támogatja az ICD-t, hanem az IDE. A Microchipnek csak MPLAB és MPLAB X van.
(#) röntgen válasza icserny hozzászólására (») Jan 25, 2013 /
 
Bocs, rosszul fogalmaztam. Pont arra lennék kíváncsi, hogy az MPLAB és MPLAB X-en kívül van -e fejlesztő környezet ami elfogadja az ICD2-t.
(#) Istvanpisti válasza sirály12 hozzászólására (») Jan 25, 2013 /
 
Örülök, hogy sikerült megoldanod!
(#) potyo válasza röntgen hozzászólására (») Jan 25, 2013 /
 
Én még nem hallottam ilyenről. Égetésre máskor volt valami program, nem jut eszembe a neve, de debuggolásra nem tudok másikról...
(#) icserny válasza röntgen hozzászólására (») Jan 26, 2013 /
 
Idézet:
„arra lennék kíváncsi, hogy az MPLAB és MPLAB X-en kívül van -e fejlesztő környezet ami elfogadja az ICD2-t.”
Ha netán lenne, akkor sem valószínű, hogy saját drivert fejlesztenének hozzá, pláne a "régi" konstrukciójú ICD2 és a 64 bites Win7 pároshoz.

Ezért nem ajánlottam tegnap sem a régi HI-TIDE (ez akkor volt, amikor a Microchip még nem vásárolta fel a HiTech céget), sem a SourceBoost IDE fejlesztői környezetet.
(#) röntgen válasza icserny hozzászólására (») Jan 27, 2013 /
 
Köszönöm a válaszod.
Ezekre szükség lehet! - HESTORE.HU

LED21-MR16-WH
PIC32MX764F128H-I/PT
ZL262-10DG
36,5R 0,1%
SWFLK-WW
Következő: »»   1109 / 1320
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