Fórum témák
» Több friss téma |
Sziasztok!
Elég gyakori eset, ha valami periféria használatánál a párszáz nanoszekundum, egy-két mikroszekundumos késleltetéseket néhány Nop utasítással oldjuk meg. Igen ám, de ennek az a mellékhatása, hogy a fordító (legalább is a C18) az inline assembly beszúrása miatt ettől kezdve a teljes függvényre vonatkozóan kikapcsolja az optimalizációt, ami miatt tele lesz felesleges movlb utasítással a kapott kód. Jelenleg ezt úgy oldottam meg, hogy a program futását nem befolyásoló értékadással helyettesítettem a Nop-okat (pl. #define Nop() PCLATU = 0). Van-e ötletetek, hogyan lehetne ezt valami elegánsabb megoldással megoldani?
A C18 fejlesztői gondoltak erre is.
A hozzászólás módosítva: Jan 12, 2016
 A Note 1 alatt pont azt írja, hogy ezen makrók használata befolyásolja a függvény optimalizálását
Egyébként ha az if-es szerkezet futását szeretnéd gyorsítani, akkor csinálhatsz valami ilyesmit:
A hozzászólás módosítva: Jan 12, 2016
Persze ezt nem fix if-ekkel, hanem egy 8-10 soros ciklussal, es a hatarertekek egy tablazatban vannak leteve. A felezős módszerrel. Az 1024 elembol 10 vizsgalattal megtalalja a keresett ereket. 50 elemu tabla eseten max. 6 vizsgalat. Hamár programozunk...
Hello. Olyan kérdésem lenne, hogy a MikroC PRO-ba lehet e hozzáadni további pic típusokat? Van egy 16F505-öm és azt szeretném programozni. EasyPIC v7-em van, de ha van másik olyan program amiben megtudom írni a programot, és kompatibilis az EasyPIC-el, az is tökéletes lenne.
Köszi!
16F505 - 1k program memória, 72 byte RAM, 2 szintű stack -- Nem hísználnék C fordítót.
Ha van egy ilyen programrészem, akkor hogyan fordulhat elő a program futása közben, hogy az i mondjuk 65??? (Máshol az i csak a feltételvizsgálatnál van felhasználva!) A hozzászólás módosítva: Jan 14, 2016
Hali!
pl "máshol" elírtál egy feltételvizsgálatot (==) értékadásra(=) ? vagy valahol van egy pointered, ami rossz helyre mutat.. nézd meg debuggerrel mi történik.
Feltételvizsgálatok rendben vannak.
Pointert nem használok. Nézem debuggerrel ... sajnos elég ritkán jelentkezik a hiba, én nem mindig, csak azt látom, hogy a változó olyan értéket vett fel amit elvileg nem kéne. azt hogy mikor vette fel azt már nem tudni. 
Karakterfüzér (string) változó túlírása? 65 a kis "a" betü kódja.
Sziasztok!
Nyomógombok kezelésével próbálkozom, ezen belül lenne szükségem egy olyan funkcióra, ami két gomb együttes megnyomása esetén lép működésbe. A nehézséget az okozza számomra, hogy az együttes lenyomásnak ki kellene zárnia a gombok egyedüli megnyomáskori funkcióját. Remélem sikerült érthető formában leírom a problémát. 
Egy lehetséges megoldás, ha NY_A és NY_B '1'-t ad nyomáskor
!
Már nem tudtam módosítani
:Egy lehetséges megoldás, ha NY_A és NY_B '1'-t ad nyomáskor !
szerk.: Persze a nyomógombokat érdemes "prellmentesíteni" is és NY_A-t, NY_B-t csak segédváltozóként használni !
Ezzel az a gond, hogy mikor elengedjük a két gombot, egy pillanatig az egyik még nyomva marad, és lefut annak a függvénye is.
Valószínűleg létezik egyszerűbb, de jelenleg azzal próbálkozom, hogy (NY_A & NY_B) függvényében elindítok egy timer-t, és NY_A, vagy NY_B csak ennek letelte után tud lefutni. Szerk.: A gombok hardveresen és szoftveresen is vannak prellmentesítve.  A hozzászólás módosítva: Jan 25, 2016
Tegyél a programodba akkor egy változót, amit beállítasz valamilyen értékre, amikor elindul a "kétgombos" üzemmód, és az "egygombos" egy-egy rutin elején meg ellenőrzöd, hogy az a változó "kétgombos érték"-ben van-e, és akkor ne fusson le az egygombos rutin... ja és akkor itt az "egygombos" rutinban pedig egyben nullázni is tudod ezt a "kétgombos" változót, hogyha legközelebb csak az egyik gombot nyomod meg, akkor már fusson... vagy valami hasonlót lehet kivitelezni... így első gondolatra ez nekem jónak tűnik így, aztán lehet esetleg mégse pont így jó, hanem valamit módosítani kell esetleg a gondolatmeneten, vagy valami apró részletet hozzáadni...
Hát az alap, hogy egy nyomógombot "prellmentesítés" elfogadás után egy darabig tiltani kell ( pl. minden NY_A és/vagy NY_B aktiválás után elindítasz egy számlálót, ami mondjuk 0,5 s-ig tiltja az újabb elfogadást!) ! Enélkül nem megy, de ez ugyanolyan fontos a NY kezelésben, mint a "prellmentesítés"
! A hozzászólás módosítva: Jan 25, 2016
Én más megoldást használok:
A gomb lenyomásakor átállít egy flag bitet, majd elengedéskor aktiválódik, ha aktív a flag bit, és egyben vissza is állítja a flag bitet. Így nem volt szükség a számlálós tiltásra. abcdabcd: Időzítés nélkül sajnos nem jó, mivel a két gomb elengedése után biztosan lesz olyan pillanat, amikor még az egyik nyomva van, és ilyenkor aktiválódik az egy gombos funkció.
Akkor esetleg vagy kezeld gyorsabban a gombokat, pl megszakításból... mert legalábbis elméletben eléggé kicsi az esélye annak, hogy a két gombot pontosan egyszerre engedik fel, valamelyik valószínű nyomvamarad ha nem is túl sokáig... Aztán persze ez lehet nem jó megoldás, mert véletlenül valószínűleg előfordulhat olyan, hogy mégis épp egyszerre van a két gomb felengedve...
Vagy akkor még lehet akár az ellenkezőjét is csinálni, vagyis, hogy az egygombos rutinok elején beolvasod a gombok állását, és ha a másik gomb is nyomva van, akkor a kétgombos rutin fusson... Viszont valami időzítés meg ahogy kissi is írta valószínű kell, mert lehet akkor az adott rutinok túl rövidek, és amire lefutnak, a felhasználó csak akkor engedi fel a gombot, ami amúgy gondolom csak annyi, hogy valaki megnyomja, és a másodperc töredéke múlva már engedi is fel... A késleltetés meg akkor lehet végülis akár a rutin végén is (vagy az elején), vagy pedig lehet valahogy úgy is csinálni, hogy ott ahol a gombnyomásokat kezeled és a megnyomott gombnak megfelelően indítod el a különböző funkciókat, hogy akkor oda kell rakni valami "tiltást", hogy egy gomb megnyomása után meddig ne érzékeljen másik gombnyomást --> feltételezve, hogy a felhasználók úgyse tudják végtelen rövid idő alatt "értelmesen kezelve" nyomkodni a gombokat --> így, ha pl túl gyorsan jön bármilyen két gombnyomás egymáshoz képest, akkor az valószínűleg nem "érvényes" gombnyomás... És akkor a kétgombos üzemmódot meg ezen a "tiltási időn" belül valami még rövidebb időn belül lehet "érvényes két gomb megnyomásának" tekinteni... Vagy mondjuk azt akár lehet úgy is, hogyha valami megszakítással érzékeli a program a gombnyomást, hogy akkor megnézni, hogy esetleg mind a kettő meg lett-e nyomva, és akkor az időzítős részt nem kell ezzel bonyolítani... A hozzászólás módosítva: Jan 25, 2016
És mi lenne, ha megvárnánk, amíg mindkét gomb felengedésre kerül? Utána pedig jöhetne a függvény. Igaz, hogy ilyenkor blokkolódik a program, de ha olyanok az igények, belefér. Vagy megszakításban mondjuk 10mS-ként le van kérdezve minden gomb állapota, ha le van nyomva, a hozzá tartozó változó növelve lesz 1-gyel. A főprogramban meg kell annyi segédváltozó, ahány gomb van, amiket mondjuk 100mS-ként egyenlővé teszed a gombhoz tartozó változóval. Így sima feltételrendszerrel megállapítható, hogy melyik gombok voltak lenyomva ( amelyiknek a 100mS-mal előző értéke kisebb, mint a jelenlegi). Itt nem kell prellmentesíteni se. Az időket tetszés szerint kell módosítani, hogy ne legyen se gombnyomásvesztés, se semmi tévesztés.
A hozzászólás módosítva: Jan 25, 2016
Idézet: „mivel a két gomb elengedése után biztosan lesz olyan pillanat, amikor még az egyik nyomva van, és ilyenkor aktiválódik az egy gombos funkció.” De pont erre írtam, hogy ezért az egygombos elején ellenőrizd a változót (vagy a te esetedben flag-et), hogy aktív-e... vagyis ne a kétgombos rutin végén tiltsd le, hanem az egygombos elején ellenőrzöd, ha még aktív (--> ami azt jelenti, hogy épp lefutott a kétgombos) akkor tiltod a flag-et és az egygombos rutint viszont ekkor nem futtatod... Persze lehet jobb ezt valahogy "üzembiztosabban" kezelni, mert ha meg mégis pont egyszerre van felengedve a két gomb, vagy csak azon az "időfelbontáson" belül, amilyen felbontással a készüléked ellenőrizni tudja a gombok állapotát, akkor így meg az azutáni egygombos gombnyomás érvénytelen, és akkor a felhasználónak újra meg kell nyomnia a gombot, hogy érvényes legyen --> az meg nem biztos, hogy jó, mert akkor meg a felhasználó szempontjából úgy tűnik, mintha nem érzékelne minden gombnyomást a készülék... A hozzászólás módosítva: Jan 25, 2016
Idézet: „Én más megoldást használok: A gomb lenyomásakor átállít egy flag bitet, majd elengedéskor aktiválódik, ha aktív a flag bit, és egyben vissza is állítja a flag bitet. Így nem volt szükség a számlálós tiltásra.” Ezek szerint a prell ezen kívül szűrve !Viszont így egy gomb lenyomásával ( felengedés nélkül!) "beragad", idegesebb emberek nagyon erősen fogják nyomni a gombot, mert nem reagál egyből ! Szerintem nem ez a jó megoldás, de Te tudod!
Köszönöm mindenkinek a segítséget. Sikerült megoldani, az alábbi kód megfelelően működik:
kissi: Ebben a formában lenyomott gomb esetén a program tovább fut, nem ragad be. Kovidivi:A Te megoldásod is nagyon jónak tűnik, bár lehet hogy kicsit belekeverednék. Elmentem későbbre, még jól jöhet. abcdabcd:Valami hasonlóval próbálkoztam először, de időzítés nélkül sajnos nem jó. A hozzászólás módosítva: Jan 26, 2016
Üdv. Lenne egy olyan kérdésem, hogy csinálnék az autómba egy pices turbónyomás feszültség és mi egyéb mérő műszert és az értékeket bar graph megjelenítéssel szeretném csinosítani a kijelzett számok- értékek mellé. Egy "előnyagyolt" programot össze tudtam barkácsolni. Amit szeretnék rajta változtatni, hogy ne az összes vagyis 5X7-es karakterenként lépjen a kijelzés hanem karakterenként külön függőleges sorokban vagyis finomabb kijelzéssel működjön a dolog és ne egy egyszerű kijelző törléssel távolítsa el az előző mért értéket hanem valami ésszerűbb megoldással, így rengeteget frissít a kijelző és mindíg nulláról fut fel az érték (bar). Szeretném ha valaki tudna segíteni mit kéne átírni , hogy a fentieknek vázolt módon működjön a program. Linkelek egy videót mégis mire gondoltam. LCD BARGRAPH Igazából a progress bar ha működne onnan már megoldanám csak sajna nincs akkora tudásom kivitelezni
A videó alján levő linkben megtalálható a megoldás. Igaz az nem mikroc-ben van, de nem nehéz átvenni belőle a lényeget. 5 karaktert kell létrehoznod a legvékonyabb csíktól a tele karakterig, és azt kell kiírogatnod egymás után. A kijelző törlést meg úgy tudod elkerülni, hogy a törlendő karakter helyére kírod az újat, vagy ha törölni kell akkor SPACE-t .
Idézet: „Ebben a formában lenyomott gomb esetén a program tovább fut, nem ragad be.” Igaz, csak feleslegesen vizsgálod pl. a NY_A =1 && timerflag egyidejűségét, mert gondolom a timerflag csak akkor áll be, ha elég ideig nyomtad a gombot ! --> lassítja és "terjengőssé" teszi a kódodat ( persze, az hogy ez számottevő-e, az más kérdés!)!Ugyanezt írtam szerintem, csak az újbóli vizsgálat nélkül !
A timerflag mindig be van állva, kivéve a dupla gombos üzemmód utáni 200ms-ot.
Sziasztok!
Az alábbiakban van C18-as I2C írás függvénye ("gyári')
Amikor elkészült a küldés, akkor azt a Idézet: sor figyeli. Azonban ezt a megszakítás flaget semmi sem törli itt. Tehát azt nekünk kell. Ez így normális? Kicsit furcsállom, hogy azt nem rakták bele... „while ( !PIR1bits.SSPIF ); // wait until ninth clock pulse received”
Na, megint hamar írtam, hát ez evidens, nekünk kell törölni a megszakítás bitet. Csak ha egy kezdő programozó elkezdi ezt használni, akkor majd csodálkozni fog, hogy miért nem működik jól a program.. Jó, mondjuk tudnia kell a kezdő programozónak is hogy törölni kell a flagbitet.
 Bár akkor minek a C ? |
Bejelentkezés
Hirdetés |
