Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Ha komolyan gondolod az RTS/CTS használatát, akkor vagy felejtsd el az MCP2200-at (Bővebben: Link), vagy kísérletezz vele, és próbáld megérteni a Microchip sajátos logikáját!
Bár az RTS ősidők óta azt jelenti, hogy Request to Send, az MCP2200 adatlapja szerint az "I am ready to receive" értelemben használja. Bővebben: Link (lásd: 1.3.4 pont)
Nyilvan Microchippek a "modern" RTS/CTS-t implementaltak:
Idézet: „A non-standard symmetric alternative, commonly called "RTS/CTS handshaking," was developed by various equipment manufacturers. In this scheme, CTS is no longer a response to RTS; instead, CTS indicates permission from the DCE for the DTE to send data to the DCE, and RTS indicates permission from the DTE for the DCE to send data to the DTE. RTS and CTS are controlled by the DTE and DCE respectively, each independent of the other. This was eventually codified in version RS-232-E (actually TIA-232-E by that time) by defining a new signal, "RTR (Ready to Receive)," which is CCITT V.24 circuit 133. TIA-232-E and the corresponding international standards were updated to show that circuit 133, when implemented, shares the same pin as RTS (Request to Send), and that when 133 is in use, RTS is assumed by the DCE to be ON at all times.[10]” Bővebben: Link A gond inkabb az lehet, hogy ez az egesz a firmware-ben van implementalva es igy a PC oldalon nincs lehetoseg a kommunikacioba torteno beleszolasba. Ki kellene probalni, hogy a bufferek mit engednek meg ill mi van ha a PIC tartosan nem akar adatokat fogadni...
Köszönöm a linket, hasznos információ!
Idézet: Nem olyan nagy baj, „A gond inkabb az lehet, hogy ez az egesz a firmware-ben van implementalva es igy a PC oldalon nincs lehetoseg a kommunikacioba torteno beleszolasba.”  mert a Windows usbser.sys meghajtója úgysem kezeli rendesen az RTS jelet. Biztosan nem véletlen, hogy minden valamire való USB-soros protokol konverter saját meghajtót használ (CP2102, PL2303, FT232RL).
Sajnos az angol szöveget csak részben értem. Nekem csak az kellene, hogy a PIC egy mondatot (max. 60 karakter) beolvasása után állítsa le az adatfolyamot, majd ha végrehajtotta (néhány perc is lehet), olvassa tovább.
Ezt az MCP2200-val lehet produkálni, ha jól értettem.!?
Ezt lehet, csak az a kérdés, hogy a PC-n futó alkalmazásnak ki mondja meg, hogy várjon?
Remélem, hogy ezt már az USB protokoll elintézi, vagy mégsem?
Szerintem nem. De mondtam, hogy kísérletezni kell...
Sziasztok!
A következő gondom akadt egy PIC24HJ64GP502 (Microstick) típusú kontrollerrel: A hardveres UART1 egységet használom a PIC és PC közötti kommunikációra (PICKit 2 UART Tool). Átlagosnak mondható beállításokkal (9600 baud, 8N1) konfigurálom a kontrollert, mely a belső 7,3728 MHz-es oszcillátoráról működik (PLL nincs, a CPU és perifériák is Fosc/2- vel működnek). A vételhez engedélyezem a megszakítást, az adáshoz viszont nem. A PIC egyszerűen visszaküldi a vett adatokat, tehát egyelőre semmi ördöngősséget nem csinál. A kommunikáció kezdetekor, amikor a PC felől elküldök egy karaktert, a megszakítás megtörténik, viszont az kétszer is egymás után, pedig karaktert csak egyet küldök. Az első megszakításnál kiolvasva az U1RXREG regisztert 0x00- val tér vissza, a második megszakításnál (csak egy karakter volt elküldve) már a helyes értéket olvasom ki a vételi regiszterből. Ha a megszakítás rutinban vizsgálom, hogy az U1STA regiszter URXDA bitje 1-be billent-e, akkor csak a második megszakításnál olvasom ki az U1RXREG tartalmát, amelyben a helyes karakter van. Mindez csak a legelső vett karakternél van így, a többinél már normálisan működik. Ez így nekem jó is lenne, hiszen úgy tűnik sikeresen megoldható a probléma. De... A fő gond, hogy én DMA- val szeretném használni az UART-ot, ott pedig sajnos nincs lehetőség figyelni az URXDA bitet. Természetesen a DMA esetén is ugyanígy történik, az első karakter, amelyet a DMARAM-ban elhelyezkedő puffer tartalmaz a 0x00. A többi rendesen megérkezik és a későbbiekben is a helyes adatok szerepelnek a pufferben. Végülis oly módon meg tudtam oldani a dolgot, hogy az UART egység konfigurálásánál kezdetben engedélyezem a belső LOOPBACK-et, ezután elküldök a kontrollerrel egy "dummy" karaktert, visszaállítom a modult normál módba (loopback kikapcsol), majd ezután engedélyezem a DMA csatornát is. Ezzel a dolog működik is, minden adatátvitel megfelelően végbemegy. A probléma itt az, hogy a LOOPBACK csak a PIC RX-t választja le a kontroller lábáról, a TX-t nem, így elküldésre kerül a dummy karakter is. Természetesen a későbbiekben a PC-n futó kliens le tudná ezt kezelni, tehát nem értelmezné a dummy karaktert, csak picit piszkálja a csőröm, hogy ez így eléggé "fapados". Ha esetleg valakinek lenne ötlete egy szebb, jobb megoldásra, az kérem ne tartsa magában! Előre is köszönöm a hozzászólásokat és elnézést a regényért. (Fejlesztői környezet: MPLAB X 6.0; Fordító: MPLAB C30 3.25)
Hogy csinálod az inicializálást? Célszerű egy letiltással kezdeni, az esetleges hibabit beállások törlése érdekében.
Ha jól látom, a PIC-kwik projektben gyakorlatilag csak az UARTEN bitet állítjuk vissza 1-re (feltéve, ha BRGH=0 megfelel). A megszakításban először a hibabiteket ellenőrizzük (PERR, FERR, OERR), s csak akkor használjuk fel a kiolvasott karaktert, ha minden rendben volt. Az Errata szerint a hibainterrupt nem megbízható, gondolom ezért kell a hibabiteket külön vizsgálni. DMA-val nem foglalkoztam, nem is tudom, hogy ott a fentihez hasonló hibavizsgálat hogyan oldható meg.
Letiltással kezdek én is, de csak utána inicializálok. Én nem ellenőrzöm a hibabiteket, ezt majd ki fogom próbálni. Így igaz, én is olvastam, hogy a hibákhoz tartozó megszakítás nem mindig megbízható. DMA esetén nem találtam utalást arra, hogy a hardver közvetlenül vizsgálná a hibabiteket. Azt tudnám elképzelni, hogy DMA mellett engedélyezem a vételi interruptot is és abban ellenőrzöm a hibabiteket, csak így megint ott tartok, ahol a part szakad. Pont azt szeretném elkerülni, hogy karakterenként megszakítás legyen. Mindenesetre köszönöm a válaszod, később még próbálkozom a dologgal.
Üdv.!
Ha van egy PIC-es készülékem, ami RS232-n kommunikál a PC-vel, lehet olyat csinálni, hogy számítógép nélkül az adatokat egy webes felületre tölti fel, így bárhonnan elérhetem? Mert egy állandó üzemű számítógép elég energiaigényes.
Szia!
Egy Ethernet illesztős pic és sok programfejlesztés... Vannak kész eszközök: RS232 - Ethernet illesztők. pl: Moxa, Lantronix, stb.
Sziasztok,
Hogy lehet megoldani PIC18F14K22 és PIC24HJ64GP202 -nél hogy ne tudják kiolvasni (kilopni) a PIC-ből a programot? Mit kell beállítani? Azért kérdezem, mert nem szeretném lezárni úgy a PIC-ket, hogy utána ne lehessen újra programozni.
En hasznaltam ezt a panelt ,ill az elodjet. A MikroE ad hozza mintaalkalmazast is. Nekem 16F887 procival ment lokalis halozaton. A konyvespolcon talalhato 40-pin demo panelt csinaltam erre a projectre. A mukodes a potik leolvasasa, a kapcsolok lekerdezese, valamint a LED-ek vezerlese volt LAN-on keresztul. Az eredeti MikroC mintapeldat alakitottam at egy kicsit, es mukodott szepen. A projekt egy egyetemi demo-nak keszult.
A konfigurációs biteknél a kódvédelmet kell bekapcsolni. A kódvédelem utána csak a PIC törlésével szüntethető meg, de újraprogramozható, tehát nem kell aggódnod.
Közben rájöttem és egy dugdosós próbapanelon kipróbáltam egy másik 14K22 PIC.kel.
__CONFIG _CONFIG5L, _CP0_ON_5L & _CP1_ON_5L __CONFIG _CONFIG5H, _CPB_ON_5H & _CPD_ON_5H __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H __CONFIG _CONFIG7L, _EBTR0_ON_7L & _EBTR1_ON_7L __CONFIG _CONFIG7H, _EBTRB_ON_7H köszi
Na a végén csak sikerült megoldani a problémát, most már rendesen működik DMA-val, meg anélkül is. Úgy tűnik nem minden esetben megfelelőek a gyári függvények (OpenUART1(), CloseUART1()). Mellékletbe felteszem a kódot, hátha egyszer más is hasznát veszi. A működés röviden: A DMA 0 csatorna ping-pong módban, folyamatosan működik, ez a két vételi pufferbe helyezgeti a vett karaktereket (5 karakter után megszakítás). A DMA 1 csatorna One-Shot módban működik, ez mindig az aktuális vételi puffer másolatát visszaküldi. A timer csak egy LED villogtatását végzi.
Örülök, hogy működik! Az viszont nagyon nem tetszik, hogy a DMACS1bits.PPST0 bitet a főprogramban vizsgálod. Ennek a helye (a DMA buffer kiürítésével együtt) a DMA0 megszakítást kiszolgáló eljárásban volna.
Igen, a PPST0 bittel kapcsolatban teljesen igazad van, jelen alkalmazásban megfelelően működik, ha viszont a főprogram hosszabb ideig nem ér rá lekezelni, akkor már a másik puffer lesz kiválasztva. Nem terveztem, hogy sokáig így hagyom, csak elfelejtettem módosítani. A buffer másolással mondjuk már annyira nem értek egyet, de elképzelhető, hogy igazad van. Azért a főprogramban másolom át, mert nem akarok túl hosszú időtartamig a megszakításban maradni, az 5 karakter csak a próba kedvéért annyi, egyébként ennél több lesz. Véleményem szerint akkor lenne jelentős probléma, ha nem lenne idő lekezelni a főprogramban addig, amíg a másik puffer megtelik. De ha esetleg tévednék, akkor légy szíves mond el, hogy miért helytelen ez a megoldás!
Idézet: Erre találták ki a több prioritási szintű megszakítást. „Azért a főprogramban másolom át, mert nem akarok túl hosszú időtartamig a megszakításban maradni” Idézet: De azt mikor és hogyan tudod ellenőrizni, hogy ez nem következik/következett be? „akkor lenne jelentős probléma, ha nem lenne idő lekezelni a főprogramban addig, amíg a másik puffer megtelik.”
Persze, a többszintű megszakítás megoldást jelentene, ekkor jól gondolom, hogy a nested interruptot is engedélyezni kellene? Azt természetesen nem tudom ellenőrizni, hogy a puffer is felülíródott-e, de abban az esetben, ha csak egy puffer van és annak tartalma még nem lett feldolgozva, akkor teljesen mindegy, hogy mikor másolom be a DMA-tól származó adatokat, ha nem tudom feldolgozni, akkor mindegy, hogy a megszakításban másolom bele a karaktereket, vagy a főprogramban. Ezt csak azért említem, mert nem pusztán az lesz a feladat, hogy a beérkezett karaktereket visszaküldözgessem. Na mindegy, ezt majd később még megálmodom, mindenesetre köszönöm az észrevételeidet!
Idézet: Igen. „Persze, a többszintű megszakítás megoldást jelentene, ekkor jól gondolom, hogy a nested interruptot is engedélyezni kellene?”
Igen láttam, de mint irtam nincs semmi gondom egyik telefonos riasztóval sem! Az kérdeztem hogy 2 db. pic-et hogyan lehet összekötni.
Sziasztok!
3,3V-os dspic-el kellene analog jelet mérnem, 5v-ig. Lehet e a referencia fesz 5V, vagy le kell osztanom a bejövő jelet? Esetleg műveleti erősítő? Köszi kszabi
Az adatlap miért nem egyértelmű?
Idézet: „Voltage on any combined analog and digital pin and MCLR, with respect to VSS ......................... -0.3V to (VDD + 0.3V)”
Két megoldás van: leosztás vagy 5V -os kontroller.
Ezt olvastátok már?
Bővebben: Link Ezek az új perifériák nagyon hasznosak, örülök hogy létezik már ilyen PIC. Kár hogy nem 18F-re vannak, de talán majd olyan is lesz. A CLC modulról itt egy videó: Bővebben: Link Ez tök jó! Bár igazából csak lespórolható vele 2-3 külső TTL IC. De a komplemens hullámforma generátor (CWG) és numerikusan vezérelt oszcillátor (NCO) meg aztán még jobb lehet. Bár nem értem még hogy pontosan mik is és hogyan működnek, de többször lett volna már szükségem könnyen, széles skálán és nagy felbontással beállítható, változtatható frekvenciára. Hát ha még a hullámformát is be lehet állítani... 
Csak óvatosan tervezni, bevásárolni. Egy 10F322 szimulációjában nem megy a megszakítás, és a portok állapotát sem látom rendesen. A szimulátor még beta és gyűlnek az erratak...
NCO : 20 bites akkumulátor és 16 bites növekmény, a kimeneti frekvencia max a bemenő/16 lehet. Best of Electronic Design 2011
Persze, nem is tervezem hogy veszek belőle egyenlőre. Egyszer már megjártam az új típusokkal.
Idézet: „a kimeneti frekvencia max a bemenő/16 lehet.” Úgy érted minimum?  És a bemenő/16 illetve a bemenő frekvencia közt 65536 lépésben lehet állítani? |
Bejelentkezés
Hirdetés |
