Sziasztok!
Olyan kérdésem lenne hogy van ez a forrás kód és ebben azok az ukrán karakterek amiket ki ír az lcd az hova van eldugva?
Előre is köszönöm a segítséget!Kellemes húsvéti ünnepeket!

Ott van, mutatom, ni!

Szoval miutan nem tudjuk, milyen lcd es milyen ukran karakterek...
De az egyetlen valoszinu helyen, az EEPROM adatok soraiban keresnem.
Hacsak a .h file-ban nincsen. Nem ismerem a C nyelvu file-ok strukturajat.

Én meg nem tudom megnyitni a fájlt ...

Egyébként az LCD .h állományaiba szokták letárolni a karaktereket.
Bár az egész ABC nem fér bele a kijelző ROM-jába, de gondolom ott érdemes elsőnek keresnie..

Ezt már egyszer megtárgyaltuk, az eepromban vannak a karakterek, és nem sok esélyed van kihámozni belőle. Az átlagos LCD karakterek 5x7 pixelből állnak, +1 8. sor a soköznek, és egyebeknek. Vannak online és letölthető karaktergenerátorok, de fogalmad sincs meg senkinek sem, hogy a program írója milyen logika szerint írta be a bájtokat az eepromba. Hosszas kódelemzés után kihámozható, de senkinek sincs itt arra ideje, hogy ezzel foglalkozzon, de ha mindenképp ki akarod hámozni akkor keress egy karaktergenerátort a neten és sok sikert.
Szerk, ráadásul azt sem tudjuk milyen karakterekról van szó mert az a kódban nincs leírva, a forrás oldalt meg nem adtad meg.

Üdv mindenkinek!

Van egy ipari alkalmazás, melyben pic12f675 dolgozik belső órajellel. Analog bemenetet használva figyeli a feszültséget, és bizonyos feszültség alatt egy belső számláló elkezd számolni, aztán ha elér egy értéket a kimenet alacsony szintre kerül. Röviden, tömörem ez egy időzítő, ami kapcsol valamit. Eddig nem volt gond, mert hosszu ideig ment az időzítő, de most hogy csökkenteni kellett az idejét, így már nem felel meg az elvártnak. Szóval nagy a szorás a belső órajel miatt. Sőt hőmérsékletváltozásra is elég változatos időt produkál nyílván. A cél az lenne hogy nadjából egyformák legyenek, mivel ebből nem 1db lenne. Mondjuk 10 perces időzítés esetén +-10 másodpercen belül kellene maradnia. Gondoltam itt a külső kvarcra, de szerintem egy átlag 4mhz-es kvarc ami 25 fokon 30ppm-et produkál, szintén nem felelne meg. Vélemény, esetleg ötlet? Előre is köszi!

Használj külső 20MHz-es kvarcot. Azzal bőven elérhető a leírt pontosság. Ha századpontosságú kell, akár külső oszcillátor egységet is használhatsz. Az ráadásul csak 1 lábat igényel. (viszont drágább)

Holnap próbapanelon meg fogom nézni 20mhz-es kvarcal. Gondolom akkor ilyen 30 fokos hőmérsékletváltozásnál is az a pontosság marad. Bánom hogy belső órajel használatával készítettem az eddigieket. Csak elsőre megfelelt így is...

Szia !

Nem egészen értem/osztom, amit írsz ! Ha egy kvarc 30 ppm-es, akkor a vele kapcsolatban lévő jel is 30 ppm-es, azaz ha mérsz 600 s-ot, annak a 30 milliomod részével térhet el, ami 0,018s !
A belső RC oszcillátornál elég tág hőmérséklet határoknál kb. 100 kHz az eltérés a 4 MHz-hez képest, ami 100/4000 = 2,5 % ! Ez azt jelenti, hogy nagyon rossz esetben ilyen pontos lesz a mérésed, azaz 600s * 2,5% = 15s ( de ez a legrosszabb eset és kb. 80 C-on belül!) !
Szerintem vagy szoftveres problémád van vagy a PIC-ek gyári konfigurálása nem pontos és nem ellenőrizted le! Nekem még nem volt gondom a belső oszcillátorok pontosságával!

Tudod az a gáz hogy hétvégén itthoni körülmények között tesztelve a 10 perce fixen beállított érték az egyiknél 9 perc 57 másodpercnél kapcsolt ki. Csináltam még 3 ilyen átprogramozást, és azok is 1-4 másodpercen belül maradtak. Mondjuk nem hűtőttem, melegítettem őket, kb 22 fokon voltak. Aztán ma bekerült a helyére és ott majd a melegedésre vagy az isten tudja mire csökkentek. 9 perc és 9 perc 30 között voltak a végén. Szóval sosem voltak egyformák az egymás utáni teszten, itthon viszont igen, és nem próbapaneles összerakás volt, hanem a beépített panel... Na ekkor gondoltam a külső kvarcra, aztán kérdeztem, és most vagyok itt. Amugy Proteus simulatorban is néztem egy tesztet, ott is megfelelt. Ettől persze a valóság produkálhat meglepetést, de nem hiszem hogy programhiba lenne, de holnap a végére járok itthon ismét. Legrosszabb esetben mikroc-ben írok valamit, mert az utobbi egy évben azt használom, ez meg mikor készült 30 percesre, más fordító volt kéz alatt.

Az nagyon sok, szerintem nem a belső órajel miatt van !

A belső oszcillátora elég stabil egy ilyen feladathoz.
Tápfesz problémák, lebegő bemenetek, előírt kondik hiánya okozhat ilyen gerjedésszerű tüneteket.
Érdemes lenne szkóppal rámérni.

Sziasztok!Most kezdek a PIC-ek világával ismerkedni.Elsőnek egy Topi féle dcf77 órát szeretnék építeni Bővebben: Link.
De PIC16F84 vagy PIC16F84 helyett PIC16F628A-m van.
Abban szeretném kérni a segítséget hogy a fordításnál mit kell átírnom hogy a PIC16F628a-val is működjön? Ezt már át írtam include <P16F628A.INC> de ez még kevés , a következő sor jelentése nem tiszta számomra include "pic16cxy.inc".
Köszi

Szia,
Először is, üdv. a klubban!
Viszont én nem ajánlom kezdésnek a DCF77-et. A grafikus LCD-k lelkivilágán túl vagy? Először azzal érdemes ismerkedni. Ha már túl vagy rajta nem szóltam, csak sokan írták, hogy nem jó a DCF77 vétele, és kezdőként valami olyat kéne csinálni, amiben kevés a buktató. Pl.: Univerzális időzítő PIC16F628A-val.

Sziasztok!
Szeretnék segítséget kérni! PIC18F4550 bajlódok, méghozzá a megszakítás kezelésével.Az INT0 megszakítást felfutó élre állítottam be, de a lefutó élre is létrejön a megszakítás. Valahol biztos elrontom de nem tudok rájönni hogy mi a hiba.

Szia!
Nyomógomb/kapcsolót akarsz vele lekezelni? Lehet a prellegés miatt van. De jobb lenne, ha beillesztenéd a kódodat.

Már a másik bemenetet is kipróbáltam de az is így csinálja.

A képen a zöld a bemenő jel, a sárga megszakítás.

És mi van rákötve a bemenetre?
Szerk.: a sárga az melyik kimenet?

Az olvasoint() eljárás megvárja, míg kiléptetődik az adat. Ez alatt az idő alatt a megszakítás tiltva van. A soros vételi megszakítás engedélyezett, de nincs lekezelve.

De pont az a baj, hogy van megszakítás.. Kicsit nem egyértelmű nekem ez a helyzet..

Egy kártyaolvasó modul van a bemeneten. A sárga a "teszt" kimenet. Ezzel próbáltam az oszcilloszkópon a megszakítást. A soros port megszakítását majd később fogom használni azért van bekapcsolva.

A "teszt" egy portláb?
Így mit csinál?


Apropó, az "if" és a nyitózárójel közé rakj szóközt!

A teszt az RD1 kimeneten van. Kipróbáltam a módosítást de semmi javulás. Bootloaderrel dolgozom, lehet hogy az kavar be?

Hát, lehet, hiszen ha beállítasz egy egy fel/lefutó élt a megszakításnak, akkor csak arra fog reagálni, amit beállítottál.
Továbbá, itt kis b betű legyen!

helyette:

Meg máshol is..
Illetve próbáld meg a bootloader nélkül is.

Szia!
Köszönöm az üdvözlő szavakat.
Még az előttem áll az lcd vezérlése, szerintem az sem lesz kis falat. Arra szerintem a piccolo pjoektet jó lesz, de ha van jobb ötleted szívesen meg halhatom. Köszönöm a jó tanácsokat.De már megvásároltam az dcf77 modult,lehet elmegyek és veszek egy PIC16F84A-est ahhoz meg van a HEX file.De elolvasom az általad felkínált cikket is.

Köszönöm az eddigi segítséget, majd a hétvégén átírom a programot és megnézem bootloader nélkül.
Üdv: Topika

Végülis nincs nagy ördöngősség a DCF-ben, csak először érdemesebb az LCD alapjait átvenni. A DCF77 meg megvár. Egy a lényeg, legyél kitartó, és figyelmes!
Ezeket feltétlenül olvasd el, ha még nem tetted:
Bővebben: Link
Bővebben: Link
Bővebben: Link

Miert is?

Tudom mire gondolsz, hogy a fordítónak mindegy. De én a tagolásra gondoltam, illetve az MPLABX atombugjai után már semmin se csodálkozok...

Egyenlőre tiltsd le. Vedd ki a programból a soros adás kezelését is.

Sajnos a legnagyobb baj az, hogy nem lehet tudni, mi váltja ki a megszakítást. INT0 -ról ír, a programban az INT1 szerepel...
A megszakítási prioritás bitek 1 -re állnak be, így minden megszakítás a YourHighPriorityISRCode() függvényt hívja meg. Itt a feltételtől függetlenül állítja a program a test kimenetet.