Fórum témák
» Több friss téma |
Hello!
Utánépítettem ill.teszteltem egy 16f84 -el megoldott soros porti (rs232) kommunikációt megvalósító áramkört,aminek a dokumentációját és az asm forráskódot itt találtam meg: PIC 16F84 <-> RS232 A forráskód is ott van az oldalon alul és a linkelt modulok forráskódja is. A problémám a következő: A kommunikáció a PIC és a PC (Hyperterm) megbízhatóan működik,viszont ha a főprogramban ebben a : "LOOP btfsc RSflag ; check RS232 data reception flag call RSservice ; if set, call RS232 echo & LCD display routine goto LOOP" ciklusban egy: "MOVFW RXD BCF W,0 MOVWF PORTB" inktatok be akkor nem történik SEMMI ?! Pedig a port irányok a TRISB szerint jól vannak konfigurálva. Igazából a PORTB-re szeretném a Terminálból beolvasott Bytot kiiratni ,mégpedig a LOOP ciklusban mert így folyamatossan "vezérelhetnék" vele valamit. Azt tudom ,hogy a RB0-ás láb megszakításként van használatban az RS232-es komm-ban azt nem is használnám.. Ha valaki ért a PIC programozáshoz és kicsit belenézne nekem a forráskódba hogy mi lehet a hiba ,nagyon megköszönném. Már gondoltam arra is ,hogy a BANK-ok eltérő memóriacímkezelésénél lehet hiba...  Idézet: „MOVFW RXD” Itt szerintem egy MOVF RXD,0 utasításnak lenne értelme. MOVFW egyébként sincs, csak MOVWF, de az pont ellenkező irányba mozgatja az adatot. Idézet: Jó lenne látni a te programodat, mert az eredetiben én nem látok semmiféle TRISB beállítást.„Pedig a port irányok a TRISB szerint jól vannak konfigurálva.” Idézet: [quote]Miért is a Loop ciklusban? Szerintem az RSservice rutint kellen az igényeidnek megfelelően átírni. A Loop ciklusban csak vár a program, hogy jöjjön egy karakter. A karakter értelmezése és valami vezérlési feladat végrehajtása ennek határára csak akkor esedékes, ha jött valami új információ. „Igazából a PORTB-re szeretném a Terminálból beolvasott Bytot kiiratni ,mégpedig a LOOP ciklusban” Idézet: „Itt szerintem egy MOVF RXD,0 utasításnak lenne értelme. MOVFW egyébként sincs, csak MOVWF, de az pont ellenkező irányba mozgatja az adatot.” Szigorú értelemben véve igazad van, de mivel én pl assembler fejlesztőt (MPLAB) használok és nem a csak a beépített utasításkészlettel dolgozom ,ezért használható a MOVFW is ami egy egyszerűsített utasítás az akkuba másolásra. Idézet: „Jó lenne látni a te programodat, mert az eredetiben én nem látok semmiféle TRISB beállítást.” Igazad van részben,mert nem a főprogramban van definiálva a B- port hanem ebben a RS kommunikációt szabályzó modulban => RS_096 Mégpedig itt: "#define RXport PORTB,0x00 ; Needs to be an interrupt supervised #define RXtris TRISB,0x00 ; port! When modify, set adequate ; flags in INTCON register." Idézet: „Miért is a Loop ciklusban? Szerintem az RSservice rutint kellen az igényeidnek megfelelően átírni. A Loop ciklusban csak vár a program, hogy jöjjön egy karakter. A karakter értelmezése és valami vezérlési feladat végrehajtása ennek határára csak akkor esedékes, ha jött valami új információ.” Azért mert pl én "folyamatos" fogyasztó kapcsolgatást szeretnék ,azaz pl .: egy lámpát be v kikapcsoljak egy SSR(szilárdtestrelé) segítségével vagy relével.Azaz nem kommunikáció lenne a célom és gondoltam erre szabadon futó LOOP ciklus a legmegfelelőbb ,mivel ilyenkor szinte "folyamatos" a jel ami a B-portra kiíródna .Időben a megszakítások lefutási ideje nagyon kicsi ,nem zavaró. Idézet: „használható a MOVFW is ami egy egyszerűsített utasítás az akkuba másolásra.” OK, akkor tied a pont! Idézet: „#define RXport PORTB,0x00 #define RXtris TRISB,0x00” Ez nem állít be semmit, ez csupán definiál. Az idézett állományban itt látok beállítást: Ezt kellene bővíteni, vagy ehhez hasonló utasításokkal kellene ouputra engedélyezni az általad matatni kívánt biteket is. S ez a megoldása felvetett problémádra. Idézet: „Azaz nem kommunikáció lenne a célom és gondoltam erre szabadon futó LOOP ciklus a legmegfelelőbb ,mivel ilyenkor szinte "folyamatos" a jel ami a B-portra kiíródna” Ennek akkor van értelme, ha a bejövő karakteren kívül van más bejövő információ is, ami a vezérlés alapjául szolgál. De akkor természetesen azt a bemenetet is figyelni kell valamilyen input utasítással...
Ha megnézed ezt itt, lehet hogy előbb boldogulsz, én kis gyakorlattal 5 perc alatt megírtam a PIC-re valót ezzel amit ott látsz...
egy oldallal hátrébb meg van egy jobb komm progi a "terminál"-nál RS232
HEllo dcsabi
Amint látom a megoldásod nem 16f84-re van ,egyébként nagyon korrekt és egyszerű,de mivel megoldottam a probléma lényegi részét sajnos a pontot nem te kapod, icserny-t illeti.  Icserny: A logikád nagyon sokat segített ,tényleg félreértettem a #define utasítást és kicsit félreértelmeztem ,hogy mit takar a 0x00( = 0d) se volt előttem tiszta ,szóval  a köv megoldásra jutottam: Az RS232 komm kezelő modulban definiáltam az összes port kivezetését külön külön majd inicializáltam így: Idézet: „#define RXport PORTB,0 ; Needs to be an interrupt supervised #define RXport1 PORTB,1 #define RXport2 PORTB,2 #define RXport3 PORTB,3 #define RXport4 PORTB,4 #define RXport5 PORTB,5 #define RXport6 PORTB,6 #define RXport7 PORTB,7 #define RXtris TRISB,0 ; port! When modify, set adequate #define RXtris1 TRISB,1 #define RXtris2 TRISB,2 #define RXtris3 TRISB,3 #define RXtris4 TRISB,4 #define RXtris5 TRISB,5 #define RXtris6 TRISB,6 #define RXtris7 TRISB,7” Valamint lejebb az inicializációnál pedig: Idézet: „RS232init macro BANK1 bcf TXtris ; set output bsf RXtris ; set input with weak pull-up bcf RXtris1 bcf RXtris2 bcf RXtris3 bcf RXtris4 bcf RXtris5 bcf RXtris6 bcf RXtris7 bcf OPTION_REG,INTEDG ; RS232 interrupt on falling edge BANK0 bsf TXport ; set default state: logical 1 bcf INTCON,INTF ; ensure interrupt flag is cleared bsf INTCON,INTE ; enable RB0/INT interrupt bsf INTCON,GIE ; enable global interrupt endm” A main programban pedig a LOOP ciklusban ezt a megoldást használtam: Idézet: „LOOP btfsc RSflag ; check RS232 data reception flag call RSservice ;MOVLW 1d ;PortB számláló értékadás ;MOVWF COUNT2 ;MOVLW 250d ;Ciklusváltozó értékadás ;MOVWF COUNT ;KIIR ;Ciklus kezdete ;BTFSC RXD,COUNT2 ;Értékvizsgálat a beolvasott byttól függően: ;BSF PORTB,COUNT2 ;1-et ir ki ;BCF PORTB,COUNT2 ;0-át ír ki ;INCF COUNT2 ;PORTB számláló növelése ;INCFSZ COUNT ;Ciklusváltozó növelése ,0-nál ciklus vége ;goto KIIR BTFSC RXD,1 BSF RXport1 BCF RXport1 BTFSC RXD,2 BSF RXport2 BCF RXport2 BTFSC RXD,3 BSF RXport3 BCF RXport3 BTFSC RXD,4 BSF RXport4 BCF RXport4 BTFSC RXD,5 BSF RXport5 BCF RXport5 BTFSC RXD,6 BSF RXport6 BCF RXport6 BTFSC RXD,7 BSF RXport7 BCF RXport7 goto LOOP” Amint látható megpróbáltam egy ciklussal is kivitelezni ,hogy így talán praktikusabb és gyorsabb lessz a kivezérlés ,de sajnos a közvetlen PORTB-re való írás valamiért nem működik,csak ha a definiált változót használom Persze a COUNT és COUNT2 változókat definiáltam.De ennek ellenére ezzel a "fapados" megoldással tökéletessen működik,1 dolgot kivéve. Mégpedig ,hogy a kimeneteken mérhető feszültség 0,2V ,a tápfesz 5,12V jához képest! Ha jó a sejtésem akkor egyfajta PWM vezérlés valósul meg a kimenet vezérlésénél ha minden igaz,mégpedig a rövid "ciklusidő" miatt ami a kiíratásra esik. És ez azért baj mivel így egy szilárdtestrelét meghajtani már nem tudok, mivel annak legalább 3V tápfesz kéne. Persze tudom ,hogy egy egyszerű tranyós megoldással tápszintre erősíthetem a jelet ,de ha nem muszály akkor szoftveressen oldanám meg. Vmi 5let? :no: Idézet: „Vmi 5let?” Van egy rossz hírem: helyetted nem fogjuk tudni kitalálni, hogy valójában mit is akarsz csinálni! Most azért mérsz alacsony feszültséget, mert effektív értéket mérsz, s mivel a bit bebillentése után szinte azonnal törlöd is, igen kicsi a kitöltés.... Impulzusgenerátornak elmegy (most pont ilyen feladatra készülök egy gyorsabb MCU-val), de mi értelme? A vezérlést én úgy továbbra is csak úgy tudom elképzelni, hogy a bejövő adat függvényében kapcsolnád ki vagy be a biteket (a sokat emlegetett RSservive rutinban). Pl. "A" vételekor PORTB.1 bekapcsol, "a" vételelkor kikapcsol. "B" karakter vételekor PORTB.2 bekapcsol, "b" karakter vételekor kikapcsol, ésatöbbi... A HPC Explorer kártya demójában van ehhez hasonló példa: a számítógép billentyűzetén az 1,2,3,..8 gombok lenyomására a megfelelő LED állapotát átbillenti.
Először is a sok define, meg bcf-bsf helyett én inkább ezt használnám:
Idézet: „ #define RXtris TRISB #define RXport PORTB . . . clrf RXtris bsf RXtris,0 ” A végét meg nem tudom mennyire gondoltad át: Idézet: „ BTFSC RXD,1 BSF RXport1 BCF RXport1 ” Ha (RXD,1) == 0, akkor Idézet: „ NOP BCF RXport1 ” fog lefutni, aminek a végén RXport1 = 0, ha (RXD,1) == 1, akkor Idézet: „ BSF RXport1 BCF RXport1 ” fog lefutni, aminek a végén RXport1 ismét 0! (kaptál egy kb. 1 ms-os impulzust) Idézet: „kaptál egy kb. 1 ms-os impulzust” Ne túlozzunk! :awink: Csak 1 mikroszekundumos impulzust! (4 MHz-es órajelet feltételezve)
Hello!
Az impulzusüzemet illetően igazad van ,de már megoldottam szdavid 5lete alapján,viszon ezt a "bitátbillentést" még mindig nem értem ,ha jól tudom csak annyi ideig íródik ki az adott port lábára az impulzus amíg az utasítás végrehajtódik.Vagy talán tévedek?!
Tudod nem a pontért , hanem inkább azért... ne vesszünk el a részletekben... ami 3 perc alatt megoldható azt, kár 3 napig "dédelgetni"...
amit én ajánlottam az egy jól bevált dolog és azonnal müködik... Sokat kinlódtam én is amig "megszólalt az első PIC-em... Most ez többnyire úgy megy , hogy az áramkört megcsinálom beépítem a helyére, és a progi az annyira tizedrangú, hogy sokszor a helyszínen (laptop+égető+panelra rádug...) rögtönzöm 10-15 perc alatt...Mert tudom, hogy elsőre müködni fog...
Hello!
Köszönöm ,hogy figyelmeztettél a baklövésemre ,mivel tényleg azonnal töröltem a kiírt bitet ,helyette így oldottam meg a dolgot:"BTFSC RXD,1 goto AL_1_1 BSF RXport1 goto AL_1_2 AL_1_1: BCF RXport1 AL_1_2:" Ez nagyon jól szinte teljes fesszel üzemel azaz szinte teljes a kitöltés.Viszont mivel ciklusba nem tudtam rakni a dolgot ,7x hajtódik végre.. és kicsit lassú a reakció idő,a küldött karakter és a kiiratás között.Bár elvileg a ciklussal sem lenne kevesebb mivel a CPU időből ugyanannyit v többet vesz el ,hiszen 7x fut le a ciklus is...  A ciklusos megoldásom ez lett volna: " MOVLW 1d ;PortB számláló értékadás MOVWF COUNT2 MOVLW 250d ;Ciklusváltozó értékadás MOVWF COUNT KIIR ;Ciklus kezdete BTFSC RXD,COUNT2 ;Értékvizsgálat a beolvasott byttól függően GOTO AL1 BSF PORTB,COUNT2 ;1-et ir ki GOTO AL2 AL1: BCF PORTB,COUNT2 ;0-át ír ki AL2: INCF COUNT2 ;PORTB számláló növelése INCFSZ COUNT ;Ciklusváltozó növelése ,0-nál ciklus vége goto KIIR " A port inicializását is a te megoldásoddal oldottam meg ,de az volt a kisebbik gond ,de kösz h figyelmeztettél a felesleges deklarációkra. Utólag is bocsánat ,hogy ilyen szétszórt vagyok ,próbálok jobban odafigyelni arra ,hogy mit is hajt végre a program...
Hello!
Igazad van a fejlettebb mikrovezérlők sokkal több mindent tudnak A/D D/A átalakítók PWM,USART stb stb... ,de mivel én még "kezdő" vagyok és nem sokat foglalkoztam PIC-el így gondoltam a legismertebb 16f84-el kezdem a tanulást.De igazad van a köv PIC már egy fejletebb típus lesz.Mivel én sem szeretem túlbonyolítani a dolgokat  És az idő is nagon fontos tényező. 
Én igazából azt a segédprogit akartam a figyelmedbe ajánlani, amivel ezt gyorsan meg lehet csinálni,... és még sok mindent szinte percek alatt...Erról van szó a grafikus PIC programozás nevü topic-ban...
A 16f84 helyett teljesen jó a 16f628, árban fele és sokkal többet tud... A programírás meg rohamlépkekben megy az előbb említett dologgal...
Hello!
Még nem próbáltam ezt a grafikus PIC fejlesztést,de mindenképpen megnézem.Egyébként ha már a témánál tartunk szertinted milyen nagytudású és nem túl drága PIC-el tudnám fejleszteni a tudásom(gondolok itt belső perifériákra pl .:többfajta PWM áramkörökre ,USART ,A/D,stb..)? Ja és Pl mondjuk 3 Porttal minimum.
Hello!
A LOOP ciklusból áttettem az RS_Service rutinba a port bitjeinek állítását és tényleg billenti.... Szóval megoldódott minden problémám,igazad volt  Eredetileg ns-t írtam, aztán hirtelen eszembe ötlött, hogy 4MHz, az már mikrosec, de az, hogy a "u (mivel mű-t elég nehéz írni) = mikro", "m = mili" már kimaradt.
A " nagytudású" az relativ... de a 16F876(A) az bőven begfelelne erre a célra... Az emlegetett topicban feltettem egy nyák tervet is ez fejlesztésre is alkalmas. LCD-t is tudsz hozzá tenni van 14 bemenet 8 kimenet amit tudsz módosítani, uart...analóg meg egy 10k-s potméter...
ez jó a "grafikushoz fejlesztéshez"... A gf... fejl.. azért is jó mert mellette készül a forrásfile, és tanulni lehet belőle, ezek előre kidolgozott szubrutinok, amiket a progi összeilleszt az alkalmazás igényei szerint, természetesen egy halom paraméterezési lehetőséggel... Az uart-nál maradva, ez ott egy kész keret,... a használni kivánt byte-okat csak "be-link-eled" és kész...Ha hardware-sen rákészülsz, az összes lehetőséget ami a PIC-ban van egy délután kipróbálhatod vele,... Aki nem próbálta nem hiszi el, hogy így is lehet... Idézet: „ha jól tudom csak annyi ideig íródik ki az adott port lábára az impulzus amíg az utasítás végrehajtódik.” Nem, ha egyszer bebillentettél egy bitet, akkor az addig ott marad, amíg át nem írod (vagy le nem tiltod a kimenetet). Tehát minden kimenő porthoz/bithez tartozik a mikrokontrolleren belül egy tároló is (data latch). Idézet: „szertinted milyen nagytudású és nem túl drága PIC-el tudnám fejleszteni a tudásom(gondolok itt belső perifériákra pl .:többfajta PWM áramkörökre ,USART ,A/D,stb..)?” Szerintem meggondolandó a 18F sorozatra való áttérés. De mindenképpen olyat válassz: - amelyikre van C fordítód is (mint pl. a C18 student verzió) - Pickit2 segítségével pedig _hardveresen_ is debugolható. (a 16F sorozat "butább" példányai még nem támogatják a hardveres debugolást, s némely esetben az erőforrásik (RAM/ROM) sem elégségesek - a debugolás ugyanis lefoglal belőle - s akkor megtörténhet, hogy kevés marad az alkalmazásnak...). Ha USB kommunikáció felé is kacsingatsz, akkor pl. 18F4550 vagy valami hasonló. Ha pedig a sebesség is számít, akkor érdemes megpróbálkozni a dsPIC33FJ család valamelyik tagjával. Van közöttük kellemesen kezelhető 28 lábú változat is... A Pickit2 mellesleg kommunikációra is használható (ez akkor érdekes, ha nincs a számítógépen soros port, mint a mai notebookok legtöbbikénél...). Nem utolsósorban a Picki2 3 csatornás logikai analizátorként is használható (tehát oszcilloszkópszerűen mutatja, hogy mi jön ki
Hello!
Kipróbáltam az általad említett grafikus fejlesztő programot (ha jól tévedek Parsic a neve). Még nem teljessen értem ,hogy melyik elem milyen szubrutinhoz tartozik ,ill a megszakítások kezelése sem tiszta,de a szimuláció része nagyon tetszik.És a bit/byte folyam kezelése is egyszerűnek mutatkozik.A ciklusok és logikai műveletek ,időzítők stb nagyon tetszenek!
Hello!
Akkor én abban a szerencsés helyzetben vagyok ,hogy futásidőben is tudok/nék debuggolni mivel PICKit 2 programozó készülékem van (USB-s),de még bőven nem használtam másra ,csak égetésre... Majd kipróbálom előbb utóbb az általad emített funkciókat. Az USB komm. szerintem nyomós ok ,amit kérdeznék ,hogy ,ha pl az általad említett 18F4550 beépített USB inteface-t tartalmaz ,akkor nekem kell bele megírnom a "drivert" hogy felismerje pl az XP mint célhardvert? Meg hát igen a soros port elavult/sokrszor nincs már az újabb gépekben és lassú.De pl egy soros-USB átalakító meg nem az igazi... A RAM/ROM viszonyokról meg annyit ,hogy a mai technikai fejletségi szint melett a 16f84-es szériának fillérekbe kéne kerülnie mivel már egy közepes mobilban is elég nagy teljesítményű procik vannak és ram ,bár igaz itt mikrokontrollerekről van szó.
Feltételezem, egy pic-et valamilyen feladat végrehajtására , ....vagy összetettebb dologra akarod felprogramozni.
Ezek az elemek amiket ott látsz azoknak a variációjával tudod megoldani az adott feladatot. Ezeket az elemeket kötözöd bit/byte szinten és "felparaméterezed"... PL: uart kommunikáció esetén beállítod a portsebességet, nyugtázás (igen-nem) és a kommunikációban résztvevő byte-okat. A többi elemnél is több ilyen lehetőség van... Ez egy kicsit másabb gondolkodást kér elsőre, de utána rohamléptekkel lehet haladni... Debbuggolásra én még sosem gondoltam, ha a szimulátorban müködött és az MPlab lefordította akkor biztosan müködött... Olyan fordult elő a kezdetekben, hogy nem teljesen azt csinálta a progi amit szerettem volna , de én hibáztam... A asm rutinokat is bele lehet illeszteni , (az elemek közé, van hozzá modul) akár többet is, erre is van példa... sőt az adott topicba is tettem fel egyet, I2C-s óra/kalendár olvasása írása... Ha van kérdésed, akkor inkább abban a topicban... Idézet: „futásidőben is tudok/nék debuggolni mivel PICKit 2 programozó készülékem van” Csak a PIC16F84 nem alkalmas hozzá... De a logikai analizátor funkciót kipróblhatod,az processzorfüggetlenül használható. Idézet: „az általad említett 18F4550 beépített USB inteface-t tartalmaz ,akkor nekem kell bele megírnom a "drivert" hogy felismerje pl az XP mint célhardvert?” 1. Igen, neked kell feltölteni az MCU-t USB kezelésre alkalmas firmware-rel, s ha nem valami "szabványos" (pl. HID) protokolt használsz, akkor a PC-n futó operációs rendszer(nek látszó tárgy)-val/vel is össze kell barátkoztatni. Vannak mintaprogramok a Microchip honlapján (FSUSB demo), azokkal el lehet kezdeni. Idézet: „a soros port elavult/sokrszor nincs már az újabb gépekben és lassú” Főleg nincs. Elvileg USB-RS232 átalakító kábelt is lehet venni, az is egy lehetséges megoldás. Sőt, a saját áramköröd mellé is rakhatsz ilyen átalakítót. Ez sem elvetendő megoldás. Idézet: „A RAM/ROM viszonyokról meg annyit ,hogy a mai technikai fejletségi szint melett a 16f84-es szériának fillérekbe kéne kerülnie” Szerintem a gyártási költségek egy tetemes része független a RAM/ROM mennyiségétől. S a régi technológiával gyártott IC önköltsége nem lesz kisebb amiatt, hogy ma már új technológia is van. Az új tecnológia előnyeit akkor tudod élvezni, ha újabb fejlesztésű PIC-et veszel. Például a 16F sorozatból is jobban jársz, ha a 16F887-et vagy a 16F726-ot veszed a 16F84A helyett... |
Bejelentkezés
Hirdetés |
