Sziasztok

Sajnos akárhogy próbálkozom nem sikerül sehogy sem megvalósítani az input beállítást, hiába próbálkozom videókkal vagy próbafeladatokkal másoknak működik nekem nem. Tudnátok nekem adni egy működő példaprogramot ami felvillant valahol egy led-et ha valahova adok +5v-ot? pic16F887 -essel próbálkozom mikroC ben. Eddig Bport nulladik bitjének a lábát állítottam be inputnak ahogy a Button tutorial mutatta a library manager ben, de csak az input világít és sehogy sem csinál semmit. Köszi

Valószínűleg nincs letiltva az analóg bemenet a B0 lábon. Adatlap ANSELH regiszter. Hogy a mikroc librarykben hogy kell tiltani, fogalmam sincs.

Valaki tudna segíteni!Feltettem az MPLAB IDE 8.91-et.Van egy usb pic kit2-m.
Ezt a progi akarom rajta futtatni.

LIST p=16F628A ; a processzor típusát közli az assemblerrel
#include <P16F628A.inc> ; alapértelmezett beállítások a chip-hez
ERRORLEVEL 0,-302 ; elnyomja a bank-váltás üzeneteit
__config 0x3D18 ; konfigurációs értékek (oszcillátor,stb.)
org 0x0000 ; beállítja a 16F628-as kezdeti címét
; (itt indul a program)
Start
movlw 0x07
movwf CMCON ; kikapcsoljuk a komparátort
; (így a 16F84-re hasonlít)
bsf STATUS,RP0 ; kiválasztjuk a Register Page 1-et
movlw b'00000000' ; kimenetként állítjuk be az összes lábat
movwf TRISA ; (mindkét porton)
movwf TRISB
bcf STATUS,RP0 ; vissza a Register Page 0-ra
Cimke
movlw 0xff ; bekapcsoljuk az összes bitet
movwf PORTA ; (mindkét porton)
movwf PORTB
nop ; a NOP a GOTO-val együtt négyszögjelet
nop ; állít elő a kimeneten
movlw 0x00 ; kikapcsoljuk az összes bitet
movwf PORTA ; (mindkét porton)
movwf PORTB
goto Cimke ; ugrás a ciklus elejére (végtelen ismétlés)

end

BUILD FAIL ra fut. Nem tudom mit ronthattam el.
Nagy segítség lenne nekem,mint kezdő,ha valaki tudna egy olyan config-ot,küldeni,amivel feléledne a pic-em.

Az org 0x0000 arra utal, hogy absolute moódban kell fordítani. De ez Assembly nyelv, inkább a PIC kezdőknek topikban a helye.

Véletlen szám generáláshoz PIC18F46K80 procit próbálom úgy belőni, hogy a timer fusson a SLEEP alatt is. Gondoltam elaltatom, majd a WDT ébreszti, közben a timer fut.
Amikor ébred akkor a timer mindig más lesz, hiszen az quartz a WDT meg RC.
Csak nem műkodik az MPLAB szimulátorban.
Lehet egyáltalán ilyet csinálni ?
Vagy a quartz oszci leáll mindenképpen ?



Lehet menet közben átállítani a WDT osztót ?
hi-tech C nem enged 2 db __CONFIG( 2, ... ) makrót !

A sleep leállítja a kvarcot is, kivéve a timer1 kvarcát.

__CONFIG helyett próbáld a

formát. A konfig bitek pontos neveit megtalálod a Program Files\Microchip\xc8\v1.21\docs\chips\ mappában levő fájlokban.

C18-ban nem lehet a TMR1 értékét olvasni? Kiabál a fordító, hogy nincs ilyen regiszter...
Szerk.: 18F1320
Szerk2.: a header fájlban is csak H meg L regiszter van. Ez szégyen.

Miért ne lehetne? A PIC-ben is csak H és L van, ehhez igazodj. Nézd meg az adatlapban a sémaábrán, hogyan van megoldva a 16bites Timer kiolvasása, hogy szinkronban legyen. A 18F 8 bites...

Gondoltam, hogy ha már C, akkor van annyira intelligens, hogy nem kell játszadozni alsó meg felső bájtokkal, de tévedtem.
Ez most úgy tűnik mint ha hisztiznék, de nem...

Hát, végül is megcsinálhatták volna, ez igaz.

Meg is írták: a <telepítési mappa>\src\pmc_common\Timers\t1read.c -ben...

Mondjuk én még sehol sem találkoztam olyannal, hogy hardveres regisztereket egyben kezelt volna a fordító így direktben. Meg most pl. Timer esetén így kell, esetleges másik regiszterpárnál másképp kellene kezelni, stb., túl macerás. Esetleg vannak ezek a makrók meg függvények (Pl. OpenUart). Sosem szoktam ezeket használni, nem tudom, timerre mit tudnak.

Én sem. Viszont egyszerűnek tűnik, de lehet nem az.

A C mivel az asm kiváltására készült nagy hangsúlyt fektet a változó típusokra. Ez alapvető dolog !
A Microchip nem a C nyelv....nehogy a kutya farka csóválja a kutyát !
Szegény fordítóprogram íróknak igazodni kell a vashoz !
A pic18.h -ban van egy rahedli makró !
READTIMERx()
Az x természetesen nem x !!!

A Hi-Tech PICC18-ban nincs #pragma config.
Jó pár éve gyúrom a PIC-eket, de eddig sosem kellet a config-on futás közben módosítanom. Úgy tűnik menet közben nem is lehet. Pedig hasznos lenne a WDT időt kódból állítani !

A WDT LF-INTOSC-ből kap jelet. Ha a proci másik belső osciból megy akkor a WDT és a timer1 nincsenek szinkronban.
A doksi ezt írja :
In RC_IDLE mode, the CPU is disabled but the peripherals continue to be clocked from the internal oscillator block using the INTOSC multiplexer.

Csinált ilyet valaki ?
Elég bonyolult kibitelgetni.
Olyasmi kellene hogy RC oscillátorból induljon, majd RC_IDLE mód, amikor valamelyik timer fut. A WDT ébreszt és akkor a timer véletlent mutat.

INTSRC = 1; // 31.25 kHz device clock is derived from 16 MHz INTOSC source (divide-by-512 enabled, HF-INTOSC)
SCS1 = 1; // 1x = Internal oscillator block (LF-INTOSC, MF-INTOSC or HF-INTOSC)

Köszi a segítséget előre is ...

Köszi, majd megnézem.
Kit6263: azért nem annyira szegények a programozók...

sziasztok már kezdek nagyon ideges lenni, mikroc -ben a példaprogramot lemásoltam 2x16 os lcd kijelzőre összekötöttem ahogy a példában van azzal a pic-kel ami a példában van. Elsőre működött is de aztán valamiért eltűnt a fenti 16-os sor és csak az alsó 16 sor világít a kijelzőn de az viszont mindig. Rendeltem egy új kijelzőt és ugyan az a baja. mi lehet a gond?

Lehet, hogy a macska ráhpisilt...

Kontrasztfesz rendben, nem túl sok? Bár fordítva szokott lenni, procitól jöbő inicializás nélkül a felső sor szokott sötét lenni. A proci elindul, tudsz egy ledet villogtatni?

Ha kipróbált programmal nem megy a kijelző, az esete 99 %-ban bizonytalan kontaktus, vagy elkötés miatt szokott lenni.

köszönöm a gyors választ, ezeket mind végigpörgettem. Másik pic másik lcd másik égető platform. 1 hét kínlódás után rájöttem hogy a program project indításakor nem adtam meg azt az órajelet hogy megegyezzen a kvarcom értékével. Elsőnek biztos jó volt csak kontaktos lett :s így nem indult el az lcd de a ledek még villogtak a portokon. sunyi kis hiba egy nem odafigyelésből.

Sziasztok!

Egy 18f14k50 típusú PIC-et igyekszem felprogramozni (Datasheet itt) és egy igen meglepő hibába ütközök: amikor a beégetett programot futtatom az eszközön, akkor nem csinál semmit, viszont ha megérintem ujjal az RA5-ös lábat akkor a beégetett szoftvernek megfelelően fut. (ha bármi mással érintem meg, vagy földre húzom, netán tápot adok neki akkor nem csinál semmit. Csak és kizárólag ha ujjal érek hozzá) Proteus Isis szimulátoron is jól működik a program.
A kapcsolás csak egy led-ből áll 300 Ohm-os előtét ellenállással. A hiba akkor is fent állt amikor nem az alább mellékelt kódot égettem bele, csak egy egyszerű "kapcsold be a ledet" programot. Mellékelem a .hex file-t is.
Előre is köszönöm a segítséget!

////////////////////////////////////////////////////////////////////////////////////
#include < p18f14k50.h >
#include < pwm.h >

void main(void)
{
OpenPWM1(0xFF);
SetOutputPWM1 (SINGLE_OUT, PWM_MODE_1);
SetDCPWM1(512);
}
////////////////////////////////////////////////////////////////////////////////////

Bár off, de fel van húzva az MCLR 10k-val Vdd-re? Van 100n a Vdd és a Vss között? Bármilyen konfigurációt csináltál? Mert a programból az derül ki, hogy nem...

Mert az az oszcillátor bemenete, és várja az órajelet. A kezedről 50Hz megy bele neki.

SZÉGYEN GYALÁZAT !!!
46k80-as procit gyúrom !
pic18.h-ban ez van :
#define T1RD16ON T1CON|=0x80
RD16 - az az 1. bit --- nagy blamázs !
Van nagyobb is !!!
MPLAB szimulátorban :
Ha az RD16 bit be van kapcsolva akkor leáll a Timer1.
Ha nem kapcsolom be akkor meg a 16 bites olvasás túlcsordulásnál hibás lesz !



Állítólag Microchip adja el a legtöbb procit a világon !

Szia!
A szimulátor csinálja a dolgát. A RD16 módban TMR1H -ba akkor tárolódik ay érték, ha a TMR1L -t olvassák. A TMR1 szimbólum a TMR1L -vel azonos.

|gy már jó lesz. Ha a watch ablakben szeretnéd nézni, akkor a TMR1 helyett a TMR1_internal szimbólumot használd (16 bites kijelzéssel).

Sajnos sokkal rosszabb a helyzet !!!
A proci tudja a 16 bites kiolvasást.

Ha futó timert olvasok 8 biten ( az L-t és H-t külön ), akkor ellenőrizni kell a túlcsordulást :
Read H
Read L
Read H - Ha ez nem egyezik az előzővel akkor a két olvasás között rollover volt és újra kell olvasni !

Ha ezt nem teszed meg véletlenszerűen rossz értéket kaphatsz.
Kicsi az esély, de van !

Az MPLAB sajnos bug-os...nem kicsit nagyon !
Szerintem :
A K-s procik elég újak és már kifele mentek az MPLAB-ból, hát nem igazán foglalkoztak vele és nem is igen fogják megcsinálni.
Most szerintem a 8.92 az utolsó.
Felraktam az MPLABX-et és az jól csinálja !

Meg kell nézd és megértsd a Timer1 16bites működési módját(adatlap, rajz), akkor más lesz a véleményed!
Ahogy Hp41C már írta neked a helyes kiolvasási sorrendet, azt kell követned! Ez tiszta hardver függő dolog, nem lehet megerőszakolni. Írásnál először a TMR1H "puffert" kell feltölteni, majd a TMR1L-be íráskor beíródik a H- is. Olvasáskor fordítva. Először az L-t kell kiolvasni, amikor is egyidőben a H is betöltődik. Ekkor lehet kiolvasni, eltárolni.
Nem rossz az az MPLAB szimulátor...

Szia! Jó volt a tipp, bár volt konfig beállítás (mplab automatán hozzácsapja a hexhez a konfigot, de az a kódban nem jelenik meg) csak nem volt az oscillator jól beállítva. Már jó és fut is rendesen az összes dolog amit szeretnék, kivéve egy valamit, de azt leírom inkább válaszon kívül a következő kommentben.

Köszönöm a válaszodat és pepe1125 válaszát is!

Sziasztok!

Szervó-t szeretnék vezérelni, nagyjából mindegy milyen módon. Jóó, nem teljesen, de már akkor is boldog(abb) ember lennék ha valahogy legalább működne.
3 lehetséges módot vadásztam össze a netről:

1: PWM
2: timer+delay
3: delay

Vegyük sorra:
PWM: Fogalmam sincs, hogy hogy állítsam be a PWM-et 50Hz környékére, szóval itt megbukott a mutatvány. Nyilván ha az menne, akkor csak a kitöltési értékkel kéne játszani és a motor működne.

Timer+delay: Ez úgy működne, hogy a Timerrel számolok kb 20ms-ig aztán ürítem a tárolót és ráadom a szervó vezérlő lábára a villanyt, némi (0,9ms-2,1ms) időt delay-ben tölt a pic, aztán elveszem az áramot és a ciklus kezdődik elölről. Ehhez a módszerhez mellékelek kódot is, mert ezzel próbálkoztam. A kis motorocska ment egyszer jobbra, egyszer balra, de mindig ütközésig. Nem sikerült jó helyre hangolnom. Gondolom az órajeltől, a timer előosztójától és a számláló 8 vagy 16 bites tárolójától függ az, hogy tényleg 20ms-onként csordul-e túl a timer. Na, ezt nem sikerült belőni. (állítottam kódból az OSCCON-t, remélem jól, de ez sem biztos )



Delay: Ez tisztán delay alapú vezérlés, nyilván nagyon amatőr, a teljes processzoridőt megeszi, viszont így sem sikerült az elvárt működésre rábeszélni a motort . ehhez is mellékelem a kódot. (a delay beállítások a mellékelt kódban szinte teljesen randomok már, mert minél többféle képpen próbálkoztam vele, sikertelenül)



Szóval a rengeteg szócséplés után (amiért szíves elnézéseteket kérem) az lenne a kérdésem, hogy miként kéne kivitelezni szegény szervonak a vezérlését? Főleg a PWM alapú megoldás érdekelne.
pic18f14k50-es pic-et és Tower pro sg90-es servo-t használok.

Előre is köszönöm a válaszokat!
Üdv!

Egy tanulságos történet:
Vont réges - régen, egy (nem is annyira) messzi - messzi (nem is annyira) galaxisban....
Volt két compiler a 18F -ekhez (talán még több is, de ez most nem lényeges): A HiTech és a Microchip C18. Mindketten működtek szépen, ki - ki használta azt, amit szeretett. Aztán az ellenség keze betette a lábát. A Microchip felvásárolta a HiTech fordítót és összedolgozta a C18 -cal XC8 -cá. Ekkor kezdődtek a problémák. Átvettek sok-sok megírt állományt anélkül, hogy átnézték volna. (Pl. 8 bites PIC -eknél a feltételes fordításban benne van a cooprocesszor kezelése... Majd egy 80287 sarkába felragasztom a 10F320 -at...). Mivel a régi 18F -eknél (sem J sem K nincs a típusszámban) a RD16 bit a T1CON 7. bitje volt, a HiTech megírta a makroját, a T1RD16ON -ot. Minden jó volt, hiszen a fordítójuk nem kezelte az új (J -s és K -s) 18F -eket.... Hogy blama -e, döntse el mindenki maga.
Tanulság: Nem érdemes az előre definiált makrokat és könyvtári függvényeket használni (főleg nem az egy - két utasításból álló műveletek elvégzésére). Terjengős, lassú és még hibás is...
A fenti makro 2 utasítás és elrontja a WREG -et, míg a T1CONbits.RD16 =1 csak egy BSF utasítás. Ráadásul jól olvashatóan benne lesz a forrásodban.

Az XC8 fordítónak semmi köze az MpLab keretrendszerhez, sőt ugyan az (esetleg frissebb verzió) lesz az MpLabX alatt is.
Egyébként az MpLab -ból is a 8.80 vagy még korábbit javaslok használni:
Kit nem idegesít, hogy a szimulátor, mint debugger kizárja a PICkitx -et, mint programozó egyidejű használatát (min tudnának veszekedni? Ha egy régi projectet betöltök, a mostanival is megy szépen),
Egyszer csak a verzióváltással kb. 200 Midrange kontroller (amelyeknél a WREG nem érhető el FSR -ként) esetén eltünt a WREG és a STKPTR a Watch ablak regiszter listájából.
Mintha tudatosan történtek volna... Használd már az MpLabX -et. Ahhoz való gépbővítés sajnos nem ingyenes...
Félreértés ne essék, nem akartam az XC8 -at érdemein felül mentegetni. Az ingyenes változat az assembly megoldásnál min. 4-szer (egy 2k -s 16F628 assembly program átírva nem fér bele csak a 16F1847 -be), a fizetős csak 2-szer hosszabb kódot generál. Nagy lelkesen felinstalláltam, programokkal lemértem a képességeit, majd jött az uninstall (V1.10).