Köszönöm a gyors és részletes választ. Tudnál példát írni alkatrészteszterre?

Egy monitor tápból 3 diódát szedtem ki, mert beszerelt állapotban gyanúsak voltak, mikor megmértem. A 3 dióda: SR5100, SR515 és SR506. Mindegyik kiszerelt állapotban a multiméter dióda funkciójában 0,300 alatti értéket mértem: SR5100-nál 0,299V; SR506-nál 0,188V és SR515-nél 0,272V. Ezek a diódák rossznak számítanak ugye?

A lomex webáruházában láttam SR506-ost, viszont SR5100-ast és SR515-öst nem. Ezek mivel helyettesíthetők?

Korábban 2 monitorunkat meg tudtam javítani, mert a táp nyákján mindegyiknél volt felpúposodott kondenzátor, azt kicseréltem, és megjavultak a monitorok. Most egy harmadik monitort szeretnék megjavítani. Ennek is a táp nyákján volt 2 kondenzátor, ami púpos volt, azokat kicseréltem (lásd feltöltött képen a pirossal bekeretezett kondenzátorok) (illetve volt a két púpos mellett egy harmadik nem púpos is, azt is kicseréltem), de nem javult meg a monitor, ráadásul kiszerelt állapotban a kondenzátorok kapacitását megmértem, és az a rájuk írt kapacitással egyezett.
Szóval a monitort ha bekapcsolom, akkor kb. fél másodpercre előjön a kép, amit látni kellene, de utána elsötétül a képernyő. Ha kikapcsolom majd be, akkor megint kb. fél másodpercig látható a kép majd eltűnik. Valakinek van valami ötlete mit kellene kicserélnem? A nyákról a képeket csatoltam.
Amikor a monitort bekapcsolom, akkor a táp nyákon az egyenáramú végén az 5 és 15V-ot mérni tudom.

Sziasztok!

Az autóm gyári ülésfűtés kapcsolója tönkrement. Helyette be szeretnék szerelni egy a lomex-ben vásárolt 3P SPST kapcsolót (a [45-07-09] azonosítójút vettem meg). Ezen van LED is. Most, mikor raktam volna össze a dolgot, kezdtem el gondolkodni, hogy a régi kapcsolómon nem volt led, és csak két vezeték ment a kapcsolóhoz. Viszont ezen az új kapcsolón 3 pólus van. Jól gondolom, hogy valahonnan még oda kellene vezetnem ehhez a kapcsolóhoz a földet?

Sziasztok!

Pic16F1829 mikrovezérlőt kapcsoltam össze az UART modulján keresztül a számítógéppel.

Ha a CCS-C 5.009-ben a program elejére a:

dirktívákat írom, szépen megy a soros kommunikáció.

Ha viszont a

direktívákat írom (azaz a FUSES-ban átírtam az INTRC_IO-t HS-re, és a delay-ben 4millió helyet 20milliót írtam), akkor nem megy egyáltalán a soros kommunikáció.

Mi lehet ennek az oka? Szeretném, ha a mikrovezérlő 20MHz-en menne, mert az egyik pin-jén egy jelet mintavételezek, és ezért minél nagyobb órajelet szeretnék használni.

Kedves Medve!

Úgy tűnik, hogy ha az "üveg"-et leszorító keretet jobban megnyomom, akkor megjelennek új pixelsorok. Azaz az "üveg" kontaktjával lehet tényleg probléma. Leszedtem az üveget a panelhez szorító fémkeretet, és azt láttam, hogy a panelen nagyon sok kis réz "pad"-van az üveg hosszabbik oldala mentén mindkét oldalon. Az üvegből pedig szintén a két hosszanti oldala mentén 1-1 szivacsszerű, az üveglap vastagsága irányában túlnyúló lap van, aminek a panellel érintkező peremén mintha valami csatlakozó dolog lenne. Mintha ezek érintkeznének a panel réz "pad"-jaivel. Lehet ez a kontaktus a rossz?
Csak nem értem mitől romlottak el bizonyos kontaktusok? Mert eddig egy fejlesztett áramkört próbapanelen tesztelgettem, ott még a 2. és 4. sora a kijelzőnek tökéletes volt, aztán a legyártott áramkör első tesztelésekor volt egy kis probléma, mert volt az áramkörben egy rövidzár rész, amitől a tápegység egyből lekapcsolt, viszont azóta már a 2. és 4. sorból is csak az alsó 4 pixelsor jelenik meg. Lehet ez okozta a problémát?
Ezekkel a kontaktusokkal lehet valamit csinálni?

Kedves hozzászólók. Nem tudom miért, de mostmár működik.

16F1829

Azt nem írtam, de az interrupt-on-change próbánál felfutó élere történő megszakítást állítottam be. De próbálkozom tovább, és kipróbálgatom a javaslatokat.

Elnézést, a Pic kezdőknek akartam beírni, csak siettem, és nem olvastam végig a fórum címet.

A tekerés irányát úgy próbálom meghatározni, hogy ehhez az egértekerőhöz van egy infraled, és ehhez egy tokba épített 2 fototranzisztor van. Kipróbáltam, hogy figyelem külön-külön a PIC azon lábait, amikre a fototranzisztor van kötve, és ha a jelszint magas, akkor a neki megfelelő LED-et felkapcsolom, ha meg alacsony, akkor lekapcsolom (a jobb érthetőség kedvéért a PIC RB5 és RB6 lábára vannak kötve a fototranzisztork, a RC0 és RC1 lábra egy-egy LED, és az RB5 láb jelszintjeinek függvényében kapcsolgatom az RC0-ra kötött LED-et, és az RB6 láb jelszintjének függvényében kapcsolgatom az RC1-re kötött .LED-et). És ahogy szép lassan tekertem az egértekerőt, akkor először felkapcsolódik az egyik LED, majd a másik is, majd lekapcsolódik az 1. LED, majd lekapcsolódott a 2. LED is. Úgyhogy elvileg jól működik a dolog.
Ezután kipróbáltam, hogy interrupt-on-change-re kötöttem az RB6-os fototranziszort, és az interrupton belül a másik jelszintjének függvényében a 8db PORTC-re kötött LED-eken egymás után jobbról balra vagy balról jobbra léptetem a felkapcsolt LED-et, de ez már nem működött, állandó irányú tekerés esetén is felváltva villódzott az egymás melletti LED-ek, van hogy továbblépett, de ott megint az egymás mellettiek villództak a tekerés hatására.
Úgyhogy emiatt már az utolsó tippem az, hogy az okozhatja a problémát, hogy van egy rész, amikor a tekerés hatására a PIC lábán a tiltott tartományba esik a feszültség, és ez okozza bajt.

Sziasztok!

A PIC-em adatlapjának DC Characteristics részében az Input Low Voltage-hoz max 0.8 V van írva, a Input High Voltage-hoz min 2V. Azt szeretném megkérdezni, hogy ha a PIC lábára 0.8-2V közti feszültség jut éppen, és lekérdezem a PIN állapotát, akkor most arra mit fogok kapni?

Onnan jön ez a problémám, hogy egy egér tekerőgombját a hozzá tartozó infraled+2 db egybeépített fototranzisztor együttessel szeretném felhasználni, és ahogy tekerem szép lassan a tekerőt, akkor a fototranzisztoron (attól függően, hogy a lyukacsos tárcsán keresztül mennyi infrafény jut rá), más más feszültség esik, azaz a PIC-en lábán 0.2-4.5V- ig mindent mérek a tekerő helyzetének függvényében. És az a problémám, hogy lehet hogy emiatt, de nem működik a tekerés irányának meghatározása.

Sziasztok!

Van egy 4soros, soronként 20 karakteres LCD kijelző modulom DEM 20486 SYH-LY/V.
PIC-cel vezérelem. Az a problémám, hogy az első és 3. sorban a karakterek felső felét írja csak ki, a 2. és 4. sorban rendesen a teljes karaktereket. Találkozott már valaki ilyennel? Rossz a modul, vagy valahogy elállítódott?

Viszont most hogy már nekem is van CCS 5, kipróbáltam az IOC funkciót PORTB 4-es pinjére, aztán a 7-es pinjére is, de itt már a lefutó élnél is belemegy a megszakítást lekezelő ciklusba. Megírtam a teljes programot MPLAB-ban assembly-ben, és annál is úgy működött, hogy a lefutó élre is belement a megszakításba. Ez viszont már valami CHIP probléma lehet.

Kedves Sasmadár!

Kipróbáltam, és ahogy sejtettem, így is tökéletesen működik élőben is. Csak a felfutó élre indul az interrupt, és csak egyszer fut le egy felfutó élre.

Egy kis kiegészítés az előző hozzászólásomhoz. Először meghatároztam, hogy milyen chip kell a feladathoz, és meg is vettem. Aztán azért kell a PORTB-s IOC, mert előre ittam a medve bőrére, és mivel láttam a 16F1829 adatlapján, hogy a PORTB-n is van IOC, én oda terveztem azokat a dolgokat, amihez az IOC kell. És már le is gyártottam a nyákot, és ezután kezdtem neki a vezérlőprogram megírásához. Akkor szembesültem azzal, hogy a nekem meglevő CCS v4.086 nem is ismeri ezt a chip-et. Akkor ami frissebb verzióhoz "hozzájutottam", az a v4.114 volt. Ez már ismerte, bár azt a header file alapján rögtön furcsáltam, hogy miért csak a PORTA-s IOC-t ismeri. Mindenesetre elkeztem próbálkozni a PORTA-s IOC-vel, ami nem sikerült vele. Akkor írtam ASM-ben ilyen LED villogtatást az IOC tesztelésére, és az működött mind a PORTA, mind PORTB esetén. Azaz a chip az jó. Úgyhogy tovább próbálkoztam a CCS-el PORTA-s IOC-t csinálni, hátha csak én rontottam el valamit, és jártam ezt a fenti kanosszajárást.

Mindenesetre most ma hozzájutottam az 5-ös CCS-hez köszönhetően Nektek. Úgyhogy mostmár menni fog egyszerűen a dolog. Köszönöm segítségeteket.

Kedves sysy.

Ez igaz, de nekem 2 db PORTB lábon kell IOC funkció majd.

Le is írom, hogy mihez csinálom ezt az egészet. Egy majdan saját használatú nyák levilágító berendezés vezérlését tervezem. A mikrovezérlő a következőképpen fog működni:
Egy egérből kiszedtem a görgetőgomb és az alatt levő nyomógomb részt (a görgetővel együtt az ott levő Infraled-et és annak jelét vevő fototranzisztort, ami ráadásul olyan kivitelű, hogy kettő az egyben, mivel kettő kell ahhoz, hogy az egérgomb forgatásának irányát is meg lehessen határozni). Namost ha benyomkodom a gombot, azzal kiválaszthatom, hogy a levilágítás időtartamát, vagy a melegítés időtartamát, vagy a melegítés hőmérsékletét akarom beállítani. Ezek közül amelyik ki van választva, annak az időtartamát meg a görgő görgetésével tudom beállítani. Lesz még egy nyomógomb, aminek megnyomásával a levilágítás vagy a melegítés indítható.
A levilágítás alatt azt értem, hogy a fóliára kinyomtatott áramkört ráteszem a lakkal befújt nyáklapra, és UV lámpával világítom a beállított ideig.
A melegítés alatt pedig azt értem, hogy a lakkal befújt nyáklapot valamilyen hőforrással (még nem tudom mi lenne a legalkalmasabb erre a célra) melegítem, hogy a lakk minél hamarabb megszáradjon a nyáklapon.
Ez egy ládaszerű berendezés volna, aminek a lehajtható tető részében lenne a melegítő rész, az alja felén meg a levilágító UV csövek.
Mert jelenleg filctollal rajzolom az áramkört a nyákra, és maratom le utána vas-kloriddal a felesleges rezet. És ez a filctollas áramkör átrajzolás meglehetősen időigényes.
A berendezésen a kapcsolattartást egy LCD kijelző biztosítja (8bites üzemmódra terveztem meg a nyákot, aztán jutott eszembe, hogy 4bittel is lehet vezérelni). Kell még 2 pin az LCD enable és utasítás/adat pinjéhez. Kell 1-1 pin a funkció választó nyomógombnak illetve a start gombnak, ami a levilágítást vagy a melegítést indítja. Kell 2 pin a görgőnek. Kell 2 pin az Uv csöveket illetve a melegítő egység reléjét kapcsoló tranzisztornak, valamint 1 pin a hőmérséklet mérő szenzornak (a DS1820 hőmérséklet szenzorral 1 pinen is lehet kommunikálni). És ekkor 17 pin-nél járunk. Kell még 1-1 pin a föld és a Vdd-nek. Így jött ki, hogy egy 20 pin-es chip kell.
Mondjuk első körben csak a levilágító részt fogom megépíteni, a melegítést majd megoldom manuálisan egy hajszárítóval kezdetben. Csak úgy akartam ezt az egészet megcsinálni, hogy alkalmas legyen melegítéses funkcióra is. A nyákra terveztem egy 4 pinen csatlakozási lehetőséget ICSP (áramkörön belüli programozás) célra, hogy ha esetleg módosítani kell a chip-en a programot, akkor azt is meg tudjam csinálni.
2 éve kezdtem tanulgatni ezt a mikrovezérlős dolgot, mert érdekelt, egyébként gépészmérnök vagyok, és nagyon élvezem ezt a dolgot. Hála istennek itt van ez az internet is, ahol csomó tudást össze lehet szedni, köszönhetően azon önzetlen embereknek, akik ilyen kis bevezető leírásokat, jegyzeteket készítenek, illetve akik pl. ilyen fórumokon is segítenek azoknak, akik megakadtak valamiben. Kár, hogy nem fiatalabb koromban találták ki ezt az internetet.

Kedves Sasmadár!

Az általad a v5.09-el fordított program tökéletesen működik. Csak felfutó élre megy bele az iterruptba.

A v5.09-es CCS verzióból csatolt 16F1829.h header file-ban pedig már látom, hogy a PORTB IOC-je is benne van, nem csak a PORTA-é, mint nekem a v4.114 verzióban.

Bárcsak nekem is v5.09-es verzióm lenne, és nem vesztegettem volna el 2 hetet ezzel az IOC-vel a rossz működés miatt. Annak ellenére, hogy tudjuk, hogy a v5.09-ben már jól működik ez a 16F1829 chip esetén, ennek ellenére nekem ASM-ben kell ezt megírnom a v4.114-es CCS-emen belül, mert ráadásul nekem a PORTB-n kell ez a IOC funkció.

Azt még kipróbálhatnánk, hogy a v5.09 verzión belül kell-e az interruptban a PORT olvasása. Mert a 16F1829-es adatlapjában az IOC fejezetben én ezt nem olvastam, hogy "be KELL olvasni a portot, hogy a belső tárolóban elmentésre kerüljön az állapota. És ehhez képest, ha megváltozik, akkor hívja megint a megszakítást." Azaz ki kellene úgy is próbálni, hogy az interruptnál meghívott szubrutin elejéről ki kellene törölni az input_a() sort.

Köszi, ezt már csak holnap próbálom ki, mert már elraktam a próbapanelt meg programozót. Jó éjt.

Beírnál a program elejére egy #byte IOCAF = 0x393 sort, a megszakítást lekezelő szubrutin végére pedig egy IOCAF = 0x00 sort? És akkor ezzel szoftveresen törölnénk a megszakítás flag-et, és akkor szerintem már nem villognának felváltva a 4-4 LED. Ugyanis szerintem most is csak a felfutó élre vált a LED, csak mivel a megszakítást jelző flag nem lett törölve, így ahogy kijön a megszakítást lekezelő szubrutinból a program futás, már megy is vissza, mert azt hiszi, egy újabb felfutó él jött.

És akkor leellenőrizném a futását a chip-en élőben.
Szerintem ezzel meg is lesz oldva a dolog.

Illetve ha van 5.09-es CCS-ed, elküldenéd az ebben levő 16F1829.h header filet (valahol a Program Files\PICC\Devices könyvtárban vannak)? Meg szeretném nézni, hogy abban már benne van-e a PORTB-re vonatkozó IOC is. Ugyanis a v4.114-ben a header fileban csak a PORTA-ra vonatkozó IOC van benne, a chip adatlapja alapján (illetve Assembly-ben meg is csináltam) a PORTB-n is van IOC megszakítás.

Kipróbáltam a hex file-t. Azt csinálja, hogy kb 5 másodpercig világít az összes lámpa. Majd kialszik. Ezután ha az optokapcsolót kikapcsolom (és ekkor a PORTA,2-re magas jel jut), akkor elkezd váltakozva hol az első 4, hol a második 4 LED lámpa világítani. Azaz szerintem mostmár bement az interruptba, csak valószínűleg most is úgy akarta törölni az IOC flag-et, hogy az INTCON-ban törli a 0-s IOCIF bit-et, ami viszont nem törölhető, csak olvasható. És a chip meg folyamatosan azt látja emiatt, hogy megint van egy megszakítás (mivel a vlóságban az IOCIF bit éréke 1 maradt), és újra bemegy a megszakítást lekezelő interrupt-ba, és átváltja az egyik 4 LED világítását a másik 4 LED világítására. Érdekes, hogy még az 5.09-ben sem tudták ezt az IOC-t normálisan megcsinálni.

Feltöltenéd az lst file-t is? Megnézném benne, hogy hogy törli az interrupt flag-et a megszakítás szubrutinjában.

Kedves sysy és Sasmadár!

Köszönöm, hogy foglalkoztok a problémámmal. Én sem ülök a babérjaimon, hanem próbálom kideríteni a hiba okát. A Bővebben: Link hozzászólásomban levő kis tesztprogramnak megnéztem a CCS C v4.114-ben történő fordításakor kapott lst file-ját:



Ebben a következő furcsaságokat találtam:
1. A 004D sorban BCF 0B.0 van írva a clear_interrupt(INT_RA) megfelelőjének, ami BCF INTCON.IOCIF-et jelent, azaz törli a IOCIF flag-et. Azonban a PIC16F1829 chip adatlapjában a 13.3 Interrupt Flags fejezetben írják, hogy "The IOCIF bit of the INTCON register reflects
the status of all IOCAFx and IOCBFx bits." Illetve a 13.4 Clearing Interrupt Flags fejezetben
"The individual status flags, (IOCAFx and IOCBFx bits),
can be cleared by resetting them to zero." Továbbá a 8.6.1 INTCON REGISTER fejezetben "Note 1: The IOCIF Flag bit is read-only and cleared when all the Interrupt-on-Change flags in the IOCxF register have been cleared by software." Azaz szerintem nem úgy kell törölni az IOC megszakítás flag-jét, hogy törlöm az INTCON regiszter IOCIF bit-jét, hanem az IOCAFx regisztereket törlöm.

2. A 007D program sorban: MOVLB 07 = Bank 7 kiválasztása
007E programsorban BSF 14.2 = BSF IOCBP.2 azaz a PORTB 2-es pinjének pozitív átmenetének a figyelése!!! Azaz nem a PORTA 2-es pinjének figyelését állította be, hanem a PORTB 2-es pinjének.

3. A 0080 és 0081-es sor voltaképp 1-re állítja az INTCON regiszter GIE és PEIE bitjét. Hogy a PEIE bit-et minek kell 1-re állítani, azt nem tudom. Amikor ezt a teszt programot Assembly-be írtam meg, nem állítottam a PEIE bit-et 1-re, mégis működött a program.

4. A gomb változót csak arra használom, hogy az interruptot lekezelő szubrutinban hol egyik, hol másik sort hajtassam végre, azaz hol az első 4, hol a második 4 LED-et kapcsoljam fel, hogy lássam mikor lép be az interrupt-ba. Csak éppen egyszer sem lép be.

5. Kipróbáltam sysy a kódodat, de az sem működik.

6. A CCS C programnak megvolt a v4.108 verziója, de az még nem ismerte a PIC16F1829-es chipet. A legfrissebb CCS, amihez hozzájutottam, és már ismerte ezt a chipet, az a v4.114. Valószínűnek tartom, hogy ebben jelenhetett ez a chip meg először, és nem jól csinálták meg. Lehet a CCS C v5-össel már jól menne, de az sajnos nincs meg nekem.

Kedves sysy!

Csak most volt időm tovább foglalkozni a dologgal. Beolvastam a PORTA-t még a main-ben is, meg az interruptban is, de nem működik. Bele sem megy az interruptba.
A program bekapcsoláskor 1 másodpercre felkapcsolja a PORTC-n levő 8 LED-et, majd lekapcsolja. Ezt követően a PORTA2-re kötött optokapcsoló kikapcsolásával a PORTA2 magasra egy, meg kellene hívódnia az interruptnak, ami a PORTC-n levő LED-ek felét kapcsolgatja tesztelés céljából, de nem kapcsolódnak fel, azaz be sem lép az interruptba. Pedig a chip PORTA2-es lábán mérem is az alacsony és magas jelszintet.
Mi hiányzik még a programból?

Kedves sysy!

Köszönöm válaszodat! Viszont nem értem. A beolvasás alatt input_a() utasítást értesz? És ilynkor a port milyen belső tárolóban mentődik el?

De ezzel a #byte direktívával nem csak az első 256 regiszterhez (azaz a BANK0-ban levő regiszterekhez) tudok nevet rendelni?

Kedves efiscp!

Nagyon szépen köszönöm, hogy foglalkoztál a problémámmal és válaszoltál, és részben a megérzésed az ASM blokkal igaznak is bizonyult. Ugyanis közben a CCS által készített .lst file átbogarászása során szerencsére rájöttem a problémára. Az interrupt-ot lekezelő void bit16szam_konverzio_BCD(signed int16 bit16_szam) szubrutinban levő ASM blokkban a bankváltást csináltam a 7-es bankra, amit aztán nem váltottam vissza. A CCS viszont a változóimat a 0-ás bank General Purpose Registereben helyezte el. A CCS a LCD_kepernyotorles(); (és egyébként minden más szubrutint) úgy fejezett be, hogy a bank-ot a 0-ásra váltotta vissza, ezért amikor először azt írtam a kódba, és utána jött a változónak az értékadás, akkor jól működött a dolog, fordítva meg nem.

Az ASM blokk azért kellett bele, mert valamiért a CCS függvényeivel megírt interrupt-on-change megszakítás a PORTA,2-es pinen (illetve más PORTA pinen) sem működött rendesen. Ráadásul ezen 16F1829-es chipnek a PORTB-jén is van ilyen interrupt-on-change lehetőség, viszont a CCS-ben ezen chiphez tartozó PIC16F1829.h header file alapján az enable_interrupt() utasításba csak PORTA-t, vagy PORTA-s pineket írhatok, PORTB-t egyáltalán nem. Nekem meg majd a PORTB kell.
Az, hogy CCS saját függvényeit felhasználva nem működik az interrupt-on-change megszakítás rendesen szintén megírtam ide a fórumba Bővebben: Link, de arra senki nem válaszolt.
Pedig lehet csak én rontok el ott is valamit, és örülnék, ha legalább a PORTA menne a CCS beépített függvényeivel.

Megváltoztattam a bit16 változónevet másra, de nemez volt a gond. Viszont még tovább kísérletezve azt vettem észre, hogy ha az interrupton belul a bit16szam_konverzio_BCD() függvényt úgy hívom meg, hogy bit16szam_konverzio_BCD(9876), akkor szépen kiírja a kijelzőre a 9876 számokat, viszont ha a
kijelzendoertek=9876;
LCD_kepernyotorles();
bit16szam_konverzio_BCD(kijelzendoertek);
módon hívom meg, akkor 0-t ad át függvényparaméternek.

Ha viszont felcserelem ebből a 3 sorból az első kettőt, akkor meg már jól működik:
LCD_kepernyotorles();
kijelzendoertek=9876;
bit16szam_konverzio_BCD(kijelzendoertek);
Azaz ha a változónak közvetlenül az előtt adok értéket, mielőtt meghívnám a bit16szam_konverzio_BCD() szubrutint.

Miért nem mindegy a sorrend?

Tovább tesztelve a programot úgy látom, hogy az interruptnak a szubrutinjában meghívva a bit16szam_konverzio_BCD(kijelzendoertek) szubrutint az lefut, de nem adódik át neki a kijelzendoertek, ezert ir ki 0-t. Valaki meg tudná magyarázni nekem, hogy mi az oka annak, hogy a szubrutint meghívva miért nem adódik át a paraméterben megadott érték?

Kedves Forumtársak!

A CCS C compiler-rel van gondom. A PIC16F1829 mikrovezérlő PORTA:2-es pinjén érkező felfutó él esetén megszakítás hívódik meg. Ez már jól müködik. A megszakításon belül az egyik felfutó élnél az 123 számnak kell megjelennie az LCD kijelzőn, ha újra jön egy felfutó él akkor pedig a 9876 számnak kellene megjelennie. Újabb felfutó élre megint az 123 karakter jelenik meg, és így tovább váltakozva (ez tesztelés miatt van). Az 123 karakter egyesével vannak kiiratva az LCD-re, mint különálló számok, és ez működik is. A 9876 számnál viszont egy szubrutin hívódna meg, ami ezt számjegyekre bontja, és ezeket a számjegyek lennének utána kiiratva. Na ez a rész nem működik, csak egy nulla jelenik meg ennél. A szubrutin a main(){} részben meghívva jól működik, akkor kiírja a számjegyeket. A problémám az, hogy nem értem, az interruptban meghívva miért nem működik.
Remélem valaki tud segíteni, és elmondja, miért nem hívódik meg a bit16szam_konverzio_BCD szubrutinom az interrupt-ot lekezelő szubrutinon belül, vagy ha meg is hívódik, akkor miért nem kerülnek a "tízezres, ezres, szazas, tizes, egyes" globális változókba bele az értékek. Bemásoltam a programot (az LCD_inicializalas szubrutint nem, mert elég hosszú, és az működik).
(Megjegyzés: Az LCD-t 4 biten vezérlem, ezért van az, hogy a karaktert reprezentáló byte felső és alsó 4 bitjét egymás után küldöm az LCD-nek)

Kedves Moderátorok

Pénteken nyitott témám (PIC interrupt On Change probléma) lezárásra is került rögtön, és a témaindító hozzászólásom ide került át. Szombaton még láttam is a hozzászólásom itt, már nem. Hova tűnt?

Az előző nyitó hozzászólásomban bennemaradt a megszakításkezelő szubrutinban a output_c(0x03); sor, de azt csak próbaként írtam be, hogy hátha az if-be nem megy bele a program (bár akkor az if utáni else-be be kellene mennie). Azt most nem kell figyelembe venni, csak már nem tudtam a nyitó hozzászólásomat módosítani.