Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
6000. Ft szeptember 30-ig a pickit2 starter kit a chipcadben!
A rendes ara 11.000 Ft korul van.
Sziasztok! Ránéznétek a progimra? A lényeg, hogy figyelem a PORTB 1. bitjét és amíg nyugalomban van, addig zöld LED megy (green sub), és ha aktív lesz a bemenet, akkor piros LED megy. Az a bajom vele, hogy mikor a pirosnak kellene menni, vagyis aktív a bemenet, akkor megy a piros, aztán a zöld és így felváltva, amíg meg nem szűnik a jel a bementen. Tehát, ha meghívódik a Red rész, akkor lefut a Green rész is. Miért van ez? A btfss okozza ezt, valamilyen státusz bitet vissza kell állítani? Köszi!
* * * ujra: btfss PORTB, 1 call Red goto ujra Red movlw b'0100' movwf PORTB call Delay250 Green movlw b'1000' movwf PORTB call Delay250 * * *
...a delay rutin vége: retlw 0x00
Idáig működött a dolog, de mióta beraktam a btfss parancsot, azóta van ez...
A REd végére is kell visszatérés (return)
... call Delay250 return
na igen, de így meg pirosban marad végig...
vasalós vagy világítós technikával gyártott a nyák?, szép.. én bevásároltam recés felületű nyákból, hiába csiszolom, sz*r!
MEGINT ELŐBB ÍRTAM, MINT RENDESEN VÉGIG GONDOLTAM VOLNA
UJRA BTFSS PORTB,1 GOTO RED GOTO GREEN RED ... CALL DELAY250 GOTO UJRA GREEN ... CALL DELAY250 GOTO UJRA
Köszi, így működik. De tulajdonképpen miért nem volt jó a CALL paranccsal? Egymás után meghívott szubrutinokból, már nem talál vissza? Valaki elmesélhetné, mert engem érdekel.
Csak a második (delay) szubrutinból tértél vissza (arra a pontra ahonnan meghívtad). És így végrehajtotta a zöld LED bekapcsolását is
Idézet: „Egymás után meghívott szubrutinokból, már nem talál vissza?” Csak ha megtelik a stack (verem). Több egymásba ágyazott hívásnál figyelni kell, főleg, ha interrupt is van.
De visszatalál mindenhonnan, ha van a megfelelő helyen return vagy retlw. Az nem nevezhető szubrutinnak, amit call-lal meghívsz, aztán nincs sehol "vége" valamilyen visszatérő utasítással.
Ha a "red" és a "green" szubrutin akar lenni, akkor mindkettő végére kell egy return (vagy retlw) - magyarul a "call delay" sorok után. Egy kicsit ha továbbgondolod a proci működését, akkor rájöhetsz, hogy a "call delay/return" utasítás helyett ha egy "goto delay"-t írsz, az ugyanúgy fog működni (csak eggyel kevesebb mélységig használja a stacket), mert ilyenkor a "delay" rutin végén lévő return (retlw) lesz az, amelyik a meghívott "red" vagy "green" szubrutin visszatérő utasításává válik. Elsőre lehet, hogy kicsit bonyolultnak tűnik, de ha csak egyszer végigjátszod papíron, hogy mik történnek, szerintem rögtön világos lesz.
Sziasztok!
Nagyon nagy kérdésem lenne: Valaki nem tudna mondani egy helyet vagy küldeni vagy nincs-e meg valakinek letöltve a PICBASIC™ Compiler progi???? A hivatalos hely ahonnan le lehetne tölteni pénzért kínálja és hát nem valami olcsón. Ha tudtok kérlek segítsetek, plíz!! 
CALL -lal is megcsinalhatod kis modositassal:
Az elonye a GOTO-ssal szemben, hogy a fuggvenyeid barhonnan hivhatok, ugyanoda ter vissza. Raadasul ha a "fo program" valtozik attol meg a rutinok valtozatlanok maradhatnak - mag akkor is ha az UJRA cimke valtozik vagy ha mashova szeretnel vissza ugrani... A hatranya, ahogy mar elhangzott a stack hasznalat, a PIC-eknel eleg limitalt a stack melysege, meg kell nezni az adatlapon mennyi es ezt is figyelembe kell venni mikor a firmware-ed tervezed. Ja es meg egy hatrany: egy hajszalnyival hosszabba program es egy szempillantasnyit tovabb is tart amig lefut... (2 ciklusnyit)
Elnézést a késői válaszért, most jutott időm erre.
Igen, tudom, hogy a PIC az PIC, és nem microsoft  De a honlapra van kiírva, hogy nem fogja frissíteni, és nem fog új cikkeket írni. Igazából össze lehet ollózgatni innen is, onnan is cikkeket, amivel már lehet tanulni. Szóval nem is szükséges annyira, csak egy mondatot megért a felhívás.Az elméleti résszel kezdtem én is, de azért célirányosan: gyakorlati alkalmazási lehetőségek felé mozdítom az elméleti anyagot. Egyelőre nem sok eredménnyel, mint mondtam, nincs sok időm sajnos. Jelenleg. Kellemes éjszakát mindenkinek!
Nahat, hogy milyen faradt vagyok mar!
Aaa, csak lefekves elott beneztem irt-e valaki valamit, erre egybol kiszurtam a hibat - sajat magam QA-ztam
"Egy kicsit ha továbbgondolod a proci működését, akkor rájöhetsz, hogy a "call delay/return" utasítás helyett ha egy "goto delay"-t írsz, az ugyanúgy fog működni (csak eggyel kevesebb mélységig használja a stacket), mert ilyenkor a "delay" rutin végén lévő return (retlw) lesz az, amelyik a meghívott "red" vagy "green" szubrutin visszatérő utasításává válik."
Ezt hogy értetted?!http://www.hobbielektronika.hu/forum/wtopic.php?post_id=281431&act=...pop=1# http://www.hobbielektronika.hu/forum/wtopic.php?post_id=281431&act=...pop=1# Ha GOTO-val küldöd el, akkor nem menti el a viszatérési címet, így amikor találkozik valamilyen RET utasítással, akkor nincs honnan JÓ címet elővenni --> nem megfelelő helyre fog visszaugrani!!!http://www.hobbielektronika.hu/forum/wtopic.php?post_id=281431&act=...pop=1# http://www.hobbielektronika.hu/forum/wtopic.php?post_id=281431&act=...pop=1# Ezzel szerintem megzavartad a kérdezőt.... Steve  
Na ez így akart menni...
 "Egy kicsit ha továbbgondolod a proci működését, akkor rájöhetsz, hogy a "call delay/return" utasítás helyett ha egy "goto delay"-t írsz, az ugyanúgy fog működni (csak eggyel kevesebb mélységig használja a stacket), mert ilyenkor a "delay" rutin végén lévő return (retlw) lesz az, amelyik a meghívott "red" vagy "green" szubrutin visszatérő utasításává válik." Ezt hogy értetted?  Ha GOTO-val küldöd el, akkor nem menti el a viszatérési címet, így amikor találkozik valamilyen RET utasítással, akkor nincs honnan JÓ címet elővenni --> nem megfelelő helyre fog visszaugrani!!! Ezzel szerintem megzavartad a kérdezőt.... Steve
Szia !
Szerintem így értette : ... CALL GREEN ... ... GREEN ... GOTO DELAY ... ... DELAY ... RETURN Így oda fog visszatérni ahonnan a 'GREEN' szubrutint meghívta . És a kérdező ezt szerette volna, de javítsatok ki ha tévedek.
Igen, így értettem.
Arról volt szó, hogy a "red" és a "green" azok szubrutinok, amiket call-lal hívunk meg. Egy ilyen szubrutin végén lévő call/return utasításpárt lehet lecserélni egy goto-ra. Ilyenkor a rutin végén call-lal meghívandó másik rutin végén lévő return lesz az, ami a főprogramba visszatér. Ezáltal megspórolunk egy veremhelyet, ráadásul egy programmemósia-helyet és futásidőben egy utasításvégrehajtást is.
Jó politikus lennél, mert amúgy az az egy mondat, a környezetéből kiragadva, csak úgy általánosságban tényleg nem mond igazat. De ha hozzáolvasod az eredeti helyén az előtte lévőt is, összefüggéseiben, akkor azért már van értelme.
Persze, akinek ez nem világos, hogy miért is jó, az nyugodtam használja a szabályos módon a call-t, és utána a return-t. Aki foglalkozik rendszeresen programozással, előbb-utóbb rájön ezekre az egyszerűsítésekre maga is. Alapvetően én nem szeretem használni, mert kissé nehezebben átlátható lesz a program, de a (midrange) PIC-ek stackjének elég szűkös mérete miatt szoktam alkalmazni.
Viszont ha jobban belegondoltok, akkor ez nem más, mint 1 szubrutin, amiben van két belépési pont és egy kilépési a delay után.
 Az más kérdés, hogy hogyan szervezem ezt az editorban. Aki ad egy kicsit a formára, az struktúráltan adja elő a külcsínyt. Egyébként ez a megoldás a jobb, mert valóban felesleges szubrutinokat egymásból hívogatni(szanaszét szabdalni egy nagyobb egységben is elképzelhetőt). Persze ez is, mint annyi minden a feladattól függ. Ha van elég verem és van elég idő, akkor lehet egymásba ágyazni is minden gond nélkül. A lényeg, hogy tudjuk mit miért teszünk. (természetesen ezen utóbbi eszmeömlésem a kérdezőnek szól, nem neked...) szerk: közben egyszerre írtunk. 
Meg annyit ehhez az egeszhez - es akkor flame on
- hogy ezek azok a dolgok amiket egy jo HLL compiler automatan elintez es a programozonak nem is kell oda figyelnie - sot sok esetben nem is tud mindarrol ami tortenik, a kod csinalja azt amit o elvar tole. Ha kozben valtozik a forras es nem lehet a rutinokat egybe agyazni akkor a legkozelebbi forditasnal mar ertelem szeruen nem csinalja meg a compiler. Ehhez kepest egy asm-ben manualisan kell ilyenekre figyelni - ami tegyuk hozza egy gyakorlott asm kodolonak nem okoz problemat
Hát, a szenzorok valószínűleg 10-20 m-es kábel végén csücsülnének. Akkor inkább vonalmeghajtóval próbálkozok, de a MAX232 sem hiszem, hogy átvinne 20 m-nyi vezetéket...
A diódát pedig inkább elfelejtem... A másik kérdésem, hogy milyen PIC lenne alkalmas a célra? Kritérium, hogy könnyen lehessen 16*2-es LCD-t illeszteni hozzá, legyen elég portja a nyomógombokhoz, szenzorokhoz (legalább 3 gomb és 4 vagy 5 szenzor), RS232 kommunikációhoz számítógép felé, és emellett egy 16kB-os EPROM-ot is kellene kezelnie. Első közelítésben egy 16F877-re gondoltam.
Hol is kezdjem...
Kell egy USART az RS485 vonalhoz. Ha ez megvan, akkor erre fel tudsz fűzni szinte bármennyi(~250) slave egységet. Kell még egy USART, ha a PC-vel is kapcsolatot akarsz, vagy egyből egy USB-s PIC(pl. 18F4550) is befigyelhet, és akkor a PC felé a legjobb kapcsolatod lesz. Vannak olyan PIC-ek is, amiben két USART van, de ezek legtöbb esetben SMD-k és 80 lábúak. Lehet esetleg kapcsolgatni az egy usartot ide oda, de az nagyon macerás, és nem túl egyszerű lekezelni. A Slavekre(távadó egységekre) kell egy olyan PIC, ami olcsó, és van USART-ja. Én a 16F627A-t szeretem ilyenre használni, de biztosan vannak már kevesebb lábbal olcsóbban is USART-os PIC-ek, csak nem nagyon keresgéltem mostanában ilyen után(chipcad). RS485 csatolónak jól bevált az SN75176. (Slavenként egy + a központ) Szenzornak én az SPI-s protos példányokat ajánlom, mert programból nagyon könnyű kezelni akkor is, ha nincs a PIC-ben SPI port.
A nagyobb távolságokkal kapcsolatban, szerintem inkább az RS485, vagy áramgenerátoros meghajtások körében kellene szétnézni. RS485-öt külön javaslom, még összegányolt panellal, saját sodrású vezetékekkel is tökéletesen stabilan futott 800 kW-os motorok és frekiváltóik mellett (SP485-ös illesztőt használtam, de sokféle van).
A PIC-hez, ha jól számoltam: 11 láb az LCD-nek (ha az EN is vezérelt), gombok / (digitális?) szenzorok 8, RS232 2 láb, EEPROM meg mondjuk 3-4. Ez összesen 24, a 877-nek van 32, szóval fizikailag beleférne még egy RS485 meghajtása is; van belőle 20 MHz-es kivitel, az is elég szokott lenni. Viszont szerintem kicsit drága a képességeihez mérten, én is csak azért építgetek ilyenből (meg 876-ból), mert van belőlük jópár maradék. |
Bejelentkezés
Hirdetés |
