Egy jó tanács: Ha kérik tőled, hogy nézd meg az adatlapban a megszakítások lekezelésével kapcsolatos dolgokat, és az LVP bitet ellenőrizd le(PGM lábbal kapcsolatos történések), akkor tedd meg, mert a legjobb szándékú válaszolók is megunják előb utóbb, hogy nem teszel semmit a megoldás érdekében és várod a sült galambot, és okoskodva reagálsz a segítő válaszokra! Én az első pillanatok óta ezért nem válaszolok neked. Én türelmetlen és kíméletlen vagyok azzal aki értetlen, nézd el ezt nekem és próbáld hasznodra fordítani, hogy vállalom a rossz szerepét az érdekedben!

Nem hiszed... Kipróbáltad? (HS-el?)

A következő a gondom :
Pic16f684-et használok és szeretném használni az INT és az RA_change megszakítást is. Ez a Pic egy újab típus és már tartalmaz egy IOAC regiszter ahol elvileg maszkolni lehet, hogy melyik RA lábról fogadjon el RA_change megszakítást.
A gond az hogy én ugyan beállítom, hogy csak az RA1 lábról jövő megszakítás éljen, de a normál INT (ez ugye az RA2-n lakik) megszakítás lefutása után is lefut az RA_change megszakítás. (Próbáltam már, hogy az INT rutin elején törlöm a RA_change megszakítás jelzőbitjét, de hiba továbbra is fenn áll és az RA_change rutin is lefut.) Van valakinek valami ötlete a dolog megoldásával kapcsolatba?

Na ezt most megkaptam!

Átírtam a kijelző inicet szilva tanácsára úgy ahogy az adatlap kéri és kivettem a megszakításokból az osztásokat BCD átalakítást és mentettem a w és status tartalmát. Így már indul rögtön, de még a megszakítást rosszul kezeli le. mikor meghívódik eltűnik a kijelzés és megint meg kell hívni hogy visszajöjjön. Kipróbáltam HS és XT módban is. Mindkettővel indul rendesen mostmár.
Az LVP bit kivan kapsolva mert a configban beírtam hogy LVP OFF. Az adatlapok angolul vannak és előfordul hogy rosszul értelmezem ami oda van írva mert én németet tanultam csak.
Most komolyan értetlen voltam?

Voltál! Most már majdnem jó úton jársz!
Hogy miért majdnem?

Ezt láttad az adatlapban? Mert én biztos vagyok benne, hogy nem! (varázs szó SWAPF !). Ha kitalálod miért nem jó amit írtál, kapsz egy virtuális pirospontot!
Ja és igen, ettől borulhat a megszakításban a program!

Bármelyik interrupt bekövetkezésekor a program végrehajtása a 0x04 címen folytatódik. Itt neked kell gondoskodni a forrás kiderítéséről. Ha ezt nem teszed, akkor az összes rutin le fog futni ami onnan található(véletlenszerű eredményekkel). Miből gondoltad, hogy a PIC tudja magától, hogy mi okozott megszakítást? Nézted a megszakítás áramkörét? Annak 1 kimenete van! A 16biteseknél jött be először a vektoros megszakítás, de ebbe ne menjünk bele...
Esetleg a forrás többet mondana, mert lehet, hogy félre is értettelek!

Meg tudom erősíteni, amit watt is írt: jó úton haladsz! Viszont azt is szívleld meg, amit spenyo-nak írt, ugyanis a te kódodban sem látom sehol, hogy foglalkoznál azzal a megszakításban, mi okozta azt.

Ami problémákat kapásból látok (lehet, hogy nem csak ennyi van, de ezeket mindenek előtt el kell hárítani):
- az interruptban a context mentés-visszaállítás így nem lesz jó (ahogy watt is utalt rá), nézd meg az adatlapban az ide vonatkozó részt;
- az INTCON feltöltéséből úgy látom, hogy az INT és az RBIE interruptokat használnád, de az interrupt rutinban nem ellenőrzöd a ide vonatkozó interrupt flageket
- az RBIE esetén az adatlapban van egy protokoll leírva arra, hogy mit kell tenni, hogy a "változás" állapot megszűnjön és az interruptból kilépve ne rögtön újra az RBIE interrupt aktivizálódjon, ezt be kellene tartani
- azt ugyan hirtelen nem látom a programból, hogy pontosan mikor, milyen rendszerességgel állítod be a "FLAG,0"-t, de gyanítom, hogy jobb lenne felülvizsgálni, hogy tényleg szükséges-e ilyen rendszerességgel írkálni az EEPROM-ot, az ugyanis nem ilyen jellegű felhasználásra van kitalálva, az írhatóságainak a száma véges

Szia,

Megszakitasban a statusz mentes: Az a baj, hogy mikor a megszakitas meghivodik nem tudni, hogy milyen allapotban van a bank szelekcios regiszter. Ez egy paradoxon, mert ha atallitod, hogy a W-t elmendsd pl, akkor a bank szelekciot mar nem fogod tudni elmenteni mivel atirtad es mikor az interruptbol vissza tersz a fo program vselkedhet furan.

Emiatt (is) sok PIC-ben (ha megnezed a 874-es az adatlapjat a 877-esben is) van egy speci RAM terulet, az un. 'access ram'. Ez a 70h - 7Fh -ig terjedo terulet ami a tukorkepe a 0x70-0x7F -ig terjedo teruletnek es oda kell rakni a teruletet amire ezek a mentesek megtortennek.

Sajnos azonban a 874-esnel ilyen terulet nincs, csupan a 0-as RAM van letukrozve a 2-esre illetve az 1-es a 3-asra. Namost emiatt a 0-as es az 1-es bankon is le kell foglalni ugyanazon az offseten a mentesre hasznalt teruletet. Szerencsere Te nem hasznalod a masik bankot, igy nem lesz ezzel problema, csak jo lenne erre is figyelni.

Viszont nagyobb gond, hogy a W-t MOVF utasitassal allitod vissza, ami ugye allitgatja a Z flaget. Nezd meg az adatlapot az Example 14-1 leirja hogyan kell szabalyosan megcsinalni a kontextus mentest / vissza allitast.

Meg egy apro tanacs: Azonositokban, cimkekben stb soha ne hasznalj ekezeteket. Egyedul a megjegyzesben hasznalhatsz -- bar szemely szerint azt is kerulom.

Oopsz, nem lattam ezt a hozza szolast es jol leirtam neki a megoldast

Ennyi előnyt adtunk neki! Remélem ezután fog tudni válaszolni a miértre!

Szia, köszönöm szépen a segitségedet, megnézem amit ajánlottál. A programot asm-be irom.

Sziasztok!
megcsináltam ezt a programozót, forrás itt , (nyákterv a mellékletben) és egyszerüen nem akarja megprogramozni a pic12F629-emet.
Winpic-t használok, beállítások: (melléklet 01, 02, 03, 04)
Válaszotokat előre is köszi!

Ez lemaradt:

Köszönöm a hasznos hozzászólásokat!
Átírom a programot ezeknek a tanácsoknak megfelelően jobban figyelve a memória lapozásokra. Ma a hugom ballagása miatt nem volt időm átírni de holnap mindenképp megcsinálom és jelentkezem mire jutottam.
Valaki kérdezte hogy miért mentek az EEPROM-ba.
A km számláló tartalmának meg kell lennie azután is hogy levettem a gyújtást, ezért mentem km-enként az eepromba. Más 5letem nem volt erre.

Teljesen korrekt az elgondolas. Azt vedd csak figyelembe, hogy az EEPROM irasnal 1 minden byte kiirasa olyan 5-7ms-et tesz ki 5V es nornalis (25C) homersekletet feltetelezve. Azonkivul mindenkepp ellenorizd visszaaz iras sikeresseget (ki kell olvasni es osszehasonlitani az eredeti ertekkel).

Amugy sokan bonyolitjak a helyzetet (ezt egyenlore nem javasolnam, csak gondolat ebresztonek): Szoval sokan csak akkor irkalnak az EEPROM-ba, ha a gyujtast elvettek. A PIC taplalasat termeszetesen meg kell oldani, de arra vagy ott van mar eleve az akksi, vagy sokan egy megfelelo meretu elkot tesznek be ami arra az idore amig az EEPROM iras be nem fejezodik a megfelelo taplalast biztositja. Van olyan is ahol egy gomb elemmel oldjak meg, hogy a PIC gyakorlatilag sohasincs kikapcsolva igy nem felejt. Szoval sok mas megoldas is elkepzelheto termeszetesen, de en szerintem ez az eepromos irkalas is teljesen megfelelo.

Akkor mi van, ha pont 999m-nél veszed le a gyújtást? Kidobtál majd egy km-t? Jobb, ha a PIC mindig tápot kap, és gyújtás levételkor mented a km(méter?) számlálót. Ezt lehet még tovább fejleszteni trudnai által említett kondis időnyújtással és feszültség figyeléses megszakításra történő eempromba mentéssel, ha valaki leszedi az akkut(mondjuk menet közben ritkán szednek le akkut, amúgy meg már el van mentve a legutolsó gyújtás levételkor a számláló...).

A memória lapozásról annyit, hogy még nem lapoztál, mert nem akkor a a program. Ha ilyen kicsi marad, akkor nem is kell törődni vele most. Ettől függetlenül később fontos lehet ennek ismerete.
A megszakításhoz szükséges mentések részletesen benne vannak az adatlapban, nem kell kitalálnod semmit, csak másolni!

Én is jobb ötletnek tartanám a háttértáplálást megoldani és azt érzékelni valahogy, hogy a motort leállították (gyújtás érzékelése, vagy ha esetleg van fordulatszámmérés is, akkor abból is lehet tudni).

A háttértáplálás esetén lehet olyan áramköri kialakítást alkalmazni, amikor az LCD modul "alvó" üzemmódban nem terheli az áramforrást még azzal a pár mA-es fogyasztásával sem, illetve lehet a PIC-ből elektronikusan is kapcsolni az LCD modul tápellátását. Megfelelő hardver- és szoftverkialakítással bőven 100uA alá lehet menni az "alvó" állapotban a PIC fogyasztásával, így lehet nyugodtan a RAM-ban tartani az útadatokat.

Persze a motor leállításakor érdemes egy mentést csinálni az EEPROM-ba, de az üzem közbeni rendszeres írkálást én mellőzném.

Hogy mik vannak!

Az áramforrásról és a kis fogyasztásról jutott eszembe:
Kép: Hivatkozás

Nem rossz! Kicsit durung, de vannak jó ötletek.

Igen, ez tényleg jópofa, sokáig kerestem, hogy mit ír a fogyasztásáról, de aztán megtaláltam: . Kb. erre utaltam korábban, bár valószínűleg az aktív 3mA fogyasztás sem olyan tragikus egy motorakkumulátor esetén.

16F-ek esetén - ha az I/O-k megfelelően vannak kialakítva, és azokon nem folyik el felesleges áram - még a 15uA alá is lehet menni bőven az inaktív állapotbeli fogyasztással. Persze az ilyen extrém alacsony fogyasztás hajhászásának tényleg csak akkor van létjogosultsága, ha pl. egy CR2025 vagy CR2032 elem lenne a háttértáplálás, és a motorakksiról csak a gyújtás bekapcsolása alatt kapna tápfeszültséget az áramkör.

Írtam egy ilyen led villogtató programot és ez sem működik!

Valami nagy gond van ezzel a PIC-el!
Néha megy néha nem!

Hogy van bekötve az MCLR? Van-e 100nF kerámiakondi a táplábakon jó közel(min. 1-1db)?
HS oszci van kiválasztva(ha jól emlékszem 4MHz?)?
szerk: A programot most nézem, látom nem. Próbáld ki úgy is!

Valamint itt már elfelejtetted az LVP bitet letiltani megint!
És ha csak 1-eket töltesz az időzítés számlálókba, akkor nem villogni fog, hanem fél fényerővel világítani, legalább is a szemed ezt fogja látni.

Valamint, ha az időzítést meghívó CALL előtt készíted elő a később a PORTD-be kivinni kívánt 10000000-et, akkor az nem lesz kivive, mert a W értékét elrontod az időzítő rutinban. (kicsit sok hiba nem gondolod? )

Nem tudom említettem e hogy áramkörön belül programozok mert PLCC tokozású a PIC és nem egyszerű ki be húzgálni.

Az MCLR 10k val van felhúzva a +5V-ra.

Tapasztalatok:

Amikor beleégettem a sebességmérő progit és kész lett az égetés rögtön volt kijelzés szépen ahogy kell. Amint lehúztam az égetőt és a saját tápjával próbáltam ami egy 9V-os elem, már nem volt jó, megint nehezen indult. Pedig mértem a táp IC után a +4,9V ot. A GND-t és a +4,,9V ot külön vezetékkel is hozzákötöttem a PIC lábához és tettem 100nF ot is rövid lábakkal közvetlen a PIC lábára.
De mégsem jó és ez a ledvillogtató sem akar működni. Az előzőben rossz filet csatoltam mert ababn le volt véve az időzítés kicisre hogy rendesen tudjam tesztelni a szimulátoron. Ezekkel az időzítésekkel próbáltam most.

A LED villogtatód szerintem kicsit hibás, az első DELAY előtt nem írod ki a kívánt bitmintát a portra, majd csak a DELAY után teszed ezt meg, ami miatt a DELAY-ben a W-be töltött érték fog a portra kikerülni, nem az a minta, amit kézzel betöltöttél. Jelen állapotában a PD7 helyett a PD0 bitet billegteti a progi.

A "hol megy, hol nem"-ről kicsit többet írhatnál. A tápfesz bekapcsolásakor nem indul mindig, vagy menet közben is le tud állni, vagy ha közelítesz valamelyik lábához, esetleg megérinted, akkor áll meg, vagy mit is tapasztalsz konkrétan? Az adatlapot most olvasgatom, azt írja, hogy belsőleg állít elő egy RESET jelet a tápfeszültség 1.2-1.7V szintje fölé emelkedéskor, ezért ha az MCLR lábat direktben vagy ellenállással a Vdd-re kötöd, akkor nem szükséges külső RESET áramkör. Ellenben ha túl lassan emelkedik a norml szintre a Vdd, akkor előfordulhatnak indulási problémák, és szükséges lehet a külső RESET áramkör, ami hosszabb ideig tartja bekapcsoláskor RESET állapotban a CPU-t.

Kérlek olvasd el amiket írtam, és tedd meg amik abból következnek! Több dolgot figyelmen kívül hagytál a programodban, ezért NEM működhet!

Na átírtam a led villogtatót és működik!
A saját 9V-os eleméről!

A sebességmérővel kapcsolatban:

A tápfesz ráadásakor nem indul, a kijelző olyan mint mikor PIC nélkül kapcsolom be! Csak a felső sor megy és teli kozckákat jelenít meg.
A tápfesz elvételét és ráadását ismételgetve sokadikra elindul de menetközben le is fagy. Van mikor nem de legtöbbször igen. Volt olyan is hogya programozóról adva a tápot elindult rendesen elsőre mindig de a megszakításokat nem kezelte lefagyott aminek el is mondtátok az okát. De most már se a programozás után se az elemről nem indul el sehogy.
Pedig olyan a kijelző inic része amit az adatlap megkövetel. Valahol nagyon elszúrtam azt a progit lehet még jobban mint eddig. Jah hát ha közelítek a PIC valamelyik lábához vagy csak a tokhoz attól egyszer kétszer lefagyott de volt hogy el is indult de ez egy két alkalom volt. Direkt érintgettem kézzel hátha elindul, de nem.
Na keresem tovább a hiba okát a kódban, remélem nem a kijelző rossz.

Jah most így néz ki a program!

Nagyon szívesen! (Én kérek elnézést!)