Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Az IESO-t mondjuk ki kéne kapcsolni. Meg ki kéne olvasni menet közben a PLLEN állapotát, és kirakni valami kimenetre, amit multiméterrel vagy egy LED-del lehet nézni.
A VPP volna a 12V, a VCC1 volna a stabil 5V, a GND volna természetesen a test, az RB7 volna az PGC(órajelvonal), az RB6 pedig volna a PGD(adatvonal). A PIC 16F690-es lábain szerintem pedig a következők a láb bekötések- a VPP 4-es láb, a VCC1 az 1-es láb, a GND a 20-as láb, az RB7 a 10-es láb, az RB6 pedig a 11-es láb. Szerintetek jól gondolom az itt le írtakat?, így helyes volna a bekötés??.
Nem! Itt írtam le. Az adat és az órajel lábak Típusonként eltérhetnek. Ezért kell megnézni az adatlapot.
IESO mindegy mert nincs külső oszcillátorom de azért kikapcsolom, PLLEN deafult 0 de kiraktam és tényleg 0. Ha 1 be állítom akkor már rendesen el is szál az oszcilloszkópom de attól persze frekit még tudok mérni és kb tényleg meg 4 szereződik tőle a freki.
Oké értem! akkor annyi a lényeg hogy mindig meg nézem az Ic adatlapját, és majd át kötöm a lábakat az IC-é foglalatnál ha szűkséges. Na ezzel akkor rendben vagyunk, de még mindig ott van az a probléma hogy a programozóm még mindég nem tudja meg írni ezt a fajta PIC-et, de viszont ott szerepel a programban ez a fajta PIC, csak sajnos szürkén lehet látni ezt a típust, és nem lehet rá kattintani ere a típusra, ezt a problémát hogy lehet ki küszöbölni?.
Jó későn szólok, de menjünk át a PIC kezdő. fórumba.
Oda is fel tetem ugyan ezt a kérdést, folytassuk akkor ott.
Az IESO-ra én is azt hittem, hogy mindegy, de ha az adatlap azt mondja, hogy csak kvarc esetén kapcsoljuk be, akkor én nem tennék máshogy. A PLLEN pedig egyértelműen képes lenne elrontani az eredményt.
Amit még kipróbálhatsz, hogy írsz valami assembly kódot, ami fel-le állítgatja az egyik portlábat valami ismert, alacsonyabb frekivel (bsf, nop..., bcf, nop..., goto az elejére), és annak nézed a frekijét. Ha mondjuk 2MHz-re rakod, akkor a 2x1us-os periódusnak jól láthatónak kéne lennie a szkópon.
Kipróbáltam, (majdnem) ugyan az az eredmény.
Azt hiszem ezzel meg kell várnom míg holnap watt vagy icserny feljön.
A szkópod tuti? Esetleg megpróbálhatod hangfrekvenciára belőni az egyik PWM kimenetet, és "meghallgatni".
igen, tuti
Sziasztok!
Kontroller: PIC18F14K50 Probléma: USB-vel. Ennél a PIC-nél szerintetek hogy kell bekötni az USB-t? Csak mert a 251. oldali rajz szerint van egy belső 3.3V-s feszültségszabályzója, és találni a neten sok olyan kapcsolást, ahol a VUSB lábra egyszerűen tesznek egy 470nF-os kondit a föld felé, ugyanakkor PIC32MX-es tapasztalataim szerint a V-USB lábra 3.3V-ot kell kívülről adni... Illetve hova kössem a V-BUS-t például? Mivel nincs 5V toleráns lába (amikor 3.3V-ról járatom). Ne kössem be? Feszültségosztón kössem be egy megszakításos lábra? Na mindenesetre 3 szerencsétlen madzag bekötéséről beszélünk, de még nem sikerült működésre bírni, pedig építettem már néhány PIC-es panelt és eddig még egyiknek az USB-jével sem sz****m ennyit. Help please! Köszönöm, Ádám Szenvedtem-et akartál írni ugye? A hozzászólás módosítva: Júl 12, 2013
Idézet: Igen, ennyi kell. Lásd: PICCOLO projekt„találni a neten sok olyan kapcsolást, ahol a VUSB lábra egyszerűen tesznek egy 470nF-os kondit a föld felé” Idézet: Áramkorlátozó ellenállással bármelyik bemenetre. „Illetve hova kössem a V-BUS-t például?”
Sziasztok!
PIC18F25K80-nal szeretnék PID-es motorvezérlőt csinálni. Félreértés ne essék, már csináltam ilyet de akkor csak az volt a lényeg, hogy tartson egy sebességet, most viszont használni is szeretném amihez szükség volna arra, hogy tudjak rendesen időt mérni az inpout capture-rel. Viszont valamiért nem úgy viselkedik a PIC belső oszcillátora ahogy kéne. Először azt vettem észre, hogy a PWM frekvenciája nem annyi mint amennyit a PRx register értéke indokolna (50Mhz-es oszcilloszkóppal mértem meg) ezért INTIO1 módra álltam át és megmértem a CLKOUT(RA6) lábon a frekit aztán felszoroztam 4-el. így 28,57 MHz adódott, aminek ugye a belső órajelnek kéne lennie és mivel nem állítottam be leosztást (jobban mondva kiszedtem a deafult /2-es leosztást) ezért ennyinek kéne lennie a belső oszcillátor frekvenciájának is, de elvileg 16MHz a belső osszcillátor frekvenciája. Három PIC-kel is kipróbáltam de mind pontosan ugyan ezt az értéket produkálta. Ez egy gyári hiba? Ennyire megbízhatatlanok a PIC-ek belső oszcillátorai vagy én csesztem el valamit? Ez a C18 kódom (egyenlőre csak a PWM-ig jutottam ugye):
Csinálj egy Timer osztást és mérd meg egy lábon az eredményét. Ha ott is ilyen eltérést mérsz a számításokhoz képest, akkor talán a belső oszci ilyen gáz, de szerintem valami miatt nem jól méred a szkóppal a frekit. Legalább két módon meg kell győződni, hogy jól mérsz! Ekkora eltérést egy 1Hz-es LED-es villogtatás is kimutat...
A hozzászólás módosítva: Júl 12, 2013
XD a szkóp volt rossz
xd előtte 10 perccel még jó volt
Akkor megvan a hiba
Nekem viszont sikerült olyat csinálni, hogy van három teljesen egyforma áramkör, teljesen azonos program, gyakorlatilag sorozattermék. Az áramkör néhány esetben csinál visszafelé számolást, és a hátralevő időt ki is írja lcd-re másodpercenként. Na az egyik áramkörben az egyik visszaszámlálás valamiért változó sebességgel halad, lelassul, majd ismét visszaáll normálra. Nem csak a kijelző frissítése marad ki, mert szépen egyesével halad lefelé, de mondjuk három másodperc alatt megy lejjebb egyel. Miközben a háttérben valahogy mégis stimmelnek a dolgok, mert ds18b20 szenzorokat olvas, és ott ha elcsúszna az időzítés, akkor crc hibás lenne az eredmény, ezt viszont nem jelzi, hogy az lenne, mert akkor megállna az egésznek a futása. Egyébként tökéletesen működik, csak épp ez a visszaszámlálás valamiért ennyire megfogja. Pedig elvileg külső áramkörtől nem függ ilyen téren, az lcd is fix időzítésekkel dolgozik, meg a többi bemenettől sem függ a program futása. Gondolnám problémának a programban, hogy esetleg valamelyik rész soká fut le, de egyrészt úgy van megírva, hogy ilyen ne legyen, másrészt akkor a másik két áramkörben miért jó ugyanaz a program? X akta...
 hol láttál 13-at? A hozzászólás módosítva: Júl 15, 2013
Van egy perifériám, melyhez soros porton kapcsolódom.
A periféria néha önállóan is szolgáltat adatot, többnyire azonban a PIC kérésére. A periféria által küldhető kb. 40 lehetséges adat mintája a program memóriában letárolásra került. Terveim szerint a soros porti adás és vétel FIFO körforgó rendszerben működik majd. Arra kérnék segítséget miként lehetne a leghatékonyabban beazonosítani a periféria által küldött adatot a letárolt minták alapján? Milyen összehasonlítási algoritmust javasoltok?
Ha nincs sok idő a hasonlítgatásra, akkor a bináris keresést fontolgatnám. (Bár nem tudom hogy milyen összetételű adatokról van szó...)
Szia!
Én nem ismerek "véletlenszerű" számoknál ( --> adatok ) általánosan használható, jól kereső algoritmust. Sorba rendezném a lehetséges mintákat vélhető gyakoriság alapján és ilyen sorrendben próbálnám végig a mintákkal történő egyezést az első találatig! A hozzászólás módosítva: Júl 16, 2013
Hát igen: idő valóban nincs sok a hasonlítgatásra, de azért nem tűnik nagyon kiélezettnek sem a dolog Viszont a bináris kereséshez rendezett lista kell emlékeim szerint ezek meg karakterek, ráadásul értelmes szavak formájában.. Így a felezős módszer nem járhat6ó út.
Akkor talán ismertethetnéd az adatok felépítését, a kontroller típusát, esetleg a nyelvet, amit programozáshoz használsz. Úgy könnyebb segíteni...
Ha csak 40 féle minta van, akkor azt könnyen el lehet dönteni az adatok egy adott részének vizsgálatával. Igaz nem írtad, milyen hosszú egy adat, de ha hosszú, akkor elég csak egy bizonyos részt kiválasztani, ami jellemző, ha rövid, akkor pedig még rövidebb rész elég lehet. Ha szerencsés vagy, akár 5..10 karakterből meg lehet mondani melyikről is van szó.
|
Bejelentkezés
Hirdetés |
