Fórum témák
» Több friss téma |
Idézet: Az adatlap szerint a 8-as láb RB0! „ha elrontották és a 8-as láb valójában már az RB0, akkor az mindent megmagyarázna.”
Igen, sajnos elrontottam a panelemet. Sikerült összekevernem a TQFP tokozást QFN-nel.
Köszönöm azoknak, akik segíteni probáltak. lutyii
Egyebkent van valami ertelmes oka, hogy egy ilyen esetben NEM egyezik meg a labkiosztas?
Belul a szilicium gondolom tok ugyanaz.
Személyes megfigyelésem szerint az egyes tokozás típusokra vannak "hagyomány"-ok, amik alapján elrendezik a lábkiosztást, és az sokkal dominánsabb elv, mint akár a pic típusjele.
Hagyomány? Megfontolás illetve tervezés.
pl. - Nagy dip toknál jellemzően miért van a tápbevezetés középső lábon? A tokon belüli kivezetés rövidebb. - Nagyobb tokokon miért van több táp illetve föld láb? A hozzávezetés impedanciájának csökkentésére. - Miért is kell minden táp és föld lábat bekötni? Az un. ground bounce (föld hozzávezetésen keletkező potenciál eltolódás) csökkentésre. - Az oszcillátor lábak miért vannak a föld kivezetés közelében? Egy jobban megtervezett panelen ezeket a kivezetéseket és a hozzájuk kapcsolódó elemek kivezetését egy un. guard ring (árnyékoló gyűrű) veszi körül, hogy csökkentsék az arra haladó jelek hatását az oszcillátorra. stb. Ezekre az okokra egyébként akkor derül fény, ha a tokba beleláthatnánk. Persze aki gyártja, annak vannak dokumentációi a tokon belüli vezetékezésről.
Valaki megtudná mondani, hogy a WATT égetőáramköre a WPB programmal vagy a WinPIC800-zal miért csak az I/P tokozású PIC-jeimet ismeri fel?
A 16F628-ból 20/P és 20I/P tokozásúakat kaptam (csak) és nem ismerik fel. A 16F88 I/P-t és 16F684 I/P-t igen.  Idézet: „Valaki mérte már meg, mit tudnak sebességre a pic32mx1-esek ? Ram-ba töltve biztos viszi a program a 40mhz-et, de mi a szitu flash-ből?” Flashből is viszi. Én egy 220-assal játszottam, és bizony egy utasítás - egy órajel. Egy invertálás oda, egy invertálás vissza - ez két órajel, 40MHz-en pontosan 50us lesz (20Mhz-es kimenő jel). Ha ciklusban akarod csinálni, akkor viszont kell jump is bele előbb-utóbb, úgy viszont egy nop, egy invertálás, egy jump, egy invertálás kóddal felére csökken az effektív frekvencia, azaz 100us (= 10MHz-es kimenő jel).
Hali!
PIC18f4550/C18-hoz keresek UART programozásához példaprogramot. A soros átvitel programozásával akarok megismerkedni. Üdv.
Hali!
Köszi, az USB CDC és HID programozásán már 'átrágtam magam' , jelenleg a RX/TX programozásával próbálkozom. Üdv.
Az USB Device - CDC Serial Emulator gyári demót is nézd meg , abban benne van a soros port kezelése is.
De nézegetheted a PICula projektemet is, mert abban ugyan PIC18F4520 szerepel, de a soros port kezelése ugyanúgy történik a 4550-nél is. Ha CTS/RTS vonalakat is akarsz vezérelni, akkor az utóbbi nem tökéltes számodra, mert én csak az RX/TX jeleket kezelem (ezen jelek nálam egy CP2102 USB/UART protokol konverterhez csatlakoznak, de ez már részletkérdés).
Hali!
Köszi a tippeket, egyenlőre csak az RX/TX-t akarom kezelni. A PICula projekbe benéztem, de ezek szerint nem kellően. Üdv.
Hali!
Nézegetem és próbálom értelmezni a megadott forrásokat és kérdésem a következő: a PICCOLO project keretében van lehetőség az USB HID kominikáció mellett és közben az RX/TX-n adatok belolvasására? Üdv. Idézet: A PICCOLO projektben USB CDC kommunikáció van, nem HID (HID kapcsolatot csak a bootloader használ).„a PICCOLO project keretében van lehetőség az USB HID kominikáció mellett és közben az RX/TX-n adatok belolvasására?” Elvileg lehet mellette soros porti kapcsolat, de az "intelligens megoldásoknak" (pl. printf használata) határt szab az, hogy C18-ban a STDIO csak két eszköz kezelésére (pl. USB CDC és LCD) van felkészítve. Gondot okozhat névütközés is. Most fejből nem emlékszem, de lehet, hogy az egyik projektben azokat a függvényneveket használom a soros port kezelésére, amelyeket a másik projektben az USB CDC kezelésére. Kell tehát némi kreativiás, ha ezeket össze akarod házasítani. Elvi akadálya nincs...
Hali!
Köszönöm, az elvi lehetőségre voltam kíváncsi. A függvénynév azonosságokat észrevettem. Majd a módosításokat megcsinálom mint a CDC helyett a HID USB kapcsolatot. Üdv.
Sziasztok!
PIC16F-nél ha C-ből hívok assembly függvényt, aminek a prototípusa void func(int t), akkor hová kerül a paraméter? W-ben lesz az LSB? És hol lesz az MSB? És miért nincsen leírva ez sehol konkrétan (nem találom)?  Köszönöm a válaszokat! Üdv, Thomy
Szervusz!
A paraméterek a paraméter listában megadott változókban lesznek a a RAM-ban, itt konkrétan a "t" nevű változóban lesz a paraméter. Nem tudom miért is keresed a munkaregiszterekben, a C nem erről szól. Üdv. István
Szia!
Megnézve, mit művel a fordító, a kérdéses 2 byte-nyi paraméterem a 0x70 és 0x71 címen lévő GPR-ekbe kerülnek (a paraméterek ált. regiszterekben kerülnek átadásra RISC-nél, mert ez nagyon gyors. Az, hogy C, mit számít?). A kérdés itt főleg az, hogy honnan tudom, hogy oda fogja tenni, bárhonnan is hívom meg az assembly kódomat? Vagy lehetséges assemblyben hivatkozni egy paraméterre a nevével? Kicsit kontransztba álíltva: pl ARM-nál megadják a calling conventiont, hogy "ha ilyen a paraméter, akkor ebben a regiszterben kell keresni". Üdv,Thomy
A paraméterek száma és mérete szinte korlátlan lehet, a PIC munkaregisztereké viszont koránt sem...
Nem kell tudnod fizikailag hova teszi, majd a fordító gondoskodik róla (többek közt ezért is számít hogy C), esetleg optimalizálhat ha csak byte vagy int hosszúságú a paraméter és látja hogy a függvényben a paramétert az első lépésben felhasználod egy műveletben, nem kell tovább tárolnia későbbi felhasználásra a függvényben. Igen a beszúrt assemblerben is lehet hivatkozni a paraméter nevével, pl. az alábbi CCSC kódrészletben az i3, i4, i5 változóval, igaz ezek lokális változók, de a paraméterek is ugyanolyan változók, a függvényben ugyanúgy használhatók.
Szia!
Értem, köszönöm. Meg tudnád mondani, hogy hogyan kell a következő kódrészletet helyesen megírni?
Itt akadtam el, mert nem találom a hívási konvenciót. Üdv Thomy
Szervusz!
Így már értem a gondodat, "extern" assembler modult akarsz meghívni PIC C-ből! Ezt valószínűleg C fordítónként eltérő módon lehet kezelni. Ha megmondod milyen C-vel akarod megoldani a dolgot akkor lehet, tényleg tud majd valaki segíteni. Ennyit találtam hirtelen a problémáról HI-tech C-re:External Assembly Module Én általában megmaradok a C nyelv eszközeinél, ha muszáj pár sor beszúrt assemblert írok. Ha teljesen assemblerben megírt modult kellene beilleszteni, akkor is egy C függvényben helyezném el, amely gondosodna a paraméterek átvételéről és ha kell a visszatérési érték átadásáról a hívó függvény részére.
Szia!
A kérdésemet így is megoldottad, megpróbálom megírni inline assemblyként. Köszi! Üdv, Thomy
"ha muszáj pár sor beszúrt assemblert írok."
Bocsi a kukacoskodásért, de az Assembly nyelv fordítóját hívják assemblernek.
Kedves hozzáértők...
Szeretnék egy feladat elvégzése után "elaltatni" egy 12F675-öt... Hogyan fogjak hozzá? ...vagy elég ha delayt rakok egy ciklusba és akkor mivel semmi dolga - nem fogyaszt?
Sziasztok!
Az alábbi problémára keresek választ. A portot (TRISB) kimenetnek konfigurálom. A LATB-re kiírom a (B'11111111) értéket, a WATCH ablakban ha megnézem a LATB értékét, akkor nem a D'255'-öt kapom vissza, hanem D'224'-et. Megnéztem a PORTB regisztert is, de a jelenség ugyan az. LISTP=PIC18F4550; lista megadása INCLUDE RADIXhex; alapértelmezet számrendszer megadása org0x0020; program memoria kezdő címe movlwb'00000000' movwfTRISB MAIN movlwb'00000000' movwfLATB nop movlwb'11111111' movwfLATB GOTOMAIN; ugrás a MAIN címkére END üdv. VFR72
Szia!
Az RB0.. 3 analóg módban van. Ld. ADCON1 regiszter vagy a Config3H regiszter PBADEN bitje. ((6000))
Szia!
Köszönöm a gyors segítséget. Hogy erre miért nem gondoltam... üdv. VFR72 |
Bejelentkezés
Hirdetés |
