Fórum témák
» Több friss téma |
Idézet: „if(ora_10==2 & ora_1==4){ // 24:00:00-kor a teljes órát nullázzuk ora_10 = 0; ora_1 = 0; perc_10 = 0; perc_1 = 0; mp_10 = 0; mp_1 = 0; }” Érdemes??(Lehet a 2 sec naponta sietés okozhatja ???) 2 seces késést hogy lehetne korrigálni ha felmerült(írtam lapra....)??? A hozzászólás módosítva: Ápr 10, 2017
Kötelező, különbem tovább számolná az órát.
Nézd át a kódot, hogy milyen esetek fordulhatnak elő. Érdemes abból kiindulni, hogy miképpen hibázhat a program. 24 óra a legtöbb amit 24órás időszámításban vehetsz, ha nem nullázod, akkor 24:00 + 1perckor nem 0:01 óra 1 perc lesz, hanem 24:01. De ezt lehet nagyobb eltéréssel is vizsgálni. Ha óra átvált 24órára, akkor nulláztuk az összes időmérő változót. Számít a hőmérséklet, hogy ha nem egyenletes, akkor előfordulhat hogy késik vagy siet egy kicsit. Ha nagyon pontos órát akarsz akkor érdemes külső óra kvarcot vagy külső RTC-t használni. De ez gondolom nem egy atomreaktor lesz, hanem tanuló projekt. Kezdetben ne bonyolítsd túl a dolgokat, csak szépen okosan tisztán, hogy tanulj belőle. Ha nagyon késik és jól mérhető akkor a timer nincs jól beállítva, vagy ha minden jó, naponta korrigálod az eltérést. A hozzászólás módosítva: Ápr 10, 2017
A 2 sec per nap késéssel régi időkben olyasmit csináltak, hogy kvarcot összeforrasztották valami fém kalapos tranzisztorral, amin csak azért hajtották át az áramot, hogy fűtse a kvarcot. Külön hőmérő kellett, hogy a környezeti hőmérsékletet mérje, és annak alapján fűtse a kvarcot plusszban, mert annak hiányában a környezeti hőmérséklet megint csak elhangolt (tél / nyár). Ha nem akarod abba belegyilkolni minden idegszáladat, inkább fogadd el, hogy napi 2 sec nem a világ vége. Esetleg szuper pontos kvarcra cserélni a jelenlegit még meg lehet tenni, de azon túl hagyd a fenébe.
Ha mégis muszáj pontosabbat gyártani, szabad környezetben vagy (van rálátásod hosszúhullámú adókra), és beleférnek derékszögbe állított ferritmagos tekercsek a készülékházba, megpróbálhatsz ráhangolni a DCF77-re, és lesz másodperc pontos időd bármikor.
Ekkora eltérés simán lehet a kvarc gyártási szórásától. (meg a panel kapacitás viszonyaitól, meg a hőmérséklettől, meg a lábak hosszától, stb....). Ha pontos értéket szeretnél legegyszerűbb egy trimmerkondenzátorral megoldani. Pár év múlva meg - ahogy a kvarc is öregszik, - elég újra beállítani, nem kell a programot átírni.
Akkor a SIETÉST 2sec szoftveresen vagy hadweresen oldjam meg.??
Másik lehet baj 7805stab icé höje?? kb 1cm re vannak egymástól.
Van különbség a kétfajta írásmód között?
Ne bonyolítsd túl magadnak ezt az egészet..
Nagyon precíz akarsz lenne.. Nem kell. Elsőnek semmi kép. Ha zavar minden napforduló előtt vagy után -2mp-et vegyél el és kész.. ![]() Szoftveresen nyúlj hozzá, ha annyira zavar.. ![]()
Rendben igazad van
![]() ![]() Más témába szeretnék kérdezni van egy 5x5x5 led kockam. Egy szinten max 30mA folyik igy nagyon fontos a jó hatásfokú multiplexelés elkeztem "optimalizálni" De sajnos meghaladja a tudásomat.... A kód:
Jól csinálom????
Miért használsz int típusú változót?
Elég oda az unsigned char is. (8bit) Ennyi változó esetében érdemes megfontolni, hogy tömböt használj, úgy jobban áttekinthetőbb és rendezettebb lenne. Bár amúgy, így nincs benne sok felesleges dolog, szóval elég gyorsan fog lefutni.. ![]() Van egy disassembler ablak, amiben meg tudod nézni mit és hogy mekkora kódot fordít a fordító. A hozzászólás módosítva: Ápr 10, 2017
igy kéne időmultiplexelnem vagy inkább más modon??
Sziasztok!
Lehet, hogy nem pont megfelelo topic, de megis pic-el kapcsolatos es kevesbe vagyok jartas a lelki vilagaban. Adott egy pic16f872, aminek az eeprom memoria reszerol kellene egy dump. A gond az, hogy csak nullakat tudok kiolvasni, a konfiguracios bit word: 0x0C01. Ahogy en kitudtam bogozni, a konfig bitekbol az kovetkezik, hogy a CP nem csak a program es flash memoria reszre, hanem az eeprom reszre is engedelyezve vannak?
dsPIC C nyelve. Lényegében a linker működése lenne itt érdekes.
0x0C1=0b0000 1100 0000 0001
bit 5-4: kódvédelem. Ha mindettő nulla, akkor a program memória és az EEPROM terület is védve van, nem olvasható.
Nem akarlak megszavarni....
Megnézted más mit is fordut ebből a kódból??? 27 db 2 byte-os változót kell a software stack -re tenni, ami darabonként a következőkből áll: - a paramétert be kell tölteni egy átmeneti változóba, onnan indirekten címezve a memóriába írni, - meg kell hívni a rutint, - a paraméterek értékéről (16 bitesen) meg kell állapítani, hogy 0-e, - ha 0 a bites változót 0 -ra, ha 1 a bites változót 1 -re kell állítani. - visszatérés után (minden meghívás után) a 27 adatot "le kell venni" a stack -ről. Ez a tevékenység sokkal több időbe fog telni, mint 40us (a delay ideje a kijelző ciklusban). A byte (unsigned char) kb. fele ennyi művelet lesz, de még az is mérhetetlenül sok... A hozzászólás módosítva: Ápr 11, 2017
Az első kérdés ilyenkor, hogy működik e most a programod?
A második, hogy kielégítően működik e a programod? Ha igen, akkor jó, ha nem akkor nem jó.. ![]() Egyelőre nem törődnék vele, majd ha lenne jobb ötletem, akkor kipróbálnám. Ami nagyon fontos és jó lenne, ha mindig oda figyelnél, hogy a megfelelő típusú változókat használd. Nem tudom milyen fordítót használsz, de nézd meg nincs e olyan változó típus hogy boolen, ha az nincsen, akkor marad az unsigned char típus. Itt a lényeg az, hogy a te "int otodikleded1" változód, 2-4byte-os. Vagy is 16-32 szer több mint amire szükséged van. Az unsigned char is 8 szor lesz több mint amire szükséged van, de még is csak fele akkora, és fele annyi időbe kerül a lefutása. A változó típusokat át kellene nyálaznod kicsit.. Bővebben: Link ![]() A hozzászólás módosítva: Ápr 11, 2017
Biztos, hogy nem nézi meg, mert az ugyebár assembly, azt meg nem érti (ő sem).
A hozzászólás módosítva: Ápr 11, 2017
Pedig nagyon tanulságos a Disassembly Listing ablak... Felváltva láthatók a C és a belőle keletkező assembly utasítás sorok. Csak az assembly rész hoszzát kellene nézni...
A Fényerővel van problémám sajnos amikor egy képet rajzolok mondjuk egy szinten és időmultiplexelve akkor nagyon jó elfogadható a fényerő
De ha 5 szintre terjed ki a "kép" akkor van olyan hogy alsó szint jobban világit mint a közepe peddig az alsó szinten több led villágit mint a közepén. Ha több szintű az animáció akkor drasztikusan csökken a fényerő. MikroC és van boolen(igaz.hamis) változó igen van benne akkor inkáb azt használjam? A hozzászólás módosítva: Ápr 11, 2017
ohh....... Ba... Nem tom hogy felejtettem ezt ki a for ciklusnál igy néz ki a dolog:
A dsPIC-ekhez C30 és XC16 fordítók vannak, és linkerje mindegyiknek a sajátja. Melyikkel akasztottál bajszot?
A fényerő szabályozás legvalószínűbben kapcsolástechnika problémája. Ha azonos ideig hajtod meg a ledeket minden alkalommal (impulzus üzemben), és több led esetén gyengül a fényerő, akkor a kapcsolás technikát hibáztad el. Mindegyik áramútnak önálló kapcsoló kell. Ha azt kispórolod, olyankor lesz az a jelenség, hogy több led esetén mindegyik gyengébb.
A másik lehetőség a program hiba. Ha sok szintet hajtasz, és valamelyik nincsen bekapcsolva, akkor is szintenként kell végig menned, és üresjáratban hagyni az alkalmazást arra az időszeletre, amikor nem használt szintet hajtana meg. Ha azt kihagyod, és azonnal ugrasz a következőre, összegubancolódnak miatta a fényességi értékek.
Így is ki lehet fejezni...
Hogy a fenébe keresen az ember bármit is ha még a parametrikus táblázatuk is rossz. Nem hiszem el, hogy a MC még ezt sem képes rendbe rakni.... Nem tudok megtalálni x számú PWM-el rendelkező uC-t mert van 4 paraméter rá és nincsenek szinkronban. Pl: van 1 pwm kimenet de nincs hozzá ccp, eccp vagy standalone a táblázatban. Vagy épp fordítva. Milliárdos cég és nem tudnak egy embert ezzel foglalkoztatni... Észbontó.
Minden szintem 30mA folyikvagy is nem aminuszlábak vannak össze kötve ha nem a pluszok.
hmm vagy is a szintek idejét is számitásba kell venni még ha üres járat van akkor is jól értem???
MC-ékről az a pletyi, hogy még mindig áll a balhé az Atmel egyesülés miatt. Túl nagy náluk a káosz részleteken dolgozni.
Idézet: „Minden szintem 30mA folyikvagy is nem aminuszlábak vannak össze kötve ha nem a pluszok.” Ápoljuk szép újmagyar anyanyelvünket ![]() ![]()
Egy kapcsolási rajzot dobjál már fel.., hátha többet látunk..
Elkezdtem foglalkozni a kóddal is, és a lábakat azt még úgy ahogy értrem, de kérdezem, hogy jó-e ez így? Visszaolvasva megtalálható a kapcsolásom, nem mellékelem újra.
Ezen a részen viszont mit módosítsak? Egyáltalán jó-e nekem?
A hozzászólás módosítva: Ápr 11, 2017
|
Bejelentkezés
Hirdetés |