Fórum témák
» Több friss téma |
A DT direktíva egy-egy retlw utasítás paraméterének tárolja a karaktereket. Az utasítás kódja 18F -en 16 bites, ami lehetővé teszi utasításonként két karaktert tároljunk, így a szövegek fele annyi helyet foglalnának.
A DB direktíva egy-egy byte -ot fordít a program memóriába, utasításonként 2 darabot. Páratlan számú adatot kiegészíti egy 0x00 -val. Működik az alábbi forma is, ugyan úgy látható, mi lesz a kijelzőn: DB "Szerbusz pajti! "," Hogy vagy? " A kiolvasásra a tblrd utasítás használható.
A reléhez mindenképp tedd be a diódát nehogy visszacsókoljon
 Nézd meg, hogy a Buzzered hány voltos mert, ha 5v-al táplálod, és 12v-os, akkor nem fog szépen és hangosan sípolni. És lehetőleg a Buzzert ne a PIC-ről jövő szálról tápláld...és talán ellenállás sem kell vagy csak nagyon kicsi, ha 5v-os.. A gombnyomásokat nem kezeled, nem látok pergésmentesítést ez is lehet baj.. Az isr-ben azért is bennragadhat mert van benne végtelen ciklus.
Tehát azt mondod, ha DB-t használnék, nem kellene a tblrd-t kettesével léptetnem?
Ha db -t használsz, akkor tblrd utasítással lehet kiolvasni az adatot. A DT -t használsz, akkor egy a szubrutinban elhelyezett PCL regiszterbe való írással lehet hozzáférni az adatokhoz. Működik az a öszvér megoldás is, hogy DT -vel letett adatokat tblrd utasítással olvasunk ki, de ebben az esetben minden "felső" byte számunkra értéktelen lesz, így a TBLPTR regisztereket módosítani kell.
A hozzászólás módosítva: Márc 4, 2015
A reléhez milyen diódát érdemes tenni?
A buzzerem öt voltos, így valószínűleg nagyon sok neki az 1k, este miután írtam a bejegyzést, kicsit variáltam vele, úgy hangosabb lett, de szerintem ki fogom hagyni teljesen. Viszont az öt voltot hogy érted? Kösszem közvetlenül a feszstab 5V-os lábához, vagy elég, ha kicsit megvastagítom a közös táp vezetőszálat. A gombsormban van pergésmentesítő, csak beleraktam a kijelző vezérlést, met ha folyamatosan nyomom a gombot, akkor addig a kijelző meghajtás nem működik.
Igazából arra gondoltam még, hogy a PIC másik időzítőjét kellene használnom a kijelzőre, ami folyamatosan menne. Így sok kódsort spórolhatnék, valamint nem is kellene mindenhol kezelni a meghajtást. Csak ehhez megint nem nagyon értek még. Végtelen ciklusban mire gondolsz? Arra, amikor a perc és a mp is nulla lesz? Mert ott akkor kikapcsolom az időzítőt, akkor nem kellene az egész megszakítás folyamatnak megszakadnia?
A PCL regiszteres módszer nekem nem működött normálisan. Csak csekély adatmennyiséget tudtam vele letárolni, azt is csak a programmemória egy adott területén. Jelenleg így olvasom:
KIOLVASAS CLRF TBLPTRU MOVFF MI6,TBLPTRH MOVFF MI5,TBLPTRL TBLRD* MOVF TABLAT,W CALL KIIRAS RETURN Az adatokat pedig a program legvége mögött tárolom, a 0x2000 hexa cím fölött. Ha tudsz jobb módszert, szívesen kipróbálnám.
Még meg kellene tudnom, hogy hogyan tárolod a szöveget és hogyan módosítod a MI5 értékét.
Egy adott hosszúságú szöveg kiírása:
Egy 0x00 végű szöveg kiírása:
A hozzászólás módosítva: Márc 4, 2015
1N4007-es egyenirányítót használok én oda.
Az kb. 1-1.5A-et bír el. Az 1k-s ellenállás a Buzzerhez nagyon sok, tegyél oda egy 100Ohm-ost vagy 200 körülit, próbálgasd ki. (A Buzzer adatait is megnézheted, hogy mennyi áramerősség kell neki és úgy is beállíthatod az ellenállás értékét) Közvetlen vidd a stabilizátortól a vezetőt a buzerig, ne a PIC-en keresztül. A Buzzer meg húzhatja vagy bezavarhatja a PIC táplálását. Ráadásul 100nF-os kondikkal sem szűröd a PIC közvetlen lábát vagy táplábait, ez is egy hiba lehet. Bár most nem pontosan tudom mi miért is van, de szerintem ez rész nem szerencsés az isr-ben.
Ha STOP van akkor egyszerűbb lenne csak simán a STOP-ra reagálnia nem még a kivezérlésre is, amúgy az csak egy pillanat, szóval...
Persze lehet neked tök más miatt van ott, de a lényeg, hogy nem szerencsés..
Ha jól értem, akkor te a programba írod a szöveget, és rögtön ki is olvasod?
Akkor minden egyes szöveg megjelenítéséhez kell ez a 13 sor? Nekem van írva egy 55 soros olvasórutin, ami a programmemória hátsó részéből címzés alapján veszi ki a szöveget. Akár 255 előre letárolt 2x16 karakteres szöveget. Így néz ki:
A szöveget bpedig így tárolom:
Meghívása pedig ennyi: MOVLW D'4' MOVWF MI1 CALL SZOVEG
Néztem már a buzzer adatlapját, de már nem emlékszem. Majd az alapján kicserélem az ellenállást, a tápot meg átkötöm.
100nf-os kondit a Vdd és Vpp-hez is tegyek, vagy elég csak a Vdd-hez? A STOP-ot azért tettem az isr-be, hogy le tudjam állítani az időzítőt, majd folytatni. Ha kiveszem belőle, akkor sem működik megfelelően. Eredetileg a kijelzés nem volt benne a gombok kezelésében, de zavart, hogy bár csak max másodpercekig tart a gombnyomás, de nem szépen reagál a kijelző rá. Azért is írtam, hogy lehet megfelelőbb lenne egy másik timer-t beiktatni ami csak a kijelzőt kezelné.
Az miért jó, ha tudod? Mire mész 50 igen, 32 talán válasszal?
Tegyél fel egy jól megfogalmazott kérdést, majd kiderül, tudunk-e segíteni. A hozzászólás módosítva: Márc 4, 2015
Sok apró kérdés:
Miért nem használod a tblrd*+ változatot, ami automatikusan növeli a TBLPTR regisztereket (átvitelkezeléssel)? Mivel a DT leteszi a "felső" byte -okba a retlw utasításkódját, ezzel a megoldással kétszer kell növelni a mutató regisztereket átvitel kezeléssel. Egy második tblrd*+ egyszerűen megtenné, a kiolvasott adatot nem is kellene kivenni a TABLAT -ból. Ha egy sorral végzett, a mutató pontosan a következő sorra állna automatikusan, csak akkor kellene módosítani, ha nem a soron következőt kellene kiírni... A megoldásomban a kiíró rutinok szétbonthatók két részre: 1 - a TBLPTR regiszterek feltölése és a hossz megadása, ha kell 2 - maga a kiolvasó és kiíró rész. Az elsőből annyi kell, ahány különböző szöveget kell kiírni, a másikból csak egy példány kell. A hozzászólás módosítva: Márc 4, 2015
Azért találtam ki ezt a módszert, mert komplex vezérléseket is kell készítssek, és így a programomba nem zavar bele a kijelzőkezelő. Az csak ott van valahol a progi végén, és ha a program futása közben üzenetet kell küldjek a felhasználónak, egy 3 soros paranccsal megtehetem, és a program már megy is tovább, a kijelzőn meg ott a szöveg. Ráadásul, mivel teljesen különálló egységként van a program végén, így nem zavar bele a program értelmezésébe. Áttekinthetőbb az egész. Többek között ezért is programozok assemblerben, mert szekcionáltan futtatható a program, nem kotor végig, ha kell ha nem az összes kódon, ezáltal a futás sokkal gyorsabb és stabilabb. Gyakran programozok PLC-t. A létradiagramm kezelése még egyszerűbb mint a C nyelv, de egy hosszabb programnál már csúnyán be tud lassulni, ráadásul egy látszatra egyszerű és logikus módosítástól, van hogy egész más helyen borul el az agya, mint ahol módosítok. Viszont valamiben segíthetnél! Tudsz olyan módszert, amivel a programmemória egy előre kiválasztott területére a program futása közben adatokat lehet írni, későbbi kiolvasás céljából? Mert amiket én a netről összemazsoláztam, vagy túl bonyolultak, vagy nem működnek.
A 100nF-ot a VDD és GND közé kell tenni a PIC-hez lehető legközelebb.
Arra kell törekedni, hogy az isr-ben a lehető legkevesebb utasítás legyen. Mindent amit lehet kezeld inkább a main() szekcióba. Az isr elvileg másodpercenként 1000szer fog lefutni, vagy is ha minden pompásan működik, akkor 1 ezredmásodperce van a megszakításnak, hogy minden utasítást elvégezzen. Ez fontos, hogy ezen idő alatt ki is tudjon lépni a főprogramban.. Azt kell megnézned, hogy mi is történik valójában a programodban. Fut a main() szekciód folyamatosan és mikor megszakítás van 1000-ed másodpercenként vagy is 1ms-onként, akkor mindent felfüggeszt a PIC és elvégzi a megszakításban megadott utasításokat, majd ha végzet vissza tér a főprogramba oda ahol előtte félbehagyta a műveletét...és ezt ismételgeti ameddig le nem állítod. Közben elfelejtettem miért is írtam ezt Mit csinál egyébként, videót készítettél róla? A hozzászólás módosítva: Márc 4, 2015
Elmegyek enni, rakok bele diódát meg kondit és csinálok videót.
Annyit csinál amúgy, hogy fut a végtelen ciklus, és amikor elindítom a megszakítást, a próbaképp beállított 17 perc 32 másodperc kb egy perc nullára ér, majd bennragad a korábban említett buzzer csipogtató if ágban.
Megépítettem a Kapcsolást, beégettem a pic-be az ott található hex file-t.
És mivel nem vagyok jártas a hálózatokban, a kérdésem az lenne hogy milyen beállítások szükségesek az android oldalon, és a router oldalon hogy műkődjön a a 3g-s vezérlés. Köszönöm!
Az általam javasolt megoldás szövegei, a szöveg paramétereinek beállítása(i) és a kiíró rész egymástől függetlenül bárhol lehetnek elszórva a programmemóriában (ha 64k -nál nagyobb a programtár, a TBLPTRU is kezelendő).
Hogyne működne, de több dolgot be kell tartani: - Ne legyen program végrehajtás az írni / törölni szánt területen, még a megszakítási rutinból sem. - Egy teljes tarományt lehet törölni és írás előtt törölni is kell. Ha csak módosítani szeretnénk egy-két adatot, akkor a tarományt ki kell olvasni RAM -ra, ott módosítani, a tartományt törölni kell és vissza kell írni a módosított adatokat. Az üres tartalomra törlés nélkül is lehet írni. (Álatalában egy 1 bitet lehet 0 -ba írni, de 0 bitet csak törléssel lehet 1 étrékűre állítani.) - A programozási utasításban megadott számú byte - ot / utasítást lehet egyszerre beírni. Konkréten a 18F14K22 esetén 64 byte -os tarományok törölhetők, 16 byte = 8 utasítás írható egyszerre. Az assembly nyelvű mintapélda az adatlapban megtalálható.
Kicsit módosítottam a kódon..
Próbáld meg így, hátha  A hozzászólás módosítva: Márc 4, 2015
Kösz a választ, de sajna az én esetemben ez a megoldás nem járható. Túl lassú és macerás.
Akkor már inkább EEPROM-ba tárolok, az jóval egyszerűbb, csak annak meg a felülírhatósága véges. Vagy kell csináljak egy olyan tápot, ami külön látja el a PIC-et egy komoly pufferrel, és el kell használjak egy lábat tápfigyelésre, hogy adatokat tudjak menteni, és alapban a ramban kell dolgozzak. Az meg ugye osztott, így kevés áll rendelkezésre, ráadásul az indirekt címzésnek is vannak komoly gyerekbetegségei. Ugyanúgy, mint a PCL-nek. Igazából nem is értem a fejlesztőket, hogy a programmemória írása miért van ilyen kegyetlenül elbonyolítva. Ha egyszerűen írható lenne, nem is kellene bele EEPROM. Főleg azért, mert ha módosítok a programon, az EEPROM-ból ugyanúgy eltünnek a bevitt adatok, mint a programmemóriából. Ehez képest viccesnek találom, hogy ha a táp nem szűnik meg a PIC-en a programmodosítás során, akkor a RAM-ban lévő adatok megmaradnak.
Az általad javasolt módosításokkal annyi változást történt, hogy kicsit lassabb fut le az interupt. De még mindig sokkal gyorsabban, mint a valós idő sebessége.
Itt elérhető egy videó a kijelzőről működés közben: http://spgabor.uw.hu/VIDEO0007.mp4 A picre töltött kód az általad javasolt módosításokat tartalmazza. A videón 5 percre beállított időzítés történik. Akkor indul el az időzítés, amikor a kijelzés meghajtás leáll, ez látszik is, hogy az utoljára kiírt két karakter marad csak a kijelzőn. Majd amikor nullázódik a perc és másodperc, akkor visszatért a while(1) ciklusba a folyamat és csupa nulla lesz a kijelzőn.
Azt próbáld már ki, hogy mondjuk a másodpercenkét ki és be kapcsolod a relét vagy ha van különálló LED akkor azt.
A kijelző meghajtás és egyéb addig legyen kikommentelve.. Ezt azért, hogy kizárd az esetleges rossz beállításokat vagy hibás beültetést.. Csak az isr működjön.. Ez próbáld ki több féle idővel és közben mérjed is egy órán vagy valamivel... Amúgy a videón nem sokat látni, árnyékban kellett volna a kijelzőt tartani mert alig látható mit ír ki.. A hozzászólás módosítva: Márc 4, 2015
Idézet: „Akkor már inkább EEPROM-ba tárolok, az jóval egyszerűbb, csak annak meg a felülírhatósága véges.” De mégis sokkal több, mint a program memóriáé... Idézet: „Az meg ugye osztott, így kevés áll rendelkezésre, ráadásul az indirekt címzésnek is vannak komoly gyerekbetegségei.” Ez inkább a 16F -ekre vonakkozik, a 18F -eken az egész RAM egyszerűen kezelhető indeirekten. Idézet: „Főleg azért, mert ha módosítok a programon, az EEPROM-ból ugyanúgy eltünnek a bevitt adatok, mint a programmemóriából.” Mind az MpLab -ban, mind a PICKit2 kezelőú programjában beállítható az EEPRom mamória tartalmának megőrzése. A hozzászólás módosítva: Márc 4, 2015
Én a neten azt olvastam, hogy az EEPROM ujraírhatósága kb 1000, a programmemóriájé viszont min 10000. Mindazonáltal hagyom magam meggyőzni, ha azt mondod hogy ez pont forditott.
Idézet: „Ez inkább a 16F -ekre vonakkozik, a 18F -eken az egész RAM egyszerűen kezelhető indeirekten.” Az adatlap szerint a ramból mindössze 96 byte-ot használhatok szabadon. Ez van a memoria lap elején. A másik 160 byte a funkcióregisztereknek van fentartva. Indirekt címzéssel még sosem tudtam a felső ramsort elérni.
Relével próbáltam és most tényleg valami nem jó.
A relé nem másodpercenként vált, hanem darál nagyon gyorsan. Viszont így, meg a relé egyszer sem húz be:
A hozzászólás módosítva: Márc 4, 2015
Az EEPROM tartalmat beállítottad?
A hozzászólás módosítva: Márc 4, 2015
Hülyeséget írtam, a második esetben is rossz, folyamatosan kapcsolgatja a relé állását, csak véletlenül kinyomtam az időzítés futását.
Akkor valami a beállításoknál hibázik, vagy a bekötésnél..
Az első verziónak működnie kellene.. De ne felejtsd ki a timer flag-et törölni mert akkor nem lesz jó sosem.. Az isr végére ezt be kell tenned:
Valahogy így:
A hozzászólás módosítva: Márc 4, 2015
De ha nem törlöm, akkor ezzel folyamatosan másodpercenként kellene ki-be kapcsolnia a relének.
A megszakítás végén mindig törölni kell a flag-et..
Lehet ez meg is oldja a problémádat.. |
Bejelentkezés
Hirdetés |
