Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Szia!
Én csak arra szerettem volna felhívni kiskacsa2009 figyelmét, hogy az órához biztosan nem kell 3 darab 16F887, az időt számolni, beállítani és a kijelzést egy darab is meg tudja csinálni. Az eredeti elképzelésből hiányoltam a beállítási lehetőséget. Az analóg órákon az óramutató nem ugrik egyik óráról a másikra, hanem "folyamatosan" megy előre (pl. negyed hatkor az öt és hat közötti osztás negyedénél jár). Valóban elszámoltam 4*60- at írtam 3*60 helyett. A hozzászólásomban pont azt írtam, hogy a ledek vezérlését at kell gondolni a megépítés elött. Szia...
Én sem ismerem a CC5X fordítót, de már többször felhívtam Szigetiván figyelmét, hogy olvassa el a CC5X User Manual-t! Többféle matematikai könyvtárat ismertet (lebegőpontos, fixpontos, miegyéb), pont azért, hogy az adott feladathoz optimalizálni lehessen a memória (és más erőforrások) felhasználását.
Itt a legnagyobb problémát tényleg a tizedespont okozza, de a kifejezés tovább egyszerűsíthető: i = a + 10*2.3/7 helyett i = a + 23/7 írható. Az más kérdés, hogy ennek úgysincs értelme, hiszen az egészosztás miatt i = a + 3 lesz belőle.... Az eredeti algoritmust kellene inkább revideálni!
Szerintem ilyen esetben inicializáláskor nem egy adott értékkel kell feltölteni a számlálót, hanem egy adott értéket kell HOZZÁADNI ( ebből csak a TMR1H léptetésénél lehet probléma, de azt is le lehet valószínűleg kezelni!), így nem vesznek el a holt időben beérkező impulzusok!
( remélem nem értettem félre a problémádat?! ) Steve
Sziasztok!
Ajánlom figyelmetekbe ...
Én csak azt nem értem minek birizgáljátok a timer számlálójat ? Miért nem compare üzemmódban használjátok ?
Igen, tudom, hogy hozzáadni szokás, az az OR-olás gyakorlatilag a hozzáadással azonos jelen esetben. A gond ott volt, hogy nem volt mindegy, mikor teszem ezt meg: ha megvártam a timer1 értékváltását , és közvetlenül utána update-eltem a számlálóregisztert, akkor jó volt, ha csak úgy vaktában, akkor - úgy tűnt - időnként nem sikerült lépnie, amikor kellett volna.
Aham, hát lehet, hogy pont ebben van az ok leírva: nem mindgy, hogy mikor update-eli az ember a timer regisztert, mert elveszthet egy számlálást.
Nekem eszembe jutott az óra építésekor, de mivel sosem használtam még olyan módban, lusta voltam foglalkozni vele. Meg amúgy minden appnote és egyéb példa is a timer regiszter újratöltését emlegeti.
Gyanítom, hogy compare módban azt kellene csinálni, hogy a komparálási értéket mindig megnövelni 1/16 másodpercnyi-vel az interruptban. Apropó: compare int is fel tudja ébreszteni a PIC-et? Mert az órám az 1/16 másodperceket szépen "átalussza".
Sziasztok!
Mivel már annyiszor mondta régebben icserny elolvastam az ehhez kapcsolódó részt, és csak utána kérdeztem. Mindent megpróbáltam úgy használni ahogy abban a manualban írva van Amit ezzel a fordítóval adtak matek könyvtárak az csak a math16.h és a math24.h. Köszi a javaslataitokat a tizedespontot kivettem és átalakítom a képletet, de attól még mindig ezt a hibát írja ki.. Idézet: „Az eredeti algoritmust kellene inkább revideálni!” Ez mit jelent, nem ismerem a revideálni kifejezést?
Felülvizsgálni, górcső alá tenni...
Sziasztok !
A megszakításokkal kapcsolatban kérdezném hogy ha egy futó megszakítás alatt jön még egy megszakítás (ugyan attól a perifériától ami kiváltotta, pl soros vételnél) akkor mi történik? Félbeszakad és az elejétől lefut újra a megszakítás? Hogyan működik ez a dolog?
Nem szakad meg, hacsak nem macerálod a megszakítási rutinban a GIE bitet, amit tilos csinálni. Újra le fog futni mégegyszer a rutin, amikor az elsőt befejezte.
Viszont ha újra bebillen ugyanaz a megszakítás, amíg az előzőre nem fut le a rutin, akkor ott azért el kellene gondolkodni, mert vagy rossz a program szervezése, vagy a kontroller nem elég gyors a feladathoz.
Köszi, így már értem.
Ezt azért kérdeztem mert a soros vételt úgy gondoltam megvalósítani, hogy ha "x" ideig nem jön adat az RCREG be akkor az "x" idő lejárta után kezdem meg a beérkező adatok feldolgozását. De ezek szerint máshogy kell ezt megoldanom, nem így.
köszi
A következő kódot próbáltam épp az imént a CC5X free verziójával:
Az eredmény sikeres fordítás lett: Total of 323 code words (15 %) * Estimated CODE SIZE of full optimization: 246 code words (-23 %) RESTRICTIONS on commercial usage applies as described in file readme.txt Loaded C:\PIC\cc5xtry\main.COD. BUILD SUCCEEDED: Thu Apr 16 12:53:59 2009 Látható, hogy a float miatt kellett neki a 24 bites floating point matematika (math24f.h), amivel ez ez a rövid kód 323 szót elfoglal a programmemóriából. A nem ingyenes verzió teljes optimalizációjával is 246 szó lenne a lefordított méret.
Idézet: „elolvastam az ehhez kapcsolódó részt” Hmmm. Ha elolvastad, akkor vajon miért nem tűnt fel, hogy a math16.h csak 16 bites egészek szorzására és előjel nélküli 16 bites egészek osztására alkalmas? Most nem tudom, hogy éppen mivel szenvedsz, de a belinkelt programodban is van egy olyan sor, ami a fordító számára értelmezhetetlen: temperature = 0.0488*((10*homer)-1024); Idézet: „nem ismerem a revideálni kifejezést?” Gugli barátod csak tudja!?
Alapvetően egy megszakítási rutinban nem "illik" várakozni, főleg nem egy olyan eseményre, ami tőled függetlenül vagy bekövetkezik, vagy nem.
A soros vétel interruptját úgy szokás megírni, hogy a beérkezett karaktert valami biztonságos helyre eltenni (akár csak egy saját változóba, akár egy bufferterület következő szabad helyére), és valamilyen jelzést beállítani (pl. egy saját változó egyik bitjét), amivel a főprogramnak jelzed, hogy jött új adat. Az interruptnak ennyi a dolga, majd a főprogramban várakozhatsz arra, hogy jöjjön be adat, de ott az interrrupt által beállított jelzést kell figyelned. Feldolgozás után meg - természetesen - törölni kell a saját jelzésedet.
Szerintem úgy is lehetne órát csinálni hogy egyszer jól beállítod a komparálást, és akkor mikor beesik a megszakítás akkor úgyis nulláza a timer countert, te meg csak számlálod hogy hányadik megszakítás ez. (mert valószínűleg 1mp alatt több megszakítás fog beesni) Tehát nem kell később birizgálni se a countert, se a comparátort.
Jólvan na, mindig igazad vanMajd próbálok figyelmesebben olvasni.
Ha érdekel elmondom mivel szenvedek most éppen. A PIC-em RA1 és RC0 lábára kötöttem két szenzort és azokkal szeretnék mérni. Ezért van szükségem ADC-re és egy képletszámolásra, majd szeretnék még egy Bin to ASCII konverziót a végén. Mivel a C-vel mégcsak most barátkozom, ezért a kérdéseim néha egyszerűnek tűnhetnek neked vagy másoknak akik már egy ideje a témával foglalkoznak, de sajnos fennakadhatok 1-2 dolgon, ami még nekem nem tiszta.. Köszi a válaszod
Tudsz mutatni valami folyamatábrát, pszeudokódot vagy ilyesmit erről? Nem világos, hogy pontosan mit akarsz mondani.
Szia!
Köszi én is kipróbáltam és most már nekem is működik Majd megpróbálom optimalizálni t = 25*((10*homer)-1024) / 512 képletemre (homer = ADC által adott 10 bites szám), és remélem szép számot kapok a végén Nagyon köszi a segítséget!
Igen, es ez egy nagyon jo otlet. Az egyetlen kerdes mar csak az, hogy ez az uzemmod megy-e sleep alatt, mert ezzel a modszerrel szilva valami hihetetlen kis fogyasztast ert el. A compare meg csak akkor mukodne, ha a timer1 szinkron modban menne, az viszont sleep alatt nem megy. De persze lehet felre ertettem valamit.
Szerintem a timer nem nullázódik attól, hogy a compare interrupt beesik. Az a 16 bites számlálólánc simán számol tovább.
pedig nullázódik ha úgy állítod be:
Compare mode, trigger special event (CCPxIF bit is set, CCPx pin is unaffected); CCP1 resets TMR1; Én ezt dcc jel generálására használom. (ott állitgatom a comparátort, de ez itt most lényegtelen) Sleep üzemmődban nem megy ez ,mivel a timer áll.
Csak annyit akartam ezzel, hogy a comparator üzemmóddal be lehet állítani hogy meddig számláljon el a timer két megszakítás között. Nem szükséges a timer számlálóját manuálisan állítgatni.
Köszönöm, kezdem érteni (vagy csak azt hiszem...)
Sziasztok!
Elkészítettem a hozzászólásaitok alapján a progit, csak sajnos rossz eredményeket ad..Csatolom hátha valaki meglátja a hibám, mert most nekem még nem sikerült észrevennem mit rontottam el.. köszönöm!
Az ADRESH-t nem kéne összeadás előtt 256-al megszorozni(miután a felső 6 bitet kimaszkoltad 0-ra)?
Potyo tanácsolta, hogy használjam így, ha ugyanarra gondolunkBővebben: Link
|
Bejelentkezés
Hirdetés |