Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Légy szíves valami képfileban feltenni a rajzot!
Nálam az ingyenes Eagle azt mondja rá, hogy sérült, vagy illegális Eagle verzióval lett csinálva.
Az Eagle-5.6.0 Lite szereti.
Egészségedre!
A termisztort levehetnéd próbaképpen! Én inkább arra gyanakodnék (mármint a vezetékére), nem a kijelzőre.
Sziasztok!
Segítségeteket szeretném kérni. A konkrét probléma az, hogy ha az USART -on küldök pl. egy hexa 10-es értéket, akkor az őt követő switch-case parancson belül nem ugrik a "case 16:" -ra, hanem a default részre. Beszúrtam az alábbi sort kód a legelejére, hibakeresés céljából:
A csatolt képen látható, hogy milyen értékek jönnek vissza. Érdekes, hogy pl. a 33 visszajön.
Esetleg probalkozhatsz az LCD adat ill vezerlo vonalaira egy-egy 50pF kornyeken levo keramiaval is.
Megoldódott a probléma. Az OpenUSART() -ból hiányzott a "USART_BRGH_LOW" paraméter. Nem tudom, hogy hagyhattam le
 Bocs a felesleges kérdésért.
Már majdnem írtam, hogy biztosan jó-e a Baud Rate, de látom már minden okés...
Próbáld meg, hogy a 4MHz-es kritály mellé 33pF kondikat teszel. A 15pF inkább a 20MHz mellé való.
Az MCLR lábra is tegyél egy 100n-t.
Az analog bemenetet sem szoktuk kondi nélkül tervezni. Oda is érdemes lenne egy 100n. (Még akkor is, he nem ez a baj.)
Vagy még inkább a termisztor osztópontjáról minimum egy RC taggal"szűrt" jelet vezetni az analóg bemenetre. Vagy méginkább RCR hálózatot használnék.
Igen, én is RCR-t szoktam(?R, 1..100n, 2k2 -> ANx). Ha osztó is van, akkor R/RCR. Ha van veszélye, hogy a fesz túlhaladja az A/D bemeneten megengedettet, akkor még egy 5,1-es, vagy 4,7-es zenert is be szoktam tenni, ha nem hamisítja a mérést. Ha hamisítja, akkor tranyós védelem...
Van benne igazság mert míg nem volt rajta a termisztor addig nem is fagyott le soha, csak miután rátettem és visszakerült az áramkör a motorra utána rögtön össze vissza ugrált a sebeség kijelzés amikor forgott a kerék de ezt megoldottam, de a fagyással nem tudok mit kezdeni.
Leforrasztom a termisztort és megnézem mi lesz, hát berosálok ha az a baja. De ha az is a baja akkor egy árnyékolt vezetékkel elvileg megoldható ugye? És írok a programba egy részt ami egy ledet villogtat másodpercenként egyszer és kiderül melyik fagy le a kijelző vagy a PIC. Ezt a timer0 felhaszánlásával tervezem úgy hogy 1:256 os előosztást választok ki és minden túlcsorduláskor növelek egy regisztert. Kiszámolom azt hogy meddig kell növelni a regisztert hogy kb 1 másodperces legyen a villogási sebesség. Elvileg a port lába elbír egy ledet 10mA áramaml.
Árnyékolt vezetéket nem hinném, inkább a pic oldalára kell az említett diódás illetve RC szűrős megoldást odatennni.
Szia!
A sok új típus miatt egyre több az Errata. Sok csúnyaság szokott bennük lenni. Egy tÍpusnál több kiadása is lehet és még azt is tudni kell, milyen verziójú az a példány, amit programozunk.
Sziasztok!
Mai napi felfedezes, hogy a Microchip-nek van egy speci microcontroller csaladja (lehet tobb is nem tudom) amelyik kifejezetten nagy felhasznaloknak es elsosorban a Nagy Kina teruletere keszult (Greater China, nem tudom jol irom-e magyarul?). A nagy felhasznalok gondolom 100 ezres vagy meg ennel is tobb peldanyszamban rendelnek, de ez csak egy feltetelezes mert nincs semmi konkret info a reszletekrol. Ez az MCVxx csalad ami ugy tudnik a PIC baseline alapjaival kozoskodik. Kulonosebb infot errol a Microchip oldalan nem talaltam (sem a keresojevel, sem a product tree-ben sem pedig a MAPS-ben nem latszik a termek). Ha a tpusszamra rakeresek a googlival akkor fokent kinai site-okkal talalkozom ahol az MCU-t meg lehet rendelni. Az egyetlen nyom ami elarulja, hogy ez nem egy esetleges hamisitvany, hogy az adatlap letoltheto a Microchip oldalarol: MCV14A DataSheet Ha minden igaz ki lehet ezzel ill a csalad mas tagjaival valtani nehany PIC baseline-t: Idezet egy kinai nyelvu forumrol -- Google-lal nagyjabol angolra lehet forditani
Amit meg sikerult kideriteni, hogy ez egy olcsobb valtozata a PIC-eknek, ami egyreszt magaval hordozza hogy nincs a Microchip altal teljes mertekben letesztelve (azt a felhasznalo teszi meg), masreszt nincs olyan bo valasztek tokozasban. Idézet: „De ha az is a baja akkor egy árnyékolt vezetékkel elvileg megoldható ugye?” Van egy olyan gyanúm, hogy az antennaként működő vezeték a tápfeszre visz tüskéket. Ott kellene valami zavarszűrés. Induktivitás és kapacitás (vannak gyári zavarszűrők is) lenne szerintem a legjobb, mert az nem szól bele a termisztoros osztód lelkivilágába.
Hogy mik vannak ! Még jó hogy a "normál" baseline tipusok se túl drágák. Gondolom azért nem veri nagy dobra ennek a létezését, mert nem akar magának konkurenciát házon belül sem.
Érdekes lesz, ha ezeket a "nem teljes mértékben letesztelt" vezérlőket ilyen "ICD2"-vel debug-olják!
Sziasztok!
Segítséget szeretnék kérni MPLAB-MCC18 környezethez. Egy PIC18F1220-at akarok felprogramozni, de elkadtam. Létre kellett hoznom néhány tömböt:
És vannak egyéb változóim is. A probléma az, hogy nem fordul le a kód:
Nem akarok már több tömböt, de amik vannak, kellenének. Nincs valami trükk, hogy elférjenek a memóriában és leforduljon a kód? Mit kellene tennem? Köszi Zoli
Használd az acces ram területet is, mert a simából alig marad szabad mivel a stack-et is oda teszi a fordító.
Nem történne semmi az A/D bemenetre kerülő feszültséggel. Az A/D bemenet elég nagy impedanciát képvisel ahhoz, hogy a bemenettel sorbakötött pár k-s ellenállás a DC szintbe ne szóljon bele. A soros ellenállás -> párhuzamos kondenzátor -> soros ellenállás így nem fogja elállítani a belőtt skáládat, csupán a nagyobb frekvenciás zavarokat fogja eliminálni. A hőmérséklet-mérésnél amúgy is olyan lassú a változás, hogy nincs szükség gyors mérésekre és nagy sávszélességre.
Sajnos még mindig ugyanaz a helyzet, hiába írtam oda az access kulcsszót.
Nem ismerem a C18-at, de hi-tech nél volt olyanom, hogy egy függvény akkora lett hogy nem fért bele a psect-be, bármi is legyen az. Felosztottam kisebb darabokra, és úgy már jó lett. Lehet hogy nálad a main nagyon nagy, csinálj pár függvényt, átláthatóbb is lesz a main tőle.
Ebben lehet valami lidi, az az uzenet szerintem inkabb a kod meretre utal minthogy a ram-ra. Ott van, hogy a
tehat egy min ekkora kod szekcionak kellene lennie a linker scriptben -- mar feltetelezve, hogy egyaltalan van-e osszessegeben ekkora kod terulete a kerdeses PIC-nek? Szerk: Mar latom, 18F1220 -- annak ugye 2kword program tara van, annak elegendonek kell lennie -- akkor lehet a linker scripttel kell farigcsalni vagy a darabolasos modszer hatha segit.
Szia!
Már én is olvasgatom. Több, mint érdekes, amit a kinai írt: A 16F630-ban pl. 8 mélységű a stack, a MCV14A-ban pedig 2. ("Can replace...") Az MCV14A-ban van A/D konverter, így keveredethetett ide a 16F630 - 676. A többiről még nincs adatlap... Más programjukban is van "problems introduced": Az MPlab 8.15 még jól tette fel a kérdést, hogy a megnyitott lista állományt frissítse-e a fordítás után, ha hibát talált. A 8.30 és a 8.33 hibás fordítás után a kérdést csak akkor tesz fel, ha a fókuszt elveszti és visszakapja. Szia. Idézet: „A 16F630-ban pl. 8 mélységű a stack, a MCV14A-ban pedig 2. ("Can replace...") Az MCV14A-ban van A/D konverter, így keveredethetett ide a 16F630 - 676.” Ez a 2 szintu stack dolog normalis lehet mert az MCVxx csalad ugye a baseline-on alapszik, a 16F630 me mid-range-es. gondolom a kivaltasnal nem azt ertettek, hogy 100% kod kompatibilitas, hanem hogy amit esetleg 16F630-cal megtehetsz valoszinuleg ezzel az MCV14A-val is megteheted? Amugy kinai nyelvu adatlapot talaltam... nem sikerult meg kiexportalni es lefordittatni.... viszont... a nagy keresgelesekben egyre erdekesebb helyekre jutok  Pl PIC16C5X kompatibilis TSK165x
Értem, és tényleg az volt a baja mert elvágtam most a hőmérő vezetékeit és mentem vele kb 10km-ert és egyszer sem fagyott le. Tökéletesen működik. Kipróbálom az általatok említett RC szűrőt és köszönöm a segítséget mindenkinek.
Még a dudára kell tennem valami kondit mert az megzavarja még az elektromechanikus fordulatszámmérőt is pedig az gyári. Szerintem párszáz nF párhuzamosan vele megoldja ezt a problémát is.
Frekimérést(négyszögjel) C be hogy érdemes megoldani, ha kb 0-4khz ig kéne mérnem(pontosság nem szükséges)?
Periódusidőt mérjek, vagy x idő alatti periódusokat? Gondolom célszerű előbbinél a T0 számláló túlcsordulását számolni. Esetleg valaki egy kódrészlettel ha megdobna azt is megköszönném |
Bejelentkezés
Hirdetés |
