Én itt mindenképen a hardveres prellmentesítést preferálnám (1db kondi már sokat lendít a helyzeten). Amit hardveresen meg lehet oldani, azt nem szoktam/nem szeretem szoftveres tajkolással lekezelni.
Mindemellett ha megengedsz pár apró észrevételt..
1. Kicsit jobban struktúrálhatnád a forráskódot (áttekinthetőbb)
2. kicsit több kommentet fűzhetnél hozzá, pl hogy melyik változó mire való, hogy ne a kódból kelljen visszafejteni. Ez később ha elő kell venni egy régi programot Neked is sokat fog segíteni.
3. Mivel csak egy gombot figyelsz, azt át lehet tenni az RA2-re, és az EXT_INT megszakítást figyelni. Így csak akkor lesz megszakítás, ha valóban gombnyomás törtánt, ellentétben at INT_RA-val. Egyszerűsödik a kód, átláthatóbb és értelmezhetőbb lesz, nem lesznek felesleges megszakítások.

Persze mindennek ennél a projectnél nincs számottevő hozadéka, de ha most megszokod, később igen sokat segíthet.

W

En a hardware-es prell mentesitessel nem ertek egyet, kiveve, ha a PIC-nek van ST bemenete es igy csak egy ellenallas es egy kondi kell hozza, ilyenkor termeszetesen megfontolando.

Amiatt gondolom igy, mert a kontrollerrel szepen meg lehet oldani ezt a feladatot (is) es cserebe alkatreszeket es helyet sporolunk a panelon, ami ugye egyszerusiti az aramkort - az pedig eloallitasi koltsegeken jelenthet megtakaritast, de egy otthoni projectnel is egyszerubbe teszi a hobbista eletet.

Ha interruptosan akarjuk megvalositani akkor kell egy timer interrupt is. A timer szamlalojat mindig nullazzuk ha erzekeljuk a felfuto (vagy lefuto, attol fugg hogy kotottuk be) elt. Ha a timer interrupt bekovetkezik, akkor meg kell vizsgalni valoban gomb nyomas tortent-e (meg mindig magas vagy alacsony a port laba), es ha igen, akkor lehet azt a jelzo bitet bebillenteni ami a gomb megnyomasat fogja jelenteni a foprogramban. A timer interruptot ugy kell megirnunk, hogy az termeszetesen csak egyszer kovetkezhessen be... ill. ha ismetlest szeretnenk akkor mindaddig ameddig a gomb lenyomasa teljesul (de akkor szamlalok ill statusz jelzok illenek oda).

Ennek egy valtozata mikor az elso jelzesre ugyanugy beallitjuk a timert, de a gomb nyomasat kivalto interruptot ideiglenesen letiltjuk ezzel elkerulve, hogy a prell idejere tobb szaz interrupt beessek. Ilyenkor ugyanugy a timer lejartakor ellenorizzuk valoban gombot nyomtak-e le es a fentebb leirtak szerint jarunk el, de kozben ujra engedelyezzuk a gomb lenyomasat kivalto megszakitast...

Való igaz, ez is lehet szempont, bár csak a hely probémával értek egyet (bár a mai SMD világban már ez sem lehet túlzott akadály ha a nyákot nem házilag készítjük), a költség oldal vitatható (2-5 HUF nem jelenthet akkora problémát, nem éri el az összköltség 0,5%-át sem).
A PIC-eknek bizony van ST bemenete gazdagon, lehet belőlük válogatni. (a 16F690-nél az A2 is az)
Mindamellett ha a kapcsolóval párhuzamosan köt egy kondit fel/lehúzó értékének ismeretében belőhető hogy a kondi a prell ideje alatt még éppen ne tudjon újratöltődni.
Nekem ez hobbi célokra eddig tökéletesen bevált. Nem vitatom hogy nem 100%....
Szoftveresen valóban sokminden megoldható, de az már olan .....-os megoldás (ez itt nem az anti rekám helye).
Vannak cégek, ahol a nyákok tervezésekor elkövetett hibákat szoftveresen javítják....
No de nem vagyunk egyformák... kinek a pap, kinek a papné.... nekem a láányuk

Köszönöm szépen mindkettőtök észrevételeit, tanácsait! Igyekszem betartani !

Az általad használt R és C értékekre azért kíváncsi lennék. Gondolom 4k7-10k és 100-220nF között van valahol. Ilyenkor abszolút nem használsz szoftveres prellmentesítést?

10-15k - 100n párost használtam (igaz nem sokszor, de eddig nem volt vele semmi gondom, bár ez nem jelenti azt hogy nem is lesz, de elvileg minden prell-nél a kapcsoló legalább részben kisüti a kondit, így nem szabadna hogy gondot okozzon.

Sziasztok!
sprintf függvénnyel próbálok egyik váltózó adott helyiértékét egy másik változóba áttenni kevés sikerrel. Tehát például ha a var1=543 és nekem a második digitet kell áttennem akkor a var2-nek négynek kéne lennie, viszont nem az. A változók unsigned int típusúak. sprintf(var2, "%01u", var1); Mit csinálok rosszul?

Tartok tőle hogy a sprintf lényegét nem érted pontosan.
A %01u azt jelenti, hogy 0 a vezető nullákkal feltöltve 1 byte hosszan írja ki u előjel nélkül a kapott 8bites értéket egy char[] be.
"A változók unsigned int típusúak."
Ez már itt gyanús.... az unsigned int 8 bites.
Az 543 nem 8 bites.
A vezető 0-ák feltöltésének 1 karakter esetében nincs értelme, bár hibát nem okoz

Mindenek előtt döntsd el, hogy neked a 4 mint byte (0x04) vagy a '4' mint char (0x34) kelll??? 0x04 <> 0x34!

Köszönöm a válaszod! Ezek szerint a sprintf-el jól melléfogtam, most használtam csak először. Az adott helyiértékeket byteonként kéne átmásolnom egy változóba, tehát 4=0x04ként jellene meg ott.

Ha egész számokkal dolgozol próbáld a problémádra az osztást ( / ) és a modulust ( % ) használni...
PL: var2 = (var1%100)/10

Pontosan melyik állományra gondolsz, mert a SW books könyvtárban nem találtam ilyen leírást.

A PIC könyvtárban keresd!

Ez a fejezet tényleg ilyen rövid, vagy csak elfelejtetted feltölteni?

chap13_tmrs_cap_measure.pdf

Egészen pontosan melyik irományra gondoltál, mert nem ismerek rá a címéből.

Így már működik, köszönöm!

eBook - PIC Programming with C.pdf. Erre gondoltam. A PIC konyvtarban.

Jaaaa! Ezért nem találtam. Én a CCS team-től kerestem és ez sajna nem az. Ez a könyv nem rántotta le a titkokról a leplet, ha voltak is ilyenek. Kezdőknek jó, de sajna nem autentikus. Azt hittem, valami marhanagy áttörés lesz és beleláthatunk a misztérium legmélyébe. Mindenesetre köszi, hogy felhívtad a figyelmünket erre.
(Valami jobb megosztóoldalt is találhattál volna ezeknek a jobb sorsra érdemes könyveknek.)

Mondjal valami jobbat. Regebben probalkoztam "data.hu", "juzendit", RS, es egyeb ilyenekkel, de ugyanaz a baromsag. Itt legalabb nem torli a tartalmat, es van 10G szabad tarhely.

Sziasztok!
Lenne egy láma kérdésem:
Ha egy mért értéket szeretnék besorolni (majd az alapján) műveletet végrehajtani, hogy a legegyszerűbb? Eddig if-else -vel készítettem, de már túl sok a paraméter. Gondoltam a switch-case-re de ott meg a feltétellel van gondom.
Ilyesmi a skálázásom: ha érték 10-12 -ig akkor..., ha érték 12-14,4, akkor...., ha érték nagyobb mint 15, akkor... etc. Van erre valami logikai rendszer? Vagy marad a sok if()?

Rapidshare sem törli az állományokat, én ott tartom a megosztani kívánt adataimat. Ha pontgyüjtő vagy akkor még ráadásul szereti is ha sokan töltik le a filéidet. Bár mostanában a rapidshare is bekeményített a letöltőkkel szemben. Azt hiszem, hogy mindenki ráhajtott a pénzre. Most, hogy belegondolok, nem is olyan rossz az a tárhely, ahol te tartod a filéket. Csak egy kicsit el van dugva a letöltés gomb

Csinalhatsz ugro tablat, ha van elegendo program memoria ehhez. Tehat egy tombot letrehozol amiben cimkek / fuggvenyek cimei vannak, es egyszeruen a parameter az index, az alapjan a tombbol kiemeled a meghivando fuggveny cimet es ra ugrasz.

Amugy a switch..case -nek ha jol optimalizal a CCS, akkor abbol is ilyen tablat kell neki legeneralnia. Kicsit talan csunyacska a kod, de hatekony...

Masik lehetoseg, hogy az elso lehetoseghez hasonloan jarsz el, csak nem fg cimeket, hanem azok indexeit tarolod el, aminek igy ksiebb a memoria igenye. Ezutan ezzal az index-szel cimzed meg a fuggveny cimeit tartalmazo tabladat...

Ha pedig maradsz az if..else-nel akkor probaldd meg binaris faba szervezni -- tehat eloszor megnezed a kozepenel nagyobb-e, ha kisebb akkor megnezed a harmadanal stb. Igy sokkal kevesebb if-el el fogsz jutni a vegrehajtando kododhoz...

Sziasztok!

Kérdésem annyi volna, hogy mikor készítem az interrupt függvényeket van- e jelentősége, hogy hova helyezem el a megszakítás függvényt (main elé mögé) és a megszakítási függvények sorrendje számít? Pl tmr1 megszakítását tmr2 mögé teszem van jelentősége?

Köszönöm válaszotokat

Azért kérdezem mert csináltam egy megszakítást tmr1-el kifogástalan a működés szépen meg is történik a megszakítás. Viszont ahogy elhelyezem a tmr2 megszakítás függvényt onnantól már a tmr1 és tmr2 megszakításom sem hajtódik végre, pedig a statusz jelző flagek setelödnek?? Nem tudom mit kavarhattam el.

Tudtommal nincsen. Arra kell nagyon ügyelni, hogy az #int_akarmi direktíva és a hozzá tartozó eljárás közé ne kerüljön semmi. Például:

Amit megfigyeltem ha a programomban elhelyezek még a timer initializálások előtt egy delay_ms(10); -et akkor nem működik. A megszakításokat nem kell return;-al zárni?

Hali
Altalaban a "main" legyen az utolso.A 16-os sorozatnal nincs prioritas az IT-k kozott. Amelyik elobb becsap, az fog vegrehajtodni, majd az utana kovetkezo. Ezt a kodod fogja kivalasztani. Nezd meg a "lst" filet a 0x04 cimtol, es lathatod hogyan kezeli az IT-t. A 18-as sorozat mas teszata, mert ott van alacsony, es magas prioritasu IT. Termeszetesen a magas prioritasu hajtodik vegre eloszor. A "return" nem kell, mert ez nem adhat vissza erteket. Azt akkor hasznaljuk, ha egy nem "void" fveny ad vissza valamilyen erteket: " return ch".

Köszönöm , ds pic-el dolgozom ott van prioritás valahogy ez a delay függvény kavar be.

Köszönöm! Sajnos a memória kevés (szokás szerint).
A switch/case -nél, hogyan lehet feltételt megadni? Vagy előtte paraméterezzem le a mért értékeket? De akkor már megint belefutottam az if/else körbe... A switch/case-nél nem csak 1 figyelt változóra/portra lehet beállítani?

Hali
Lehet a kovetkezo format hasznalni:
Persze elo kell allitani a valtozot. Lehet a legkisebb lepessel osztani az eredeti valtozodat, es utana az osztas eredmenyevel megcsinalni a fenti trukkot. Persze nem lehet mindenre rahuzni ezt, de azert egyes esetekben hasznos lehet.

Köszi. Magát a switch/case eljárást ismerem. Az én esetemben ez így értelmetlen lenne. (A változót csak if/else-vel lehetne előállítani. Akkor meg már felesleges a switch/case) Gondolom én. Ha mégis félreértettem, akkor egy kicsit még magyarázd, légyszi!