Hali!

Nekiestem újból az egésznek!

És van valami amit megint nem értek:

Egyszer kiadok néhány utasítást, amivel vezérlő regsiztereket állítok és indítom az órát:
StartI2C()
while(SSPCON2bits.SEN)
...
StopI2C();

Idáig minden rendben.

Aztán később mikor olvasni akarnám:
StartI2C()
while(SSPCON2bits.SEN)
...
StopI2C();
Akkor itt megakad: while(SSPCON2bits.SEN)

Mit felejtek el? Mit kell resetelnem, hogy ne kerüljön végtelen ciklusba?

Köszi

Te miért a SEN bitet nézed? Az elvileg a START bit kivitelére felszólító vezérlő bit. Nem tudom most hirtelen, hogy mikor és mi állítja vissza? Én a Start bitet így viszem ki:

;--------------------------------------------------------------------
START_BIT BANK1
BSF SSPCON2,SEN
BANK0
BTFSS PIR1,SSPIF
GOTO $-1
BCF PIR1,SSPIF
RETURN

Az SSPIF az I2C vonal akcióinak visszajelzésére szolgál, ha jól emlékszem. (START, RE_START, STOP, ACK, ACK_NEG stb)

AN544 igaz a kód 17-es sorozatra iródott, de nem látom akadáját hogy átírásra kerüljön.

Hali!

Miért van az, hogy a C-ben megírt programom nem indul el rögtön, ahogy tápot kap a kártya? És a RESET sem működik megfelelően.

ASM-ben láttam, hogy van egy org KezdVect az elején! Ennek van C-ben megfelelője?

Köszi

Lehetőségek:
Nem jól van konfigolva az LVP bit.
Nincs felhúzó ellenállás a MCLR lábon.
Nincsenek jól beállítva a megszakítások(akkor is ha nem használod őket.
Egyébként annyiból, amit írtál elég nehéz kitalálni...

Értem. Azért próbáld ki, mert nekem így jól működik, és elvileg erre való az a bit.

Hi!

Ez egy teszt kártya és a chipcad-es asm progikkal nincs baj, azok indulnak rendesen. (tehát az MCLR kizárva)

Az elején beállítom: #pragma config LVP=OFF

Mire gondoltál a megszakítás kapcsán?

vannak a pragmák, egy-két változó, aztán meg a while ciklus, amiben meghívom az órát olvasó függvényt, valamint a kijelzőre írást. Aztán ennyi.

Kellene még valami?

C-hez csak kicsit értek. Nem tudom miért nem megy a C-s progi, miközben az asm-ok jól futnak.
Érdekes, mivel a C-t mindenki egyszerűbnek tartja. Ha engem kérdezel ez zöldség. Az asm-ot sokkal könnyebben megtanultam mint a C-t, pedig PC-n programoztam C-ben, (nem sokat). PIC-en erőltetett a nyelv, de majd megszokom és akkor másképp fogom gondolni, nagy valószínűséggel!

Ez egyébként az én esetemben is így van...vmiért nyűgnek érzem a C megtanulását PIC-hez...a fene tudja, miért...

Beállítottad az összes config bitet? Itt egy lista az összessel: http://ww1.microchip.com/downloads/en/DeviceDoc/C18_Config_Settings...7f.pdf

Eddig 16f84et programoztam, de azt tanácsolták, hogy lépjek tovább PIC18F452-re. Megnéztem az adatlapját, láttam, hogy van A/D átalakítós bemenete, meg hogy nagyobb a memóriája, de még lenne kérdésem.
1. Miben több, mitől jobb 18-as, mint a 16-os?
2. Milyen felület és milyen fordító kell ahhoz, hogy C-ben programozzak PIC-et?
3. Milyen utasítások használhatóak C-ben PIC-hez?
4. Hogy épül fel egy C-ben megírt program PIC-hez?

köszi

1. Van néhány "kiegészítő" utasítás, amikkel így egyszerűbb a PIC kezelése; az alapvető különbségeket megtalálod az "AN716"-os dokumentációban a MicroChip honlapján...

2. C fordítóból létezik egy csomó féle PIC-ekhez (nemrég linkeltem be az oldalra egy helyet, ahonnan le lehet tölteni a legújabb CCS típusú fordítót; keress rá a "CCS PIC Compiler" nevű topikra, ha a bal oldali listán nem lenne már kint!)

3. Ez kizárólag a fordító függvénye! Ha egy bizonyos fordítóra specializálva írsz egy programot, azt általában kisebb-nagyobb módosításokkal lehet csak másik fajta fordítóval értelmeztetni...nem óriásiak a különbségek, de mégis akadnak!

4. Erre nem tudok válaszolni, mert nem vagyok túlzottan jártas C-ben, ezt majd más elmeséli :yes:

köszönöm kimerítő válaszodat

18F-hez inkább a C18 fordítót javaslom. Mégiscsak az a gyári, legjobban követi az ANSI szabványt, és ehhez találni a legtöbb programot a neten is. A Student verzió 60 napig korlátozás nélkül használható, utána is csak valami optimalizálásokat nem csinál. De át lehet verni, szimplán vissza kell állítani a dátumot. Nemtudom a CCS ebből a szempontból hogy áll, de a C18 tökéletesen integrálódik az MPLAB-ba, az MPLAB SIM-el szimulálható a program, ICD2 és egyéb gyári programozókkal két kattintás beégetni a programot, stb.

Ugyanúgy épül fel, mint a PC-re írt C program. Nézz meg néhány programot ezügyben.

Az alábbi programrészletben azt nem értem, hogy miért kell a TRISA és TRISB beállítás előtt a Status-t "bántani". Mindig úgy írtam a programokat, hogy ezt a részt mindig átmásoltam és csak a trisa-t és trisb-t változtattam, de nem egészen világos ez a rész.
START
BSF STATUS,RP0
MOVLW B'00000011'
MOVWF TRISA
MOVLW B'10000000'
MOVWF TRISB
BCF STATUS,RP0

Mert a PIC-en belül! hardveresen a belső memória (ahol a regiszterek találhatóak) 4 úgynevezett "Bank"-ra oszlik...egyik bankban lévő regiszter tartalmát nem lehet csak úgy módosítani, ha épp a másik "bankban vagy".

Egy egyszerű példát tudok erre mondani, ami világossá teszi az egészet:

"Tegyük fel, hogy van egy füzeted, amiben van 4 db lap. Namost lapozás nélkül a harmadik vagy akár a második lapra nem tudsz írni, és arról nem is tudsz olvasni sem!"

Ugyanez játszódik le a PIC-ek esetében is. A STATUS regiszter RP0 és RP1 jelű bitjei pedig ezt a lapozási műveletet végzik.

[size=9]Amire szükség lehet az a reset vektor, ill kezdőcím c-ben történő beállítása.
pl a lentebbi kellene C-ben:

F EQU 0x0001

;------------------VECTORS--------------------------------------------

org 0x000000 ; reset vector
bra START

org 0x000008 ; high priority interrupt vector
bra TMR1_ISR

org 0x000018 ; low priority interrupt vector
bra TMR3_ISR

;--------------------PROGRAM-----------------------------------
START
.......


Van valakinek ötlete?

Melyik C-ben?

Microchip C18.
Amúgy ugyanaz a téma, mint amit a Csaplár Z. is írt.
pl.: Ha kihúzom az ICD2-t az USB-ből (vagy órák múlva a laptom elalszik és elveszti vele a kommunikációt) a cucc tovább fut, de ha a panelből húzom ki az ICD csatlakozóját megáll. Panelen kiadott resetre meghülyül. Visszadugom az ICD-t, ill. a panelt:
ICD0083: Debug: Unable to enter debug mode. Please double click this message for more information.
ICD0069: Debug: Unable to run target
Ez még logikus is lenne, de ha manuálisan átírom MPLAB-ban a PCL-t 0-ra szépen elindul az elejéről, ahogy kellene. De sem önállóan tápbekapcsra, vagy resetre nem áll fel (ICD nélkül). Tuti valami banális dolog amit nem vettünk észre. Amúgy 18F4520 fut a Chipcad-es FD1 demo panelben.

köszönettel
:nemtudom:

Nem véletlenül az, hogy nem Programmer-ként, hanem Debugger-ként van kiválasztva az ICD2, akkor is, amikor önállóan akarod a programot futtatni?

most már tényleg jobb.

THX

Hát igen, nem ártana a használati utasítást is elolvasni néha.

Való igaz, csak az zavart meg, hogy icd nélkül csupaszon elvártam volna tőle, hogy beinduljon.
De hát ugye olvasni tényleg nem árt. Mindenesetre +1x kösz!
:worship:

Sziasztok! Készített már valamelyikőtök Ricoh óra IC-vel órát (RS5C372A, vagy R2025S)?
Milyen pontossággal bírtak belső "jusztírozás" nélkül?
Eddig 10 óra alatt 4mp-et siet.

kösz

Pontatlan, de be lehet állítani majdnem pontosra. Atomóra nem lesz soha!

Gyanítom a 2025-ös a belső Q miatt pontosabb lehet, mintha veszek egy külsőt a másikhoz. Ha heti 1-2 mp-re le lehet nyomni az eltérést az már a célnak megfelelne. Előtte persze tanulmányozom a dokumentációt...
:nezze:

Kösz a választ!

Közben én is rájöttem az általad leirt modon (elolvastam a datasheetet)

méegyszer kösz!

Egy problémám akadt:

PIC-ben (16F628A) programoztam le egy mikrokapcsoló gombnyomását interrupt-tal. Azt látom, hogy a mikrokapcsoló megnyomásakor esetenként több interrupt is történik.
Szerintem ennek az lehet az oka, hogy a gombnyomás csak egyszer, azonban a felfutó él többször is megtörténik (mondjuk remegő kéz miatt).

Mi erre a megoldás?

Igen, ezt hívják a nyomógomb "pergésének". Ez ellen pergésmentesítő kapcsolással, vagy - ha megoldható - szoftveres pergésmentesítéssel szoktak védekezni.
A pergésmentesítő kapcsolás (amennyire én tudom) egy Smith-triggerrel megoldható, a szoftveres út pedig az, hogy figyeled, az előző felfutó él óta mennyi idő telt el, s ha túl rövid, a jelet "eldobod".

Igen, jól látod a helyzetet, egy parányi dolgot kivéve

Az a furcsa dolog, ami ilyenkor történik, nem a kéz remegése miatt van, hanem a (kapcsolón belüli) fém érintkezők találkozásából/pici súrlódásából adódik.

Hivatalosan az a neve a jelenségnek, hogy: pergés

Erre szoktak alkalmazni különböző eljárásokat/pergésmentesítést.

Ez történhet gyakorlati (hardveres) vagy elméleti (szoftveres) síkon. Ha keresel, akkor találhatsz rá megfelelő kapcsolásokat a neten, amivel ez a "többszörös megnyomás" elkerülhető...

Viszont ha már a kezed ügyében van egy PIC, akkor célszerűbb egy külön kis várakozó részt beiktatni a programba, mert ez egyszerűbb...

Az egész lényege a következő (én így szoktam legalábbis csinálni, ha csak egyfelől érkezhet megszakítás):

- minden megszakítás be van kapcsolva
- érkezik egy jel a gombról, a PIC a megszakítási rutinba lép
- én ilyenkor azt szoktam csinálni, hogy a megszak. rutin első lépésében kikapcsolom (nem véglegesen) az összes megszakítást (persze elég csak a gombra vonatkozót kikapcsolni)
- kikapcsolt megszakítás pedig ugye nincs semmilyen hatással a PIC-re ("a külvilágtól elzárt lesz")
- majd a megszakítás-programrész lefut szépen
- és végül ismét visszakapcsolom a megszakításokat
- és ismét jöhet a gombnyomás (ha kell) :yes: