Üdv mindenkinek! Eddig csak olvasó voltam, de most elakadtam: a RB4 interrupt az MPLAB-ban jól múködik, de a panelon megbolondul. Mit jelent a katalógus mondata: "Polling of PORTB is not recommended while
using the interrupt-on-change feature." Szavazni itt aligha kell...

Azt jelenti, hogy megszakítás használatával nem kell a főprogramban ciklikusan rá-ránézni a portra a változás detektálása végett, ezt elvégzi a hardver és megszakítást generálva jelzi azt. Egyébként mi a hibajelenség?

Polling itt nem szavazást jelent, hanem időszakos lekérdezést. Vagyis azt mondja, hogy ha az interrupt-on-change engedélyezve van, akkor nem ajánlott a főprogramból a PORTB kérdezgetése, hanem csak a megszakításjelző flag bebillenésekor kérdezd le. Gondolom azért, mert a megszakítás után a PORTB lekérdezése törli a megszakításjelző flag-et, és így bizonyos körülmények között lemaradhatsz a valódi megszakításról. Bár így most nem jut eszembe, hogyan állhatna elő ilyen körülmény, de pontosan melyik PIC-ről van szó?

Sziasztok!

Valószínű, hogy nagyon egyszerű a megoldás, de én nem tudom. Hogyan tudom a PORTD egyik bitjét 1-be állítani C-ben. Nem így akarom: PORTD=0x01; HI-TECH C fordítóm van. Segítsetek legyetek szívesek.


Köszi

Nem egyszerűen PORTD1=1; ? Vagy esetleg ha már a C18 stílusú, akkor PORTDbits.RD1=1. Nézz bele a PIC tipusának megfelelő header fájlba, ott megtalálod, hogyan vannak elnevezve.

Megvan! Köszi. Simán RD1=1;

Köszönöm a választ. Pic16f628 a PORTA komparátorként hibátlanul működik, míg az RB4-et földre nem kapcsolom. Innentől a komparátor sem megy, és az RB4 megszakítás hatásos, de másik kimenetet kapcsol, mint kellene. (Radiátor és padlófűtés összehangolt vezérlésének szánom, ahol a kapcsoló a szobatermosztát, a padlófűtés visszatérő hőmérsékletét a komparátor ciklikusan ellenőrzi megfelelő késleltetéssel. Kimeneten a kazán, egy mágnesszelep és egy keringtetőszivattyú.) A megszakításkor a GIE bittel - remélem - minden zavart letiltottam, majd a rutin végén engedélyezem újra a megszakítást. A szimulátor rendben kezel mindent...

Sziasztok!

Valaki el tudná magyrázni, hogy hogyn működik az aktív magasan kapcsolt kapcsoló?

Az aktív alacsonyt értem, azt nem értem, mért más az aktív magas csak attó, hogy nem 10k az ellenállás érték hanem 180 ohm

lehet baj, hogy a komparátor kikapcsolásakor lekérdezem a kapcsoló (RB4) állapotát? Ezt majd megnézem!

Mondjuk a GIE bitet jobb nem macerálni a megszakítási rutinban.

Áruld már el, hol láttad, hogy a GIE bitet a megszakítási rutinban állítani kell bárhová is?

Szerintem valami más ott a különbség, nem (csak) az ellenállás.

Szia!

Ugyan úgy működik. A kapcsoló / nyomógomb a tápra kapcsolódik, a jelvezeték pedig a földre van húzva ellenállással.

A bemeneti áramokkal is kell számolni.
A mai CMOS áramköröknél a bemenet árama elhanyagolható, és kb megegyezik a magas és az alacsony szinten mérhető áram.
A régi TTL normál elemeknél a magas szintű bemenő áram ~100 uA, az alacsony szintű 1.4 mA volt. Az alacsony logikai szint maximális értéke a bemeneten 0,8V. Ezeknél az áramköröknél a lehúzó ellenállás nem lehetett nagyobb mint (0,8/0,0014) azaz 571 ohm. Ha egy ellenállásra több bemenet is kapcsolódik, a bemeneti áramokat össze kell adni, és a legrosszabb esetben sem haladhatja meg az ellenálláson eső feszültség az alacsony bemeneti szint maximális értékét.

Alacsony szinten mérhető bemenő áram a TTL családokban:
74xx: 1.4mA, 74LSxx: 0.4mA, 74Sxx: 2mA
Vannak olyan elemek, amik egyes bemenetei többszörös áramot használnak.
Jó az öreg a háznál...

Idézet:
„Jó az öreg a háznál...”

Mondjuk én azt hittem, PIC bemenetéről van szó, ha már PIC-es téma...

Van, amit magam találok ki... Háromféle megszakításom van, és egy végtelen türelmes rendszerem. Nem örülnék, ha egymásba csapdosnának az interruptok. Feltételezem, hogy így csend van a megkezdett rutin közben, és nem kell mindent a verembe pakolni. Az sem baj, ha kimarad egy-egy megszakítás kezelése, a rendszer elbírja.

Csak épp ezzel elcseszed az egészet, hogy a megszakítási rutinban a GIE bitet macerálod. Adatlap szépen leírja, hogy a GIE bitet a hardver nullára állítja, amikor a megszakítási rutin kezdőpontjára ugrik és magától visszaállítja, amint a RETFIE utasításra ráfut. Ezzel biztosítva van a csend egy megszakítás kiszolgálása alatt.

Idézet:
„Mondjuk én azt hittem, PIC bemenetéről van szó, ha már PIC-es téma...”

Igen, en is majdnem bele kezdtem a TRIS meg a felhuzo ellenallasok es 5V <-> 3.3V elemek csatolasanak magyarazataba

Szia!

Egy fiatal tervező elolvassa a könyveket, és azokban szereplő mintapéldákat próbálja meg alkalmazni - esetünkben pic -kel. Ahogy a mai napig nem tudjuk lebeszélni az embereket a 16F84 -ről, úgy a mintapéldák is a hőskorban íródott könyvekből (TTL receptek @ TI) származnak...

Szia!

Ajánlom , hogy olvasd el ezt a cikket...

Jó reggelt!
Annyira belezuhantam a csatornaváltás normális kiértékelésébe,hogy teljesen belegabajodtam. A kijelzések egymásba csúsznak, lefagy. Az _1 az első azután a a _0 az _1 ezelőtti állapotának különbégére lenne. a_2 meg a második lenne, de ez így nemjó. Pedig van késleltetés. És szerintem nem az a baj, mert ha nagyon nagyot teszek bele ugyanazt csinálja csak szaggatva

Szia'

A csatorna kiválsztása (ADCON regiszter bemenetválasztó bitjeinek írása) és a GO bit 1-re állítása között kell 2 * Tad időt várni! Ez nincs benne a programodnban, pedig már megírtam...

Az OP rendszer nem dobott rá hibaüzenetet. Próbáltam már azt is, hogy megcserélem a D+ és D- vezetékeket. Az sem segített. Láttam olyan kapcsolást, ahol ezekre a vezetékeken 22 ohmos ellenállást tettek. Azt is kipróbáltam, de nem segített. Amúgy volt idő, amikor ment. Azt csináltam, hogy ICD3-al töltöttem fel a szoftvert a PIC-re. Akkor ment egy darabig. Utána megint nem. A vezetékek hossza 1,5 max 2 cm. Ennyire van a csatlakozó a kontroller lábaitól.

Szia!

A betöltött program véletlenül nem Debug módban fordult?

Sziasztok!

Van egy makacsul visszatérő problémám amire nem találok megoldást. Nem régen már felvetettem itt a fórumon, kaptam is ötletet, de a hiba ennek ellenére azóta is előfordul. (eredeti hsz #885764) Akkor icsernyi javasolta a BOR bekapcsolását, de a helyzet nem változott. Ha teljesen lemerül a táp (LI-ON akkuról jár az áramkör), tehát szépen lassan leesik a tápfeszültség 2,4V ig akkor az áramkör már egyáltalán nem kap tápot. (Mivel a LI-ON akkuban lévő elektronika ekkor már lekapcsolja a tápkimenetét a mélykisülés megakadályozása miatt) Ha feltöltöm az akkut és megnézem az EEPROM területet, megint teli van "00" értékekkel. A programot ugyan (pont e miatt jobb híján utólag...) úgy írtam meg hogy ebben az esetben az eeprom területet a kontroller ismét feltölti az állandó értékű paraméterekkel, de vannak olyan eltárolt értékek is a területen amik üzem közben eltárolt változó értékek. Ezeket ugyebár már nem tudom vissza írkálni mert a bánat tudja hogy eredetileg mi volt melyik címen. Tehát erre kéne valami megoldás vagy ötlet, esetleg a hardveren kéne valamit változtatni..stb. A kontroller egyébként 3,3 V stabil tápról jár, 3,4 V nál pedig elmegy sleep be mert ilyenkor már a vezérelendő hardver (GSM modul) is sleepbe kerül, lekapcsol. Tehát a kontrollerre 3,4 V alatt nincs is már szükség. Esetleg hardveresen kapcsoljam le a tápot a kontrollerről 3,4 V alatt..? Van valakinek valami ötlete erre a problémára..?

Köszi előre is..

Szia!
Arra is figyeltem. Nem Debug módban fordult. Én valami hardver hibát gondolok rá, de nem bírom elképzelni, hogy mi lehet. Nem tudom már, hogy mit vizsgáljak rajta.

bocs, az előbb nem sikerült...: eredeti hozzászólás linkje..

Az EEPROM területre írsz a programodban? Biztos, hogy elmegy aludni és nem csökkent tápfeszültséggel írkál az EEPROM-ba?

Sziasztok! Az alábbi kódban hogyan tudnám elérni azt, hogy a függvénynek átadott paramétert az assembly kód is lássa? Sajnos semmi értelmeset nem ír erről a manual. SDCC -ről van szó.

Hiba: Symbol not previously defined (us).
Érdekes, mert a macro_delay változót látja ha _ jelet teszek elé, de az us-t nem. Van ötletetek? köszi

Igen, ez már a sokadik verzió volt és mint mondtam, belezavarodtam. Azóta visszacsináltam, van előtte késleltetés. Még mindig beleszól az egyik a másikéba nemkevéssé. Olyan 1-20 értékváltozást okoz. Akkor is beleszól az éppen üzemenkívüli ha nem váltok csatornát és az inaktív potit tekergetem. Szóval valami alapvetően nemjó. A potik mind a kettő 10k-s. Leginkább akkor csúsztatja szét ha a közepe felé jár. A két végéhez közel, már nem nagyon szól bele egyik se a másikéba.

Nem próbáltad esetleg más USB kábellel?

Nem próbáltam másik kábellel, de közvetlenül rádugtam a gép USB portjára. Megpróbáltam másik gépekben, de ott sem volt semmireakció.