Fórum témák

» Több friss téma
Fórum » PIC programozása C nyelven, C-Compiler
Lapozás: OK   41 / 153
(#) adamhollos válasza watt hozzászólására (») Jún 14, 2011 /
 
Köszönöm, nektek. Majd írok az eredményekről.
(#) Bell hozzászólása Jún 18, 2011 /
 
Sziasztok!
Van egy "Low pin count USB development board" -om, benne egy PIC18F14K50.
A vele adott dokumentumban található mintapéldák jól működnek.
Szeretném az A/D konverzió eredményét néhány másodpercenként egy excel állományba küldeni az USB porton, mintha az billentyűzetről érkezne.
Tehát semmi soros port, merthogy minek az ide.

Szerintem az USB portnak ez lenne az egyik leghasználhatóbb funkciója.

Tudna valaki adni ehhez egy kis útbaigazítást?
(#) adamhollos válasza Bell hozzászólására (») Jún 18, 2011 /
 
Nézd meg icsreny honlapját!
(#) icserny válasza Bell hozzászólására (») Jún 18, 2011 /
 
A Microchip Application Libararies (MAL) letöltése és kibontása után találsz egy csomó demó programok. Ezek közül az USB Device - HID Keyboard kell neked, ebbe kell belemódosítani, hogy azt küldje, amit akarsz.
(#) Bell válasza icserny hozzászólására (») Jún 18, 2011 /
 
Mindkettőtöknek köszönöm!
(#) zenetom hozzászólása Jún 24, 2011 /
 
Hali!
Nem akarja elfogadni a C18 a "TBLRD+*" utasítást, csak ha simán azt írom be hogy "TBLRD" még a "TBLRD*"-t se fogadja el. Természetesen asm blokkok közé írtam:
  1. _asm
  2.  TBLRD+*
  3. _endasm


Azért lenne jó ha elfoagdná, mert akkor nem kell a TBLPTR regiszterhármast egyesével növelni...
(#) potyo válasza zenetom hozzászólására (») Jún 24, 2011 /
 
Az nem jó, hogy a fordítóra bízod a dolgot, és simán csak rom-ban tárolt tömböt használsz?

Mellesleg a TBLPTR nem olyan, hogy ha az alsót növeled, akkor túlcsorduláskor növeli a többit is? Nem néztem utána, csak tippelem, hogy ilyen lehet.
(#) zenetom válasza potyo hozzászólására (») Jún 24, 2011 /
 
A tömböt így deklaráltam, tehát a programmemóriában van:
  1. static const unsigned char rom ADATTABLA[4096] =
  2. {0x00, ......0x00}

Egyébként egy asm kódrészletet szúrtam be, amiben eredetileg TBLRRD+*-el olvasok az org 0x1000-es címtől kezdődően.
Nagy nehezen sikerült kideríteni hogy a C hova rakja ezt a tömböt a programmemóriában
Azért akartam a TBLRD+*-ot használni, mert -bár lehet a fordító is ezt használja- ez a leggyorsabb hozzáférés a memóriáhozm illetve nem kell az assembly részben átírni semmit.
Ha a rom-mal a programmemóriában helyezek el tömböt, akkor ugyanúgy lehet rá hivatkozni (pl.: ADATTABLA[5]) mint ha az adatmemóriában lenne?
(#) potyo válasza zenetom hozzászólására (») Jún 24, 2011 /
 
Igen, ugyanúgy lehet. Nézd meg, hogy mire fordítja a fordító a kódodat, és csak akkor állj neki tovább reszelni rajta, ha nem elég optimális a fordított kód.
(#) zenetom válasza potyo hozzászólására (») Jún 24, 2011 /
 
Köszi a választ!
Akkor használom simán tömbként, viszont felmerül akkor még egy probléma. Meg kell szakítani az assembly részt, és közbe kell rakni a C részt:
  1. _asm
  2.     ...
  3.     UJSOR:
  4.     ...
  5. _endasm
  6.  
  7.         ADATTABLA_CIM++;
  8.         PIXELEK = ADATTABLA[ADATTABLA_CIM];
  9.  
  10. _asm
  11.     ...
  12.     GOTO UJSOR
  13. _endasm


Itt kiabál a fordító, hogy
Idézet:
„Error [1111] undefined label 'F' in 'main'”
, ami gondolom azért van mert nem tudja hol van az "UJSOR" label, mert meg lett szakítva az assembly rész. Jól gondolom?
(#) zenetom válasza zenetom hozzászólására (») Jún 24, 2011 /
 
Ez a hibaüzenet valami más miatt van. Lehet túl hosszú az assembly rész? (kb. 34 soros)
Szerk.: megvan. Nem tetszik neki a SWAPF utasítás, ez a nyomi C fordító két változót akar ezzel az utasítással megcserélni, nem pedig egy bájtban lévő 2 nibblét
(#) potyo válasza zenetom hozzászólására (») Jún 24, 2011 /
 
Pontosan miért is vannak ezek az asm részek beszúrva? Azt az UJSOR ... GOTO UJSOR dolgot C-ben is meg lehet ám csinálni!
(#) zenetom válasza potyo hozzászólására (») Jún 24, 2011 /
 
Azért hogy ne kelljen átírni C-re
De úgy látom mégis csak az lesz belőle.
(#) Kiwy hozzászólása Jún 27, 2011 /
 
Sziasztok!
Egy PIC16F1826-ot szeretnék felprogramozni. A beégetendő programot az MPLAB-ban írtam meg, HITECH fordítóval fordítottam. Programozó eszközt nem vettem, watt párhuzamos port alapú programozóját építettem (watt-féle LPT programozó v4.0). Ennél a Vpp 12V. Azt szeretném megkérdezni, hogy az MPLAB-ban beállítható konfigurációs biteknél nagy- vagy kisfeszültségű programozási módot kell beállítani? Ráadásul a uC adatlapjában (PIC16F1826) az van írva, hogy a Vpp lábán 8...9V feszültség lehet (absz. max. a 9V). Akkor ez így most nem fog működni (mármint az égetés)? Tönkretenném vele a uC-t? Az adatlapban a nagyfeszültségű programozási módnál van egy ábra, hogy valami kiegészítő áramkört kell csinálni ICD2-höz. Esetleg azt kéne megépíteni? Sajnos nem tudok rájönni.

Válaszaitokat előre is köszönöm!

üdv, Kiwy
(#) MPi-c válasza Kiwy hozzászólására (») Jún 27, 2011 /
 
12V-tal ne is próbáld programozni! Az adatlapban lévő áramkör alkatrészei (LM431) beszerezhetőek (pl. RET, TO92 vagy SO8 tokozással is, kb. 70 Ft áron) vagy egy zénerrel és egy ellenállással is megoldható. Én az utóbbit alkalmaztam.
Ez a kérdés egyébként nem passzol a topikba!

el.jpg
    
(#) Kiwy válasza MPi-c hozzászólására (») Jún 27, 2011 /
 
Köszi a választ! Bocs, hogy ide írtam, de nem találtam jobb topikot a kérdésemnek. Ha esetleg ajánlanál egy megfelelőt, azt megköszönném. Esetleg "PIC - Miértek, hogyanok..."? És az ellenállást meg a Zenert hogy kötöd be (a képből nem nagyon látszik)? És milyen alkatrészeket lehet betenni (ellenállásérték, Zener-típus)? Előre is köszi!
(#) MPi-c válasza Kiwy hozzászólására (») Jún 29, 2011 /
 
Hát ez csak egy Zener-diódás feszültségstabilizátor alapkapcsolás (illik ismerni...)

kapcs.pdf
    
(#) zenetom hozzászólása Júl 3, 2011 /
 
Már régóta akarok olyat megvalósítani, hogy egy saját portfélét létrehozni, különböző portok bitjeivel.
Pl.: a "PORTSAJATbits.pin1" legyen a "LATAbits.LATA0"-val egyenlő, a "PORTSAJAT.pin6" legyen a LATCbits.LATC1" megfelelője.
(#) watt válasza zenetom hozzászólására (») Júl 3, 2011 /
 
  1. #define PORTSAJATbits.pin1  LATAbits.LATA0

De inkább adj neki normális nevet, mint pl. Gomb1, vagy LED2, vagy ami beszédesebb.

pl.
  1. #define mLED              LATDbits.LATD6 //LED
  2.         #define mLED_On()         mLED = Be
  3.         #define mLED_Off()        mLED = Ki
  4.         #define mLED_Toggle()     mLED = !mLED
(#) zenetom válasza watt hozzászólására (») Júl 3, 2011 /
 
Hopsz a lényeget nem is írtam. Vagyis a PORTSAJAT 8 bites legyen, és lehessen neki értéket adni, aminek megfelelően állnak be a különböző portok.
(#) watt válasza zenetom hozzászólására (») Júl 3, 2011 /
 
Mi értelme ennek?
Egyébként az unionnal lehet ilyet csinálni. Én még PORT-ra nem használtam, csak sima regiszterre, de át lehet ültetni szerintem.

  1. union{
  2.  unsigned char x;
  3. struct st_FLAGbits1 {
  4.     unsigned b0:1;
  5.     unsigned b1:1;
  6.     unsigned b2:1;
  7.     unsigned b3:1;
  8.     unsigned b4:1;       
  9.     unsigned b5:1;
  10.     unsigned b6:1;
  11.     unsigned b7:1;                     
  12. };
  13. }FLAGbits1;
  14. #define FLAG1 FLAGbits1.x


Használata:

  1. FLAGbits1.b1=1; //1. bit beállítva
  2. vagy:
  3. FLAG1 = 0; //jelzők törlése


Érdemes lenne belenézni a header fájlba, hogyan deklarálják a PORT-okat!
(#) watt válasza watt hozzászólására (») Júl 3, 2011 /
 
Így oldják meg:
  1. extern volatile near unsigned char       LATB;
  2. extern volatile near struct {
  3.   unsigned LATB0:1;
  4.   unsigned LATB1:1;
  5.   unsigned LATB2:1;
  6.   unsigned LATB3:1;
  7.   unsigned LATB4:1;
  8.   unsigned LATB5:1;
  9.   unsigned LATB6:1;
  10.   unsigned LATB7:1;
  11. } LATBbits;


Szerintem elég lehet magát a structúrát leírni újra, csak más hivatkozásnevet kell legalul megadni a LATBbits helyett.
(#) watt válasza zenetom hozzászólására (») Júl 3, 2011 /
 
Idézet:
„PORTSAJAT 8 bites legyen, és lehessen neki értéket adni, aminek megfelelően állnak be a különböző portok”


  1. #define SajátPortnév  PORTB(vagy LATB)


  1. SajátPortnév  = 25;
(#) zenetom válasza watt hozzászólására (») Júl 3, 2011 /
 
De ez csak RB-re vonatkozik. :hide:
Köszi az eddigieket, megpróbálok már valami összeállítani.
:yes:
(#) watt válasza zenetom hozzászólására (») Júl 3, 2011 /
 
Nem értem akkor, hogy mit akarsz!
(#) zenetom válasza watt hozzászólására (») Júl 3, 2011 /
 
Tegyük fel, van egy eszközünk, amivel kommunikál a PIC. A kommunikációs csatorna 8 bites (mint pl.: az LPT adat bitei). De nekünk nincs a PIC-en egy teljes szabad portunk, és egyszerre szeretnénk egy byte-ot kiküldeni az eszköznek.
Szerk.: tudom hogy maszkolással meg lehet oldani, de kíváncsi vagyok, hogy máshogy is meg lehet-e. Most nézem a portdefiníciós header fájlt, és abból merítek ihletet.
(#) watt válasza zenetom hozzászólására (») Júl 3, 2011 /
 
Valamilyen konverzió szükséges a programban ilyen esetekben, legyen az egy maszk előkészítése, vagy a portok bitjeinek egyenkénti beállítása az adat szerint. Hogy ezt egy makróval oldod meg, vagy egy szubrutinnal, majdnem mindegy, bár a makró mindenhová beül ahová beírod a rutin viszont lehet lassabb. Az ilyen megoldásoknál azt is figyelembe kell venni, hogy az adat ne kerülhet ki egyidőben a célportra, hanem legkevesebb annyi lépésben, ahány portra oszlik az adat. Ezért kerülni kell az ilyen megoldásokat, ha sebességkritikus a vezérlés. Lassabb eszközök esetén, mint pl. az LCD, 2..3 portra el lehet osztani, bár a 4bites vezérlési mód majdnem mindig elfér egy port egy részén.

Több portot nem fogsz tudni egy struktúrába fogni.
(#) zenetom válasza watt hozzászólására (») Júl 3, 2011 /
 
Idézet:
„Több portot nem fogsz tudni egy struktúrába fogni.”

Hogy én mindig megtalálom a prog. nyelvek határait...
Akkor marad a maszkolás.
Köszi hogy írtál!
(#) watt válasza zenetom hozzászólására (») Júl 3, 2011 /
 
Ez igazából fizikai korlát.
A maszkolást lehet makróval, vagy szubrutinnal. Használata így is kényelmes lehet.
(#) icserny válasza watt hozzászólására (») Júl 3, 2011 /
 
Idézet:
„Az ilyen megoldásoknál azt is figyelembe kell venni, hogy az adat ne kerülhet ki egyidőben a célportra, hanem legkevesebb annyi lépésben, ahány portra oszlik az adat. Ezért kerülni kell az ilyen megoldásokat, ha sebességkritikus a vezérlés.”
Ez fontos szempont, amit felvetettél. Meg kell vizsgálni a kapcsolást abból a szempontból, hogy okoz-e működési zavart az, hogyha az adatbitek nem egyidőben jelennek meg. Az audio DAC-nál például kellemetlen impulzusokat okozhat az adatbitek nem egyidejű beállása (glitch). Az LCD-nél nincs gond, mert ott az adatbeírás egy külön vezérlőimpulzus hatására történik, s azt akkor adod ki, amikor az adatbitek mindegyike beállt már.

Kritikus esetben egy külső adatregisztert kell beépíteni az áramkörbe. Ez lehet soros-párhuzamos átalakító is, mint pl. a Microchip I2C vagy SPI portbővítő IC-jei.
Következő: »»   41 / 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